Разработка AI PM — управление проектами с LLM

Почему AI Project Manager буксует на живых проектах

Управление проектами с LLM упирается не в качество модели, а в состояние данных. Языковая модель уверенно отвечает на вопрос «что в проекте», пока проект живёт в одном файле. На живом проекте всё разложено по трекеру задач, календарю, репозиторию, документам и переписке в мессенджере, и ни один источник не полон. Ассистент собирает ответ из того, до чего дотянулся, и уверенно достраивает остальное — это первый и самый частый сбой внедрения ассистента в проекты.

Второе — права. Руководитель видит весь портфель, подрядчик только свой контур, аналитик часть карточек. Агрегатор под одной сервисной учёткой либо теряет половину контекста, либо отдаёт в ответ то, что конкретному человеку видеть не положено. Разграничение доступа приходится протаскивать через весь путь данных, а не навешивать на выдаче.

Третье — свежесть. Люди закрывают задачи в конце недели, синхронизация идёт по расписанию, и к моменту вопроса срез устарел на день-два. Автоматизация статусов без перестройки привычек команды даёт аккуратную панель с неверными числами, и на неё начинают опираться в решениях.

Прогноз сроков проекта при таком входе считается по числу открытых задач, а не по фактической длительности цикла. График выходит ровным и ломается на ожидании ответа от смежника, переделке, отпусках. Поэтому AI Project Manager буксует не на демонстрации, а на второй-третий месяц работы.

Разбираем, как это закрывается: единый слой данных, правила доступа по ролям и регулярная сверка ассистента с реальностью.

Измеримый эффект: сроки, статусы, загрузка команды

Управление проектом перестаёт зависеть от того, кто и когда вспомнил обновить статус. Агент сам читает события в трекере задач и репозитории — переходы, комментарии, правки — и собирает картину по фактам. Руководитель получает сводку к началу дня вместо часового обхода команды.

• Статусы без ручных опросов. Из Jira и аналогичных трекеров подтягиваются изменения по задачам, из репозитория — активность по коду: сводка собирается сама, у команды остаётся 10 минут на уточнения.
• Раннее предупреждение о просрочке. Прогноз считается по историческому темпу закрытия похожих задач: сигнал приходит за 3-5 дней до срока, когда перераспределение ещё возможно, а не в день срыва.
• Загрузка команды по данным. Число одновременных задач на человека, время в работе, частота переключений — перегруз и простой видны на графике, а не в памяти руководителя.
• Точность прогноза сроков. Отклонение прогноза от факта считается по каждой итерации: по мере накопления данных разброс сокращается с недель до 1-2 дней на горизонте цикла.
• Прозрачные сдвиги сроков. У каждой правки плана остаётся причина и данные, на которых она основана, — при разборе видно, где оценка была занижена, а где изменился объём работ.

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

Форматы внедрения: от подсказок до автономных действий

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

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

Как расширяют полномочия

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

Как проходит внедрение: семь шагов инженерной работы

Порядок работ здесь не формальность. Ассистент по управлению проектами не «знает» предмет сам по себе — он выводит состояние проекта из данных, которые до него доходят, и расходится с реальностью ровно там, где источники противоречат друг другу. Поэтому мы идём от аудита источников и прав к приёмке на исторических проектах: сначала фиксируем, что считается фактом, и только потом учим на этом модель.

1. Аудит проектных данных. Разбираем источники: трекер задач, календарь, репозиторий, документы, переписку. Смотрим полноту, дубли, устаревшие статусы и права доступа по ролям — и сразу отсекаем то, что нельзя отдавать в модель.
2. Модель предметной области. Договариваемся о словаре: что такое проект, задача, препятствие, готовность. Без единого словаря ассистент считает прогресс по-своему и расходится с руководителем.
3. Настройка интеграций. Подключаем системы, задаём расписание синхронизации, правила сопоставления сущностей и разграничение доступа. Отдельно описываем поведение при рассинхроне и ручных правках.
4. Сборка ассистента. Роли, шаблоны сводок, правила эскалации и обязательная ссылка на источник в каждом утверждении. Всё, что нельзя подтвердить данными, помечается как предположение.
5. Прогон на исторических проектах. Проверяем на закрытых проектах с известным итогом: где ассистент совпал с решением руководителя, где ошибся и почему. Правила правим до приёмки, а не после.
6. Приёмка решения. Критерии фиксируем заранее: доля ответов, подтверждённых источником, время на подготовку сводки, точность определения отклонений. Приёмка — на проектах, которые заранее не показывали.
7. Передача регламентов. Короткие инструкции для руководителя и команды: как задавать вопрос, что делать при сбое синхронизации, как откатить правило, кто владелец системы.

Схемы, политики доступа и регламенты на выходе

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

• Карта источников данных — системы, базы и файлы, откуда ассистент берёт контекст: способ доступа, периодичность обновления, владелец каждой записи и точка, где заканчивается его зона ответственности.
• Политики доступа к данным — матрица прав по ролям и уровням: что доступно каждой группе, какие разделы исключены полностью, как это правило проверяется после изменений.
• Регламент работы с ассистентом — допустимые типы запросов, места обязательной проверки человеком, порядок оформления ответа и фиксации ошибки.
• Конфигурации — шаблоны подсказок, правила разбиения документов на фрагменты, параметры подключений и поиска, версионируемые вместе с кодом.
• Документация по внедрению — схема компонентов, точки интеграции, внешние зависимости и порядок развёртывания с нуля на чистом контуре.
• Инструкции для сотрудников — короткие сценарии на 10–15 типовых задач с примерами корректного и неверного запроса.
• Порядок сопровождения — набор проверок работоспособности, частота обновления индекса, точки откатов и ответственные роли.

Такой комплект снимает главный риск эксплуатации: знание о системе остаётся у заказчика, а не у подрядчика. Новый инженер входит в проект по документации, а не по переписке, и любое ограничение можно перепроверить, а не принимать на слово.

Кейс: планирование релизов в продуктовой команде

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

Мы подключили AI Project Manager к Jira и к репозиториям: агент читает активность по задачам и изменениям кода, сам собирает статус, пересчитывает прогноз даты релиза и показывает расхождение между заявленным и фактическим прогрессом. Спринт планируется на исторических данных по похожим задачам, а не на интуиции.

Метрики до и после

Руководитель перестал быть узким местом в отчётности: разбор статусов занимает около часа, остальное время уходит на приоритеты и разблокировку команд. Управление релизами стало разговором о решениях, а не о сверке таблиц.

Что делать, если AI уже внедрён, но планы не соблюдаются?

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

Вторая причина — размытые критерии готовности. Задача «доработать интеграцию» может висеть открытой, хотя фактически сделана, и наоборот: формально закрытая работа возвращается на повторный цикл. Пока у задачи нет проверяемого признака завершения — пройденного набора тестов, принятого результата, согласованного документа, — модель и команда считают её по-разному, и план расходится с фактом уже на этапе учёта.

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

Диагностика занимает несколько дней и сводится к трём проверкам: полнота и свежесть данных проекта в трекере — например Jira, формализованные критерии готовности у каждой задачи, назначенный владелец решения. Там, где хотя бы одно звено не закрыто, автоматика управляет не проектом, а его отражением в учётной системе.

Технические сомнения: доступ, точность, зависимость от модели

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

Как разграничиваются права доступа?

Права наследуются от существующей системы: ассистент видит те проекты, задачи и документы, к которым у сотрудника уже есть доступ. Роли настраиваются по командам — руководитель направления получает сводку, участник только свой участок. При смене роли доступ отзывается вместе с учётной записью, а не отдельной заявкой.

Насколько точны рекомендации?

Модель не принимает решений: она собирает контекст из задач, переписки и статусов, предлагает варианты и показывает, на чём основан вывод. Ссылка на источник есть в каждом ответе, поэтому проверка занимает секунды. Качество считаем на ваших данных — доля принятых предложений видна по метрикам, а отклонённые разбираем.

Не потеряем ли контроль над ассистентом?

Подключение к задачам, расписанию и документам идёт через ограниченный интерфейс: чтение и подготовка черновиков. Отправка сообщений, смена сроков и статусов остаётся за человеком. Журнал действий доступен администратору, поэтому любое предложение можно отследить, отклонить или откатить.

Обсудим задачу и вернёмся с оценкой и планом работ

Для оценки проекта не нужен полный пакет документации — достаточно контекста о том, как управление проектами устроено у вас сейчас. Чем конкретнее вводные, тем точнее мы называем состав этапов и срок до старта внедрения.

Что помогает быстрее выйти на план работ:

• Описание текущего процесса: как ставятся задачи, кто меняет статусы, где собираются отчёты и сводки по вехам.
• Примеры реальных запросов и сообщений, которые сегодня разбираются вручную — 30-50 штук достаточно, чтобы оценить разброс формулировок.
• Обезличенная выгрузка задач и истории комментариев за период: по ней видно, какие данные вообще доступны и в каком качестве.
• Требования к доступам и хранению переписки: что допустимо отдавать модели, а что должно оставаться во внутреннем контуре.
• Кто со стороны заказчика принимает результат и по каким критериям считает, что AI Project Manager отвечает корректно.
• Ограничения по срокам запуска и предпочтения по размещению решения: внешняя инфраструктура или ваш контур.

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

Опишите задачу коротким письмом или голосом — обсудим её с инженерами и вернёмся с оценкой и планом работ.