
Я на Хабре недавно, но уже успел заметить две вещи:
-
Во-первых, здесь довольно быстро устают от хайпа вокруг искусственного интеллекта и минусуют статьи, в которых пишут про ИИ без негативного опыта его применения.
-
Во-вторых, здесь с понятным скепсисом относятся к любым новым стандартам, сводам знаний, фреймворкам и манифестам, особенно если речь идёт о чём-то управленческом.
… а текст ниже заходит сразу на обе эти территории…
И всё же рискну.
Хочу написать о концепции агентного управления проектами и манифесте агентного управления проектами. Я участвовал в разработке этих документов, и мне важно не только показать результат, но и получить обратную связь от сообщества. Любую. Включая жёсткую.
С чего всё началось?
Всё началось не с теории и не с попытки придумать ещё один красивый термин.
С начала 2026 года мы довольно плотно обкатывали агентов в нескольких ролях проектной команды.
У нас были:
-
агент администрирования проекта,
-
агент мониторинга коммуникаций,
-
агент планирования проекта.
Да, между ними были пересечения по функциям. И это, кстати, тоже отдельная тема. Границы между агентами на практике оказываются более размытыми, чем это кажется на архитектурной схеме.
Сначала мы гоняли всё это в своих проектах: в консалтинге и внедрении ПО. Потом попробовали те же идеи в строительных проектах. Надо признать, что опыт оказался одновременно очень вдохновляющим и очень отрезвляющим.
Удивило нас примерно следующее.
Агенты действительно хорошо работают там, где человеку приходится быть скучным и последовательным:
-
непрерывно смотреть в несколько источников,
-
замечать слабые сигналы,
-
собирать статус,
-
напоминать,
-
подсвечивать расхождения,
-
пересчитывать сценарии.
Там, где обычный руководитель проекта делает это урывками, потому что у него совещания, переписка, контракты, эскалации и просто ограниченный объём внимания.
Но разочарование было не меньше.
Очень быстро выяснилось, что агент не уменьшает хаос сам по себе. Если процессы в проекте кривые, статусы декоративные, данные неполные, а ответственность размыта, агент не исправляет эту картину. Он её ускоряет. Иногда ещё и очень убедительно.
И вот в этот момент стало понятно, что проблема вообще не в том, какая LLM лучше и какие промпты писать.
Проблема в другом. Что делать, когда в проекте появляется новый участник, который не просто отвечает на вопросы, а начинает влиять на информационную картину, из которой люди потом принимают решения?
Где заканчивается инструмент и начинается агент?
Это, пожалуй, была главная развилка.
Пока ИИ просто выполняет поручение по запросу: написать текст, собрать таблицу, посчитать вариант плана, проверить формулировку – это полезный инструмент. Но по логике AgPM система считается агентом, когда ей делегируют управленческую функцию. Она сама решает, что показать человеку, как важное, и работает регулярно или непрерывно без нового запроса на каждый цикл.
Иными словами, агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.
Зачем нам вообще понадобился ещё один манифест?
Потому что классическое управление проектами эту ситуацию описывает не до конца.
И PMBoK, и ISO 21502, и PRINCE2, и другие привычные рамки по-прежнему остаются полезными. В AgPM нет идеи всё это выбросить и начать жизнь с нуля. Наоборот, речь идёт не о замене классического проектного управления, а о том, чтобы добавить в него нового участника проектной системы – ИИ-агента.
То есть это не новая религия вместо старой, а попытка ответить на вопрос о том, какие правила нужны, чтобы рядом с формальной системой управления не выросла вторая, теневая и неуправляемая.
Для меня именно это и стало причиной, почему вместо ещё одной методички по промптам появились документы управленческого типа. Потому что на практике упираешься не в качество генерации, а в вопросы вроде этих:
-
Кто отвечает за последствия рекомендации агента?
-
В какой момент сигнал становится фактом?
-
Можно ли считать вывод агента основанием для изменения плана?
-
Что делать, если два агента спорят друг с другом?
-
И как не принять зелёный дашборд за реальное здоровье проекта?
Что в этих документах кажется мне действительно полезным?
Несколько вещей, я надеюсь, точно будут полезны для тех команд, которые вступают на пока что мало изученную территорию внедрения ИИ-агентов для управления чем угодно и проектами в частности.
Во-первых, жёсткая фиксация того, что ответственность остаётся за человеком. Не у модели, не у системы, не у того, кто интегрировал ИИ, а у конкретного человека, принимающего управленческое решение. В концепции это оформлено как двухслойная модель: классическая RACI остаётся человеческой, а агенты живут в параллельном слое ролей. С полномочиями, но без ответственности за результат.
Во-вторых, очень полезной мне кажется сама логика жизненного цикла проектной информации.
-
Сигнал – это ещё не факт.
-
Факт – ещё не официальный статус.
-
Статус – ещё не изменение базового плана.
В концепции это разложено по шести стадиям:
-
сигнал,
-
гипотеза,
-
подтверждённый факт,
-
утверждённый статус,
-
запрос на изменение
-
и изменение базового плана.
Для практики это важнее любой красивой AI-терминологии.
В-третьих, в документах отдельно подчёркнуты вещи, без которых агентная система быстро становится опасной:
-
агентное целеполагание,
-
объяснимость,
-
подотчётность,
-
возможность отмены,
-
безопасная деградация,
-
пропорциональность.
Особенно близки мне последние две.
Безопасная деградация – потому что агент не должен при сбое утащить проект в неконтролируемый режим.
Пропорциональность – потому что попытка натянуть тяжёлую агентную рамку на маленький проект очень быстро превращается в карго-культ автоматизации.
В-четвёртых, четыре области практик:
-
целеполагание,
-
реализация,
-
интеграция.
Это не ещё один линейный процесс из шести шагов, а скорее постоянные темы, которые РП должен держать в поле зрения. Мне нравится эта логика, потому что она ближе к реальной жизни проекта, где всё идёт одновременно: ты и настраиваешь рамку, и разгребаешь текучку, и калибруешь поведение системы, и постоянно стыкуешься с внешним миром.
В-пятых, модель зрелости из пяти уровней. От прозрачности, где агент только структурирует картину, до непрерывного обучения, где появляется межпроектная память и перенос знаний. На мой взгляд, это полезно уже хотя бы потому, что в этой модели есть нормальная стартовая точка. Не давайте сразу автономный ИИ-офис, а давайте сначала научим систему наблюдать и не врать. Или хотя бы врать недорого.
Что меня в этой истории до сих пор смущает?
Скажу прямо. Сырого здесь ещё много.
Меня смущает риск переусложнения. В какой-то момент любая хорошая идея в управлении начинает обрастать рамками, словарями, классами решений, протоколами и журналами до состояния, когда она становится тяжелее проблемы, которую должна решать.
Меня смущает и другая вещь. Главный риск здесь не технологический, а человеческий. Опасность не только в том, что агент ошибётся, а в том, что человек перестанет думать, потому что думает агент.
Отсюда ложный контроль, деградация компетенций, размывание ответственности и эффект усиления слабого РП, который с агентом начинает принимать решения, на которые без агента просто не решился бы.
И ещё мне кажется спорной сама граница между помощником, агентом и частью обычной автоматизации. В документах предложены достаточно ясные критерии, но на практике будет много пограничных случаев. И поэтому мне особенно интересно мнение людей, которые строят процессы с использованием ИИ-агентов руками, а не схемами.
Где это всё может дать реальную пользу?
Лучше всего смысл подхода виден не в принципах, а в сценариях.
В концепции есть очень приземлённые примеры:
-
агент раньше замечает, что подрядчик скрывает отставание,
-
быстрее пересчитывает варианты после изменения объёма,
-
готовит материалы к встрече со спонсором на основе актуальных данных,
-
помогает новому РП быстрее войти в проект,
-
автоматически отслеживает критичные изменения у партнёра.
Есть и антисценарии: ложный сигнал, перегрузка рамкой, оптимизация не той функции.
Собственно, наши пилоты и подтолкнули нас примерно к тем же выводам.
Больше всего агенты пригодились там, где нужна непрерывность наблюдения, сопоставление разнородных данных и быстрое формирование вариантов. Хуже всего – там, где хотелось заменить ими смысл, контекст и политическую навигацию.
С этим они не справляются. И, думаю, ещё долго не будут.
Зачем я пишу об этом именно сюда?
Потому что такие документы бесполезно писать в вакууме проектных офисов и корпоративных презентаций.
Мы проложили в открытый доступ два PDF:
При этом концепция – документ для обсуждения проектным сообществом. И это, пожалуй, лучшая формулировка того, как к ней и стоит относиться.
Не как к канону. Как к приглашению в спор.
Поэтому мой призыв очень простой.
Посмотрите на эти документы как на ещё один AI-лендинг, а как на попытку описать управленческую проблему, которая уже появилась на практике. И напишите (например, в комментариях), где здесь действительно есть полезная рамка, где – переименование давно известных вещей, а где – просто лишняя сущность.
Особенно интересны возражения по четырём точкам:
-
где проходит граница между инструментом и агентом,
-
нужна ли для этого вообще отдельная дисциплина,
-
насколько реалистична модель зрелости
-
и какие правила обязательны с первого дня, а какие только утяжеляют систему.
Мне в этой истории важнее не согласие, а разбор. Потому что хуже ещё одного манифеста может быть только ситуация, когда агенты уже работают в проектах, а разговора о правилах всё ещё нет.
Где скачать документы?
Сайт проекта: https://agenticpm.pro/. И выше прямые ссылки.
На сайте доступны два документа: «Манифест» и «Концепция v1.0».
Автор: YVKim


