[Почему универсальные ИИ-ассистенты не справляются с плановой проектной отчетностью]

Большую часть своей карьеры продакт-менеджера я встречала пятничный вечер одинаково: собирала еженедельный отчет по проекту. Проблемой было не само его написание — с этим я справлялась. Настоящей проблемой был час до него, когда приходилось восстанавливать картину того, что реально произошло за неделю.

Открыть Jira, отфильтровать по спринту, проверить, какие тикеты закрыты, какие съехали и какие сменили статус без объяснений. Сверить это со Slack-треда, где кто-то во вторник упомянул блокер. Выгрузить данные ворклогов. Вспомнить, что клиент спрашивал на созвоне в среду, и убедиться, что отчет это учитывает. Проверить, совпадает ли процент выполнения майлстоун с тем, что тимлид озвучил на стендапе вчера.

К моменту, когда все данные были собраны, мой мыслительный ресурс был почти полностью исчерпан, потому что мне приходилось быть точкой сборки между шестью инструментами, которые не интегрировались друг с другом.

Я думала, что это просто такая работа. А потом начала задаваться вопросом: а точно ли так должно быть?

Когда я начала экспериментировать с ИИ-инструментами, еженедельный отчет казался самым логичным документом для старта. Задача по его формированию структурирована, результат предсказуем, формат стабилен. Если ИИ мне где-то и поможет — то здесь.

Весь полдень я провела за составлением детального промпта: описала формат отчета, добавила контекст по проекту, вставила данные о тикетах из Jira и попросила Claude собрать из этого еженедельный статус-апдейт.

Результат был... грамотным. Структура — правильная, язык — четкий. Если бы я не знала глубоко свой проект, это читалось бы как настоящий отчет. Но это был отчет о данных, которые я ему дала, а не о проекте. Когда я забыла добавить Slack-тред с заблокированной API-интеграцией — она не попала в отчет. Когда данные из Jira, которые я вставила, были двухдневной давности — отчет отражал проект с неактуальными данными. Когда я спросила о рисках по срокам, ответ оказался общим: у модели не было никакого представления о прогрессе скорости продвижения команды по скоупу работ или о том, что мы обещали клиенту.

И главная проблема: все это не могло работать автоматически. Каждую пятницу мне все равно нужно было садиться, собирать данные, формировать промпт, вставлять все в окно, проверять результат и вручную добавлять то, чего модель не могла знать.

Отчет оставался срочным, ручным и моей головной болью.

Чтобы понять, почему Claude и ChatGPT упираются в стену на таких задачах, достаточно разобраться в одной фундаментальной особенности их работы — без технических деталей.

Универсальные LLM сделали большой шаг вперед в части непрерывности. ChatGPT Projects, Claude Projects и аналогичные функции позволяют прикреплять файлы, задавать постоянные инструкции и сохранять историю диалогов между сессиями. Это реально полезно, и это честно признать.

Но мою проблему это не решило. Сохраняется только тот контекст, который вы явно предоставили: загруженные документы, написанные инструкции, история предыдущих разговоров. Модель не тянет живые данные из Jira, не видит, что изменилось с прошлого спринта, и не запускает отчет в 9 утра в понедельник без вашего участия. Проблема не в памяти, а в живом подключении к системам, где реально живет проект, и в способности действовать по расписанию без человека в цепочке.

Это и называется отсутствием промежуточных состояний (stateless) на операционном уровне — осознанное проектное решение, которое делает модели безопасными, защищающими конфиденциальность и применимыми миллионами людей для совершенно разных задач. Модель, которая автономно подключается к живым системам каждого пользователя, была бы кошмаром с точки зрения безопасности.

Но для проектного менеджмента это существенное ограничение — потому что PM-работа как раз таки предполагает сохранение состояния. Каждый статус-апдейт существует в соотнесении с предыдущим. Каждый риск-флаг имеет смысл только в контексте текущего спринта, динамики скорости команды, ожиданий клиента и договоренностей с последнего ревью. Без наиболее актуального контекста ИИ может написать отчет, не рассказывая вам о том, что реально происходит в проекте прямо сейчас.

Это различие важнее, чем кажется: универсальный LLM с прикрепленным проектом знает то, что вы ему сказали. А агент, осведомленный о проекте, знает, что на самом деле происходит.

Когда я формировала свой промпт для Claude, я вручную компенсировала все эти ограничения: была и планировщиком, и дата-пайплайном, и слоем памяти. Модель лишь помогала мне отформатировать результат после того, как я сделала всю работу. В какой-то момент я перестала компенсировать и начала записывать, что мне реально нужно, и собрала это в список.

Итак, вот список из моих потребностей, чтобы наконец можно было автоматизировать отчеты:

• Доступ к данным проекта в режиме реального времени. Полезный инструмент должен видеть, что реально происходит в Jira, GitHub и Slack прямо сейчас, а не то, что я скопировала час назад. Устаревшие входные данные дают устаревшие выводы, а устаревшие выводы подрывают доверие клиента.
• Память о предыдущих событиях. Прошлый спринт важен для понимания текущего. Отчет, который не знает, закрыли ли мы 80% запланированного скоупа в прошлый раз, не может адекватно оценить, нормальная ли сейчас скорость, тревожная или требующая внимания. Исторический контекст — не опция, а то, что делает статус-апдейт значимым, а не просто описательным.
• Знание специфики конкретного проекта. У нашего проекта есть конкретные майлстоун-обязательства, чувствительные темы для клиента, командные договоренности и пороги рисков. Инструмент, который этого не знает, выдает общий результат. А такой результат требует участия человека, чтобы сделать из него что-то реально полезное, что полностью обесценивает автоматизацию.
• Способность работать по расписанию без моего участия. Весь смысл автоматизации еженедельного отчета в том, чтобы он формировался еженедельно без моего вмешательства. Инструмент, который требует, чтобы я каждую пятницу садилась и запускала процесс, ничего не автоматизирует — он просто изменяет форму ручной работы.
• Доставка сформированного документа адресатам. Отчет, который существует только в окне чата — это черновик. Результат должен дойти до тех, кому он нужен: письмом клиенту, постом в командный Slack-канал или форматированным документом. Доставка — часть задачи.

Универсальные LLM частично закрывают первый пункт (с ручными усилиями) и не закрывают оставшиеся четыре нативно. Это не недостаток, у них другая задача. Реальный выигрыш в эффективности — это подобрать инструмент, который справится с вашей задачей.

Сразу оговорюсь: это не аргумент против Claude или ChatGPT. Оба — реально полезные инструменты, которыми я продолжаю пользоваться. Суть в том, что разные инструменты подходят для разных задач, и путаница между ними стоит времени.

Универсальные LLM отлично работают с задачами в рамках одной сессии: написать письмо клиенту, проработать фреймворк приоритизации, сделать саммари только что загруженного документа, подготовиться к сложному разговору, обдумать логику решения. Эти задачи выигрывают от широких знаний модели, гибкого мышления и способности работать с тем, что вы приносите. Они не требуют непрерывного сохранения контекста, доступа к живым данным или запуска по расписанию.

Проектная отчетность — другая категория задач. Она требует постоянного обновления контекста, потому что отчет имеет смысл только в соотнесении с предыдущими. Она требует доступа к данным в режиме реального времени, потому что отчет на основе вчерашних данных из Jira уже устарел. Она требует запуска по расписанию, потому что отчет, который формируется только если человек нажал соответствующие кнопки, не является автоматизацией. И она требует инфраструктуры доставки, потому что отчет в окне чата не доберется до тех, кому он нужен.

Самый четкий сигнал, что вы используете неподходящий инструмент, — когда вы обнаруживаете, что выполняете значительный объем ручной работы, компенсируя то, чего инструмент не умеет. Копируете данные из Jira в Claude каждую неделю, ставите напоминание в календаре, чтобы запустить процесс сборки отчета, и вручную пересылаете результат клиенту.

Вся эта ручная работа — реальные потраченные часы, и они накапливаются. Когда я четко поняла, где именно разрыв, вопрос стал проще: как должен выглядеть инструмент, который закрывает все пять моих потребностей?

Хочу конкретно описать, что изменилось, когда я начала использовать обновленный PM агент от Enji для плановой отчетности — потому что разница ощутима и заслуживает описания.

Первое, что я настроил, — повторяющуюся задачу для формирования еженедельного отчета. Я описала, что хочу получать: статус-саммари с выполненными задачами, текущими блокерами, отслеживанием майлстоунов и рисками для клиента — и указала, что отчет должен отправляться каждый понедельник утром на почту клиента и в командный Slack-канал. Это была разовая настройка, и с тех пор отчет формируется и отправляется каждую неделю без моего участия.

Агент формирует отчет на основе реальных Jira-тикетов, закрытых или измененных за прошедшую неделю, сверяет их с активностью в коммитах и данными ворклогов, проверяет текущий спринт относительно запланированного майлстоуна и отмечает все, что выбивается из паттернов. Если тикет завис в одном статусе дольше нашего типичного времени цикла — агент это фиксирует. Если скорость сгорания денежных средств опережает выполнение скоупа — выносит на поверхность.

В первый раз, когда в отчете появился риск, который я сама не заметила — зависимость, которая создаст узкое место через два спринта — я поняла, что конкретно означает "контекстно-зависимый" на практике. Модель анализировала доступные ей данные в накопленном контексте и выдавала инсайт, на который у меня ушло бы еще тридцать минут ручного копания в данных.

Отчет также учитывает файл Project.md, настроенный при подключении проекта к Enji, — файл с информацией о Jira-бордах. В отличие от системного промпта, который нужно вставлять вручную, Project.md подключается автоматически при каждом запуске по расписанию — контекст остается актуальным без моего участия.

Когда я вспоминаю пятничный ритуал из начала этой статьи, понимаю, что убрала колоссальный объем ручной работы. Сбор данных — исчез. Перекрестная проверка — исчезла. Синтез — исчез. Теперь мне оставалось прочитать отчет, решить, требует ли что-то коммуникации с командой или клиентов, и иногда вписать нюанс, который живет за пределами инструментов. Последнее — незаменимо. Все остальное было механической работой, замаскированной под менеджмент.

Оценивая, подходит ли универсальный AI или специализированный агент для задачи отчётности, я теперь прохожу через четыре вопроса.

1. Требует ли задача данных, которых модель не видит? Если отчет нуждается в информации из Jira, GitHub, Slack или другой живой системы, универсальный LLM потребует, чтобы вы принесли эти данные вручную. Если это нетривиальный объем работы или данные меняются достаточно часто, чтобы ручной сбор давал ошибки — вам нужен инструмент с нативными интеграциями.
2. Должен ли отчет выходить без вашего участия? Если он должен уходить в 8 утра в понедельник — за вашим столом вы или нет — есть обходные пути: Zapier или Make могут запустить модель и куда-то отправить результат, но это дополнительный слой настройки, который не решает проблему с данными. Если вам нужно, чтобы это просто работало — нужен инструмент со встроенным расписанием, как Enji.
3. Зависит ли качество отчета от знания того, что было раньше? Если ценность отчета частично в сравнении этой недели с прошлой или в понимании того, является ли текущая ситуация отклонением от исторических паттернов — нужен инструмент с регулярно обновляемым контекстом о проекте.
4. Должен ли результат дойти до кого-то, кроме вас? Если отчет нужно отправить клиенту по почте, запостить в Slack или доставить в определенном формате определенному адресату по расписанию — нужен инструмент с инфраструктурой доставки. Доставку можно настроить через платформы автоматизации, но это еще один слой, который нужно конфигурировать и поддерживать. Если доставка — ключевое требование задачи, она должна быть частью инструмента, а не надстройкой над ним.

Если вы ответили "да" хотя бы на один из этих вопросов — лучше подобрать подходящий инструмент под ваши требования, чтобы ощутить реальнуб эффективность от ИИ-автоматизации.