Системное мышление дает мощный инструмент для анализа реального мира и создания проектов, которые его изменяют. Казалось бы, такой инструмент полезен всем, кто работает со сложными системами, к которым, в том числе, относятся enterprise-проекты в ИТ. Однако, когда я несколько лет назад рассказывал про него на Analyst Days, то в обратной связи мне прилетел вопрос: «Это интересно, но зачем так сложно? Почему бы просто не взять c4-model и не создать модель на ее основе, это же гораздо проще?» В следующих выступлениях я учитывал такое мнение и старался показать, зачем системное мышление ИТ-шнику, как стреляет его отсутствие. Впрочем, я не уверен, что убедил сторонников простых решений.
Сейчас аналогичный вопрос появляется по поводу ИИ-помощников: нужно ли им мыслить в системном подходе, когда с ними ведут проектирование сложных проектов? И ответ столь же не очевиден. Вернее, для разработчиков ИИ-моделей ответ как раз был очевиден и он отрицателен: знающий системный подход ИИ будет разговаривать слишком умно, а исследования показывают, что люди этого не любят и отвернутся от ИИ. А надо, чтобы не отворачивались, а разговаривали. Поэтому ИИ подстраивается под уровень собеседника, по-умолчанию полагая его не слишком высоким в соответствии со статистикой.
Конечно, когда собеседник спрашивает о каких-нибудь специальных областях, то ИИ делает поправку на то, что говорит со специалистом. Но далеко не всегда специалисты, даже инженеры владеют системным подходом. Более того, практика показывает, что вполне можно разрабатывать программы не только без системного, но и без мышления объектами, то есть плохо выделять сущности, путать типы и экземпляры и вообще мыслить литературными нарративами вместо структурных схем. Но та же практика показывает, что нарративное мышление для решения сложных задач не эффективно, и не только в ИТ, но во многих гуманитарных областях, например, в маркетинге – для планирования исследований и компаний продвижения надо мыслить структурно, и системный подход тут полезен. И для адекватной коммуникации важно, чтобы им владел не только человек, но и его ИИ-помощник.
Однако, с указанием ИИ-помощнику на системный подход есть трудность, просто сказать «используй системный подход» – недостаточно. Дело в том, что за этими словами скрывается множество разных смыслов, начиная просто от умения применять хоть какую-нибудь последовательность вместо беспорядочного метания мысли. И среди этого множества описаний лишь малую часть составляют те, в которых говорят про мышление системами, с умением выделять их в окружающем мире, строить правильные отношения, различать эмерджентные свойства, присущие системе в целом от свойств отдельных частей, не путать функциональное и модульное деление системы. Поэтому просто по указанию «используй системный подход» ИИ легко может ошибиться. При этом даже в рамках мышления системами существует рад версий, связанных с историей развития: на первом этапе имели дело с физическими системами, затем расширили его на биологические системы, начали говорить про экосистемы, границы которых являются нечеткими и часто выделяются «по соглашению», что дальше распространили и на инженерные объекты, что знает любой, кто пробовал выделить в сложном софте «подсистему безопасности».
Таким образом, ИИ-помощнику надо достаточно подробно рассказать, какие именно методы и шаблоны мышления мы подразумеваем под словами «системный подход», а что им не является. И это представляется сложной задачей. Однако, у этой задачи есть доступное (и бесплатное решение). Чуть больше года назад Анатолий Левенчук, руководитель Школы системного менеджмента, которая примерно тогда переименовалась в Мастерскую инженеров-менеджеров, занялся задачей: объяснить ИИ, что такое – современный системный подход. Анатолию это нужно было для прикладных целей: чтобы разработать развитие системного подхода, применимое не только для проектирования инженерных систем и управления организациями, но и для работы с моделями личности и сообществ. Создание такого объяснения, которое Анатолий назвал First Principle Framework (FPF) стало самостоятельной задачей. Однако, в сентябре 2025 года вышел первый релиз, с тех пор фреймворк активно развивается. Фреймворк с самого начала создавался с помощью ИИ-моделей, а с февраля Анатолий делает это в Codex с помощью агентов.
Текущая версия FPF выложена на на github https://github.com/ailev/FPF. Это большой файл, который нужно подключить к вашему ИИ-помощнику, внутри которого – шаблоны (паттерны) системного мышления, сформулированные на языке стандартов – с именованием шаблонов, перекрестными ссылками и так далее, которые можно использовать для разных задач. В readme сейчас 14 разных путей применения FPF для разных целей: создание архитектуры, разработка рабочих регламентов, сравнение альтернатив и принятие обоснованных решений, восстановление онтологий и другие.
Последняя из них – создание аналогичных фреймворков для конкретной предметной области – Domain Principle Framework (DPF). Об этом 28.06 Анатолий проводил семинар, что и послужило для меня непосредственной причиной написать эту статью. Материалы семинара доступны на телеграм-канале https://t.me/mim_workdev/196 – презентация, запись, краткий конспект. Чуть выше на канале – пост со ссылкой на подключение и большим количеством комментариев, в нем можно посмотреть ход обсуждения, а так же несколько описаний предметных областей, созданных участниками прямо в ходе семинара, как конкретных, таких как доставка платежных документов потребителям, так и достаточно общих, таких как создание Agentic AI Planform. Это получается «из коробки», одной командой. Понятно, что это – черновик, и его потом надо дорабатывать, тоже с помощью ИИ, но это – хороший черновик, где уже учтено много проблем предметной области и типовых ошибок, которые совершают при реализации. Соответственно, когда вы будете обсуждать с ИИ конкретный проект, он все это будет учитывать.
Описано это все на языке шаблонов, структуру которых Анатолий раскрывал на семинаре, там довольно много составляющих: проблемы, решения, метрики, на которые надо опираться, примеры использования, антипаттерны и так далее, и это – вполне читаемо. И не обязательно читать самому, можно спрашивать ИИ, просить объяснить содержание.
С другой стороны, вовсе не всегда DPF и даже FPF вам помогут, это тоже видно из комментариев. Контекст проекта, если он хорошо сделан, важнее общих принципов. При этом может оказаться, что ваш контекст по терминологии конфликтует с FPF, и это надо отдельно разводить, а не просто подключить FPF. Впрочем, следует отметить, что в FPF ситуация в принципе предусмотрена, и ИИ в задании на работу можно сказать, наприме, так: «при составлении плана проекта опирайся на FPF, но изложи результат на языке, понятном для менеджеров таких-то проектов». А в целом тут все, как со сложными фреймворками в ИТ-разработке: они многое умеют, но требуют подготовки для грамотного использования. Потому что если ИИ заложил в DPF одни шаблоны, а вы мыслите иначе, то ничего хорошего из использования не получится.
В заключении я хочу отметить, что интерес представляет не только сам FPF, но и история его создания, включая организацию команды агентов, с помощью которой Анатолий их создает. Он это достаточно подробно описывает в своем блоге https://ailev.livejournal.com/, правда, там вперемежку идут самые разные материалы. В середине апреля я публиковал подборку ссылок, можно обратиться к ней – но с тех пор прошло уже больше двух месяцев, явно появилось много нового. Это работа, за которой полезно следить и пробовать применять в своей работе, собственно, в сообществе, сформировавшемся вокруг школы-мастерской Левенчука многие так и делают. А Анатолий планирует серию семинаров с подробным объяснением, как оно внутри устроено.
ссылка на оригинал статьи https://habr.com/ru/articles/1056178/