![Отличная заготовка, требующая доработки. Обзор отечественной ролевой игры Gedonia 2 [Ранний доступ]](https://ixbt.online/gametech/covers/2025/04/11/nova-filepond-78zbTu.jpg)
Заметки с XV рабочей встречи INCOSE RUS по проблемам системной инженерии
Русское (по языку, а не по стране) отделение INCOSE собралось на очередную, юбилейную пятнадцатую рабочую встречу -- второй год это происходит в высотке на Белорусском вокзале. Разговаривали, как обычно -- пару дней, 12-13 апреля 2025. Как всегда, "раз в год мы ходим с друзьями в баню". Забавно прямо было прямо на старте обсуждения услышать явную констатацию факта, что "INCOSE уже всё", тамошние старички уже далеко отстали от жизни, ибо на госденьги они только и могут, что удерживать тяжёлый системноинженерный процесс.Я там тоже сделал доклад -- рассказал о новом курсе "Системная инженерия", доклад шёл вперемешку с горячей дискуссией где-то пять часов в первый день. В этом докладе я дал две части:-- почему нельзя учить системной инженерии сразу, какие там пререквизиты, почему нынешние вузовские программы обучения инженерии крайне неэффективны. Полная программа обучения инженера, в составе которой есть и курс "Системная инженерия". Как нам удаётся учить по курсу системной инженерии гуманитариев (HR, маркетинг, юристов). -- состояние современной системной инженерии, отражённое в курсе.По итогам обсуждения я понял, что надо дать больше синонимов для мантр -- чеклист (по Gawande это, конечно, чеклист, хотя это не те чеклисты, которые мы даём по альфам, поэтому может немного путаться), по "убираем после вышивки" -- это канва, по "во всех пунктах всё должно быть согласовано и подставлено" -- это уравнение, по фокусировке ума и повторяемости -- мантра, по последовательности рассказа -- сюжет. И надо дать примеры подставновки значений. Иначе механизм работы с типами мета-мета-модели и мета-модели плохо понимаются, как и механизм обобщения и обфускации при переходе от типов мета-модели к типам модели. Нет понимания моделирования -- нет понимания вообще ничего, моделирование понимаем на этих четырёх чеклистах/канвах/уравнениях/мантрах. Так что буду переделывать материал семинара по мантрам, а также вставлю этот кусочек в семинар по курсу системной инженерии.Основные вопросы были не к требованиям, не к архитектуре, не к инженерным обоснованиям, а по новому материалу: прежде всего инженерия как проектирование "с первого раза" против инженерии методом проб и ошибок, а ещё идея динамического ландшафта приспособленности. Вроде как разобрались в том, что в сложных проектах там спектр по шкале "oracle, full knowledge -- trial and error, no knowledge", у меня там как раз нашлась красивая картинка из https://www.nature.com/articles/s41467-024-48000-1, даю её в курсе, рассказывая об инженерном процессе как техно-эволюции:Подходы к проектированию в нижнем левом углу имеют небольшое количество вариантов (размеров популяции) и циклов проектирования (поколений). Они требуют значительных предварительных знаний для успешного проектирования с оракулом, способным создать идеальный дизайн за одну попытку. Подходы к проектированию в верхнем правом углу мало используют предварительные знания и обучение, требуют меньшей способности к развитию, и их поиск менее ограничен. Метод проб и ошибок (без предварительных знаний) попадает в эту крайность, где для проектирования нетривиальных систем требуются гиперастрономические масштабы. Все остальные методы проектирования расположены между этими крайностями, и даже в случае SpaceX часть проб и ошибок -- это важная часть, ибо там речь идёт о принципиально важных новых изменениях в конструкции, а не улучшениях старой конструкции. То, что там новые корабли взрываются в ходе проб и ошибок, но взрываются в довольной быстрой для космоса последовательности -- это инженерно и рыночно оказывается много лучше, чем "первый же взлёт -- успешен" при многолетнем проектировании "для стопроцентной надёжности" (которой, как известно, никогда не бывает). Да, "человечество разучилось рисковать", как сказал когда-то Элон Маск, начал рисковать, и опередил огромное число других космических фирм, да и не космических фирм тоже. Политика у него политикой, а инженерия -- инженерией. В конце заседания мы поговорили с Кириллом Гайдамакой о том, как проектируется современный электромобиль, обнаружили этот самый спектр (и договорились, что об этом будет его доклад на нашей девятой конференции ШСМ "Современный системный менеджмент и инженерия-2025": https://ailev.livejournal.com/1749524.html):-- железо проектируется "традиционным проектированием" (не "водопад", но близко -- там очень стабильные описания того, что такое "хороший автомобиль", очень стабильные и известные архитектурные решения, full knowledge)-- программно-аппаратный комплекс электрической части и части управления -- тут классический SAFe инженерный процесс, застрявший на полпути между старинным и современным, и там уже ближе к agile как constrained trial and errors. Какое-то знание предметной области есть, но оно не так чтобы стабильно и оказывается не всегда верным.-- программная часть "в облаке", и вот там уже можно попробовать сотню раз сотрю вариантов, это ближе к breeding, генетическим алгоритмам, "полный agile", знания о том, что же такое "облачная часть эл
Русское (по языку, а не по стране) отделение INCOSE собралось на очередную, юбилейную пятнадцатую рабочую встречу -- второй год это происходит в высотке на Белорусском вокзале. Разговаривали, как обычно -- пару дней, 12-13 апреля 2025. Как всегда, "раз в год мы ходим с друзьями в баню". Забавно прямо было прямо на старте обсуждения услышать явную констатацию факта, что "INCOSE уже всё", тамошние старички уже далеко отстали от жизни, ибо на госденьги они только и могут, что удерживать тяжёлый системноинженерный процесс.
Я там тоже сделал доклад -- рассказал о новом курсе "Системная инженерия", доклад шёл вперемешку с горячей дискуссией где-то пять часов в первый день. В этом докладе я дал две части:
-- почему нельзя учить системной инженерии сразу, какие там пререквизиты, почему нынешние вузовские программы обучения инженерии крайне неэффективны. Полная программа обучения инженера, в составе которой есть и курс "Системная инженерия". Как нам удаётся учить по курсу системной инженерии гуманитариев (HR, маркетинг, юристов).
-- состояние современной системной инженерии, отражённое в курсе.
По итогам обсуждения я понял, что надо дать больше синонимов для мантр -- чеклист (по Gawande это, конечно, чеклист, хотя это не те чеклисты, которые мы даём по альфам, поэтому может немного путаться), по "убираем после вышивки" -- это канва, по "во всех пунктах всё должно быть согласовано и подставлено" -- это уравнение, по фокусировке ума и повторяемости -- мантра, по последовательности рассказа -- сюжет. И надо дать примеры подставновки значений. Иначе механизм работы с типами мета-мета-модели и мета-модели плохо понимаются, как и механизм обобщения и обфускации при переходе от типов мета-модели к типам модели. Нет понимания моделирования -- нет понимания вообще ничего, моделирование понимаем на этих четырёх чеклистах/канвах/уравнениях/мантрах. Так что буду переделывать материал семинара по мантрам, а также вставлю этот кусочек в семинар по курсу системной инженерии.
Основные вопросы были не к требованиям, не к архитектуре, не к инженерным обоснованиям, а по новому материалу: прежде всего инженерия как проектирование "с первого раза" против инженерии методом проб и ошибок, а ещё идея динамического ландшафта приспособленности. Вроде как разобрались в том, что в сложных проектах там спектр по шкале "oracle, full knowledge -- trial and error, no knowledge", у меня там как раз нашлась красивая картинка из https://www.nature.com/articles/s41467-024-48000-1, даю её в курсе, рассказывая об инженерном процессе как техно-эволюции:
Подходы к проектированию в нижнем левом углу имеют небольшое количество вариантов (размеров популяции) и циклов проектирования (поколений). Они требуют значительных предварительных знаний для успешного проектирования с оракулом, способным создать идеальный дизайн за одну попытку. Подходы к проектированию в верхнем правом углу мало используют предварительные знания и обучение, требуют меньшей способности к развитию, и их поиск менее ограничен. Метод проб и ошибок (без предварительных знаний) попадает в эту крайность, где для проектирования нетривиальных систем требуются гиперастрономические масштабы. Все остальные методы проектирования расположены между этими крайностями, и даже в случае SpaceX часть проб и ошибок -- это важная часть, ибо там речь идёт о принципиально важных новых изменениях в конструкции, а не улучшениях старой конструкции. То, что там новые корабли взрываются в ходе проб и ошибок, но взрываются в довольной быстрой для космоса последовательности -- это инженерно и рыночно оказывается много лучше, чем "первый же взлёт -- успешен" при многолетнем проектировании "для стопроцентной надёжности" (которой, как известно, никогда не бывает). Да, "человечество разучилось рисковать", как сказал когда-то Элон Маск, начал рисковать, и опередил огромное число других космических фирм, да и не космических фирм тоже. Политика у него политикой, а инженерия -- инженерией.
В конце заседания мы поговорили с Кириллом Гайдамакой о том, как проектируется современный электромобиль, обнаружили этот самый спектр (и договорились, что об этом будет его доклад на нашей девятой конференции ШСМ "Современный системный менеджмент и инженерия-2025": https://ailev.livejournal.com/1749524.html):
-- железо проектируется "традиционным проектированием" (не "водопад", но близко -- там очень стабильные описания того, что такое "хороший автомобиль", очень стабильные и известные архитектурные решения, full knowledge)
-- программно-аппаратный комплекс электрической части и части управления -- тут классический SAFe инженерный процесс, застрявший на полпути между старинным и современным, и там уже ближе к agile как constrained trial and errors. Какое-то знание предметной области есть, но оно не так чтобы стабильно и оказывается не всегда верным.
-- программная часть "в облаке", и вот там уже можно попробовать сотню раз сотрю вариантов, это ближе к breeding, генетическим алгоритмам, "полный agile", знания о том, что же такое "облачная часть электромобиля" особо нет.
Ещё у этой весьма специфической аудитории был интерес к инженерии платформы рамках DevOps (путешествие по графу создателей, где всегда он устроен чуть более кучеряво, чем представляется изначально), и как специфически организовано разделение труда между архитекторами и визионерами (уровень коллектива к команде команд) и разработчиками в команде (проектировщиками, методологами, технологами), ибо термин "разработчики" используется в двух значениях -- "разработчики системы в целом" (коллектив инженеров, отличаем от коллектива менеджеров, продвиженцев и т.д.) и "разработчики набора фич" (разработчики в команде одной крупной архитектурной части-модуля).
Обсуждение шло на современном уровне, в кулуарах после встречи отмечали, что трудно даже представить, какой прогресс в уровне обсуждений. Один из участников -- системный инженер, опытный руководитель, но когда он говорил, это были идеи 2010 года, и это было очень наглядно: вроде бы слова уже все те же самые, но акценты расставляются совершенно по-другому. И забавно выглядели некоторые замечания вроде, что "давайте обсуждать русскоязычные термины, что нам эти англоязычные различия между safety-безопасность и security-безопасность". Вежливо ответили, что лучше бы различать, и лучше бы студентов учить и англоязычным терминам -- чтобы могли читать современную англоязычную литературу прямо из постов в блогах (ибо все даже книги уже безнадёжно отстают), а не отсутствующие современные русскоязычные источники информации.
В очередной раз Антон Королёв рассказал, как готовят системных инженеров в МИРЭА (и там ему помогают несоколько членов директората INCOSE RUS, и даже читаются некоторые курсы из программы оргразвития ШСМ). В этом году было продемонстрировано, что студенты получают знание полного (а не кусочного, как раньше) инженерного процесса, с выходом не только на имитационное моделирование, но и на учебную аппаратуру (самоуправляемые тележки). Упор там на инженерные обоснования, причём в варианте разных стандартов формального представления (стандарты безопасности, близкие по духу к архитектурным стандартам). В этом году стало понятно, что учебная программа как-то устаканилась -- за счёт отказа от идеи "одного инструмента, одного репозитария" лучше получается знакомить с идеями, а не формами представления идей (формы неважны!), а заземление на реализацию даёт совершенно другой уровень подготовки. Ещё там обсуждался выход студентов на работу на заводах -- шаг на работу в "настоящих проектах" вроде "системы МФТИ" с их базовыми предприятиями кафедр. Пока же -- моделирование на деталях конструкторов со всякими ардуинами, подключёнными к нормальным компьютерам. Моделирование на Matlab, но мой совет был -- переходить уже к https://info.juliahub.com/products/juliasim, это следующее за Modelica поколение средств моделирования (и там достаточно всего open source). Ещё один совет -- выкинуть из названий учебных программ все эти "анализы", ибо надо или готовить аналитиков, которые продуктом имеют аналитические отчёты, умеют критиковать и (как максимум!) "готовить предложения" за рамками своих аналитических обязанностей, или готовить инженеров, которые на выходе меняют физический мир -- и принимать ответственность за эти изменения, а не ходить на поклон к инженерам, которые милостиво согласятся с "рекомендациями" аналитиков. Университеты да, готовят исследователей -- воспроизводят себя, но в случае инженеров надо всё-таки понимать, что аналитики -- это не исследователи, это что-то другое. Как вы лодку назовёте, так она и поплывёт: меняйте в ваших рабочих должностях, учебных программах и всём остальном слова "аналитик" и "анализ" на "инженер" и "инженерию" -- разница будет драматической.
Большой доклад Вячеслава Мизгулина был по инженерии организационных систем (больших: девелоперский холдинг, имеющий порядка ста проектов в разработке), и инженерии личности -- ибо оказалось, что речь идёт и об оргразвитии, и о развитии персонала. А вот дальше речь пошла не столько обо всей инженерии организации и инженерии личности, где надо было бы подробно рассматривать что там с функциональной архитектурой, но об эволюционной организации -- и там под самыми неожиданными терминами скрывались и архитектурные решения (замаскированные под всякие "принципы" и "ценности") и архитектурные характеристики -- всяческие "-ости". Цель эволюционной архитектуры организации и личности -- выживание на быстро изменяющемся ландшафте приспособленности, удержание этой приспособленности.
Одна из важных идей тут -- следование общим принципам разделения труда в системной инженерии. Так, надо чётко рисовать граф создателей, но в нём команды функциональных проектировщиков и оргпроектировщиков, а отдельно -- визионеров и архитекторов, уровнем выше. И там весь этот разговор про рекурсивность/безмасштабность (общие принципы на всех уровнях: холдинга, его подразделений, а затем людей в этих подразделениях) и эволюционность/итеративность (надо не только выжить сейчас, но и выжить в будущем, как говаривал Голдратт -- "деньги сейчас и в будущем"). Мы пока это не обсуждали так ярко, ибо не было прописано ещё такого детального разделения труда, как сегодня в курсе "Системная инженерия". А теперь ситуация становится прозрачной, чётче видно -- где решения более-менее современные, а где "есть вечные проблемы" -- но мы сегодня понимаем, как эти проблемы могут решаться. Организация и личность должны работать сегодня и в будущем, за это ответственны архитекторы в части конструкции, а в части целевой системы -- визионеры.
В девелоперском холдинге интересен ответ, почему довольно легко удалось поменять понимание продукта -- с торговли домами на торговлю счастливой жизнью. Советчиком тут были те самые "деньги в будущем": инвестиционный спрос (когда покупают, но не живут -- качество жизни не обсуждается, но можно обсудить "транспортную доступность") по всем кривым свёлся к нулю, ибо кто такое хотел купить -- уже купили. И остаётся только спрос на то жильё, где можно жить лучше, чем живёшь сейчас, но по минимальной цене. Инвестиционный рынок вдруг стал потребительским. И тут либо компания быстро помирает, либо меняется. Смена продукта иногда удаётся, иногда нет -- мы помним Nokia, которая пережила несколько раз кардинальную смену продукта, а один раз стала мировым лидером, а смены продукта не пережила. За то, чтобы компания это пережила, отвечают несколько разных служб, где прячутся архитекторы разных объектов:
-- архитектор должен сделать так, чтобы в компании могли идти реформы. Если нет модульности и "всё со всем связано", то реформы идти не могут. Компания вымрет. А ещё архитектор отслеживает архитектурные характеристики компании в целом. Этих характеристик (мы обсуждали это все два дня) порядка 100 известных из литературы, и они общие для систем самой разной природы, в учебниках и стандартах их обычно даётся порядка 30, а лучшая практика -- взять 3-4 важнейших для проекта и их тщательно отслеживать, а остальное всё -- делать, но "на отвяжись".
-- HR оказывается в том числе архитектором сообщества (там, похоже, сильно составная должность, как product manager) должен сделать так, чтобы сотрудники::сообщество эти реформы могли выдержать. Тут сразу три вопроса: корпоративная культура, поощряющая изменения и готовность к изменениям (learning organizations, толерантность людей и компьютеров к быстро меняющимся обстоятельствам, тут ещё и CIO неожиданно: это же HR для сотрудников-нежити!), готовность и возможность учиться (интеллект сотрудников, он оказывается архитектурной характеристикой -- и тут вопрос, как его получить? Ответ: учить. Интеллекту можно учить, но это годичные программы, а не трёхдневные, и ещё тут оказывается, что всякий career planning и многоуровневый кадровый резерв -- он прежде всего про это, ибо при карьерном росте растёт масштаб проектов, повышается число предметных областей, с которыми надо иметь дело, а это как раз интеллект), и неожиданно -- внимание к организму, где есть два подпункта: какая-нибудь прикладная физическая культура, ибо без неё нельзя держать умственные нагрузки долго, мощности организма не хватает, а ещё медицинская культура, и речь тут даже не о "закаливании для защиты от ОРВИ", а о неприятных штуках типа синдрома усталости надпочечников (синдром хронической усталости, разные "выгорания" -- это оно), мутное место в медицине (анализы его частично берут -- кортизол и его прекурсоры, уровни некоторых витаминов, уровни железа), а вот лечить -- главное средство тут БАДы и реальный отдых, причём иногда этот "отдых" может и пару лет занять, хотя сломаться можно месяцем выхода в ночь на сверхурочные. Тут граница между "психологией" и "физиологией" очень зыбкая, часто кажется, что это какие-то аспекты лени или отношения к работе, но нет, чистая биохимия, причём в которой современная медицина не разобралась, хотя и признаёт проблему.
-- ещё это должно быть поддержано на уровне команд, ибо там же надо делать перефункционализацию сотрудников, доучивать-переучивать предметной области. Это существенно пересекается с темой регламентации работы (проектирование методов работы, "рабочих процессов"), организации этой регламентации и обучению выполнения регламентов, поддержки регламентов в IT и соответствующей культурой задействования обычно того же Excel для моделирования и issue tracker для управления работами. Это оргизменения в их обычном понимании.
Когда буду переписывать "Инженерию личности" и "Системный менеджмент" придётся тут разбираться более подробно. Про личность в целом у меня ещё особо ничего в этих курсах нет, больше про прикладное мастерство, хотя приложимо всё только к прикладному, но и к фундаментальному мастерству мышления, но тут идём выше уровня мастерства на архитектурные характеристики личности в целом -- все эти "--ости", включая "агентность", "умность", "вменяемость", "эрудированность" как наличие кругозора, скользкая характеристика "лояльность", и т.д. -- все эти характеристики "воспитатели" в классических учебных заведениях знают, а также знают HR, но с учётом "Системной инженерии" можно говорить об этом более внятно и наводить какую-то рациональность. Сейчас у психологов процветают разные классификации, где ничего нет из причинно-следственных связей и воспроизводимости процессов, определяемых на основе этих классификаций -- обычно это всякие "теории развития" со стадиями развития личности (спиральная динамика, интегральная психология и ещё миллион других "ступеней зрелости", красиво подающихся в книжках, но одинаково невоспроизводимых в жизни), а также разные идеи "мыслительных типов в одной команде" (привет Адизесу, тут тоже миллион подобных классификаций и на их основе непроверяемые эвристики. Грубо говоря, "берём команду из всех знаков зодиака, это будет идеальная 2 pizza team" -- каждый первый психолог генерирует подобного сорта художественные сюжеты, а потом пишет книги, потом менеджмент всего мира пытается такое реализовать, даже не задумываясь -- почему такое должно работать. И да, объяснения "на метафорах"). А в "Системном менеджменте" надо будет тоже рассказать подробней про архитектуру, про коллектив как команду команд, про сообщество сотрудников как отдельную заботу архитектора.
А ещё мне в очередной раз подарили бумажную книжку Г.П.Щедровицкого "Я всегда был идеалистом...", издание 2002 года с почти сотней фотографий. И в очередной раз мы пообедали в "Джаганнате", там как раз напротив места заседаний. В следующем году надо будет эту рабочую встречу опять повторить, в шестнадцатый раз.
Заметки по предыдущим встречам:
XIV (2024) -- https://ailev.livejournal.com/1718668.html
XIII (2023) -- https://ailev.livejournal.com/1681434.html
XII (2022) -- https://ailev.livejournal.com/1623518.html
XI (2021) -- там тоже заметки по моему докладу про содержание курса "Системная инженерия", курса тогда не было, только обсуждалась постановка задачи, зато требования ещё были и эволюционной архитектуры в обсуждениях не было. Как сильно всё изменилось! Вот: https://ailev.livejournal.com/1563471.html
Я там тоже сделал доклад -- рассказал о новом курсе "Системная инженерия", доклад шёл вперемешку с горячей дискуссией где-то пять часов в первый день. В этом докладе я дал две части:
-- почему нельзя учить системной инженерии сразу, какие там пререквизиты, почему нынешние вузовские программы обучения инженерии крайне неэффективны. Полная программа обучения инженера, в составе которой есть и курс "Системная инженерия". Как нам удаётся учить по курсу системной инженерии гуманитариев (HR, маркетинг, юристов).
-- состояние современной системной инженерии, отражённое в курсе.
По итогам обсуждения я понял, что надо дать больше синонимов для мантр -- чеклист (по Gawande это, конечно, чеклист, хотя это не те чеклисты, которые мы даём по альфам, поэтому может немного путаться), по "убираем после вышивки" -- это канва, по "во всех пунктах всё должно быть согласовано и подставлено" -- это уравнение, по фокусировке ума и повторяемости -- мантра, по последовательности рассказа -- сюжет. И надо дать примеры подставновки значений. Иначе механизм работы с типами мета-мета-модели и мета-модели плохо понимаются, как и механизм обобщения и обфускации при переходе от типов мета-модели к типам модели. Нет понимания моделирования -- нет понимания вообще ничего, моделирование понимаем на этих четырёх чеклистах/канвах/уравнениях/мантрах. Так что буду переделывать материал семинара по мантрам, а также вставлю этот кусочек в семинар по курсу системной инженерии.
Основные вопросы были не к требованиям, не к архитектуре, не к инженерным обоснованиям, а по новому материалу: прежде всего инженерия как проектирование "с первого раза" против инженерии методом проб и ошибок, а ещё идея динамического ландшафта приспособленности. Вроде как разобрались в том, что в сложных проектах там спектр по шкале "oracle, full knowledge -- trial and error, no knowledge", у меня там как раз нашлась красивая картинка из https://www.nature.com/articles/s41467-024-48000-1, даю её в курсе, рассказывая об инженерном процессе как техно-эволюции:
Подходы к проектированию в нижнем левом углу имеют небольшое количество вариантов (размеров популяции) и циклов проектирования (поколений). Они требуют значительных предварительных знаний для успешного проектирования с оракулом, способным создать идеальный дизайн за одну попытку. Подходы к проектированию в верхнем правом углу мало используют предварительные знания и обучение, требуют меньшей способности к развитию, и их поиск менее ограничен. Метод проб и ошибок (без предварительных знаний) попадает в эту крайность, где для проектирования нетривиальных систем требуются гиперастрономические масштабы. Все остальные методы проектирования расположены между этими крайностями, и даже в случае SpaceX часть проб и ошибок -- это важная часть, ибо там речь идёт о принципиально важных новых изменениях в конструкции, а не улучшениях старой конструкции. То, что там новые корабли взрываются в ходе проб и ошибок, но взрываются в довольной быстрой для космоса последовательности -- это инженерно и рыночно оказывается много лучше, чем "первый же взлёт -- успешен" при многолетнем проектировании "для стопроцентной надёжности" (которой, как известно, никогда не бывает). Да, "человечество разучилось рисковать", как сказал когда-то Элон Маск, начал рисковать, и опередил огромное число других космических фирм, да и не космических фирм тоже. Политика у него политикой, а инженерия -- инженерией.
В конце заседания мы поговорили с Кириллом Гайдамакой о том, как проектируется современный электромобиль, обнаружили этот самый спектр (и договорились, что об этом будет его доклад на нашей девятой конференции ШСМ "Современный системный менеджмент и инженерия-2025": https://ailev.livejournal.com/1749524.html):
-- железо проектируется "традиционным проектированием" (не "водопад", но близко -- там очень стабильные описания того, что такое "хороший автомобиль", очень стабильные и известные архитектурные решения, full knowledge)
-- программно-аппаратный комплекс электрической части и части управления -- тут классический SAFe инженерный процесс, застрявший на полпути между старинным и современным, и там уже ближе к agile как constrained trial and errors. Какое-то знание предметной области есть, но оно не так чтобы стабильно и оказывается не всегда верным.
-- программная часть "в облаке", и вот там уже можно попробовать сотню раз сотрю вариантов, это ближе к breeding, генетическим алгоритмам, "полный agile", знания о том, что же такое "облачная часть электромобиля" особо нет.
Ещё у этой весьма специфической аудитории был интерес к инженерии платформы рамках DevOps (путешествие по графу создателей, где всегда он устроен чуть более кучеряво, чем представляется изначально), и как специфически организовано разделение труда между архитекторами и визионерами (уровень коллектива к команде команд) и разработчиками в команде (проектировщиками, методологами, технологами), ибо термин "разработчики" используется в двух значениях -- "разработчики системы в целом" (коллектив инженеров, отличаем от коллектива менеджеров, продвиженцев и т.д.) и "разработчики набора фич" (разработчики в команде одной крупной архитектурной части-модуля).
Обсуждение шло на современном уровне, в кулуарах после встречи отмечали, что трудно даже представить, какой прогресс в уровне обсуждений. Один из участников -- системный инженер, опытный руководитель, но когда он говорил, это были идеи 2010 года, и это было очень наглядно: вроде бы слова уже все те же самые, но акценты расставляются совершенно по-другому. И забавно выглядели некоторые замечания вроде, что "давайте обсуждать русскоязычные термины, что нам эти англоязычные различия между safety-безопасность и security-безопасность". Вежливо ответили, что лучше бы различать, и лучше бы студентов учить и англоязычным терминам -- чтобы могли читать современную англоязычную литературу прямо из постов в блогах (ибо все даже книги уже безнадёжно отстают), а не отсутствующие современные русскоязычные источники информации.
В очередной раз Антон Королёв рассказал, как готовят системных инженеров в МИРЭА (и там ему помогают несоколько членов директората INCOSE RUS, и даже читаются некоторые курсы из программы оргразвития ШСМ). В этом году было продемонстрировано, что студенты получают знание полного (а не кусочного, как раньше) инженерного процесса, с выходом не только на имитационное моделирование, но и на учебную аппаратуру (самоуправляемые тележки). Упор там на инженерные обоснования, причём в варианте разных стандартов формального представления (стандарты безопасности, близкие по духу к архитектурным стандартам). В этом году стало понятно, что учебная программа как-то устаканилась -- за счёт отказа от идеи "одного инструмента, одного репозитария" лучше получается знакомить с идеями, а не формами представления идей (формы неважны!), а заземление на реализацию даёт совершенно другой уровень подготовки. Ещё там обсуждался выход студентов на работу на заводах -- шаг на работу в "настоящих проектах" вроде "системы МФТИ" с их базовыми предприятиями кафедр. Пока же -- моделирование на деталях конструкторов со всякими ардуинами, подключёнными к нормальным компьютерам. Моделирование на Matlab, но мой совет был -- переходить уже к https://info.juliahub.com/products/juliasim, это следующее за Modelica поколение средств моделирования (и там достаточно всего open source). Ещё один совет -- выкинуть из названий учебных программ все эти "анализы", ибо надо или готовить аналитиков, которые продуктом имеют аналитические отчёты, умеют критиковать и (как максимум!) "готовить предложения" за рамками своих аналитических обязанностей, или готовить инженеров, которые на выходе меняют физический мир -- и принимать ответственность за эти изменения, а не ходить на поклон к инженерам, которые милостиво согласятся с "рекомендациями" аналитиков. Университеты да, готовят исследователей -- воспроизводят себя, но в случае инженеров надо всё-таки понимать, что аналитики -- это не исследователи, это что-то другое. Как вы лодку назовёте, так она и поплывёт: меняйте в ваших рабочих должностях, учебных программах и всём остальном слова "аналитик" и "анализ" на "инженер" и "инженерию" -- разница будет драматической.
Большой доклад Вячеслава Мизгулина был по инженерии организационных систем (больших: девелоперский холдинг, имеющий порядка ста проектов в разработке), и инженерии личности -- ибо оказалось, что речь идёт и об оргразвитии, и о развитии персонала. А вот дальше речь пошла не столько обо всей инженерии организации и инженерии личности, где надо было бы подробно рассматривать что там с функциональной архитектурой, но об эволюционной организации -- и там под самыми неожиданными терминами скрывались и архитектурные решения (замаскированные под всякие "принципы" и "ценности") и архитектурные характеристики -- всяческие "-ости". Цель эволюционной архитектуры организации и личности -- выживание на быстро изменяющемся ландшафте приспособленности, удержание этой приспособленности.
Одна из важных идей тут -- следование общим принципам разделения труда в системной инженерии. Так, надо чётко рисовать граф создателей, но в нём команды функциональных проектировщиков и оргпроектировщиков, а отдельно -- визионеров и архитекторов, уровнем выше. И там весь этот разговор про рекурсивность/безмасштабность (общие принципы на всех уровнях: холдинга, его подразделений, а затем людей в этих подразделениях) и эволюционность/итеративность (надо не только выжить сейчас, но и выжить в будущем, как говаривал Голдратт -- "деньги сейчас и в будущем"). Мы пока это не обсуждали так ярко, ибо не было прописано ещё такого детального разделения труда, как сегодня в курсе "Системная инженерия". А теперь ситуация становится прозрачной, чётче видно -- где решения более-менее современные, а где "есть вечные проблемы" -- но мы сегодня понимаем, как эти проблемы могут решаться. Организация и личность должны работать сегодня и в будущем, за это ответственны архитекторы в части конструкции, а в части целевой системы -- визионеры.
В девелоперском холдинге интересен ответ, почему довольно легко удалось поменять понимание продукта -- с торговли домами на торговлю счастливой жизнью. Советчиком тут были те самые "деньги в будущем": инвестиционный спрос (когда покупают, но не живут -- качество жизни не обсуждается, но можно обсудить "транспортную доступность") по всем кривым свёлся к нулю, ибо кто такое хотел купить -- уже купили. И остаётся только спрос на то жильё, где можно жить лучше, чем живёшь сейчас, но по минимальной цене. Инвестиционный рынок вдруг стал потребительским. И тут либо компания быстро помирает, либо меняется. Смена продукта иногда удаётся, иногда нет -- мы помним Nokia, которая пережила несколько раз кардинальную смену продукта, а один раз стала мировым лидером, а смены продукта не пережила. За то, чтобы компания это пережила, отвечают несколько разных служб, где прячутся архитекторы разных объектов:
-- архитектор должен сделать так, чтобы в компании могли идти реформы. Если нет модульности и "всё со всем связано", то реформы идти не могут. Компания вымрет. А ещё архитектор отслеживает архитектурные характеристики компании в целом. Этих характеристик (мы обсуждали это все два дня) порядка 100 известных из литературы, и они общие для систем самой разной природы, в учебниках и стандартах их обычно даётся порядка 30, а лучшая практика -- взять 3-4 важнейших для проекта и их тщательно отслеживать, а остальное всё -- делать, но "на отвяжись".
-- HR оказывается в том числе архитектором сообщества (там, похоже, сильно составная должность, как product manager) должен сделать так, чтобы сотрудники::сообщество эти реформы могли выдержать. Тут сразу три вопроса: корпоративная культура, поощряющая изменения и готовность к изменениям (learning organizations, толерантность людей и компьютеров к быстро меняющимся обстоятельствам, тут ещё и CIO неожиданно: это же HR для сотрудников-нежити!), готовность и возможность учиться (интеллект сотрудников, он оказывается архитектурной характеристикой -- и тут вопрос, как его получить? Ответ: учить. Интеллекту можно учить, но это годичные программы, а не трёхдневные, и ещё тут оказывается, что всякий career planning и многоуровневый кадровый резерв -- он прежде всего про это, ибо при карьерном росте растёт масштаб проектов, повышается число предметных областей, с которыми надо иметь дело, а это как раз интеллект), и неожиданно -- внимание к организму, где есть два подпункта: какая-нибудь прикладная физическая культура, ибо без неё нельзя держать умственные нагрузки долго, мощности организма не хватает, а ещё медицинская культура, и речь тут даже не о "закаливании для защиты от ОРВИ", а о неприятных штуках типа синдрома усталости надпочечников (синдром хронической усталости, разные "выгорания" -- это оно), мутное место в медицине (анализы его частично берут -- кортизол и его прекурсоры, уровни некоторых витаминов, уровни железа), а вот лечить -- главное средство тут БАДы и реальный отдых, причём иногда этот "отдых" может и пару лет занять, хотя сломаться можно месяцем выхода в ночь на сверхурочные. Тут граница между "психологией" и "физиологией" очень зыбкая, часто кажется, что это какие-то аспекты лени или отношения к работе, но нет, чистая биохимия, причём в которой современная медицина не разобралась, хотя и признаёт проблему.
-- ещё это должно быть поддержано на уровне команд, ибо там же надо делать перефункционализацию сотрудников, доучивать-переучивать предметной области. Это существенно пересекается с темой регламентации работы (проектирование методов работы, "рабочих процессов"), организации этой регламентации и обучению выполнения регламентов, поддержки регламентов в IT и соответствующей культурой задействования обычно того же Excel для моделирования и issue tracker для управления работами. Это оргизменения в их обычном понимании.
Когда буду переписывать "Инженерию личности" и "Системный менеджмент" придётся тут разбираться более подробно. Про личность в целом у меня ещё особо ничего в этих курсах нет, больше про прикладное мастерство, хотя приложимо всё только к прикладному, но и к фундаментальному мастерству мышления, но тут идём выше уровня мастерства на архитектурные характеристики личности в целом -- все эти "--ости", включая "агентность", "умность", "вменяемость", "эрудированность" как наличие кругозора, скользкая характеристика "лояльность", и т.д. -- все эти характеристики "воспитатели" в классических учебных заведениях знают, а также знают HR, но с учётом "Системной инженерии" можно говорить об этом более внятно и наводить какую-то рациональность. Сейчас у психологов процветают разные классификации, где ничего нет из причинно-следственных связей и воспроизводимости процессов, определяемых на основе этих классификаций -- обычно это всякие "теории развития" со стадиями развития личности (спиральная динамика, интегральная психология и ещё миллион других "ступеней зрелости", красиво подающихся в книжках, но одинаково невоспроизводимых в жизни), а также разные идеи "мыслительных типов в одной команде" (привет Адизесу, тут тоже миллион подобных классификаций и на их основе непроверяемые эвристики. Грубо говоря, "берём команду из всех знаков зодиака, это будет идеальная 2 pizza team" -- каждый первый психолог генерирует подобного сорта художественные сюжеты, а потом пишет книги, потом менеджмент всего мира пытается такое реализовать, даже не задумываясь -- почему такое должно работать. И да, объяснения "на метафорах"). А в "Системном менеджменте" надо будет тоже рассказать подробней про архитектуру, про коллектив как команду команд, про сообщество сотрудников как отдельную заботу архитектора.
А ещё мне в очередной раз подарили бумажную книжку Г.П.Щедровицкого "Я всегда был идеалистом...", издание 2002 года с почти сотней фотографий. И в очередной раз мы пообедали в "Джаганнате", там как раз напротив места заседаний. В следующем году надо будет эту рабочую встречу опять повторить, в шестнадцатый раз.
Заметки по предыдущим встречам:
XIV (2024) -- https://ailev.livejournal.com/1718668.html
XIII (2023) -- https://ailev.livejournal.com/1681434.html
XII (2022) -- https://ailev.livejournal.com/1623518.html
XI (2021) -- там тоже заметки по моему докладу про содержание курса "Системная инженерия", курса тогда не было, только обсуждалась постановка задачи, зато требования ещё были и эволюционной архитектуры в обсуждениях не было. Как сильно всё изменилось! Вот: https://ailev.livejournal.com/1563471.html
