Category: фантастика

Category was added automatically. Read all entries about "фантастика".

2019

Наш способ ускорить разбирательство с непонятками в жизни: дать людям цивилизационные priors.

Основная гипотеза, которая сейчас отрабатывается в области AI -- это то, что интеллект получается за счёт очень простого алгоритма, который работает с огромными вычислениями по разбирательству с непонятками встреченных им ситуаций (тезис Sutton, http://incompleteideas.net/IncIdeas/BitterLesson.html). Чтобы уменьшить количество этих вычислений, алгоритм должен получить в свой состав какие-то удачные эволюционные находки по поводу структуры мира, innate priors, как их называли вначале, а потом и вовсе сократили до priors. Это то, что интеллекту известно о мире "из коробки", "по конструкции", до того, как его начали учить. Количество вычислений при правильно выбранных priors уменьшается в десятки тысяч раз.

Текущие алгоритмы глубокого обучения практически не содержат этих priors. Уж заведомо содержат их меньше, чем мозги ребёнка. Поэтому и работают медленно и плохо. Так что одно из направлений сегодняшних исследований -- снабдить эти алгоритмы хотя бы такими же priors, которые есть у новорождённых человеков, чтобы ускорить мышление этих алгоритмов. Интеллект ведь -- это прежде всего про скорость мышления, скорость научения решать проблемы в какой-то предметной области, разбираться с непонятками. François Chollet в https://arxiv.org/abs/1911.01547 предположил, какие там у ребёнка priors, и дал набор тестов, которые должны демонстрировать, что предлагаемые всё новые и новые алгоритмы AI быстро решают задачи, требующие этих priors -- в надежде на то, что такие алгоритмы будут учиться дальше не хуже алгоритма в дитячьем мозгу.

Ещё один способ тестировать эти priors -- давать компьютеру решать те задачи, с которыми хорошо справляется человек. Например, набор из 57 видеоигр Atari. Выяснилось, что большинство priors, с которыми работает интеллект ребёнка, касается умения распознавать объекты окружающего мира. И в алгоритм, который учится играть во все эти 57 игр сразу были добавлены эти человеческие priors. И алгоритм начал учиться играть во все эти игры (то есть научился справляться с новой проблемой, которой раньше ещё не видел, то есть проявлять силу своего интеллекта) за меньшее число проб и ошибок, чем человек. И работает этот алгоритм в 10тыс. раз (четыре порядка!) быстрее, чем алгоритм без priors. Вот эта работа: "Self-Supervised Object-Level Deep Reinforcement Learning", https://arxiv.org/abs/2003.01384. Авторы William Agnew и Pedro Domingos (тот самый, который написал The Master Algorithm) пишут: Current deep reinforcement learning approaches incorporate minimal prior knowledge about the environment, limiting computational and sample efficiency. We incorporate a few object-based priors that humans are known to use: "Infants divide perceptual arrays into units that move as connected wholes, that move separately from one another, that tend to maintain their size and shape over motion, and that tend to act upon each other only on contact" [Spelke]. We propose a probabilistic object-based model of environments and use human object priors to develop an efficient self-supervised algorithm for maximum likelihood estimation of the model parameters from observations and for inferring objects directly from the perceptual stream. We then use object features and incorporate object-contact priors to improve the sample efficiency our object-based RL agent.We evaluate our approach on a subset of the Atari benchmarks, and learn up to four orders of magnitude faster than the standard deep Q-learning network, rendering rapid desktop experiments in this domain feasible. To our knowledge, our system is the first to learn any Atari task in fewer environment interactions than humans.

Мы делаем тот же самый ход, который люди из AI делают со своими простыми алгоритмами. Они добавляют человечьи priors, чтобы их алгоритмы стали в десять тысяч раз быстрее. Мы берём простые алгоритмы мышления в мозгах обычных (и даже уже образованных!) людей и добавляем state-of-the-art цивилизационные priors, которые выработало коллективное человеческое мышление буквально только что, в 21 веке. Спецы по AI переносят priors из мозга человека в железку компьютера, а мы переносим priors из цивилизации -- в голову человека. Мы называем эти priors трансдисциплинами (ибо это "по ту сторону прикладных дисциплин", то, что относится к "общему интеллекту", "силе мозга", а не прикладным компетенциям). Про то, что интеллект это не про прикладные компетенции, а возможности по быстрому с ними разбирательству я писал в https://ailev.livejournal.com/1498481.html (там подробней про подход François Chollet в https://arxiv.org/abs/1911.01547).

Дальше я напишу то, что писал в разных местах уже много раз. Какие именно мы берём цивилизационные priors, то есть какие именно трансдисциплины мы берём для инсталлирования их в человечьи мозги, чтобы работа этих мозгов в новых предметных областях оказывалась быстрой (может и не в десять тысяч раз, но весьма и весьма ощутимо):
-- функционально-ориентированное сознание (это нижний уровень, практически мы тренируем priors, заложенные в мозг матерью-природой. Медленное мышление S2 по Канеману должно работать как часики. У кошечек его нет, а у людей есть -- но только тех, которые выросли не в лесу, выкормленные волками. Вот нам надо, чтобы человек в режиме медленного мышления и глубоких размышлений мог провести часы, а не секунды. Клиповое мышление, блуждающее внимание -- это зло. Понятийное мышление нужно тренировать, чтобы возможности именно человеческого мозга проявились). У нас нет курса на эту тему, но уже есть доклад, где такой курс как-то рассматривается как priors, необходимые для научения решать проблемы в онтологике и коммуникации: https://www.youtube.com/watch?v=8D8cfcJ20zI
-- онтологика и коммуникация. Это priors о том, что есть актуальный физический мир, но мы можем его очень по-разному описывать, добиваясь в этом мире каких-то своих целей. Есть агенты, их много, цели у них разные, они взаимодействуют и строят описания мира и себя (онтология), рассуждают про мир и достижения целей (логика), при этом ещё и общаясь с использованием кулаков или мирно (коммуникация). Описания могут быть более или менее правдоподобными (наука), а цели более или менее злобными по отношению к другим агентам (этика). Есть курс https://system-school.ru/united
-- системное мышление про то, что описания нужно делать на многих уровнях по отношению частей и целых, и есть очень важные описания (минимально: описание функциональности, конструктивного устройства, пространственного размещения, но это только начало), которые просто таки нужно сделать, чтобы достигнуть цели, понимаемой как успешно созданная система. Успешная -- это когда множество агентов, которым для чего-то эта система нужна, договорились. На эту тему есть онлайн-курс https://system-school.ru/sm2019, курс для школьников и студентов https://system-school.ru/intro, практикум https://system-school.ru/praktikum, вводный курс https://system-school.ru/base
-- вычислительное мышление про то, как работать со всеми этими моделями, чтобы рассуждать с их использованием. Ведь их могут интерпретировать как люди, так и компьютеры. Они могут быть изложены на самых разных языках, и они могут быть ещё и коннективистскими (те же нейросетевые модели). У нас нет пока на эту тему курса, есть только постановка задачи: https://ailev.livejournal.com/1477090.html

Если есть эти priors, то у вас уже более-менее налажено скоростное (а не медленное! в этом фишка!) мышление о чём угодно. Но можно ещё больше ускорить разбирательство с новыми практиками, если дать знания о том, как делаются проекты -- как в самых общих чертах устроена человеческая деятельность. Мы называем эти priors деятельностным кругозором (думаем о нём как прохождении трёхдневного курса по каждой перечисленной практике):
-- системная инженерия (разработка концепции использования, инженерия требований, инженерия системной архитектуры, управление конфигурацией и изменениями/жизненным циклом, проверка и приёмка). Курс у нас есть -- https://system-school.ru/engineering
-- системный менеджмент (операционный менеджмент/цепи поставок/логистика, управленческий учёт и контроллинг, инженерия предприятия и архитектура предприятия/технологический менеджмент, организационные изменения/развитие и системное лидерство) – это мой курс https://system-school.ru/sms
-- системное предпринимательство (стратегирование, продвижение продукта, корпоративные финансы, корпоративная поднадзорность/governance), курса пока нет, но стратегирование уже вошло в мой курс.
-- ... остальные сферы деятельности (политика и политэкономия, религия, искусство, наука, образование и просвещение, здравоохранение, спорт, право, армия, частная жизнь/семья). Из курсов тут у нас пока только курсы по личному развитию (как учиться эффективно https://system-school.ru/study, телесная инженерия https://system-school.ru/body и системный фитнес https://system-school.ru/move, а также временно прерванный в силу форс-мажора социальный мультиданс https://system-school.ru/multidance. Да, мультиданс делается тоже на основе трансдисциплины системного мышления, см. набор ссылок на посты об этом в https://vk.com/wall-179019873_624).

При этом мы понимаем, что вот так обученный самым крутым цивилизационным priors, то есть самым крутым трансдисциплинам человек живёт и работает обычно на в одиночку, поэтому наша картина мира более сложна. Текущий пост лишь раскрывает пункт второй "2. Для усиления интеллекта людей нужно:" поста "Дело спасения утопающих -- дело интеллекта самих утопающих" https://ailev.livejournal.com/1509601.html, используя идеи из тамошнего пункта первого "1. Интеллект как результат бесконечного развития (open endedness)". Хотя наши курсы системного фитнеса можно отнести и к пункту "5. Embodied intelligence", а в кругозоре по системному менеджменту и стратегированию я существенно раскрываю содержание пункта "4. Обеспечивать распределённое по людям и компьютерам мышление".

UPDATE: обсуждение в https://www.facebook.com/ailevenchuk/posts/10217996881727676 и https://freefeed.net/ailev/56441e78-c54f-41bc-9383-42fc842c27ed
2019

Целевая система и наша система

Основная трудность в определении целевой системы и нашей системы, как водится, не в собственно системном мышлении, а в онтологике: наличие двух классификаторов для одного объекта. Я вот могу быть одновременно лысым и тёплым, но всегда найдутся люди, которые будут искать два разных предмета -- один лысый, другой тёплый. Легко путать предметы и их свойства.

Понятие "нашей системы" (our system) было введено для личной ролевой (нашего "малого проекта" в составе большого командного проекта) фокусировки внимания — и "наша система" может совпадать или с какой-то системой в составе целевой системы (т.е. подсистемой), или с какой-то системой в обеспечении (их там тьма, в том числе они вытягиваются в цепочки обеспечения, где одна из систем обеспечения "изготавливает" (т.е. вносит изменения в) другую систему обеспечения. Если люди занимаются сервисом (изготовлением и наладкой в сервисе станочков/софта) или они менеджеры (их внимание на команде прежде всего), то их системы обычно -- системы в обеспечении, а целевые системы -- это уж как у всех, то что изготавливается самим сервисом или самой командой, и иногда через целую цепочку (моя система -- наладочная приспособа "обеспечения обеспечения", которой я налаживаю станок из обеспечения, который изготавливает деталь как подсистему целевого изделия).

Скажем, в парикмахерской делают причёски. И все радостно говорят, что это будут женские причёски высокой моды, обсуждают максимальную длину волос, количество лака для одной причёски и т.д.. И поручают кому-то из команды подхакать кресло по высоте, чтобы распущенная коса до попы не оказалась косой до пола. У этого кого-то целевая система по-прежнему будет причёска (целевая система команды), а его (личной) системой — кресло (причём brawnfield, подхакивание, а не изготовление с нуля). И это кресло явно в системе обеспечения, оно не участвует во времени эксплуатации причёски. И это подсистема в парикмахерской как системе обеспечения.

При этом подхакивателю кресла не удастся вести разговоры про своё кресло как целевую систему — у всех остальных же в головах причёска как цель. Но все признают, что это кресло — его система! Но дальше целевая система при обсуждении нашей системы остаётся крайне важна — все рассуждения про кресло потом должны дотягиваться до причёски как целевой системы, иначе кресло может получиться шикарным, а причёска никакой.

Системных разбиений (в старой терминологии — холархий) тем самым тоже множество: каждая система (целевая, наша, в окружении, в обеспечении, их подсистемы) имеет своё разбиение, и даже минимально три (функциональное, продуктное/конструктивное/модульное, размещения/мест/компоновочное). Целевая система имеет своё разбиение (она часть надсистемы, т.е. входит в разбиение окружения), каждая из систем в окружении своё, каждая из систем в обеспечении своё. И "наша система" тоже имеет своё разбиение, куда она входит как часть и куда входят её подсистемы. Подхакиваемое кресло имеет свои части и входит в парикмахерскую. И ещё в момент его эксплуатации в окружении кресла находятся в том числе и волосы клиентки, которые не должны достигать пола в распущенном состоянии.

Для чего всё это нужно? В среду у меня было очередное занятие со студентами МФТИ, и мы рисовали их целевые системы и цепочки обеспечения. И определяли их роль и их системы в проекте. Системное мышление это просто управление вниманием, чеклист того, о чём нужно подумать. После того, как определялась целевая система и цепочка обеспечения, каждому становилось в разы понятней его роль в проекте, чем занят сам проект, и как там всё устроено в этом клубке людей, идей, дел и оборудования, который и называют "проектом". Целевая система тут обычно самый неопределённый элемент, ибо часто команда переконцентрируется на какой-нибудь ключевой подсистеме, и внимание оказывается перекошенным. Скажем, нанотрубки никогда не продаются сами по себе, всегда в составе смеси. Целевые системы -- смеси с нанотрубками, а не сами нанотрубки, которые тут лишь подсистемы. И это существенно сдвигает фокус обсуждения, когда идёт разговор о проектах в такой компании. Вот, кстати, пример такого же сдвига у компании NVIDIA -- "NVIDIA is not a chip company, we are a computer architecture company, we are a software company. Поэтому объявление чипов будет теперь важным событием, но не запредельно важным: типа как объявление нового электродвигателя у автопроизводителей или как объявление нового авиадвигателя у производителей самолётов" (https://ailev.livejournal.com/1416697.html). Чипы перестали быть целевой системой в компании, их целевой системой стал набор самых разных других систем -- автомобильных компьютеров и софта, компьютеров и софта для обработки медицинских изображений. Но для кого-то в комании его система -- это таки чип GPU, а для кого-то подразделение компании NVIDIA (система в обеспечении целевой).

Каждый командный проект по факту состоит из более мелких проектов. И чтобы не запутаться в том, кто что для чего когда делает, нужно различать целевую систему для всех в большой команде проекта и нашу систему для нашей маленькой команды подпроекта (в том числе и для команды из себя, любимого). И признавать, что у кого-то в проекте тоже может быть его система. Вы легко договоритесь, если обе ваших системы будете делать с ориентацией на успех целевой системы. Или не договоритесь, если ваши деятельности в общем проекте непонятно как связаны. Поэтому используйте системное мышление для управления вниманием: своим, своей маленькой команды и всей команды проекта.

Если вы рисуете картинку с целевой системой и её окружением, с цепочкой обеспечения, то она рисуется одним цветом — командным. А потом другим личным цветом на диаграмме ставится крестик, отмечающий нашу систему. Только так. Командная система координат, потом личная отметка своего места в контексте командной работы. Потом только разбирательство, что там личного внутри -- сначала окружение, только потом что внутри.
2019

Киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием

Киборгизация идёт как для людей, так и для организаций:
-- cyborg = cybernetic organism -- оригинальное определение киборга как одного организма,
-- cyborg = cybernetic organization -- организация тоже киборг, и суть киборгизации остаётся та же: добавляем компьютеры, датчики, эффекторы.

Массово организационный киборг появился даже раньше организменного киборга: личные (personal) компьютеры, а потом и смартфоны распространились попозже, чем корпоративные компьютеры: большие оргзвенья-организации уже имели ресурсы для своей киборгизации, а люди ещё нет. Организация уже строила планы своей работы в программах проектного управления, а люди продолжали делать пометки в личных блокнотиках, что уже использование экзокортекса, но в разы менее эффективное, чем использование компьютера для этих целей.

Экзокортекс, экзотело – это и есть «кибер», при этом экзокортекс и экзотело отдельных личностей shared в рамках организации. Организация -- это про полномочия распределения ресурсов для достижения каких-то целей. Вот личные работающие на благо организационных целей мозг и тело, а заодно экзокортексы и экзотела этих личностей, тоже работающие на благо организационных целей в организации являются такими ресурсами. И ещё появляются коллективные экзокортексы (айтишная инфраструктура) и экзотела (здания, сооружения, инструменты и прочее оборудование, стремительно компьютеризирующиеся), они тоже работают на цели организации.

Тезис этого текста в в том, что киборгизация позволяет поднимать осознанность как личную, так и корпоративную. Записная книжка заменяет 10 лет ежедневной тренировки памяти человеку, а issue tracker заменяет 10 лет усилий налаживания сотрудничества для организации. Киборгизация сильней психопрактик, кофе сильней психопрактик. У нас технологическая, а не психотехническая цивилизация. Психотехники должны помогать прилаживаться к технологиям, цивилизационно сегодня они не самодостаточны, они были самодостаточны 2000 лет назад, но за время пути цивилизация смогла подрасти.

Поэтому психопрактики системной осознанности нужно подхакивать, чтобы учитывать киборгизацию: осознанность с компьютером существенно отличается от осознанности без компьютера, и это верно как для отдельных людей, так и для организаций.

Системная киберосознанность прежде всего -- это работа с (shared, к одним и тем же предметам, "синхронизированным") вниманием на отчуждённых от людей и тоже shared системных описаниях, работа с глубокими стеками абстракции этих описаний, удержание внимания на тех или иных ролевых описаниях (viewpoints). Отчуждённие от людей, задействование (личного и корпоративного) экзокортекса позволяет:
-- удерживать внимание в ходе личного и коллективного мышления на большем числе объектов (они не исчезают при неминуемых сбоях внимания личности и провале внимания коллектива): мышление с экзокортексом легко обрабатывать реально большие схемы и делает при этом мало ошибок
-- асинхронно мыслить в коллективе: подумал сам, передал товарищу. Никто никого не ждёт, не нужно находиться в очном диалоге и лично присутствовать или даже присутствовать онлайн. Даже диалоги по телефону уходит в асинхронность: замещаются чатами. И совещания (полилоги -- очные или по селектору) всевозрастающе заменяются чатами.
-- обсуждать с другими или компьютером на предмет обнаружения ошибок (экспликация и коммуникация объектов внимания) – и маленькие, и большие схемы. Сшивка больших схем вместе («интеграция»).
-- Делать перерывы для отдыха и отвлечений (не теряются результаты промежуточных рассуждений), выдерживать долгие размышления без «закрытия», в том числе «многопроходные» размышления, в том числе в масштабах организации.
-- Освобождать головы в организации для дополнительных рассуждений (например, «мета» о способах мышления, сторонние исследования и т.д. – более сложные траектории мышления), не теряя контекста и результатов предыдущих шагов размышления.

Ну, и плюс всё то, что дают возможность сделать организационные архивы: найти того, кто первым сказал "мяу" (наградить или наказать за это -- не ролевая, а должностная работа), отследить ошибку, которая была допущена раньше в коллективных или личных рассуждениях, вспомнить (в том числе "найти поиском") и сделать шаблоном (откопировать с частичными изменениями) старый кейс/проект для нового, и т.д.

И ещё что в личном бессознательном -- то для личности не существует, хотя и проявляет себя в поведении. А что у личности в сознании -- то в коллективном бессознательном, существует для личности, но не для организации, хотя и проявляется в поведении организации (личность-то своим поведением ещё как влияет на поведение организации!). А что у личности в shared экзокортексе -- то для коллективного сознания (сознания всех других членов организации) существует и влияние на поведение может быть учтено. Помним, что осознанность -- это присмотр/поднадзорность, соблюдение правил и достижение целей при этом более надёжны.

Организационная осознанность -- это надзор/присмотр за вниманием по shared схемам организации. То есть речь идёт о том, что находится в информационных системах организации. Конечно, в организации есть и часть shared tacit knowledge. Но легче работать с explicit knowledge в организационном экзокортексе, в информационных системах. Это полностью соответствует attention schema theory по вопросу того, как устроено сознание: в информационной системе компании находится упрощённая схема, организующая внимание. Так что путь развития организационной осознанности -- это развитие информационных систем компании прежде всего, улучшение её информационных моделей, а не попытки заставить людей удерживать системное целое на много-много уровней выше тех систем, с которыми работают отдельные люди в организации. Весь этот присмотр за вниманием многих тысяч людей, распределённым по многим и многим системным уровням объектов организации и её окружения, обеспечивают по сути не менеджеры, не сами люди, а информационные системы. Так что для поднятия организационной системной (для многих системных уровней) осознанности киборгизация идёт в два такта:
-- просто управлять данными, data management -- это делать данные/схемы доступными тем, кому надо и когда надо. Никакой обработки данных, чистая логистика. Записал, сохранил, проверил версию, воспроизвёл актуальное. Базы данных сами по себе благо, они удерживают внимание организации и организуют её память. Главный инструмент -- это моделер, редактор. Ничего страшного, если корпоративная информационная система ничего не считает, а просто хранилище структурированных и даже неструктурированных данных. Она крайне полезна! Она помогает присматривать за вниманием, бороться со сложностью самой организации и окружающего организацию мира.
-- и только вторым пунктом в киборгизации/информатизации тут творчество, принятие решений, искусственный интеллект или машинное обучение и т.д..

CAD, который только "моделер", сиречь "редактор", и который ничего не автоматизирует (по-английски сomputer-aided design, но по-русски это САПР, система автоматизированного проектирования) уже приносит пользу: помогает управлять вниманием, реализует экзокортекс проектировщика -- одного человека (проектирование-в-малом) или нескольких проектировщиков (проектирование-в-большом, https://ailev.livejournal.com/851977.html -- в том числе выход в системы систем). Сначала учётная система и управление изменениями, поддержание актуальной (хотя и заведомо упрощённой -- схема!) модели реальной жизни в личных корпоративных информационных системах. Потом "автоматизация".

При киборгизации, конечно, киборг будет делать совсем не то, что просто человек или организация-из-людей. Киборгизация это не автоматизация каких-то функций, это изменение функций. В этом плане киборгизация, конечно, ближе к "цифровой трансформации" по смыслу -- глубокое изменение практик персональной и организационной жизни. Персональные информационные системы (включая гугль для личного пользования) и корпоративные информационные системы (какой-нибудь тот же гугль, в котором ищешь что-то по работе). При этом мы уже знаем из GTD (Get Things Done, практик персональной продуктивности), что персональные планы и рабочие планы так просто не разделить, это бесполезно и непродуктивно. Мы одни и те же на работе и дома, на вечеринке и на совещании -- и времени у нас 24 часа в сутки, мозг один и тело одно. Киборгизация глубоко трансформирует и персональную жизнь, и корпоративную -- как только мы удерживаем внимание не на быстро меняющемся и зыбком содержании собственных мозгов и уж тем более мозгов соседа, а на чём-то письменном, документированном, находящемся в компьютере.

Уже с этого момента речь не идёт о том, что "что делал человек, будет делать машина" -- на этой стадии машина ничего ещё не делает, это большая электронная записная книжка с хорошим поиском по ней. Но люди с такой хорошей коллективной записной книжкой уже будут делать совсем другое, чем без этой книжки. Термин "трансформация" не так плох в этом плане, избавляет от заблуждений, что что-то там "автоматизируется". Хотя иллюзий про "автоматизацию" тоже ни у кого давно нет. Киборгизация, автоматизация, цифровая трансформация -- это одно и то же, синонимы, и применимы они как к персоналиям, так и к организациям.

Вторая серия этой трансформации начинается тогда, когда "поиск" в этом экзокортексе может найти что-то нетривиальное -- сам экзокортекс становится умным. В экзокортексе могут быть вычисления, компьютеры могут выдать какую-то мысль, в том числе и мысль творческую (порождающие/generative алгоритмы). Осознанность становится более сложно устроенной, но просто на кибер-часть придётся больше мозговой работы, только и всего. Присмотр за вниманием за результатами коллективного уже не только человеческого, но и бесчеловечного (sic!) мышления будет всё одно нужен, чтобы достигать каких-то целей. Чьих целей -- это отдельное обсуждение, тут тоже есть вопросы к этичности создания алгоритмов, которые управляют вниманием людей, привязывая это внимание к самим алгоритмам -- компьютерные игры, фейсбук и прочие алгоритмы ведь именно так работают. Экзокортекс, который садится паразитом на психику человека, используя особенности работы мокрой нейронной сетки, увеличивает своё использование ради проталкивания целей своих хозяев (а не целей пользующегося им человека) -- это ваша проблема, но решение проблемы хозяина такого алгоритма. А если это не фейсбук или игра, а корпоративный экзокортекс и слова звучат не про мозгового паразита, а "геймификация" (так же, как в корпоративном мире не любят слово "спам", а любят "холодные звонки" или "директ маркетинг")? Это по-прежнему ваша проблема, или вы готовы отдать психику хозяину компании с его алгоритмами управления вашим вниманием? Готовы быть батарейкой в "Матрице", за зарплату? Присмотр за вниманием со стороны технических систем вызывает сразу этические и даже политические вопросы.

Литература (все непонятные слова из текста разъясняются в литературе, а не в самом тексте. Как читают научные статьи? Читают статью, и если что непонятно, то читают первоисточники. Если что непонятно в первоисточниках, то читают литературу к этим первоисточникам. И так дальше, пока не будет понятно всё. Для первого знакомства с предметной областью текста это может занять некоторое время. Если литература/первоисточники уже читаны, то тогда и сам текст должен быть понятен):
-- интернет вещей. Интернет клеток. Интернет программы -- https://ailev.livejournal.com/810255.html (киборгизация приходит оттуда, откуда её не ждут: на системных уровнях выше человека, на системных уровнях ниже человека).
-- Теория сознания как схемы внимания -- attention schema theory -- https://ailev.livejournal.com/1193568.html (и там в том числе про важность темы внимания для representation learning/deep learning). По сути, мы говорим в данном тексте о внимании в организации.
-- Тема психопрактик движения по спектру формальности -- https://ailev.livejournal.com/1461939.html
-- киберосознанность must, киберпсихика rulez -- https://openmeta.livejournal.com/237056.html
-- когда целевая система -- (кибер)люди -- https://ailev.livejournal.com/1459254.html
-- Системная осознанность, 2019 -- https://ailev.livejournal.com/1487672.html
-- Птолемеевская модель человека -- https://ailev.livejournal.com/1390574.html
-- Оргроли нескольких организованных (с известными полномочиями по распоряжению трудом и ресурсами) оргзвеньев и оргзвенья из нескольких оргзвеньев: https://ailev.livejournal.com/1487927.html (унификация рассмотрения людей и их организаций)
-- кофейный нейронет: https://www.facebook.com/groups/nevronet/permalink/1061187754047545/ (употребление кофе до выполнения задачи улучшало оценки работоспособности коллектива в 1,4 раза по сравнению с контрольной группой).
-- Мойдодыр и политическая философия интернет-вещизма, https://ailev.livejournal.com/1106188.html (кому принадлежат программные системы, которые могут влиять на нашу жизнь? Нам? Корпорациям? Госчиновникам?)
-- ссылки на несколько работ о путях эволюции цивилизации, в которой алгоритмы управляют вниманием людей: https://www.facebook.com/groups/nevronet/permalink/1314884872011164/.

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/groups/blended.learning.russia/permalink/2415362628706272/
2011

Онтика онтологизации

В данном тексте я хочу уточнить концепты онтологизации (предметная область, онтика, дисциплина, онтология, описание), чтобы потом как-то соотнести с онтологизацией определение и описание системы (метод описания/viewpoint, интерес/concern, частное описание/view, модель и т.д.). Это я делаю для прояснения связей между материалом курсов системного мышления (его онтика тут: http://ailev.livejournal.com/1278600.html) и онтологики (онтика тут: https://thpectrum.livejournal.com/8785.html), а также продвигая обсуждение проблем, поднятых в "концептуализации и возможных мирах: что там с терминами" -- https://thpectrum.livejournal.com/9845.html.

DISCLAIMER: не нужно считать, что данный текст даёт какой-то глоссарий и понятия тут задаются их определениями. Нет, в тексте не приводятся определения, хотя некоторые места в нём и выглядят похоже на эти определения. "Определения это гробик для умершей мысли" (с), разъяснения см. в тексте "Об определения системного подхода и системность определений", https://ailev.livejournal.com/1365963.html. Ну, и не считайте, что текст будет понятен неподготовленному читателю (например, тому, что не читал BORO book и мой учебник "Системное мышление").

Пространство смыслов
Мышление человека (и машин) основано на концептуальном пространстве -- многомерном пространстве смыслов. Это vector space, latent space, feature space и прочие пространства для презентации/representations из representations learning, частью которого является deep learning -- https://ailev.livejournal.com/1045081.html. В лингвистике говорят о conceptual spaces -- см.книгу "The Geometry of Meaning: Semantics Based on Conceptual Spaces", Peter Gärdenfors, http://b-ok.org/book/2514718/f34e5e.

В этом многомерном пространстве можно выделить области, репрезентируемые разными знаками, обозначающими предметы из предметных областей (domains). Мы считаем, что все рассуждения в конечном итоге опираются на наши представления о предметах физического мира и их взаимодействии, хотя они и абстрагируются потом на много уровней абстракции. Но это абстрагирование всегда рассуждений о физическом мире, мы не отрываемся от реальности. Подробности -- см. книжку про 4D экстенсионализм: Chris Partridge "Business Objects: Re-Engineering for Re-Use" (BORO book), 2000г., (http://www.brunel.ac.uk/%7Ecssrcsp/BusObj.pdf). Эта книжка выросла из длинного ряда философско-логических традиций https://ailev.livejournal.com/952930.html.

Эти означенные (т.е.помеченные знаками) области являются значениями (думайте тут о словарных "значениях", не слишком привязанных к ситуациям), они изучаются семантикой и статичны, берутся из культуры (заданы множеством употреблений разными деятелями, "среднестатистичны"). Значения тем самым уже даны ещё "до опыта" конкретной деятельности. Эти значения затем в ходе деятельности и размышлений используются как priors, постепенно уточняемыми деятелями/agents путём экспериментов и размышлений с учётом конкретной ситуации ("онтологии и бибинарная модель мышления", https://ailev.livejournal.com/1305176.html).

Какое-то место в пространстве смыслов называют концептом (concept, иногда понятие). Есть множество разных вариантов определения концептов, из которых самый популярный на сегодня и принятый у нас в курсе по умолчанию -- теория теорий/theory-theories (https://plato.stanford.edu/entries/concepts/, http://www.iep.utm.edu/concepts/).

Концептуальные представления о части мира (предметной области/domain), выраженные как какая-то структура в пространстве смыслов мы будем называть онтиками. Нюансы различений относящихся приблизительно к одному и тому же месту пространства онтик можно обсудить потом: для одной и той же части пространства смыслов можно обычно предложить множество вариантов структуры, множество онтик.

Мы будем обозначать области этого пространства терминами из разных дисциплин, показывая что они относятся с разной степенью вероятности к примерно одной области пространства, указывая их через слеш: например, логическое рассуждение/вывод/inference. Не то чтобы это всё были синонимы (лингвистическое отношение тождества терминов), но мы понимаем это просто метки/знаки/символы/теги, обозначающие одни и те же области пространства смыслов с какой-то степенью неформальности.

Если мы указали ряд терминов разных дисциплин через слеш, то это не обязательно точное совпадение помечаемых ими разных областей пространства смысла, это означает просто некоторое перекрытие этих областей пространства. Это перекрытие в свою очередь трудно определить, потоку как границы этих областей пространства не резкие, а размытые -- речь идёт о плотностях вероятности выражения какого-то смысла (точки в пространстве смыслов) термином. Особенно чётко нужно понимать, что в каждой конкретной ситуации значение термина как priors уточняется, и обозначаемый этим термином смысл как точка пространства смыслов чуть-чуть меняется, уточняется с каждым тактом рассуждений.

Онтики существуют в головах людей и компьютеров как коннективистские модели. Если речь идёт о выражении онтик в виде, в котором их можно обсуждать и делать какие-то операции над ними, то нужно говорить о рабочих продуктах -- онтических описаниях (descriptions), выражаемых знаками на каких-то носителях.

Чтобы меньше путаться с похожими словами, выбранными как термины разными авторами, пытающимися рассказать о своих дисциплинах, мы будем уточнять, из какого пространства имён (namespace) концептов взят тот или иной термин. Уточнения пространства имён мы будем давать префиксами имён авторов (например, авторов книг, откуда взят термин, или автора словарного определения) или названий дисциплин через знак :: и для наших собственных предпочитаемых значений будем указывать префикс пространства имён sys (от system). Например, Gruber::ontology/sys::discipline означает, что речь идёт примерно об одном и том же. Ровно как Kossiakoff::компонента/Clements::модуль.

Спектр формальности мышления и онтологизация
Мы принимаем существование спектра формальности мышления ("спектр мышления по одной дисциплине" из https://ailev.livejournal.com/1425003.html). Неформальность задания онтики обычно означает, что помечаемая термином область пространства смыслов довольно велика, а связи между областями пространства смысла определены не слишком точно. Возможно, в этой области другие онтики будут различать десяток разных подобластей, обозначаемых другими терминами. Возможно, что эта же онтика потом будет определена более формально: распределение вероятностей отнесения разных точек пространства смысла к концептам онтики станет много уже, и рассуждения станут однозначнее.

Онтологизация (ontology engineering/conceptual modeling/domain modeling) является практикой по повышению уровня формальности/строгости концептуальных представлений о мире. Обычно исследования (research, "наука"), в которых пытаются выяснить, как именно устроен мир, не относят к онтологизации. Онтологизация обычно -- это оформление результатов исследования в такой форме, в которых этими результатами можно с кем-то поделиться. Скажем, есть какие-то интуитивные догадки про устройства мира, невыразимые никак ("мысль изречённая есть ложь", "дао, высказанное словами -- это ненастоящее дао" и т.д.). Приведение этих "невыразимых никак догадок/инсайтов" в выразимую как-то вовне форму (оформление, формализация) и есть онтологизация. В ходе её определяют концепты как места в пространстве смыслов и дают этим концептам имена-термины.

Мы говорим, что онтика определяет (define) свою предметную область. Концепты онтики фокусируют внимание на какой-то части мира: онтика содержит концепты, позволяющие отобрать из мира те предметы и их взаимодействия, которые обозначены концептами онтики -- и тем самым онтика задаёт предметную область, вырезая её лучом внимания из всего становящимся при этом фоном мира. Онтика определяет (define) те предметы мира, которые присутствуют в нашем мышлении -- то, на что направлено наше внимание. Остальное -- фон, хаос, находящийся далеко влево по уровню формальности в спектре мышления.

Когда в ходе онтологизации для определения мира из хаоса и рассеянного внимания появляются концепты и обозначающие их слова-термины, определяющие предметы (появляется определение/definition этих предметов), мы называем это опредмечиванием. А когда мы уходим от концептуальных/знаковых представлений 1:1 (один предмет -- один коцепт), пытаясь определять предметы пространными описаниями из многих концептов или непосредственным указанием в реальном мире -- это будем называть распредмечиванием.

Результат практики онтологизации -- это всегда движение от неформальности и хаоса к строгости и порядку математического формализма, всегда максимальное опредмечивание. Н в ходе самой онтологизации может быть множество самых разных операций по формализации/деформализации множества онтик, шагов опредмечивания и распредмечивания ("откуда берутся полезные дисциплины" и "откуда берутся полезные мировоззрения" из https://ailev.livejournal.com/1425003.html).

Кроме связанных с приписыванием каким-то чётким местам в пространстве смыслов меток/концептов, чтобы к ним было легко обращаться, в онтологизацию входит и структурирование пространства смыслов на части: составление из мелких частей этого пространства каких-то бОльших частей, обозначающих тем самым бОльшее число предметов мира означает абстрагирование/обобщение, а деление больших областей-концептов этого пространства на отдельные части-концепты, указывающие более специфично какие-то конкретные предметы мира, называется конкретизацией/специализацией.

Схемы, схемоиды и их разворачивание
Формальное описание структуры онтики (какие в ней концепты и какие связи этих концептов), сделанное по мотивам "теории теорий", обычно называют концептуальной схемой (https://ru.wikipedia.org/wiki/Концептуальная_схема), менее формальное -- схемоидом (как "гуманоид" -- "не человек, но на человека похож", так и тут "не схема, но на схему похож"). Схема или схемоид могут быть выражены и графической схемой, но это совершенно необязательно -- схемы часто представляются текстами (на этот счёт есть большая дискуссия о "визуальном мышлении", см литературу в https://ailev.livejournal.com/1418832.html). Перевод графического (часто очень краткого и неполного) изображения схемы в текстовую форму на естественном языке с прописыванием в том числе и производных (опосредованных какими-то элементами или даже определяемых в других схемах) отношений между элементами схемы называется разворачиванием схемы. Чаще разворачивают даже не схемы, а схемоиды -- и в ходе разворачивания пытаются делать дополнительный шаг по формализации.

Можно считать, что данный текст представляет собой разворачивание схемы онтологизации (несмотря на то, что графическое изображение этой схемы опущено -- но легко его представить). В даном тексте, равно как и других текстах по системному мышлению и онтологике мы не претендуем на формальность и строгость предлагаемых концептуальных схем, а ограничиваемся схемоидами и их разворачиванием: мы стараемся работать в комфортной для человека зоне, где рассуждения не слишком трудоёмки, громоздки и узкоприменимы, как в случае жёстких формализаций (даже самые умные люди явно не калькуляторы), но и не в зоне произвольных фантазий, где любое слово может означать всё что угодно, и вероятность ошибочных выводов велика (поэтам нельзя доверять строительство мостов и запуск ракет).

Иногда мы будем называть формализацию деформализацию онтик движением по спектру мышления вправо и влево соответственно. Почему нельзя говорить просто о формализации и деформализации, но нужно вводить понятие спектра формальности мышления? Потому что нас интересует не только текущее положение той или иной онтики на спектре, т.е. уровень формальности/строгости онтики. Нас ещё интересует и диапазон мышления -- т.е. диапазон, в котором мы можем представить какую-то онтику для того, чтобы размышлять о её предметной области. Ибо кроме онтологизации (получения онтики) нас интересуют полезные рассуждения/логический вывод/inference с полученными в ходе онтологизации онтиками: этот вывод может делаться с разной степенью уверенности в верности результата на разных участках спектра мышления, а то и затрагивать целый диапазон формальности концептуальных представлений -- и схемоиды, и схемы.

В онтологизацию кроме формализации/деформализации (выражения схемами и схемоидами), обобщения/специализации (работы с уровнями абстракции от реальности) онтик могут входить и иные типы работы -- слияние нескольких онтик в одну, терминологическая работа по подбору точных слов для выражения содержания онтик, иногда включают работы по верификации и валидации онтик (проверки того, насколько соотносятся с реальностью рассуждения, сделанные по этим онтикам) и т.п..

Мышление и коммуникация
Онтологизация (получение более-менее формально определённых priors для смыслов) и рассуждения по результирующим онтикам с уточнением этих priors какими-то свидетельствами из предметной области вместе по большому счёту и представляют собой основные практики мышления, с тем уточнением, что эти практики выполняются а) коллективно и б) с участием экзокортекса (сначала памяти в виде записей, а сегодня и компьютеров, берущих на себя какую-то часть и онтологизации, и рассуждений).

Тем самым мышление никогда не ассоциируется с мышлением одного человека или одного компьютера, в мышлении нет птолемеевских моделей человека (https://ailev.livejournal.com/1390574.html). С мышлением нужно разбираться не в ситуациях "я сижу и размышляю", а в ситуациях совместного действия.

Тем самым мышление (и онтологизация, и рассуждения) оказываются тесно связанными с коммуникацией: передачей онтик от одних людей и компьютеров другим. Результатом коммуникации является то, что пространство смыслов у участников коммуникации (людей и компьютеров) оказывается размечено концептами примерно одинаково, в этом случае говорится, что участники коммуникации разделяют (share) онтики, т.е. примерно одинаково понимают схемы и схемоиды, по которым идёт мышление -- и дальше можно как-то надеяться, что результаты рассуждений на основе этой разметки тоже будут одинаковыми или хотя бы совместимыми и взаимно понимаемыми участниками мышления.

Коммуникация тесно связана с онтологизацией: чем хуже выполнена онтологизация, тем хуже организована коммуникация. Если чушь неудобно писать, то её всегда можно нарисовать. Если неудобно говорить, то её всегда можно спеть (и даже станцевать). Но тем и отличаются художественные произведения, что они очень плохо передают смыслы: для качественной передачи смысла нужно использование схем и схемоидов, то есть должна быть выполнена онтологизация -- и чем лучше она выполнена, тем короче может быть передаваемая информация без потери смысла. Онтологизация представляет собой сжатие информации о предметной области, оставление во внимании только важного для какого-то дела и игнорирование неважного (подробней см. "Жми, господь!", https://ailev.livejournal.com/1414038.html).

Дисциплины
Онтики бывают самые разные -- и разные виды онтик (ontic kinds) имеют свои названия, концепты для этих видов онтик занимают какие-то подчасти в общей для всех онтик части пространства смысла (границы этих частей и подчастей вероятностны! Это не чёткие дискретные границы!). Когда говорится об онтике, то не делается никаких предположений о каких-то её свойствах: в общем случае, рассуждения/выводы/inferences по онтике могут приводить к противоречиям, а могут и не приводить, она может относиться к предметам и взаимодействиям в небольшой части мира (domain, предметная область), но этим domain может быть и вся вселенная.

Микротеория (microtheory, http://www.cyc.com/wp-content/uploads/2015/07/Microtheories.pdf) или часто просто теория -- это онтика, по которой возможны более-менее формальные, непротиворечивые рассуждения в рамках какой-то строгой (по схеме и математически однозначно определённым правилам) или менее строгой (по схемоиду и правилам, определённым не столь однозначно) логики. Вампиры не существуют в научной микротеории/теории, а в микротеории/теории городских легенд они вполне существуют. Никаких противоречий в понимании высказывания "Граф Дракула -- вампир" (пример Дугласа Лената): в одной микротеории оно неверно, в другой верно, а две микротеории вместе не применяются.

Дисциплина (учебная, научная, инженерная, менеджерская и т.д.) -- это микротеория, которая рассматривается как онтика какой-то предметной области и связанные с ней мышление и коммуникация, которым можно/нужно кого-то научить для адекватного моделирования мира в рамках какой-то практики/целенаправленной деятельности по изменению мира. Всё мышление оказывается тесно связанным с понятием деятельности, но мы в данном тексте этого вопроса не будем касаться (при этом помним про посылку открытого мира: что не сказано, то просто ещё не сказано, просто не успели рассказать -- https://en.wikipedia.org/wiki/Open-world_assumption).

Ещё дисциплина эта такая онтика, которая содержит классы и классификаторы, но не индивиды. Дисциплины, изучающие конкретные места в пространстве-времени, не существуют -- они всегда про обобщение, они работают с типами, а не с отдельными объектами (и отдельные примеры типа "географии", изучающие конкретно Землю, на поверку тоже оказываются изучением не отдельных объектов на Земле, а вполне себе типов объектов. Да и по мере появления в предметах изучения других планет эта специфика пропадает. И даже в "геометрии" уже нет специфики именно "землемерия").

Поскольку дисциплинам обучают, то появляется социальный критерий признания онтики дисциплиной: дисциплины разделяются (shared) группами людей. Это в какой-то мере соответствует дополнению, принимаемому в определении онтологии по Gruber: Gruber::онтологией/sys::дисциплиной называется не любая формальная концептуализация мира, а shared (”An ontology is a formal specification of a shared conceptualization”, Tom Gruber -- http://tomgruber.org/writing/ontology-definition-2007.htm). Конечно, sys::дисциплина может определяться как формальной схемой, так и схемоидом: никаких замечаний по формальности определения дисциплины не делается.

Если говорят, что предметная область (domain, буквально набор предметов мира) определяется своей дисциплиной (всё верно: дисциплина ведь онтика!), то часто эту дисциплину называют "учебным предметом", хотя правильней было бы "дисциплина, определяющая предметы". Подробней см. метонимию, в онтологизации это главный источник путаницы -- https://ru.wikipedia.org/wiki/Метонимия. Ещё один пример метонимии: онтику, определяющую какой-то предмет в предметной области, называют определением (definition) этого предмета (а не "онтикой, определяющей этот предмет" -- онтика называется по имени связи, соединяющей онтику и объект).

Разные люди воспринимают в мире одни и те же предметы (буквально: они видят/слышат/ощущают одни и те же 4D индивиды, как-то выделяемые ими из фона -- нейронные сетки людей, несущие в себе ту или иную дисциплину, обращают внимание людей на предметы и их взаимодействия, определяемые концептами и связями соответствующей дисциплины. Но, конечно, это восприятие вероятностное -- речь не идёт о полном совпадении восприятий).

Конечно, нас больше всего интересуют не просто онтики или даже микротеории, свежепридуманные отдельными людьми, но дисциплины, которые достаточно удачны, чтобы ими пользовались целые группы людей для моделирования мира при осуществлении своей деятельности. "Проектное управление", "системное мышление", "управленческий учёт" -- нас интересует прежде всего это. Дисциплины входят в практики наряду с инструментами для поддержки этих дисциплин. Люди давно уже не работают руками, они в своей деятельности/практике обязательно используют дисциплину в голове и развёрнутые в физическом мире инструменты -- и осознанно меняют предметы мира и взаимодействия этих предметов.

Онтологии
Онтологией (ontology) называется разделяемый (shared) многими разумными существами или веществами (agents) набор микротеорий, который имеет правила по проведению в них непротиворечивых рассуждений. Онтологии выявляются (discover, о них избегают говорить "разрабатываются", ибо их не "придумывают" и затем "пропагандируют", чтобы они стали shared) для того, чтобы обеспечить максимально общие priors, применимые для старта мышления в максимальном числе ситуаций -- сама цель получения в ходе онтологизации не просто онтики, а онтологии -- максимизация числа ситуаций и максимизация числа предметов мира в онтологии. В пределе: все предметы всего окружающего мира и все рассуждения о мире, хотя это принципиально недостижимо. Максимально общие priors нужны для того, чтобы максимально непротиворечивое рассуждение разных людей могло проходить через объекты нескольких разных дисциплин, быть "междисциплинарным" и требовать как можно меньше выходов в реальность для свидетельствования о безошибочности своих выводов.

Выходя в социальную плоскость -- онтология это множество дисциплин и правила проведения непротиворечивых междисциплинарных рассуждений, объединяющих предметное/дисциплинарное мышление различных людей в одно коллективное мышление. Онтика онтологики (сокращённое обозначение общей дисциплины для онтологии как дисциплины, изущающей имеющиеся в мире предметы и логики, как изучающей правильные рассуждения, https://thpectrum.livejournal.com/8785.html) и онтика системного подхода (набор концептов и правил рассуждения с ними, дающими способ борьбы с мыслительной сложностью ситуаций по изменению мира -- http://ailev.livejournal.com/1278600.html) как раз дают системную онтологию.

В основе системного подхода лежит 4D экстенсиональная онтология, в которой все предметы/объекты мира делятся на индивиды (имеющие экстент/занимаемый объём пространства-времени в физическом мире), и абстрактные объекты (не занимающие экстента, чисто мыслительные конструкции): классы/типы (множества индивидов) и классификаторы (классы классов). Подробней см. уже упомянутую выше BORO book.

Абстрактные объекты-определения (definitions) в мире представляются их описаниями (descriptions), которые могут быть найдены в мире как рабочие продукты-индивиды (work products). Например, определение системы представляется описанием системы, онтология -- онтологическим описанием, а дисциплина -- описанием в рабочих продуктах-учебниках.

Проблема возникает тогда, когда в мышлении начинают работать с концептами, которые плохо онтологизируются. Например, понятие модели из по сути стандарта структурирования системных описаний ISO 42010 (https://en.wikipedia.org/wiki/ISO/IEC_42010): "M is a model of S if M can be used to answer questions about S. This statement has two important consequences: (1) Every model has a subject. (2) A model can be anything: (i) a model can be a concept (a “mental model”); or (ii) a model can be a work product.". Модель тем самым может быть с какой-то вероятностью онтикой-абстрактным объектом, а с какой-то вероятностью физической моделью-индивидом.

Ровно такое же затруднение происходит в понятием альфы (alpha) из OMG Essence (http://www.omg.org/spec/Essence/): альфы определения и воплощения системы имеют разный статус присутствия в мире -- определение системы абстрактно, воплощение системы имеет экстент.

В какой-то мере понятие "практики" тоже плохо онтологизируется: в его состав входит и "дисциплина" (онтика, абстрактный объект), и инструменты (рабочие продукты, индивиды).

С этой ситуацией "теория теорий" плохо работает, но неплохо справляются другие теории концептов (теория прототипов, например). Но в случае теории прототипов и других альтернативных теорий концептов очень тяжело становится с непротиворечивой и ясной логикой и правильными рассуждениями.

Интересным ходом тут является то, что определения понимаются как части мозга/вычислительной системы, реализующей мышление с этими определениями -- и тем самым про абстрактные объекты становится возможно рассуждать так же, как про индивиды. Но этот мыслительный ход не всегда оказывается успешен, хотя и помогает в некоторых ситуациях.

В общем случае, противоречий стараются избегать и как-то их преодолевать (про это см. "творчество в системном мышлении", https://ailev.livejournal.com/1425331.html), но для многих классов задач можно существенно сдвинуться от жёстких формализов к мене формальным представлениям, представить классы, включающие и абстрактные объекты, и индивиды -- и проводить далее рассуждения с такими понятиями, помня обо всех возможных проблемах. "Можно делать всё, если понимаешь, что делаешь, и каковы последствия в данной ситуации" -- совершенно необязательно поддерживать общность мышления для всех ситуаций в мире, которые были, есть и будут в будущем, можно ограничиваться каждый раз качественным мышлением для какого-то класса ситуаций.

Ещё про онтологии нужно всегда помнить: в литературе онтология очень часто это синоним онтики, а ещё очень часто онтологией называют онтологическое описание. Так что при встрече слова "онтология" нужно всегда пытаться понять, что имеет ввиду собеседник.
* * *
Следующий текст будет обсуждать онтику системных описаний (stakeholder, actor, concern, viewpoint, view, model, system и т.п.) в контексте онтики онтологизации из данного текста. UPDATE: вот продолжение -- https://ailev.livejournal.com/1429330.html
2019

Компоненты, модули и путающие их проектные менеджеры

Пару недель вокруг меня сплошняком идут путанные разговоры, порождаемые неразличением модулей (конструктивных единиц) и компонент (функциональных единиц). Идёт ли речь о каталогах (в которых пытаются обнаружить компоненты), функциональных классификаторах (в которых неожиданно оказываются закодированы модули), обнаруживаются ли два разных по структуре классификатора (компонент и модулей), и люди начинают настаивать, чтобы остался только один -- ситуаций было много.

Такое впечатление, что различию компонент и модулей никто напрямую не учит, и люди бьются об это место головой массово. У меня-то это в курсе есть, в учебниках есть (например, в http://techinvestlab.ru/systems_engineering_thinking/), разъясняется в куче стандартов (например, ISO 81346), но никто этого не читает! В последних версиях курса я удвоил количество материала про компоненты/функции и модули/конструкцию (даже по сравнению с версией http://system-school.ru/wp-content/uploads/2016/11/system_thinking_11nov2016.pdf): материал важный, он не должен пройти мимо.

Вот главный мой слайд на эту тему, и он обманчиво утверждает, что компоненты и функции совпадают (да, но только в случае системы в целом):


А дальше там несколько слайдов, где чётко показывается, что в общем случае они не совпадают -- в силу проводимого функционального анализа (декомпозиции компонент) и модульного синтеза (сборки системы из модулей, назначаемых на выполнение функций). И там ещё есть размещения, о которых тоже нельзя забывать.

Беда в том, что инженеры этот материал знают, но на уровне "опыта" (когда "нутром чую, но объяснить не могу"). А менеджеры с этим вообще не сталкиваются. В том же Архимейте функциональные и конструктивные элементы у менеджеров вызывают ступор: они не понимают, зачем и как их использовать при моделировании предприятия. Программисты в этом месте тоже тупят порядочно: им в голову не приходит, что рассмотрение архитектуры предприятий ведётся с использованием того же мышления, что и рассмотрение их программ (т.е. на базе системных представлений, зафиксированных в ISO 42010).

Александр Турханов подкинул ещё одну ситуацию: проектные менеджеры мыслят модульно (ещё бы!), а планирование ведут в компонентах и от этого много бед -- https://www.facebook.com/photo.php?fbid=10213456653987835&set=a.10207920196819866.1073741826.1145074069&type=3

Я дал пару комментов:

-- Проектные менеджеры очень часто из "управления проектами", т.е. когда идёт стройка-сборка и обсуждается логистика модулей. Отсюда и модульность в мышлении, ведущее описание. При проектировании же функциональность ведёт поначалу, но управляющие проектом вообще не при делах, их по факту извещают о том, что "мы вам уже сделали модульный синтез, закупайте модули" или "мы закончим работать дня через три, про модули после этого расскажем". Но когда менеджеры приходят в проект -- первое, что они пытаются сделать, это купить компоненты. И очень удивляются, что у инженеров от этого предложения начинается нервный тик, истерика и т.д.

-- Планирование должно быть модульно, если речь идёт о сборке. Ибо можно проверить готовность проекта компоненты, но сборку и прочую логистику можно проконтролировать только модуля. По-хорошему, конечно, функциональная структура там должна присутствовать, если модули хорошо проработаны и совпадают с компонентами в главных частях. Но для этого нужно специально думать.

[есть ещё много других проблем в общении менеджеров и инженеров: например, менеджеры запросто превращают выданные для них предварительные оценки в сделанные им обещания -- типичное бандитское "никто тебя за язык не тянул" использует ровно этот же приём]
-- Вы просто не встречались с ситуациями, когда менеджеры предъявляют сделанную инженерами функциональную декомпозицю, затем указывают на каталог модулей и требуют немедленно написать скрипт, выбирающий модули для функций. Что это модульный синтез и всё не так просто, им невдомёк: разница между фукнцией и конструкцией для них незначима. У меня за последнюю пару недель было несколько таких случаев. Плохо, когда инженеры на это ведутся (и, например, функциональную кодировку вдруг применяют к модулям, а потом удивляются чудесам и принципиальным нестыковскам).

-- Мы не обсуждаем всё необъятье нестыковок между менеджерским и инженерным описанием мира. Обсуждаем только одно: понятие компоненты инженерам ведомо, ибо им нужно, чтобы вещь работала. А менеджерам не нужно, вообще. И когда им попадает в руки компонента, то они с ней себя ведут как с модулем. Это фатально, но даже у инженеров не хватает знаний, чтобы это объяснить -- они нутром чуют обычно, что что-то не так, но объяснить внятно не могут.


UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210837191499895
2019

Мелкая моторика и интеллект

А накидайте мне, пожалуйста, сюда ссылок на тему почему и какая именно моторика улучшают и какую именно когницию. Это нужно для отнесения к легендам типа "прописи ручкой с нажимным пером и чернилами из чернильницы, чтобы рука расслаблялась регулярно при макании в первом классе и черчение настоящим циркулем в восьмом классе через мелкую моторику немеренно развивают интеллект. Моторику клавиатуры и мышки за мелкую не считать". Там есть следующие контроверсии:
а) это особенность советской школы, на Западе таких закономерностей не намеряно
б) это, конечно, работает, но значимые эффекты только для трёхлеток, для даже пятилеток это всё уже не так выражено, для восьмиклассников эффект ноль
б) пальцевая мелкая (каллиграфическая) моторика это совсем не то, с чем работают ментальные модели мозга: там идёт оперирование предметами, соразмерными человеческим рукам, а не ювелирным мелкостям пальцевых движений.
в) с чем работаешь, такие ментальные модели и развиваются: у работающих карандашом ментальные модели от движений руками, а у работающих клавиатурой-мышкой ментальные модели идут от того экрана, на который пялишься, совсем по-другому -- мозг-то пластичен! То есть не любой интеллект развивается через каллиграфию, для разных интеллектов нужно развивать разную моторику (кому-то в баскетбол играть, кому-то в StarCraft II).
г) кроме ручки и пластилина, никакие движения пальцев и руки не считаются мелкими -- так, мышка на игровых скоростях и точностях и клавиатура на слепом десятипальцевом 500знаков/мин не считаются мелкой моторикой.
д) люди с самыми идеальными почерками обычно не отличаются особой сообразительностью, чаще ровно наоборот

Можно ссылочки на какие-то исследования (а не пересказы исследований?).

Почему вредно опираться на пересказы пересказов пересказов исследований хорошо разбирается тут на примере развеивания городской легенды тренерских кругов, что лекции плохо доносят материал, а "интерактивные упражнения" делают это лучше: https://habrahabr.ru/company/billing/blog/301802/ -- "Сколько человек запоминает после пройденного им обучения? Обучаемый в среднем запоминает 10% прочитанного, 20% услышанного, 30% увиденного … 90% того, что сделал сам. Многие сталкивались c этими цифрами. Они приводятся отдельно или часто совмещаются с так называемой пирамидой обучения или конусом опыта. И все было бы хорошо и замечательно, если бы этими цифрами не был заполнен весь интернет, а сами они не являлись обманом и мистификацией".

У меня подозрение, что жупел мелкой моторики имеет какое-то нейрофизиологическое обоснование, но его влияние на интеллект совсем не такое большое, чтобы коверкать жизнь детей именно прописями и циркулями с рейсфедерами (ибо чертежи не тушью -- не чертежи! А использование туши развивает у восьмиклассников внимание к телу и мелкую моторику, к бабке не ходи, равно как использование циркуля даже с карандашом. И так далее, ходы-то на десятилетия накатаны!).

Есть ли что более-менее современное и с реальными измерениями на эту тему? По-русски необязательно, даже наоборот, желательно по-английски.

Это какой-то такой камень в фундаменте аргументации замшелости образования, что хотелось бы подтверждения его настоящести.

Как только люди соображают, как чему-то интеллектуальному научить непосредственно -- учат. Так дошкольной информатике начали учить, как только сообразили, в чём именно там дидактический затык, мыслительный. До этого учили тому же самому только семиклассников и уповали на мелкую моторику -- а сейчас программируют детсадовцы и первоклашки, безо всякой мелкой моторики. Мелкая моторика тут похожа либо на плацебо, либо на призывы бога, которым объясняется всё непонятное (например, интеллект).

В фейсбуке комменты кидают тут: https://www.facebook.com/ailevenchuk/posts/10207955835267790 (и ещё тут в группе нейронета:

Сама тема появилась из-за особо усиленной аргументации важности обучения работе с циркулем для развития интеллекта, ибо "циркуль тренирует мелкую моторику" тут: https://www.facebook.com/shperk/posts/10157330681710153
2019

Архимейт по-русски 1.1 -- бета готова

Сегодня я закончил новый перевод Archi 3.2.1, обозвал его версией 1.1 (версия 1.0 была выпущена три года назад -- http://ailev.livejournal.com/988360.html).

По сути, это третья редакция перевода:
-- первая была формальная, и все стандартнаци были очень довольны. Уже в первой редакции я максимально согласовал с уже имеющейся терминологией переводов ISO 42010 (Архимейт на нём базируется). Эта редакция так и осталась внутренней, плагина к Archi я для неё не публиковал.
-- после тестирования на клиентах я решил резко сбить пафос и убрать по возможности канцелярит-стандартит. Основной аргумент был: деньги за реализацию архитектуры платят те люди, которые айтишных стандартов не читали, но они должны хотя бы что-то понимать из ведущихся разговоров, хотя бы полпроцента. В этом виде и вышла версия 1.0 плагина к Archi (глоссарий -- http://ailev.livejournal.com/956829.html, дополнения второй версии -- http://ailev.livejournal.com/978200.html).
-- третья версия 1.1 выйдет сейчас, и я продолжил там гнуть ту же линию снижения пафоса и укорочения говорения. Профессионального сленга стало больше, на лёгкие проблемы я сознательно махнул рукой (ибо решение этих проблем, которое я пытался реализовать в версии 1.0 было хуже, чем сами проблемы), плюс учтён опыт прошедших трёх лет -- и несколько источников ошибок я постарался исправить на уровне выбора слов.

Вот главные изменения:

1. Я перестал добавлять ко всем словам название уровня. Не "объект деятельности", и даже не "оргобъект", а просто "объект". Не "процесс деятельности", и даже не "оргпроцесс", а просто "процесс". Хотя там, где одинаковые слова для похожих элементов разных уровней, я уровень оставил -- оргсервис, программный сервис и сервис "железа".

2. Уровень Business-"люди" стал "деятельностью" (не будем беречь этого слова, потратим его свободно. Busniness -- это "дело", "деятельность"). Но в некоторых местах я вместо длинного "деятельность" даю короткую приставку "орг" -- тот же оргсервис. И всё-таки я не стал называть уровень "организационным". Три уровня деятельность-"софт"-"железо" звучат для меня более понятно, нежели организация-"софт"-"железо", ибо про деятельность того же софта я сказать не могу, а вот про организацию софта -- запросто. Но оргсервис я не перепутаю с программным сервисом, поэтому не просто "сервис", и не длинно "сервис деятельности людей" (по мотивам прошлой версии перевода), а "оргсервис", ибо короче и понятней.

3. Уровень оборудования стал уровнем "железа". А заодно Node-оборудование стало "железом" (если говорить о единице оборудования -- будет единица "железа"). "Железо" пишем в кавычках. Я с клиентами в "реальном секторе" неоднократно натыкался на то, что они подолгу не понимали, о каком я говорю оборудовании -- о том, которое в их информационных системах, или в котором их информационные системы! А уточнять каждый раз, что "айтишное оборудование" -- это длиннее и не менее сленгово, чем просто "железо".

Так что было Infrastructure usage-"использование оборудования", стало "использование "железа"", Infrastructure function стал функционалом "железа", а не оборудования, а Infrastructure interface стал интерфейсом "железа".

4. Уровень программ стал уровнем "софта". А Application Component-"программная компонента" стала "программой". Описание программы (инкапсуляция, интерфейсы, реализация файлом и т.д.) чётко указывает на то, что речь идёт именно о программном модуле. Компонента там по смыслу -- "программный функционал", на выполнение которого назначается модуль. Так что слово "компонента" просто опущено.

Ну, и Application Behaviour -- работ "софта" (а не работа программ), Application Cooperation -- взаимодействие "софта", Application Structure -- структура "софта". Там, где говорится о множестве программ, где используется собирательное понятие, там "софт".

Но не "софтовый" сервис, а "программный сервис", не "софтинка", а "программа", не функционал "софтинки", а "программный функционал" -- где имеется ввиду не весь "софт" предприятия, а одна или программа или небольшая группа программ.

5. Крутейшее изменение, которое касается и ISO 42010. View (помним, что в стандарте veiw группирует входящие в него модели) переобозван из группы описаний просто описанием. Да, там нюансы. Так, архитектурное описание (description) само состоит из разных тематических групп описаний, а элементарными описаниями являются "модели" (models). По мне сегодняшнему, так это очередная попытка навести разнотиповую иерархию там, где просто специализация типа. Ведь определение системы противопоставляется описанию системы (description -- все view вместе), которое делится на тематические описания типа архитектурного -- и уже это вполне себе view. А затем view делятся на маленькие подвьюшки -- модели. А в Archi description называется Total veiw, низовых моделек нет вовсе. И слово "модель" там занято, по смыслу это как раз definition (видеть модель можно, только вынеся на какую-то диаграмму-описание или в специальном окошке диаграммы дерева-модели -- и как называется это окошко? Правильно, тоже view).

Итог: группа описаний стала просто описанием. Есть определение, а есть описание. То, что в Archi view-окошко программы и ArchiMate view обозначаются одним словом -- это ничего, это нормально. Так что там иногда путается в переводе "закрыть окошко" и "закрыть описание".

Ах, насколько же стало проще и понятней!

Viewpoint я так и оставил "методом описания" (а не "практика описания") -- подразумевается, что в метод описания входят самые разные практики, необходимые для описания (не только метамодель, но и указания по стилю -- "соглашение о моделировании", типовые паттерны и т.д.).

6. Actor-люди стали "ответственными" -- это прямой реверанс в сторону DEMO (у них там те же Actors: те, кто имеют право что-то попросить или выполнить. Это и есть суть организации: разделение полномочий и ответственности). Тут тонкость: в организации есть обычно не два (как в Архимейте), а целых три объекта:
-- должности, подразделения -- вся органиграмма (ответственности)
-- роли по отношению к деятельности (они связаны с практиками: в ArchiMate одна практика -- одна роль)
-- люди (или их группы), занимающие должности и выполняющие в этих должностях (профессиональные, по отношению к деятельности) роли.

Архимейт явно проговаривает, что никаких конкретных исполнителей ролей в нём не предусмотрено, Actors главным образом используется для выражения органиграммы. А "ответственный" обычно ещё и несколько ролей играет, ибо назначен явно не на одну практику. И вот поэтому переводим "ответственный" (главный инженер, департамент закупок и т.д.), а не просто "исполнитель".

7. Product (который я в прошлый раз честно оставил "продуктом") надёжно всех сбивает с толку -- это "банковский продукт", "страховой продукт", но в реальном секторе каждый раз удивляются, почему Арчи не позволяет поступать с ним как с продуктом, как будто он какие-то работы (activity), а не продукт! Да, ArchiMate определяет product именно как service+contract! Вот он и ведёт себя как оргсервис при моделировании! Так что я назвал его хитро: оргсервис-продукт, чтобы прямо из названия следовала аналогия с "банковским продуктом".

Парное к нему соглашение об уровне сервиса (contract) я так и назвал полностью, чтобы дополнительно прояснить эту засаду с оргсервис-продуктом как сервисом -- "соглашение об уровне сервиса". Архимейт 2.1 тут странен: в тексте подробно говорится, что чаще всего тут SLA, а иногда другие типы контрактов. А элемент назвали контрактом. Я перевёл по наиболее частому случаю, строго по стандарту! И приписал в подсказке, что могут быть и другие виды контрактов.

8. Stakeholders стали из заинтересованных сторон просто "стейкхолдерами". Язык развивается, и это нужно учитывать. Слово компьютер постепенно заменило слово ЭВМ, и тут ровно такой же случай.

9. Requirements по более тщательному рассмотрению стало не требованиями (ещё можно говорить про требования к "софту" или "железу", но про деятельность редко говорят в терминах требований), а... контрольной точкой. Это удивило и меня самого.

Идея, что это "задачи" из "целей и задач" -- тоже не проходит. Слово "задача" в части противопоставления целей и задач каждый трактует, как хочет -- каждый ведь много раз участвовал в пустопорожних спорах по формулированию "целей и задач" в каком-то важном документе и попытках определить, чем же отличаются цели от задач (о, я знаю уже много "самых верных пониманий" -- в каждом коллективе они складываются свои).

Почему "контрольная точка"? В контрольной точке же явно оттенок команд-глаголов из "управления кейсами", а не декларативная чисто инженерная запись о "требуемом свойстве"!

Ну, Goal (а requirement это по сути декомпозиция Goal) там тоже SMART-цель с ярко выраженным глаголом-командой. "Увеличить продажи на 20% к 3 января" -- цели все такие. И requierment, из них следующие тоже все имеют этот оттенок требуемого действия, а не требуемого пассивного свойства. Это требование действия, требование изменения. И даже стандарт говорит, что для достижения целей нужен план, и именно для этого служат requirement (но тут же стандарт сбивается, и продолжает говорить про "свойства системы").

После внимательного рассмотрения примеров (и особо замечания Gerben Wierda, что всякие контроли моделировать нужно requirements -- то, что требования контролируются, было и так понятно, но он уточнил, что сам контроль моделируется элементом requirement!), а также принимая во внимание тренды в части кейсов (контрольная точка становится элементом контроля, соединяющим требования и выполнение работы -- поскольку требования выполняются сейчас асинхронно, то в каждой контрольной точке указывается условие её достижения, фрагмент требований). То есть контрольная точка -- это тот самый синтез элемента плана и требуемых свойств, о которых говорит данный пункт стандарта.

Я писал в http://ailev.livejournal.com/1202776.html -- "Планируются события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах)". Вот события предприятия ("архитектуры") в ArchiMate планируются через Event, а события развития ("с архитектурой") планируются через удовлетворение requirement, контрольные точки. Так что эта логика case management попадает теперь и в дополнение целеполагания.

10. Presentation из "представления" стало "рабочим продуктом" -- объект в ArchiMate это "информация", альфа. Так что информация никак не представлена. Но она может быть представлена в данных и затем артефактом (но это уже чисто айтишные заморочки -- невидимые в деятельности), а в деятельности альфа представляется рабочими продуктами (одним или несколькими). Формулировки и объяснения стандартов ArchiMate и Essence тут весьма близки. Так что я просто учёл тут результаты наших работ с Essence.

11. Driver стал из "фактора влияния" интересом (concern). В ArchiMate, впрочем, об этом прямо говорится -- и про связь со стейкхолдером, чей этот интерес. Миром движут интересы, всё правильно. Замечание, что может быть и просто "какой-то внешний фактор" игнорируем: это означает, что интерес к фактору есть, и по норме дальше мы просто должны понимать, чей этот интерес. Но можем, конечно, не указывать, чей интерес какое-нибудь "падение рынка", язык вполне допускает тут расслабиться. Но я бы не рекомендовал расслабляться, и подумать, кого это может из стейкхолдеров волновать. Так что тут я просто чуть-чуть подправил перевод в сторону чуть более строгого системного подхода.

12. Gap стал "различием" (из "расхождения"). To be и as is не "расходятся", а "различаются".

13. Deliverable из "комплектующего" (что более пристало инженерным, а не орг-работам) стал "результатом пакета работ", практически по тексту стандарта.

14. В большинстве случаев в интерфейсе я начал писать не "ошибка при открытии файла", а "ошибка открытия файла" -- и по этому же шаблону все остальные подобные выражения. Тут, конечно, можно открывать холивар, но это явно не самый большой грех этого перевода. Хочется, хочется быть поближе к народу!

Технически сейчас ситуация такая:
-- переведено уже всё (пользовательский интерфейс+подсказки), кроме хелпа. Хелп я переводить не буду.
-- есть техническая проблема: время от времени вдруг вместо перевода показываются английские слова (иногда это при перезапуске Archi исчезает, иногда остаётся). Эту проблему буду решать в ближайшие дни -- я думаю, что-то там не то с версиями Eclipse, я сделал запрос автору Archi (ну, или придётся тут поискать какого-то местного знатока локализации в Eclipse). В принципе, основное там уже всё по-русски, и все эти вкрапления английского не слишком мешают. Тем не менее, публиковать версию пока рано. UPDATE: всё уже исправлено.
-- готов отдать language bundle для Archi 3.2.1 на бета-тестирование прямо сейчас -- под обязательство потыкать и прислать мне какие-то замечания в ближайшую пару дней. Для этого напишите мне на ailev@asmp.msk.su
2019

Гарри Поттер, только круче, или к вопросу об однополых браках.

Жена долго смотрела какой-то сериал, в восторге приговаривая "Гарри Поттер, только круче". Я даже заинтересовался -- это, оказывается, семь серий Jonathan Strange & Mr Norrell http://www.imdb.com/title/tt2548418/ (IMDB 8.4, и впрямь круче Гарри Поттера).

А вот мне Гарри Поттера неинтересно читать-смотреть (я с трудом прочёл один томик и с трудом посмотрел один какой-то фильм, да и HPMOR не до самого конца одолел, хотя и много там прочёл). И к Джонатан Стрендж и мистер Норрел я тоже равнодушен. Лет двадцать назад я читал много всякой фэнтези, но потом как-то резко бросил. И на Гарри Поттера меня уже не хватило, как уже не хватит на эту новую его (ну, не его -- без разницы) инкарнацию.

Зато жена на дух и нюх не переносит мангу и аниме. Не то чтобы она была к ним равнодушна, она их активно не любит. Но у нас в доме войны на эту тему нет: каждый тихо предаётся удовольствиям в своём углу и это никому не мешает. Прозелитизм тут бесполезен, это ж понятно.

Всё-таки люди в их любви к разным видам художеств очень разные. Даже удивляюсь, почему из-за этого нет таких же жестоких религиозных сражений, как по поводу любви к разным языкам программирования (например, по ссылкам в http://justy-tylor.livejournal.com/238336.html в вежливой форме, а вот http://vit-r.livejournal.com/814184.html более жёстко), операционным системам (хотя сейчас эти войны поутихли уже -- а как рубились вокруг RT-11 против RSX-11!), а также сексуальной ориентации.

Ежели чего, то я функциональным языкам симпатизирую, но сам писать на них не буду. И я вполне за разрешение жениться кому хошь на ком хошь в США, хотя не считаю это таким выдающимся событием, чтобы аватарку красить. Вот если бы сразу разрешили браки M:N, это было бы другое дело. Хотя вру, с учётом унификации отношения к полу правильно писать браки N, где N больше или равно единице (женитьбу на себе любимом тоже нужно учитывать!). И ещё в это N вписать как потенциальных партнёров роботов и животных, которые сумеют выразить своё согласие.

Я и сам лесбиян: только женщинами обычно интересуюсь, к мужчинам безразличен, как и к Хаскелу, и к Гарри Поттеру. Но если кому мужчины, Хаскел или Гарри Поттер нравятся, то это его дело -- при этом неважно, какого он пола, возраста, расы, вероисповедания и на белковой ли он основе, и сколько их.
2019

Системный подход и жизнь

Один из форматов, в котором мы работаем с клиентами -- это "рассказы" (не хочется обзывать их лекциями, ибо тип работы не "магнитофонный", а диалоговый -- с вопросами в обе стороны, но акцент всё-таки на презентации некоторого содержания), сопровождающиеся "рабочими сессиями", где происходит попытка применения нового материала к реалиям жизни клиента. На этих "рабочих сессиях" происходит осознание рассказанного.

С понятием "система" происходит одно и то же: в рассказе (несмотря на многочисленные примеры, предупреждения и декларации) кажется всё понятным и "невинным" -- совершенно непонятно, чего это вдруг мы уделяем этому вопросу такое внимание, говорим, что это центральное понятие. Всем кажется, что рассказывается ровно то, что и так происходит: конечно, всё состоит из систем, системы сами являются подсистемами, имеют подсистемы, их можно представить и как жизненные циклы...

На "рабочих сессиях" вдруг оказывается, что в реальности никакого системного рассмотрения не велось: разные люди по чуть-чуть рассматривали разные аспекты системы, но никогда эти разные аспекты не обсуждались вместе. И это системное рассмотрение жизни оказывается крайне продуктивным, хотя зачастую и болезненным -- из этого рассмотрения выскакивают новые знания, а "многия знания -- многия печали".

Пару лет назад я уже приводил пример упражнения "системная медитация" для личной работы (http://ailev.livejournal.com/847044.html), а вот коротенький вариант для производства (выполняется обычно коллективно топами, детали не прописываю -- всё-таки это для тех, кто слушал наши рассказы):

1. Убедитесь, что вся работа делается на хорошо видимом всеми флипчарте. Вы не гроссмейстеры, для думания вам нужна доска с фигурами, "по памяти" играть трудно. Для взаимокоординации вам нужно табло, одна версия на всех. Если флипчарта там, где вы обычно совещаетесь, нет, то прервитесь и обеспечьте.

2. Без имён систем их обсуждать невозможно. Выпишите список систем, которые вы делаете. Что это -- индивиды (с серийными номерами?), классы (описываемые строчкой каталога серии)? Отдельные уникальные системы или платформы/продуктовые линии? Где границы этих систем, какие между ними отношения? Что между ними общего, а что разного?

3. Есть ли у вас люди, ответственные за поддержание такого списка? Контрольный вопрос: в чьём компьютере этот список лежит, кто уполномочен вносить изменения в список "чем занимаемся"?

4. Подсистемами каких систем ваших клиентов являются ваши системы? Что вы об этом знаете? Как вы помогаете вашим клиентам в проектировании их систем с использовании ваших систем в качестве подсистем?

5. Пересмотрите список ваших систем, вам обязательно захочется его поменять. Если ответственного за список нет, назначьте ответственного (в чьём компьютере этот список будет жить): этот пересмотр списка нужно делать постоянно, и он его и будет делать.

6. Для каждой целевой системы-строчки из списка нарисуйте жизненный цикл в простейшем виде: стрелочка с зарубками. Помним, что жизненный цикл -- это от задумки до мусороперерботки вашей системы. Отметьте, где ваше предпринятие вступает в этот жизненный цикл, и где оно из него выходит. Убедитесь, что все присутствующие понимают, что предметом интереса является весь жизненный цикл, а не только тот его кусочек, который попал к вам на сегодня.

7. Какие жизненные циклы у подсистем вашей системы? Кто их делает, на какой стадии жизненного цикла этих подсистем вы взаимодействуете? Если у этих подсистем внешние подрядчики, то как они с вами взаимодействуют (у них ведь та же ситуация, что и у вас с вашими клиентами: они могут не понимать, что вам нужно, и зачем вам это нужно).

8. Понимаем, что система-как-жизненный-цикл является основным инструментом договорённостей между менеджерами (для которых стадии -- это проекты) и инженерами (для которых стадии -- это инженерные мероприятия), в том числе между менеджерами и инженерами клиентов и подрядчиков. У кого в компьютере живут описания/модели (полных!) жизненных циклов ваших систем?

9. Опять подумайте, какие у вас системы (напомню: платформы и продуктные линии, мелкие и крупные серии, уникальные системы, сервисы и т.д.). Вернитесь к списку и опять поменяйте его.

Теперь есть шанс, что при разговоре о вашем предпринятии (то бишь, "чего предпринимаем") принимавшие участие в этих обсуждениях хотя бы чуть-чуть понимают, что делают, до чего договорились, кто за что ответственен. И понимают, чего они не понимают, и о чём пока не договорились, и у кого на эту тему непониманий и недоговорок должна болеть голова.

Наш опыт показывает, что самостоятельно такую процедуру проделать очень сложно: она очень, очень болезненна, а люди предпочитают быть политкорректными -- и "для безопасности" тут же съезжают с обсуждения их реальных систем на обсуждение каких-то общеотраслевых генерализаций типа ЕСКД, или даже собственных беззубых (иначе бы их никто не утвердил) документов службы обеспечения качества. Ибо когда игра в производственный бисер начинает происходить "на доске" с отображением результатов "на табло", все нестыковки в понимании целевых систем, их границ "вверх" и "вниз" по цепочкам кооперации, нестыковки в приоритетах учёта интересов обеспечивающих систем тех или иных стадий жизненного цикла становятся очевидными -- и трудно удержаться от перехода обсуждения в традиционное "кто виноват" вместо конструктивного "что делать".

И только после такого первого прохода "называния систем" люди начинают подозревать, что "системный подход" -- это не совсем то (точнее, совсем не то), что они всегда думали.

И ведь это только самое начало работы, материал первых нескольких часов рассказа. Обратите внимание, ещё ведь не дошли ни до каких практик жизненного цикла, и даже вид жизненного цикла не обсуждали, только попытались его изобразить в самой примитивной нотации, и выяснить, для каких систем это нужно сделать.
2019

Развитие предпринятия

Мы в TechInvestLab -- консультанты по развитию. Мы организуем организаторов: нашими контрагентами у клиента обычно являются вице-президент по развитию и его департаменты. Мы страшные люди, и, безусловно, "враги" (ага, "лучшее -- враг хорошего") ибо нам приходится прекращать (иногда мнимое, иногда вялотекущее, иногда даже лихорадочное) совершенствование, в котором осмысленность своего существования в организации черпают десятки, сотни, тысячи людей: мы обычно начинаем ровно с того, что показываем бесперспективность этого совершенствования и делаем явной необходимость шагнуть на следующую ступеньку в практиках стратегирования, операционного управления, инженерных практиках (разница между развитием и совершенствованием более подробно разбиралась в предыдущем посте: http://ailev.livejournal.com/1032133.html).

Развитие -- это когда прекращаешь думать об одном, и начинаешь думать о другом. Это вовсе необязательно случается, когда меняется предмет работы ("развитие-в-большом", обеспечивающей системы в целом). Развитием вполне можно считать и "развитие-в-малом", переход на очередную стадию жизненного цикла. В ISO 24744 смена стадий жизненного цикла целевой системы как раз и определяется, как смена преимущественных типов думания обеспечивающей системы, смена cognitive framework.

Конечно, в окружающем мире систем много, а стадий жизненного цикла у них еще больше. Но если у вас в голове какая-то целевая система занимает главное место (помним, что понятие "система" нужно было для того, чтобы дать что-то вроде "курсора" в окружающем мире -- чтобы брать объект думания в "фокус"), то вынуть из головы одни привычные мысли и заменить их другими может быть проблемой. Когда меняется стадия жизненного цикла целевой системы, у обеспечивающей системы меняется "настройка мозга", одни знания и проблемы уходят на задний план, другие начинают занимать основной объём мозга -- и если разные стадии жизненного цикла обеспечивают одни и те же люди, можно ожидать проблем застревания на совершенствовании.

Всё это верно и для "саморазвития", когда целевой системой мы выбираем сами себя -- будь это предпринятие, или даже отдельный человек, который в этом смысле тоже оказывается предпринятием (как в смысле собственного "проекта", так и в смысле собственной "организации": вполне можно поделить внутри себя ответственность между себой-делающим и собой-осознающим эту деятельность; поговорить собой-озознающим с собой не-делающим и поругать за прокрастинацию; и даже использовать экзокортекс, чтобы себе себя нельзя было проигнорировать).

Если предмет работы не меняется, то можно назвать смену стадий жизненного цикла этого предмета "развитие в малом". Первый тут шаг -- это вообще решиться на предпринятие, стартап. Это и будет "развитие-в-большом", стратегирование. Мы в TechInvestLab поэтому часто себя называем "консультантами старт-апа", стратегическими консультантами.

Но после первого шага будут и другие: принятие решения "Go -- No go" при переходе со стадии на стадию, и далее сам переход (ведь правильно говорят: принять решение о переходе -- это ещё не перейти). Это тоже развитие, хотя и "развитие в малом": вырваться из пут предыдущих мыслей, покинуть налаженный быт размеренного пиления очередного состояния системы последовательностью всё более мелких напильников, выбраться из вонючего болота analysis paralysis, освободиться из цепкой паутины технократического и бюрократического перфекционизма, прекратить вечное совершенствование, и -- ШАГНУТЬ. Прекратить главным образом (конечно, не совсем) задумывать, начать главным образом проектировать. Прекратить главным образом проектировать (конечно, не совсем), начать почти всё время и ресурсы тратить на стройку. В какой-то момент надо плюнуть на недостижимый идеал "полностью завершенных тестов и полностью готовой системы" и начинать уже главным образом эксплуатировать.

Это всё легко только тогда, когда вас подгоняет заказчик. А если внешнего заказчика нет?! Будете ли вы себя подгонять, когда вы ежеминутно заняты каким-то архиважным делом? К тому же на каждой ступеньке, на каждой стадии жизненного цикла должно быть потрачено достаточное время для совершенствования промежуточного состояния системы. Та же дилемма: нет совершенствования -- нет развития. Но и слишком много совершенствования -- тоже нет развития, а если нет заказчика на развитие, то и подгонять при переходе от стадии к стадии развития-в-малом некому, некому проводить валидацию всего этого огромного совершенствования...

К чему я это всё пишу? Когда-то я выдвинул тезис, что можно создать очень компактный язык (набор понятий и их отношений), на котором обсуждать самые разные проблемы. Это освобождает от необходимости осваивать отдельные языки, используемые в самых разных практиках. Вот я и хочу показать, что если речь идёт о развитии, то будь это изучающий информатику школьник-малолетка, мятущийся студент, обдумывающий житьё, инжиниринговый проект (проект ведь -- это тоже предпринятие, договорка о разделении труда и ответственностей, http://praxos.livejournal.com/14905.html), или крупная инжиниринговая фирма -- все они могут получить выгоды от использования языка системного подхода, в котором рассматриваются жизненные циклы.

Жизненный цикл предпринятия (помним, что и "себя" я считаю предпринятием) -- это тоже жизненный цикл, и нужно уметь по нему двигаться с максимизацией прохода. Помним: "или ты планируешь, или тебя планируют" (хотя тут я бы писал "или ты стратегируешь, и развиваешься -- движешься по жизненному циклу, или тебя стратегируют и подвигают").

Жизненный цикл предприятия, "стратегирования в большом" -- это жизненный цикл замены его практик, жизненный цикл управления технологиями. Развитие-в-большом -- это ступени полной смены практик (при этом практики меняются отнюдь не по одной, они меняются большими связками -- в связи ли со сменой рынка, или в связи со сменой рыночной технологической платформы, инженерного или менеджерского уклада).

Развитие-в-малом -- это переходы по ступеням зрелости практик, жизненный цикл "текущего предпринятия-каким-мы-его-мечтаем-видеть" внутри жизненного цикла предпринятия-от-рождения-до-могилы. Это совсем разные жизненные циклы, но все они состоят из стадий, все они -- ступеньки развития между плато совершенствований.

Совершенствование предпринятия -- это необходимость практиковать какую-то ступень зрелости практик, чтобы получить хоть какой-то шанс шагнуть вперёд, на следующую ступень развития. Совершенствование зрелой уже практики -- это часто путь к загниванию, это прекращение развития. После того, как вы довели до блеска бумажный документооборот, у вас могут быть огромные проблемы с развитием в сторону электронной коллаборации, ибо там не просто "электронный документооборот", но проблемы с самим понятием документа как универсальной сущности -- речь ведь идёт главным образом о совместной работе разных приложений с общими базами данных! Отказаться от документов в этот момент -- это будет восприниматься не как развитие, а как махровое антисовершенствование, разрушение основ и крах того совершенства, которым нужно гордиться! Совершенное воспринимается, как лучшее, а результат развития -- только как хорошее (ибо всем очевидно, что этому ещё совершенствоваться и совершенствоваться, чтобы сравниться с уже имеющимся). "Хорошее -- враг лучшего!" -- и развитие прекращается, не начавшись. Старые парадигмы, старые cognitive frameworks умирают только с их носителями...

Первый шаг решения проблемы "развитие против совершенствование" -- это возможность её коллективного (ага, в том числе в коллективе с самим собой! Попробуйте написать ваши мысли, а затем прочесть -- и при написании, и при прочтении вы откроете для себя много нового!) обсуждения. А для возможности этого обсуждения -- нужно выучить этот язык. Как писал Harold Lawson пару дней назад в комьюнити INCOSE в LinkedIn в треде "Building SE into an Organization", -- "...it is all about understanding and communication. If you do not get people on the same page you are simply talking in the air. That is why learning fundamental paradigms, concepts and principles of systems is so important". То есть развитие начинается в тот момент, когда его можно обсуждать, когда выучен язык, на котором говорят о развитии. Нужно освоить "fundamental paradigms, concepts and principles of systems" -- и пройти ступеньку совершенствования, чтобы научиться этим пользоваться. Нужно сделать шаг "развития для развития". Это трудно: прекратить индивидуальное или корпоративное совершенствование в том, чем вы прямо сейчас сами или с коллегами заняты, и пройти ряд образовательных ступенек "о ни о чём".

Но эти "ступеньки ни о чём" лежат в основе любого общего образования, которое готовит развитых людей -- т.е. людей, не теряющихся в широком разнообразии ситуаций. Это совсем не "совершенствование", которое имеет своим предметом что-то предельно конкретное, и результаты которого довольно легко измерить (ибо совершенствование -- это повышенная эффективность поведения в одной и той же ситуации).

Это парадоксально, но самое эффективное для развития предпринятия -- это не сразу бросаться в преобразования, а сначала научить людей говорить об их предпринятии, научить людей говорить о стратегировании/развитии на языке системного подхода. Люди получают возможность быстро договориться между собой и скооперироваться (ага, в том числе договориться "внутри себя", если ваше предпринятие -- это только вы сами). И тогда начинают происходить чудеса, тогда начинается настоящее развитие и осмысленное для него совершенствование -- в маркетинге, инженерии, операциях.