Русское (по языку, а не по стране) отделение INCOSE продолжает работать по-прежнему, игнорируя любые санкции и попытки остановить жизнь, работу, исследования и общение. Собрались на очередную (уже четырнадцатую) рабочую встречу, хотя нам отказали в уже оплаченном месте в Бекасово, ибо туда принимали эвакуированые семьи из Белгородской и Курской областей – но мы просто встретились в Москве и посидели пару дней, 5-6 апреля 2024. Я отношусь к этому как “раз в год мы ходим с друзьями в баню”.
Посидели пару дней на XIV рабочей встрече INCOSE RUS по проблемам системной инженерии. Я там сделал доклад (он шёл четыре часа, записи не вели намеренно – кто хотел послушать, все пришли, и даже из разных городов) по изменениям за прошедший год: что мы сделали в плане обучения системной инженерии. Основные результаты:
– мы практически всех научились доучивать до специалиста: содержание наших программ понимается по факту всеми. Мы лет десять назад на встречах в Бекасово обсуждали, что системная инженерия не выучивается содержательно без предварительного знакомства с системным мышлением, а системное мышление не берётся без онтологии. В этом году мы окончательно решили эту проблему: курс “Моделирование и собранность” был объявлен пререквизитом к “Системной инженерии” (ещё и к моделированию была добавлена собранность, ибо оказалось, что надо научить ещё и работе с вниманием, причём организованным не “ментально”, а компьютерно), надо было изобрести как практически любую софтину или даже листок бумаги или стену сделать моделером, а также в девятой переписке курс системного мышления стал уже читаемым. Всё, проблема научения была более-менее закрыта.
– Мы сосредоточились на агентности, которая нужна для директоров по развитию: ход от специалиста (“всё знаю, понимаю, ничего не делаю, идеальный аналитик”) к практику (“со всеми договорился, работаю восхитительно, крепко сплю”) и далее к мастеру (“договорил всех вокруг себя в организации”) и даже реформатору (“начал договаривать всех вокруг организации, вышел за рамки фирмы”). Тут уже какие-то успехи, вроде бы понятно стало, как этому учить.
– Пошли корпоративные программы, когда учим сразу команду топ-менеджеров. Корпоративные программы показали, что мы ускоряем запуск организационных реформ на пару лет, при этом в основном инициатива исходит от наших мастеров, которые занимают позиции собственников, директоров по развитию, генеральных директоров предприятий. Это довольно неожиданный поворот, ибо раньше у нас ставка была на “розницу”, а не команды. Но оказалось, что у команд топ-менеджеров на базе общей мета-мета-модели (знаний наших курсов, клиенты это называют “общий язык”) согласования действий членов этих команд происходят в разы быстрее. И оргреформы идут значительно бодрее.
– Проблемы оказываются одними и теми же, что в софтверной разработке, что у машиностроителей: невозможность различить описание системы и целевую систему, поведение системы и систему, непонимание просьб по демонстрации причинно-следственных связей между собственными действиями и какими-то результатами для предприятия. Существенно увеличили время, которое тратим на вот эти вопросы (это ведь даже не системное мышление, не инженерия, не менеджмент – это семантика, онтология, собранность).
– Один из самых больших успехов – выучили команду топов-гуманитариев, это показывает силу методики обучения. Это стало возможным после курса “Инженерия личности”, ибо гуманитарии обращают внимание на системную инженерию как общий метод изменения мира только после примера инженерии личности, примеры из железной инженерии и программной инженерии им непонятны. В итоге курс “Системная инженерия” был назван самым интересным изо всей нашей линейки курсов и дающим максимальное количество инсайтов для одного из топ-менеджеров с гуманитарным образованием. Наши мечты “люди поймут важность системной инженерии, если мы будем не просто рекламу давать, а будем нормально системной инженерии учить”, которые мы тут высказывали много лет на встречах в Бекасово, оказались таки реализованными.
– Важно понимать, что происходит дальше: дали краткую характеристику курсов четвёртого-пятого семестров (и получили от участников встречи отклик: всё это буквально из жизни). Например: после третьего семестра все наши участники говорят, что их жизнь удалась, они решили множество проблем, стали умней, им стали это замечать, их тревожность упала. И потом у них начинаются проблемы с телом – через пару-тройку месяцев после выпуска. Они начинают “вывозить”, а “кто везёт – на того и наваливают”, дальше от возросшей нагрузки (обычно им попадает в управление большая толпа людей, и от всех людей начинают прилетать срочные проблемы, которые не помещаются в нормальный рабочий день) банально начинает сдавать тело. Ещё у них остаются эпистемологические проблемы, остаются некоторые коммуникативные проблемы – и это всё надо залатывать. Так что для хода от мастера к реформатору надо продолжать развивать нашу учебную программу 4-6 семестров. И ещё доделать новую инженерию – инженерию сообществ.
– и много обсуждали новую терминологию методологии: как это помогает решить множество проблем (метод/способ/культура/стиль работы в их отличиях от собственно работы/действий – метод работы скажешь, а деятельность работы – нет, и это важно, практика тут промежуточная – можно и сказать, и не сказать, и это минус, как со “стейкхолдером”).
Доклад про SAFe в отечественном автомобилестроении (команда из примерно 1000 человек) Кирилла Гайдамаки:
– карьерный рост прямо как мы описываем: делаешь пару правильных действий, тебя тут же замечают, у тебя появляется офис развития, ты стартуешь реформы (в данном случае – agile в автомомобилестроении, а именно SAFe. Кстати, в наших курсах отсылки к SAFe разных версий есть). Далее очень быстро наступают проблемы с телом – и хорошо, что мы уже как-то учим обращать на это внимание, не игнорировать. Но одно дело “обращать внимание”, а другое дело – надо всё-таки давать полноценный курс на эту тему.
– SAFe в его отличии от классического водопада и V-модели. Поговорили о том, как раскладка ролей и практик кладётся на SAFe – всё вполне адекватно, SAFe как раз учитывает современные тренды. Одно из главных отличий – это то, что на верхнем уровне не происходит никаких решений кроме архитектурных (раскладка по модулям и командам), нет существенной функциональной декомпозиции. Архитекторы декомпозицию делают до уровня, когда надо назначить какие-то ART (Agile Release Train, несколько команд разработчиков как долгосрочная команда), а сами фичи контролируют visionaries – product owners. В итоге получается “сетевая” (более-менее плоская) структура разработчиков, которая как-то асинхронно занимается разработкой самых разных фич.
– проблемы: хардверщики всё-таки плотно сидят на водопаде, переход на SAFe сначала идёт у тех, кто занимается софтом автомобиля. Иностранцы (в команде они есть) не понимают, почему даже софтверщики хотят использовать водопад, не понимают медленности разворота к практикам SAFe – “это же всё так естественно”. Но для основной массы разработчиков (пока в оргреформе затрагивается до пятисот человек) все решения – контринтуитивны, так что проект идёт не слишком быстро. И там обычные проблемы, которые нам всем давно известны (например, острое желание назвать первый ART не “первым рабочим”, а “пилотным”, “опытным” и т.д. – то есть изобразить оргреформу так, что она касается не реальной работы компании, а происходит где-то там сбоку, что её можно быстро аннулировать, принять какие-то отдельные решения по переносу результатов в основную деятельность, ибо это ж ещё не основная работа, а “пилот” и т.д.).
– ключевое тут в разделении труда: масса команд разработчиков, но выделение “вертикали власти” из архитекторов и продакт-менеджеров, а также связь с оргразвитием: SAFe подразумевает “виртуальную оргструктуру” (все эти ART), которая наложена на реальную оргструктуру, а также понимание, что можно разобрать SAFe на отдельные решения, а не обязательно осваивать полную цельную методологию.
Отдельный был доклад Кирилла про опыт западного автомобилестроения, а именно Tesla (как продвижение по той же линии, что SAFe, но SAFe при этом выглядит разве что не допотопным водопадом). Вот несколько важнейших моментов, мне всё время приходится их обсуждать в реальных командах (это же сейчас общее место в инженерии, но все эти моменты дико контринтуитивны):
– ключевое – это скорость изменений (и это то, на чём спотыкаются многочисленные конкуренты Tesla, банально не успевают стать дешевле и лучше). Изменения делаются асинхронно во всех частях системы сразу, поэтому важным является нарезка на модули и определение интерфейсов, архитектурная работа. Изменяется модуль (меняем конструкцию, не меняя сервиса). Если меняется сервис, то команды договариваются по поводу нового “контракта” на интерфейсе. И делают тесты, всё начинается с этих тестов, даже для аппаратуры. На входе и выходе интерфейса делается проверка того, что полученное и отданное соответствует стандарту.
– чёткие показатели, для которых делаются изменения (и эти показатели вполне заменяют менеджеров, они показывают, куда двигаться – например, масса конструкции, энергоэффективность, стоимость). Императив: если известно, как улучшить – обязан улучшить! Закупки инструментария и материалов облегчены, ибо каскадирование обычного бюджетирования и постановки целей – смерть для атомизации изменений.
– маршрут конвейера расщепляется для проверки гипотезы о потенциальном улучшении – туда отправляется всё больше и больше экземпляров подсистем (и системы в целом), и если изменение хорошо, то в конечном итоге отправляется весь поток. Проблема: а вдруг результаты выскочат не прямо сейчас, а позже – в ходе эксплуатации? Поэтому каждый автомобиль имеет цифрового двойника. И ещё это означает, что нет двух одинаковых автомобилей, ибо все они прошли разные маршруты сборки, и там разные улучшения.
– нет отдельного КБ и завода (эх, я вот буквально месяц назад ругался с машиностроителями, что у них на производстве нет терминала с выходом в конструкторские САПРы и PLM), вся разработке ведётся прямо на заводе, помодульно. Как определить, где ограничение на заводе? Где лежит спальный мешок Элона Маска – там и ограничение. А ещё если делать каждый раз новый маршрут конвейера под улучшения в модулях, то нужно особым образом проектировать завод чисто логистически, чтобы было легко перемаршрутизировать потоки сборки.
– … и ещё много интересного. Кирилл рекомендовал материалы Joe Justice (Joe Justice tesla - Google Zoeken – этих материалов много).
Ещё был доклад про организационное моделирование крупного строительного холдинга. Целевые системы были никак не отражены, языком моделирования был Archimate (хотя признались, что сами моделируют на экселе, но вовне везде таскают картинки), собственно инженерия не обсуждалась, разговор вёлся на внутреннем сленге, изменений в подходах по сравнению с прошлым годом не было замечено – и доклад банально не дослушали, настолько он отличался от предыдущих докладов, звучал как привет из разговоров десятилетней давности. Пообсуждали, что это только тормоза в собственных мозгах, а не “объективные причины” не позволяют вот просто брать методы современной работы (которые мы обсуждали два дня), и осваивать их на каких-то предприятиях. Никаких оправданий, что “это не про нас, у нас всё заскорузлое”. Да, заскорузлое, но просто берём – и делаем незаскорузлым.
Потом в кулуарах обсуждали, что счастье – понимать, что там передового в мире и обсуждать, как мы берём этот передовой опыт и пытаемся с ним работать, не застреваем в идеях 20-летней давности (которые нам же казались очень крутыми ещё 10 лет назад).
В воскресенье должны были обсудить вузовское образование по системной инженерии, но докладчик заболел – и решили перенести эти обсуждения на восьмую конференцию “Современный системный менеджмент и инженерия-2024” ШСМ – Конференция 2024
Бекасово отличалось всегда шикарной едой. Как обстояло дело с едой на нашей посиделке? Покушали мы в Джаганнат (веганский магазин и кафе в 50 метрах от офиса, где мы заседали, а офис в 2 минутах пешком от Белорусской кольцевой) – быстро, вкусно, довольно необычно. Так что эта часть встречи тоже не подкачала. Картинка из окна офиса, где мы заседали – выставка старых трамваев на площади перед Белорусским вокзалом, история отечественной транспортной инженерии. Мы, к счастью, историю не обсуждали, обсуждали будущее.
