1 марта 2026 · Запись

Развитие для развитых в Мастерской инженеров-менеджеров

В МИМ мы различаем: * образование (его вроде как получают однократно, "чтобы дети вошли в развитое человеческое общество"). Стационарный ландшафт целей (какие-нибудь редко изменяющиеся "федеральные образовательные стандарты"). Результат -- сертификат "выпуска". * постоянное обучение (continuous learning -- мысль о том, что учиться надо как-то и после того момента, как ты получил образование, совершенствоваться в своей профессии можно всю жизнь) -- цели дрейфуют, это признаётся. Всю жизнь надо к этим целям подруливать, они не слишком стабильны. Если вы пробегали за 10 секунд стометровку сто лет назад, это был бы мировой рекорд. Сейчас так бегать для рекорда уже недостаточно, учитесь! Результат -- непрерывно пополняемый набор приёмов достижения непрерывно растущего результата, "победитель десяти олимпийских игр подряд". * бесконечное развитие (open-ended evolution, выбор всё более и более трудных проблем для их решения, приобретение всё более и более отточенного мастерства для решения этих проблем). Цели меняются, не прозевайте момента, когда их надо менять! И развитие тут -- рост числа возможностей, достижимых в решении классов проблем. Результат -- растущий портфель удачных интервенций во всё более сложных ситуациях. В Мастерской инженеров-менеджеров принят подход развития для развитых, основанный на идеях бесконечного развития (open-ended evolution, open-endedness). Мы даём уже опытным специалистам способность быстрее входить в новые проекты, быстрее строить рабочие модели, проводить хорошо спланированные инженерные и организационные интервенции, а также превращать свои успехи в переносимые между проектами знания — так, чтобы усложнение решаемых проблем становилось для них нормой, а не кризисом. Этот подход "бесконечного развития" отличается от повсеместно принятого в образовании подхода Agile в сочетании с MVP из lean startup. Для образования обычно бралось MVP какого-то мастерства как "цель", затем как-то итеративно получали MVP этого мастерства -- и отправляли выпускника с этим MVP работать. В случае МИМ примерно так и делали, когда он был Школой системного менеджмента: продуктом там было мастерство инженеров-менеджеров, в том числе мастерство быстро разбираться с проблемами всё новых и новых областей. Такое мастерство обычно называют "интеллект". ШСМ прежде всего занималась усилением интеллекта своих "студентов" (многие из которых уже были вполне развиты -- директора и собственники предприятий, инженеры-архитекторы, опытные консультанты по проектному управлению), затем давала общие знания по инженерии и менеджменту -- и всё, выпуск. Когда МИМ был Школой системного менеджмента, как и в любом университете, там был именно учебный процесс с учебными заданиями, и были "выпускники". Можно было "выучиться", и всё, процесс закончен, "образован" -- пополняй ряды alumni, как в университетах. Agile -- отличный подход, итеративная разработка отлично ускоряет улучшение для заранее выбранной цели (этот подход появился в заказной разработке программного обеспечения -- "заказали -- получили"). Подход Agile (00-е годы) в середине 10-х годов дополнился продвинутым способом организации инженерного процесса -- "непрерывным совершенствованием" на основе воспроизводимой и дешёвой поставки с откаткой. В бизнесе это были самые разные школы continuous improvement (циклы PDCA, POOGI и множество аналогичных), которые существовали задолго до Agile и занимались улучшением рабочих процессов и продуктов на длинном горизонте, но мало кто обращал внимание на два вопроса: (1) воспроизводимость и скорость разворачивания новых решений, (2) воспроизводимость и скорость сворачивания неудачных новых решений. DevOps/SRE и CI/CD в 2010-е — это индустриализация непрерывной поставки, а затем и эксплуатации: ускорение, удешевление и повышение надёжности цикла каких бы то ни было изменений (автоматизация тестов, сборки, "выката", наблюдаемости результатов, откатов в случае неудач). Agile отвечал за дисциплину итеративной разработки, CI/CD — за дисциплину воспроизводимой поставки, а continuous improvement — за постоянное улучшение характеристик продукта и процесса на протяжении лет. Если это применить к такому продукту, как "мастерство", то от "научить мастерству" (итеративно, быстро) переходишь к "непрерывному обучению" мастерству, "непрерывному совершенствованию мастерства". Фактически это подход спорта: вот ты умеешь складывать кубик Рубика, вот ты умеешь его складывать за пару минут, вот -- уже рекорд за двадцать секунд, но ведь и дальше возможны улучшения! В университетах стали делать курсы повышения квалификации для уже выученных, можно было прийти и поднять квалификацию по выбранному тобой мастерству. Этим же были заняты и многочисленные короткие курсы повышения квалификации. В системе медицинского образования и в проектном управлении вы должны были регулярно проходить такие курсы ("получать баллы"), чтобы подтверждать современность своей квалификации по выбранному мастерству. И это правильно, дисциплины дрейфуют, отражая дрейф окружающего быстро эволюционирующего мира. Например, первая экспертная система MYCIN была отлажена в ранних 70-х годах и давала рекомендации по назначению антибиотиков на уровне лучших врачей (что и породило неоправданные ожидания по экспертным системам). Но это было единоразовым достижением quality. Архитектурная характеристика evolvability для MYCIN оказалась плохой, архитектура не подразумевала изменяемости. Поэтому MYCIN не удавалось быстро улучшать, чтобы учитывать новые антибиотики и рост резистентности микробов к антибиотикам. Через пару лет MYCIN оказался "лучшим врачом двухлетней давности". Это общий класс провалов в проектах: когда единоразовое достижение quality без архитектуры удержания изменяемости/evolvability проигрывает на длинном горизонте. В образовании аналог -- выпускник, который освоил набор рецептов под вчерашние условия: без сильных универсальных методов мышления и без дисциплины регулярного обновления он деградирует со временем относительно изменяющегося мира, даже если когда-то был “лучшим в группе”. В лучших вузах "учили думать", то есть поднимали интеллект -- и тем самым поднимали evolvability. Ещё можно было после вуза непрерывно совершенствоваться на тех же курсах (а без вуза эти курсы оставались непонятными). МИМ (тогда ещё ШСМ) тут сразу поставил задачу прежде всего усилить интеллект, чтобы его инженеры-менеджеры могли адаптироваться к быстро меняющейся конкурентной ситуации и разбираться с самыми разными новыми проблемами. Это проходило под довольно необычным для классического образования слоганом "образование для образованных": старались заменить старую версию интеллекта, которую получили инженеры-менеджеры в своих вузах, на новую, современную (прежде всего акцент был на онтологическом моделировании, системном мышлении, методологии, системной инженерии). Важно, что "непрерывное совершенствование" предполагает более или менее стабильный "ландшафт целей". Известно, к чему стремиться -- как в спорте, вы знаете, что у вас будет на соревнованиях. Lifelong learning обычно означает поиск всё лучших и лучших способов решения известных проблем, учиться танцевать или делать лучшую в мире туалетную бумагу можно всю жизнь. Подход бесконечного развития, принятый сейчас в МИМ, отличается от предыдущих "образования" и "непрерывного обучения" тем, что заставляет налаживать два процесса: проблематизацию как поиск новых интересных проблем, всё более и более трудных для решения, а также поиск всё лучших и лучших решений этих проблем. Подход open-ended development (open-endedness, open-ended evolution) отличается от “непрерывного совершенствования” не просто тем, что “цели меняются”. Отличие сильнее: в open-ended режиме производство новых классов задач становится таким же регулярным и технологизируемым процессом, как и производство решений. То есть система развития должна уметь (1) генерировать и отбирать “достаточно трудные, но решаемые” (Goldilocks) проблемы, (2) находить решения, включая промежуточные stepping stones, которые пока не оптимальны по quality, но открывают новые области пространства решений, и (3) удерживать портфель разнообразия (diversity), чтобы не застревать в локальных оптимумах. В этой рамке прогресс — это не только рост quality по фиксированным метрикам, но и рост доступной новизны (novelty) и разнообразия решений/траекторий (diversity), которые расширяют будущие возможности. В отличие от "непрерывного совершенствования", развитие предполагает смену целей -- и поэтому изменение средств их достижения, методов работы и используемых инструментов. В спорте “непрерывное совершенствование” — это, условно, минус 0.1 секунды на той же дистанции: тот же Парето-фронт, то есть те же характеристики, только выше качество исполнения. А open-ended поворот — это смена самой поверхности Парето: когда человек-спортсмен перестаёт оптимизировать прежние характеристики и выбирает новый класс задач, где прежние достижения становятся лишь одним из ресурсов, а не целью. В спорте смена “поверхности Парето” видна особенно ясно на кейсах осознанного перехода в другой вид спорта. Например, Ребекка Ромеро: олимпийское серебро в гребле (Афины-2004), затем смена вида спорта в 2006, затем -- олимпийское золото в трековом велоспорте (Пекин-2008). Это не “стать на 0.1 секунды быстрее в той же дисциплине”, а сменить набор критериев успеха, тренировочную инфраструктуру и технику — при переносе части базовых capabilities на новую задачу. Пример инженера-менеджера: сильный специалист по “скорости поставки фич” (delivery), сознательно переспециализируется на роль, где основной результат — проблематизация и выработка стратегии по решению поставленных проблем (problem framing, R&D). Он не просто “делает лучше то же самое”, но строит своё новое мастерство под другой тип проблем и другую систему критериев. В случае инженерной разработки в целом такое, конечно, тоже есть, надо говорить о смене решаемой проблемы, отражающейся как смена стратегии (в венчурном бизнесе это обычно -- вираж/pivot): фирма получает мастерство решения другого сорта проблем. Так, Nokia занималась с 1865 года бумажным производством, потом занялась кабелями и резиной, потом выделила производство автомобильных шин из довольно большого конгломерата своих бизнесов, затем получила оглушительный успех на рынке мобильных телефонов, затем осталась занимать ведущие позиции на рынке инфраструктуры мобильной связи -- каждый раз при этом решая более сложные проблемы. NVIDIA перешла от рынка видеокарт к рынку ускорителей вычислений в искусственном интеллекте, Oracle от торговли программным обеспечением к торговле мощностями своих датацентров. Конечно, есть и "антипримеры" -- их особенно много на компьютерном рынке, где изменения крайне быстры (классический пример тут -- Kodak, не пережившая перехода фотосъёмки в сферу компьютерного бизнеса из сферы химии, но также и DEC, Compaq и множество других фирм, которые были слишком хороши в своих бизнесах, слишком оптимизированы, чтобы сохранить ту самую "изменяемость", evolvability при смене ситуации, когда условия изменились уже не "немного", а "существенно": надо было менять цели, сохраняя как-то свою идентичность). Бесконечное развитие всегда было, но обычно поиск новых проблем для решения не включался в инженерный процесс: он происходил (или не происходил, чеклиста ведь не было -- ибо чеклисты инженерных процессов и инженерная строгость по воспроизводимости и измеримости были только в инженерных процессах) "по наитию" или в формате "стратегирования" в довольно вольном, почти художественном изложении изучавших это "стратегирование" учёных менеджмента. Эволюция была, стратегирование было, но разговор был неформальным -- это не входило в инженерные процессы, в них было "получение обратной связи от пользователей" (а не поиск новых классов задач, этим занимались не инженеры). В образовании этот разговор вообще не поднимался. Университеты обрабатывали новые ситуации тем, что приглашали на работу новых преподавателей, которые начинали читать новые курсы новым студентам. Эти "новые курсы" воспринимались по линии "маркетинга новых программ", а не по линии развития нового мастерства студентов. По большому счёту, каждый студент мог "помочь себе сам", проходя какие-то вторые или даже третьи магистратуры -- и надеясь, что ему для облегчения его труда зачтут какие-то уже пройденные в предыдущих магистратурах курсы. Худо-бедно, это обеспечивало бесконечное развитие, но каждая магистратура при этом рассматривалась как единичный шаг с "выпуском", бесконечное развитие в рамках университетов практически не обсуждалось, идея была в "выпускниках", а сообщество alumni университета -- это не сообщество бесконечно развивающихся студентов, а сообщество развитых. Вторая магистратура рассматривалась как "единичный акт образования для образованных", никакого "бесконечного цикла", никакой проблематизации. Мастерская инженеров-менеджеров делает несколько новых шагов: * принимает идеи open-endedness всерьёз. Принятие всерьёз (по David Deutsch) -- это осознанное использование теории open-endedness: переход от "промышленной разработки" и "непрерывной разработки" к идеям "бесконечного развития" в части организации всего инженерного процесса и его инфраструктуры. В случае МИМ это означает, что вполне развитая (развивается уже больше 10 лет!) Мастерская бесконечно развивается сама, находя себе новые и новые проблемы в быстро дрейфующем в зоне технологической сингулярности мире. В этом мире "ваши вчерашние проблемы исчезли, зато утром появились новые проблемы", причём вот это "вчера и утром" надо понимать буквально: изменения ежедневны. Мастерская бесконечно развивает уже вполне развитых инженеров-менеджеров, то есть находит новые и новые проблемы в этом развитии, более и более сложные, которые увеличивают возможности инженеров-менеджеров по решению всё более и более сложных личных, рабочих, исследовательских проблем -- и решает эти проблемы. Вполне развитые члены сообщества инженеров-менеджеров при этом продолжают предпринимать всё новые и новые шаги развития: прихватывают новые и новые проблемы, решение которых потенциально увеличит их возможности, учатся их решать, не останавливаются в этом. * включает в свои программы развития не только освоение инженерами-менеджерами стратегирования как рационального выбора оптимального метода решения поставленных проблем -- и затем доведение мастерства в выбранном методе решения до совершенства, но и проблематизацию и её теорию -- выбор проблем, достойных попыток в их решении. Это Goldilocks-проблемы, иногда называемые для людей как "проблемы в зоне ближнего развития". Но и поиск решений тоже претерпевает изменения: в поиске будут проверяться гипотезы, которые могут открывать новые части пространства решений, перспективные для непрерывного совершенствования, хотя в момент их выдвижения они могут показывать более чем скромные результаты. Эти гипотезы решений называют stepping stones. В этот момент надо говорить не только о quality (характеристике пользы решения для решения проблемы), но и о novelty -- относительной новизне, дающей шанс на резкий подъём quality в дальнейшем. * эволюция идёт не для отдельных систем, а для популяций/семейств систем. Поэтому признаётся существование не одного, а множества решений -- это характеристика diversity, и дальше речь пойдёт о портфелях решений. * но главное, что отражает сегодняшнее понимание -- это включение эволюции в сам "выходной продукт", то есть учёт bitter lesson preference: если мы поднимаем универсальность инженера-менеджера за счёт роста его интеллекта и тем самым резко поднимаем его evolvability (всё-таки исполнитель роли инженера-менеджера имеет универсальную нейросеть в своём мозге, вполне можно полагаться на замечания "горького урока" про предпочтение "заливаемых бюджетом" универсальных решений специализированным), то вместо "накачивания" его специальными методами можно просто будет давать ему бюджет времени и ресурсов в надежде на то, что он сам выполнит часть проблематизации и поиска решений в новой ситуации. Для этого надо дать инженеру-менеджеру необходимые знания: прежде всего максимальный начальный интеллект, знания об инженерии как таковой (воспроизводимые, измеримые результаты на базе рациональных причинно-следственных рассуждений), знания о том, как пользоваться усилителями интеллекта (AI-агенты как помощники, tooling), как работать с портфелями проблем и решений в ходе бесконечного развития (по алгоритмам open-ended evolution). И ещё надо добавить осознанную агентность как инициативу по изменению себя и быстро эволюционирующего окружающего мира. И, конечно, хорошая постановка проблем и проверки -- чтобы было понятно, что это не уход "в свободное плавание по прожиганию ресурсов, отличное решение не тех проблем, что нужны". Проблематизация часто считается частью стратегирования, но мы всё-таки выделяем её как отдельный метод работы. Когда говорят о стратегии решения какой-то проблемы, то имеют в виду выбранную в ходе стратегирования гипотезу о том, что какой-то метод сработает и даст реальное, а не гипотетическое решение, дальше всё "по классике": стратегия кладётся в основу планирования работ. Но обратите внимание на саму формулировку: "стратегия решения проблемы", проблема к этому моменту есть, стратегирование только должно найти стратегию её решения. Проблематизация как раз и даёт эту "поставленную проблему", причём в особой форме: как набор значений каких-то выбранных характеристик, сравнение которых у решения проблемы позволит считать, решена ли проблема, или не решена. Конечно, желающих подкинуть вам свою проблему для решения хоть отбавляй: коллеги, клиенты, правительства и диктаторы, ООН, think tanks, любой блогер, который лучше всех знает, чем вам надо заняться. Иногда вы начинаете стратегирование, когда у вас явной проблемы всё-таки нет -- а стратегировать надо, ибо это в инженерном процессе "по норме". Более корректно вписать проблематизацию как выбор того, чем заняться (а не стратегирование -- как именно заняться), и тогда придётся в явном виде обсуждать, откуда появилась и насколько обоснована та проблема, которую хотелось бы решить (потому как кто-то был очень убедителен, и "все побежали -- и я побежал") -- и не заменить ли эту проблему на какую-то более интересную, например, с большей отстройкой от конкурентов. А дальше -- гипотезы, варианты, trade-offs. Часто сходу даже при отлично поставленном стратегировании получить полное решение проблемы невозможно, но можно говорить о "перспективном для улучшения промежуточном решении (stepping stone)", планируя выход на какой-то участок Парето-фронта с каким-то набором характеристик решения и перспективами на их улучшение. И вот тут, в стратегировании (в отличие от проблематизации как "сугубого творчества") мы уже в знакомом мире маркетинга, архитектуры, где какие-то методы творчества и контроль выхода на Парето-фронт обсуждаются уже давно. Новое -- это явная технологизация проблематизации, явное обсуждение методов проблематизации. Раньше это отдавалось "предпринимательскому творчеству", сейчас начинает считаться частью инженерной работы, частью R&D. На какой именно Парето-фронт из их огромного числа выходить, на какой именно поверхности Парето (понятно, что речь идёт о поверхности в пространстве многих характеристик, а не кривой Парето-фронта в пространстве пары характеристик -- две характеристики было бы сильным упрощением) искать свой всегда промежуточный успех? Всегда промежуточный -- ибо развитие бесконечно. И идея разработки -- выход на Парето-фронт, удержание на нём. Идея развития -- не только выход на Парето-фронт, но время от времени смена Парето-фронта на более сложный и перспективный. Это рассуждение применяем не только к развиваемым инженерами-менеджерами системам, в том числе социотехническим. Это рассуждение применяем и к самим исполнителям роли инженеров-менеджеров: не только совершенствовать их уже и так развитый интеллект и мастерство, но и регулярно проводить проблематизацию и выходить на решение новых перспективных проблем, приобретая для этого новые виды мастерства, выходя на новые Парето-фронты уже среди самих инженеров-менеджеров. Ровно поэтому в Мастерской инженеров-менеджеров крайнее разнообразие специализаций инженеров-менеджеров. Напомним, что "инженер-менеджер" тут -- просто универсальная архироль, но каждый отдельный исполнитель этой роли имеет свои особенные личные возможности (capabilities), которые регулярно обновляет -- и для этого удерживает свой сильный интеллект, дающий личную изменяемость (evolvability, возможность перестроиться для новых проектов, учесть новые проблемы). Поэтому МИМ уделяет особое внимание различным метрикам evolvability для его инженеров-менеджеров: в конкуренции людей выигрывает быстрее всех меняющийся (в отношении фирм это было известно давно, но мы говорим, что для людей верно всё то же самое -- и верно так же и для AI-агентов, и для команд). Мастерская инженеров-менеджеров тем самым не столько "обучает инженеров-менеджеров" или "даёт им профориентацию". Нет, МИМ занимается развитием инженеров-менеджеров, выводя их на новые и новые ступени новых и новых видов мастерства для ведения новых и новых всё более и более сложных и перспективных проектов. МИМ поддерживает бесконечное развитие инженеров-менеджеров во всём многообразии их специализаций. Мастерская инженеров-менеджеров даёт в своих программах развития продвинутую современную картину мира, универсальные методы мышления и работы -- и весь этот универсализм базируется на одном и том же SoTA наборе фундаментальных методов мышления и выхода в действия по изменению окружающего мира, опирающихся на первые принципы. Этот набор (мы его называем интеллект-стек) подразумевает мастерство в выполнении этих методов. Мы называем это мастерство интеллектом. Интеллект позволяет овладевать всё новыми и новыми специализациями. Конечно, сам этот набор фундаментальных "первопринципных" методов тоже меняется, цивилизация ведь развивается, никакой стагнации в развитии интеллекта нет. Поэтому инженеры-менеджеры вынуждены постоянно актуализировать своё мастерство в этих методах, то есть усиливать и обновлять свой интеллект. Какие характеристики мы отслеживаем? Вот пример: * Time-to-first-credible-model в новой предметной области (скорость сборки рабочей онтологии/модели, целимся в "разговаривать с вами специалисту в этой предметной области интересно"). * Time-to-first-validated-intervention (первая проверенная интервенция, пусть даже “средняя” по качеству, агентность тут играет огромную роль, ибо можно "знать, но не вмешиваться"). * Transfer breadth: сколько разных доменов/ролей освоено с сохранением качества (прямая отсылка к generalist, Renaissance man). * Portfolio health: доля задач/решений, которые стали stepping stones (оказались перспективными и стали основой новых решений, а не окончились впустую). * Diversity coverage: сколько разных классов подходов реально поддерживается (не декларативно). * Time-to-model-revision после опровержения (как быстро обновляем знания). * Forgetting для основного мастерства (не теряем ли старые умения при освоении новых, нет ли деградации общего интеллекта при погружении в конкретные предметы). * Consolidation/compaction rate: доля результатов, которые перешли в общие знания (чеклисты, руководства), а не остались в проектной пыли. Не нужно "просто новизны", нужно накапливать эпистемический капитал. Это всё не измерители "успешного успеха" -- это как раз измерители пропускной способности всего цикла проблематизации и решения проблем, где частями являются в том числе и моделирование, и интервенция на основе модели, и проверка успешности интервенции, и упаковка знаниевых итогов с последующим переносом на новые проблемные ситуации. Волнует тут не успешность каждого витка, а скорость развития. Если у вас быстро растут возможности -- вот это успех. Выбираем проекты, в которых возможности растут, оптимизируем общий рост возможностей. Если цикл не идёт, развитие считается остановившимся, даже если ощущается как бурная активность. Это подходит опытным профессионалам с высокой автономией: тем, кто готов жить в доказательном цикле и выдерживать регулярную ревизию. А остальные? Остальных МИМ пытается такими опытными профессионалами сделать. Это и есть MVP производственного результата Мастерской инженеров-менеджеров. И никакой "профориентации по характеристикам личности": лучший способ "предсказать будущее -- это создать его", поэтому на входе кто угодно, а выхода нет (развитие бесконечно), хотя есть MVP (после разных затраченных входящими на программы развития МИМ усилий в силу разных входных характеристик этих входящих) -- "инженеры-менеджеры: опытные профессионалы с высокой автономией" как вошедшие в сообщество Мастерской полноправными мастерами. Высокая автономия (агентность) тут страхуется поддержкой сообщества, одиночка часто проигрывает ("слепые зоны" в проблематизации, переоценка novelty, отсутствие независимой проверки решений, недостаточная упаковка знаний в компактный интеллект из lessons learned). Это, конечно, не просто "мотивационные лозунги", а всё на основе подчёркивания инженерного начала (изменения мира на базе рациональных причинно-следственных объяснений) и логики характеризации Парето-фронта по характеристикам NQD (novelty, quality, diversity). Конечно, есть множество нюансов в том, как это всё реализовывать. NQD легко превращается в красивую риторику. Надо избегать ловушек: quality метрики можно "загудхартить" (вытащить одну на уровень "лучше всех", остальные провалить вообще), novelty можно превратить в “ярмарку тщеславия” с "у нас всё новое" (но работающее хуже старого и бесперспективное), diversity можно сделать декларативным. Так что приходится определять минимальный порог quality для допуска novelty-экспериментов, вводить лимит распараллеливания (не просто распараллеливание работ в части операционного менеджмента, но и распараллеливание проектов), вводить в ритм в том числе и компактификацию (например, часто обновлять руководства программ развития МИМ по итогам резидентур). Все самые разные руководства МИМ во всех программах развития (личного развития, рабочего развития, исследовательского развития, будущих программ развития, например, культурного развития) наставляют на мышление и работу на базе одного и того же набора методов сильного интеллекта. Когда инженеры-менеджеры приходят в новый проект (а жизнь всё время подкидывает им новые и новые проекты, в том числе и потому, что у них начинается довольно быстрый карьерный рост, связанный с усилением интеллекта и ростом инженерного и менеджерского мастерства, а ещё эти новые проекты появляются регулярно из-за их здорового любопытства), они уже многое знают об этом проекте -- независимо от того, в какой стране это происходит, на каком языке ведётся в этом проекте общение, какую они сами будут играть роль в этом проекте. Главное -- они используют продвинутую картину мира, позволяющую легко обнаруживать ошибки в рассуждениях и задавать сильные вопросы. В этом плане инженеры-менеджеры мастерской -- единомышленники, мышление о мире у них устроено более или менее одинаково, выстроено по руководствам личного, рабочего и исследовательского развития, они имеют на абстрактном уровне более или менее одну картину мира, основанную на интеллект-стеке SoTA научных теорий. Но мир бесконечно разнообразен в конкретных ситуациях, в самых разных проблемах, которые решают инженеры-менеджеры. Поэтому инженеры-менеджеры специализируются не только на "первых принципах", общих для всех проектов и позволяющих выстроить новые дисциплины, получить новые решения "из первых принципов". Они специализируются и на знаниях предметных областей, которые уже имеются -- "вторых принципах", и даже на знаниях о конкретных проектах в конкретной рабочей ситуации самых разных предприятий -- "третьих принципах". В этом плане они -- единомышленники, но разноработники, разноспециалисты. Ну, и разноисследователи, ибо научный метод у них один, а предметы исследования -- разные. Это всё происходит в том числе и из-за явной проблематизации: решили, что будете решать проблему получения мяса фотосинтезом -- специализируйтесь на этом, общего интеллекта тут точно не хватит, нужно будет иметь самое разное специальное мастерство химика и биолога. Если это проблема терраформирования Марса -- оцените, насколько она действительно перспективна (проблематизация), и если ответ "да" -- специализируйтесь, получите новое мастерство, ибо общего интеллекта тут не хватит. Поэтому инженеры-менеджеры все одинаковы (единомышленники, имеют общую картину мира, а ещё они уже весьма развиты, но продолжают развиваться), но все разные -- ибо специализируются на решении самых разных проблем. Каких? Всё время разных, растущих в сложности их решения, и это принципиально. Мы знаем, что open-ended системы ломаются предсказуемо: уход в «гонку новизны», распад на полностью несвязные ветки, отсутствие консолидации. Для того чтобы не было "хотели как лучше, а получилось, как всегда", мы в МИМ: * принимаем свою ограниченность по ресурсам, так что чередуем explore/exploit (периоды расширения vs периоды шлифовки и упаковки, примерно 20% exploration на 80% exploitation в нашем портфеле проектов -- это не закон, но вполне добротная эвристика, organizational ambidexterity); * проверяем, что из знаний мы могли бы консолидировать/компактифицировать/сжать (интеллект -- это прежде всего сжатие информации! “Сжатие” проявляется как (а) меньшая длина объяснения при той же предсказательной силе, (б) меньшая стоимость переноса в новый домен, (в) меньше частных правил на единицу решаемых задач). Конечно, "сжатие" тут главным образом про знания, а предъявление их людям требует повторений, кривые забывания и множество предъявлений в разных контекстах для освоения нового мастерства людьми никто не отменял. * избегаем уходить в "мультитаскинг" на множестве открытых одновременно Парето-фронтах, для этого удерживаем компактный портфель проблем и компактный портфель проверяемых гипотез для решений этих проблем, а в exploitation избегаем мультитаскинга (ухода в большое количество "заделов" и ни одной поставки). Так что МИМ -- это не "аспирантура" или "учебная лаборатория" как вариант исследовательского подразделения в университете, часть continuous education, но больше "производственная компания по развитию для развитых": * явная технологизация проблематизации (метод + инфраструктура + ритуалы постановки проблем) с выходом на стратегирование в рамках R&D; * управление портфелями (проблем и решений с учётом характеристик пользы, новизны, разнообразия) как нормальная инженерная работа; * ускорители интеллекта (AI-агенты и инструменты) как обязательные для evolvability: это не "факультативы". * основная форма работы -- рабочие проекты в резидентурах. МИМ занимается в них общей частью усиления интеллекта инженеров-менеджеров, повышением их агентности, помощью в освоении непрерывно меняющихся методов системной инженерии и менеджмента в их самом общем виде. Что это даёт инженерам-менеджерам? Прирост их возможностей, вполне измеримый эффект: * снижение стоимости входа в новую предметную область, новый проект (ориентир тут как у консультантов: "через пару недель проекта тамошним специалистам интересно со мной обсуждать тамошние проблемы"). * рост скорости первой интервенции и выхода на проверку гипотез (уменьшение времени планирования, уменьшение времени analysis paralysis). * рост доли результатов, упакованных в форму, переносимую между проектами (lessons learned в форме, например, руководств). * рост возможностей по переспециализации без деградации качества работы. 019ca9c4-9b10-7f35-8982-c5c63cc3ed02

Читать обсуждение →