— Лол, зачем AI-агенту вообще инструмент для управления проектом? Он же просто берёт и делает! — написали мне десятки человек.
Признаюсь, именно на этом я и хотел вас подловить.
Вы обсуждаете только исполнительский слой
В ответах чаще всего называли чисто исполнительские инструменты — Jira, Trello, Linear, Github issues. Jira, Trello, Linear и GitHub Issues полезны после фиксации задачи: когда есть владелец, описание, приоритет и следующий шаг. То есть в delivery-части, а не в discovery, согласовании требований и управлении ожиданиями.
Никто не подумал про stakeholder management. Про сбор требований и выявление противоречий. Про выравнивание разных шкал приоритетов, если в проекте работают несколько организаций. Про эстимирование и планирование ресурсов, про разрешение конфликтов в целеполагании, про бюджетирование, управление рисками. Про банальную организацию созвонов ЛПР в конце концов.
Это ведь тоже проектные задачи? Их ведь тоже должен агент делать, не?
Если AI участвует не только в кодинге, но и в управлении разработкой, то агент должен вести stakeholder management, фиксировать расхождения в ожиданиях ЛПР и доводить их до решения, ставить и проводить встречи — причём чётко в нужные моменты времени, — обсуждать митигацию рисков, курировать годовое и квартальное планирование портфеля инициатив, работать с приоритизацией и организационными зависимостями.
Проектное управление включает не только перемещение карточек, но и выбор инициатив, согласование требований, бюджетов, рисков и ресурсов. Оно начинается с того, чтобы определиться, какие у нас в организации будут проекты на горизонте хотя бы года — учтя интересы всех вип-кастомеров и капасити подрядчиков.
В этом месте нужен не список интеграций, а модель: какие решения агент отслеживает, чьи утверждения считает достоверными и когда инициирует эскалацию.
В обсуждении часто предполагается, что задачи уже кем-то сформулированы
Во многих сценариях не описывается источник задач: кто их выбрал, согласовал и связал со стратегией, и вся работа над проектом начинается с того момента, как задача упала вам на голову. Некоторые мне даже пытались доказать, что именно в этом и состоит управленческая деятельность — эффективно распихать то, что вам навалилось с неба.
Такой подход оставляет вне системы саму постановку работы.
Проблема в том, что мы все слишком привыкли думать исполнительским контекстом. Мы поручаем агенту задачи, и он их радостно делает. Но откуда эти задачи берутся? Почему именно эти? Кто это решил? Как они связаны со стратегическим курсом вашей организации или группы компаний? И более того — что если задач поступает настолько много, что агент физически не успевает их кодить, и вы вынуждены как-то выбирать, какие задачи отдавать в работу, а какие нет? Всё это ещё делают люди.
Здесь в рассуждениях про AI часто появляется разрыв.
Дескать, нууу это же проблема бизнеса, пусть там бизнес самостоятельно согласует приоритеты между заказчиками, бюджетами и ограничениями capacity, договорится между собой, выровняет десяток стейкхолдеров и бюджетов, и скажет нам, что конкретно делать. А мы радостно сплавим это агенту. Хо-хо! Какие мы умные.
Ребята, очнитесь. Это всё та же старая ловушка «без внятного ТЗ результат ХЗ», только перенесённая на AI-инструменты. Для молодёжи поясню: адепты этой точки зрения остаются за бортом всегда — потому что ценность смещается от исполнения к постановке и согласованию задач. И пока вы мыслите в парадигме «мне дадут задачу, а уж я-то засуну её в obsidian linear plane jira whatever и пыщ-пыщ дам результат» — вы остаётесь в низкомаржинальной части процесса.
Ценность возникает до появления тикета: в выборе и согласовании работы
Если смотреть не только на delivery-часть, то поймёте, что передать уже сформулированную задачу агенту технически несложно. А сложность — и, как следствие, ценность — находится в согласовании целей, ограничений и критериев успеха до начала исполнения. Где нужно выровнять между собой несколько заказчиков с разными интересами, бюджетами и критериями успеха. Хотя бы понять, как вообще выглядит единое описание результата, приемлемое для всех ключевых ЛПР.
Потому что поставить встречу с внятной повесткой — это тоже проектная задача. Собрать требования с ЛПР — это тоже проектная задача. Собрать — это не распарсить клодом готовую эксельку, если что. А выявить нестыковки между двумя ключевыми ЛПР, организовать встречу, провести её, на ходу сверяясь с бюджетами и стратегией, а потом сформулировать и донести итоговое решение — это отдельная цепочка действий: выявить расхождение, назначить обсуждение, провести его, сверить с бюджетом и стратегией, зафиксировать решение.
И что, у вас агент это делает?
А ведь именно там агент должен эффективно работать, понимаете? Вот там он должен ассистировать вам — и делать за вас. Вот там, где ещё нет никаких тикетов и тасков, а есть десяток мутных стейкхолдеров — людей! — каждый со своей придурью, амбициями и коммитментами. Эта часть процесса пока слабее автоматизирована, поэтому в ней больше прикладной ценности.
А уж исполнить потом поставленные задачи — да хоть прикрутив Jira MCP к клоду — энтузиаст всегда найдётся.
Пример из моей практики
Я описываю не гипотезу, а внедрение на проектах. Я собрал такой контур для двух проектов — именно под первую половину проектного управления, ту, где ещё нет тикетов.
Сквозной трекинг с самого первого пресейл-разговора. В системе у каждого участника задана роль и область, в которой его утверждения имеют больший вес — и с учётом этого взвешивает достоверность факта. Заявление финансового менеджера клиента про финансы — высокая достоверность; то же про финансы от верстальщика или тестировщика — низкая. И наоборот. Такой подход позволяет отличать сбор требований от простого извлечения строк из таблицы.
Сбор требований — это выявление противоречий между ЛПР. Детектор противоречий помечает расхождения между источниками, а не молча перезаписывает последним словом. Две версии SOW с разными датами окончания контракта — поймано до подписания. Обещали клиенту решение за X, а в смете выставили 2X — вскрыто рано, до того как документ уйдёт клиенту. Также система помечает расширение объёма работ, если новые пожелания не связаны с бюджетом или сроками.
Организовать встречу в нужный момент — тоже проектная задача, и её делает система. Три открытых вопроса без ответа 30+ дней — флаг перед следующей встречей, чтобы менеджер пришёл готовым.
Это работает около двух месяцев на двух живых проектах одновременно. Ядро — Claude со скиллами плюс пара скриптов. Основная логика собрана в промптах, скиллах и нескольких скриптах; отдельного приложения пока нет. И собрано это в enterprise-организации с формальными ролями, бюджетами и согласованиями, где я первым встроил ИИ не в код, а в управленческий контур — требования, постановку задач, межкомандные согласования — с самого старта delivery-роли.
Пока обсуждение застряло на выборе модели для кодинга
AI-исполнение быстро стало массовым навыком, поэтому дифференциация смещается выше по процессу. Уёбская (это не ругательство, а отсылка к мему «уеб дизайн») мантра погроммистов про то, что «вот ИИ накосячит и нас снова вознесут на пьедестал» — не объясняет, почему заказчик должен платить именно за ручное исполнение, а не за постановку и контроль результата. Возврат к прежней ценности ручного кодинга маловероятен без изменения роли разработчика — за такие высказывания можно банить не глядя.
Поэтому пока дураки спорят, умеет ли AI вообще в программирование и какой моделью лучше кодить — смотрите на участки, где решения ещё не формализованы: приоритизация, согласование требований, риски и зависимости. В планировании, в выявлении скрытых потребностей, в фиксации интересов, опасений и критериев успеха разных ЛПР, в выравнивании людей между собой, в эстимировании и расстановке приоритетов, в выявлении организационных зависимостей.
Пока эти действия не упакованы в стандартные функции вендоров и не закрывается парой скилов для клода. Хотя очевидно, что вендоры уже добавляют функции для работы с требованиями, контекстом и управленческими артефактами — и вам тоже стоит.
И это не решается никаким подключением ни джиры, ни линеара по MCP. Проблема не в интеграции с трекером, а в модели принятия решений и эскалаций — фиксация договорённостей, владельцев решений, рисков, бюджетных ограничений и критериев приёмки и оценками ожидаемого экономического эффекта, жизненным циклом гипотез, согласованиями и разрешениями конфликтов между людьми. И потом двусторонней трансляцией в исполнение и приёмку задач. Готовые AI-инструменты обычно закрывают отдельные части этого контура, но не связывают их от пресейла до приёмки.
Где агенту место в проектном контуре
Исполнительский слой стандартизируется; менее автоматизированной остаётся часть до тикета: согласование целей, приоритетов, бюджетов и рисков, там, где десяток живых стейкхолдеров, приоритизация между организациями и ещё пока есть спрос. Именно там агент полезен как система отслеживания решений и эскалаций.
Подключить Jira MCP к клоду — это не решение. Таск-менеджер агенту нужен не для того, чтобы двигать карточки, а для того, чтобы хранить историю решений, источники утверждений, открытые вопросы, эскалации и связь с задачами: кто легитимен заявлять что, где версии расходятся, какой вопрос висит без ответа тридцать дней и какую встречу пора созывать. В практическом виде это список договорённостей, гипотез, рисков, бюджетных ограничений, владельцев решений и статусов согласования, разрешение конфликтов между людьми — и двусторонняя трансляция в исполнение и приёмку.
Никакой готовый AI-инструмент такого в комплексе пока не делает.
Типичные сбои такого контура
Первый типичный сбой — агент принимает последнее сообщение как более актуальное без проверки роли источника. Пришло письмо от тестировщика — перетёрло данные от финансового менеджера. Без модели легитимности ролей агент будет доверять последнему источнику или самому частому источнику в переписке. Результат: решения принимаются на основании мусорных данных, и вы об этом узнаёте, когда уже поздно.
Второй сбой — тишина вместо флага. Три ключевых вопроса висят без ответа тридцать дней, и система молчит, потому что «нет дедлайна — нет эскалации». Агент, который не умеет поднимать тревогу по отсутствию движения, опасен, потому что скрывает отсутствие прогресса: он создаёт иллюзию, что процесс под контролем.
Третий — детектор противоречий без взвешивания. Два ЛПР дали несовместимые версии — агент честно фиксирует расхождение и ждёт. Но без понимания, чьё слово весомее в данном вопросе, фиксация расхождения превращается в нерелевантный список конфликтов без приоритета: противоречий в живом проекте десятки, и не все критичны. Агент должен не просто ловить нестыковки, а ранжировать их по влиянию на бюджет, срок и scope.
Четвёртый — собрал требования, но не связал их с календарём, повестками и владельцами решений. Выявил противоречия, пометил расхождения — и забыл, потому что нет связи с календарём встреч и повестками. Противоречие, не доведённое до встречи в нужный момент, просто копится в базе. Агент должен не только находить проблемы, но и инициировать их разрешение: ставить встречу, формировать повестку, приносить на неё готовые вопросы.
Почему одной интеграции с Claude недостаточно
Вендоры уже движутся в эту область: добавляют память проекта, работу с требованиями и интеграции с трекерами. Но комплексное решение требует не модели, а архитектуры: модели легитимности ролей, детектора противоречий со взвешиванием, трекера открытых вопросов с эскалацией по молчанию, связи с календарём и повестками, двусторонней трансляции между управленческим контуром и исполнительским. Отдельные компоненты можно собрать быстро, но сложность возникает на стыках: доверие к источникам, эскалации, календарь, задачи и приёмка. Связать их в контур, где данные текут от первого пресейл-разговора до приёмки задачи без разрывов — именно в этой связке появляется основная инженерная и управленческая сложность.
Пока дураки спорят, умеет ли AI в программирование, наименее автоматизированная зона находится до тикета: там, где нужно согласовать людей, ограничения и критерии результата — но есть десяток живых стейкхолдеров с разными картинами мира. Если вы ждёте, пока вам дадут задачу, чтобы засунуть её в Jira и выдать результат, — ваша роль ограничивается исполнением уже принятых решений, а не влиянием на выбор работы.