Как работать с ИИ для планирования проектов: шаги, промты, проверка

Планирование проектов ломается не из-за отсутствия инструментов. Диаграмма Ганта есть почти в каждом трекере, шаблоны структуры работ лежат в открытом доступе уже тридцать лет, а методички по оценке трудозатрат написаны подробнее, чем большинство корпоративных регламентов. Ломается оно на простой вещи, а именно на стоимости первого черновика, который слишком дорого делать и слишком больно переделывать. Языковые модели изменили именно эту экономику, и именно поэтому разговор про ИИ в планировании имеет смысл вести предметно, а не в жанре прогнозов.

Что ИИ делает в планировании проектов

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

Вот что модель делает достаточно надёжно, чтобы на это можно было опираться в работе.

• Декомпозиция цели на этапы и задачи до уровня, на котором задачу можно отдать исполнителю.
• Первичная оценка трудозатрат в человеко-часах и перевод её в календарные сроки с учётом состава команды.
• Построение связей между задачами и поиск того, что нельзя начать раньше, чем закончится предыдущая работа.
• Расстановка приоритетов по заданному критерию, будь это влияние на выручку, риск срыва или зависимость других работ.
• Генерация перечня рисков с указанием признаков, по которым риск можно заметить заранее.
• Проверка загрузки по людям и выявление недель, где один специалист стоит в трёх задачах одновременно.
• Превращение расшифровки встречи в список задач с ответственными и сроками.
• Сборка статуса проекта из разрозненных обновлений в текст, который можно отправить заказчику.

Разберу пару пунктов подробнее, потому что именно в них сосредоточена основная экономия.

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

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

Нейросеть не знает вашего проекта. Она знает, как обычно выглядят проекты такого типа. Разница между этими двумя знаниями и есть работа менеджера.

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

Чем ИИ отличается от обычного таск-трекера

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

• Трекер отвечает на вопрос, что происходит с задачами сейчас.
• Модель отвечает на вопрос, какие задачи вообще должны быть и в каком порядке.
• Трекер фиксирует факт, модель строит гипотезу.
• Трекер требует, чтобы план уже существовал, модель нужна ровно до этого момента.

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

Отдельная категория — встроенный ИИ в отечественных системах управления проектами. В Kaiten, Weeek, Битрикс24 и ряде других сервисов помощник работает внутри рабочего пространства и видит ваши задачи, сроки и участников. Это снимает главную проблему универсальных чат-моделей, то есть необходимость каждый раз вручную пересказывать контекст. Платой становится меньшая гибкость, поскольку встроенный помощник умеет то, что в него заложили, и не станет вести с вами длинный аналитический диалог о структуре работ.

На каких этапах проекта ИИ помогает больше всего

Отдача сильно неравномерна по жизненному циклу проекта, и понимание этой неравномерности экономит больше времени, чем любой удачный запрос.

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

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

Пошаговая сборка плана: от цели до задач в трекере

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

Шаг 1. Собрать вводные до того, как открывать чат

Это единственный шаг, который нельзя делегировать, и единственный, который определяет качество всего остального. Модель выдаёт общий план ровно в той мере, в какой общий запрос она получила. Запрос про план запуска продукта даст вам содержание учебника. Запрос с конкретикой даст рабочий черновик.

Минимальный набор вводных, без которых идти дальше бессмысленно.

• Результат, который считается достигнутым. Не цель в общем виде, а проверяемое состояние на конкретную дату.
• Жёсткая дата и её природа. Выставка, отчётный период, договорное обязательство. Модель по-разному обходится со сроком, который можно сдвинуть, и со сроком, который сдвинуть нельзя.
• Состав команды с ролями и реальной доступностью в часах в неделю. Не штатное расписание, а то, сколько человек действительно даёт проекту.
• Бюджет и то, что в него входит. Хотя бы порядок величины.
• Ограничения и обязательные согласования. Юридическая проверка, служба безопасности, утверждение у руководства, закупочные процедуры.
• Что уже сделано и что переиспользуется. Готовые материалы, существующая инфраструктура, прошлые наработки.
• Что осознанно не входит в проект. Этот пункт пропускают чаще всего, а он убирает половину лишних задач в ответе.

Для примера с линейкой продукции вводные выглядят так. Результат состоит в том, что к началу выставки работает сайт линейки с каталогом из двенадцати позиций, подготовлены печатные материалы, обучены четыре менеджера по продажам и отправлены три письма по базе дилеров. Срок жёсткий и привязан к дате выставки. Команда включает руководителя проекта с загрузкой десять часов в неделю, маркетолога на полную ставку, дизайнера на двадцать часов, подрядчика по разработке сайта и технолога, который даёт консультации по четыре часа в неделю. Обязательное согласование описаний продукции у технического директора занимает до пяти рабочих дней. Мобильное приложение и работа с розничными сетями в проект не входят.

План, который модель собрала за три минуты, стоит ровно столько, сколько стоят вводные, которые вы ей дали. Экономия на этом шаге окупается отрицательно.

Шаг 2. Получить декомпозицию по этапам и задачам

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

Хороший уровень дробления определяется двумя правилами. Задача должна занимать от половины дня до пяти дней и должна иметь один ответственный результат, который можно предъявить. Если задача занимает меньше половины дня, она станет шумом в трекере. Если больше недели, её фактическое состояние будет непонятно до самого конца.

Что проверять в полученной структуре в первую очередь.

• Пропущенные работы по согласованиям и приёмке. Модель почти всегда недооценивает их количество.
• Работы по подготовке, то есть доступы, учётные записи, договоры с подрядчиками, закупка.
• Задачи, которые на самом деле являются проектами и требуют отдельного разбора.
• Избыточное дробление в знакомой модели области и грубые блоки в незнакомой.
• Формулировки без проверяемого результата, по которым нельзя понять момент завершения.

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

Шаг 3. Проставить сроки, связи и контрольные точки

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

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

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

1. Утверждены описания и характеристики всех двенадцати позиций.
2. Принят визуальный ряд, то есть фотографии и оформление каталога.
3. Сайт развёрнут на тестовом окружении с полным каталогом.
4. Печатные материалы отправлены в типографию.
5. Менеджеры прошли обучение и сдали проверочный разбор продукта.
6. Сайт открыт для внешних посетителей, аналитика собирает данные.

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

Шаг 4. Расставить приоритеты и распределить нагрузку

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

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

Варианты решения, которые стоит просить сразу в нескольких видах.

• Сдвиг части работ на более свободные недели с проверкой того, что сдвиг не ломает цепочку зависимостей.
• Привлечение внешнего исполнителя на выделенный блок с оценкой стоимости и времени на его введение в работу.
• Сокращение объёма, например подготовка каталога в двух форматах вместо четырёх.
• Перенос работ на период после ключевой даты, если они не нужны к выставке.

Шаг 5. Отшлифовать план в диалоге и убрать лишнее

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

Рабочий приём состоит в прямом запросе на сокращение. Попросите указать задачи, которые можно убрать без влияния на заявленный результат, и объяснить, что именно теряется в каждом случае. Второй запрос просит объединить задачи, которые делает один человек подряд в одном контексте. На нашем примере из пятидесяти одной задачи после двух таких проходов осталось тридцать девять, и план стал заметно управляемее.

Затем стоит прогнать план через вопросы, на которые у вас пока нет ответа.

• Какие задачи зависят от людей вне проектной команды и сколько времени занимает их реакция по факту, а не по регламенту.
• Что произойдёт с планом, если ключевой участник выпадет на неделю.
• Какие работы придётся переделывать, если описания продукции утвердят с правками.
• Где в плане нет запаса вообще и почему.

Шаг 6. Перенести задачи в рабочий сервис

План, который остался в переписке, не существует. Перенос стоит делать сразу и структурно, а не копированием текста в описание одной большой задачи.

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

Несколько вещей, которые экономят время на этом шаге.

1. Задайте сквозную нумерацию задач до переноса, иначе связи между ними придётся восстанавливать вручную.
2. Проверьте, что названия ответственных совпадают с учётными записями в системе, включая написание.
3. Переносите этапы как отдельные сущности, а не как текстовую метку в названии задачи.
4. Контрольные точки заводите задачами с нулевой длительностью, если система это поддерживает.
5. Сохраните исходный диалог с моделью. Через месяц, когда план поедет, он понадобится, чтобы вспомнить логику решений.

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

Промты для плана проекта

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

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

Декомпозиция большой цели на этапы

Первый запрос должен быть самым нагруженным по контексту и самым скромным по требуемому результату. Вам нужна только структура.

Ты руководитель проектов в производственной компании с опытом вывода новых продуктовых линеек. Контекст проекта. Компания выпускает новую линейку из двенадцати позиций и готовит её показ на отраслевой выставке через четырнадцать недель. Результат к дате выставки включает работающий сайт линейки с каталогом, печатные материалы, обученных четырёх менеджеров по продажам и три отправленных письма по базе дилеров. Команда состоит из руководителя проекта с загрузкой десять часов в неделю, маркетолога на полную ставку, дизайнера на двадцать часов в неделю, внешнего подрядчика по разработке сайта и технолога с четырьмя часами в неделю на консультации. Согласование описаний продукции у технического директора занимает до пяти рабочих дней. Мобильное приложение и работа с розничными сетями в проект не входят. Задача. Собери структуру работ по этапам. Внутри каждого этапа перечисли задачи так, чтобы каждая занимала от половины дня до пяти дней и имела проверяемый результат. Сроки и даты не указывай. Формат вывода — нумерованные этапы, внутри задачи с указанием результата и предполагаемой роли исполнителя. Отдельным списком вынеси работы, которые ты добавил по собственной инициативе, потому что они обычно нужны в таких проектах, но в вводных не упомянуты.

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

Расчёт сроков с буферами

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

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

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

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

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

Карта зависимостей между задачами

Зависимости — самая скучная и самая полезная часть планирования. Вручную их почти никто не выстраивает до конца, и именно поэтому проекты срываются на связях, а не на задачах.

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

Последний пункт выдаёт узловые задачи проекта. В примере с линейкой продукции такой задачей оказалось утверждение технических описаний, от которого зависели каталог, печатные материалы, обучение менеджеров и наполнение писем дилерам. Четыре зависимости на одну работу с пятидневным сроком согласования означали, что эта задача должна быть первой в календаре и находиться под личным контролем руководителя проекта. До построения карты она стояла в середине второго этапа как рядовая строка.

Приоритеты и распределение нагрузки

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

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

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

Для каждой недели с превышением загрузки предложи три способа решения — перенос работ в свободные недели, передача работ внешнему исполнителю и сокращение объёма. Для каждого способа укажи, что он ломает в карте зависимостей, сколько примерно стоит и какой риск добавляет. Не выбирай лучший вариант, я приму решение сам.

Поиск рисков и точек срыва

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

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

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

Календарный план по неделям

Финальный запрос собирает всё в вид, пригодный для переноса в систему управления проектами.

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

Требование самопроверки в последнем предложении снимает часть ошибок, но не все. Модели плохо держат в голове арифметику на длинных таблицах, поэтому итоговые цифры всё равно стоит пересчитать после импорта, когда их покажет сама система.

Приёмы, которые повышают качество ИИ-плана

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

Запросить три версии: базовую, сжатую, с запасом

Один план создаёт ложное ощущение единственно возможного сценария. Три версии показывают пространство решений и сильно упрощают разговор с руководством.

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

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

Планировать от конечной даты назад

Прямое планирование от начала даёт срок, который получится. Обратное планирование от даты показывает, что должно произойти, чтобы срок был выполнен. Для проектов с жёсткой датой второй способ точнее, потому что он сразу обнажает невозможные места.

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

Разрывы, которые выдаёт такой запрос, обычно и есть настоящие проблемы проекта. Если отсчёт назад от печатных материалов приводит к тому, что фотосъёмка должна была начаться на прошлой неделе, вы узнаёте об этом в первый день планирования, а не в девятую неделю.

Попросить ИИ оспорить собственный план

Модель охотно соглашается с тем, что сама же предложила, если её об этом не просить иначе. Смена роли ломает это соглашательство.

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

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

Задать стресс-тест: что сорвёт сроки первым

Стресс-тест отличается от поиска рисков тем, что он работает не со списком угроз, а со сценариями и их последствиями для плана.

1. Задайте конкретное событие, например ключевой исполнитель выпадает на полторы недели в середине проекта.
2. Попросите пересчитать план при этом условии и показать новую дату готовности.
3. Запросите минимальный набор действий, который возвращает проект к исходной дате, с оценкой стоимости.
4. Повторите для трёх-четырёх разных событий, включая задержку подрядчика и возврат описаний продукции на существенную переработку.

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

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

Отдельно запросить список лишних задач

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

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

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

Пример: план запуска продукта за один диалог

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

№	Этап	Задача	Исполнитель	Часы	Недели	Зависит от
1	Подготовка	Сбор технических данных по двенадцати позициям	Технолог	12	1–2	—
2	Подготовка	Написание описаний и характеристик продукции	Маркетолог	32	2–3	1
3	Подготовка	Согласование описаний у технического директора	Руководитель	4	3–4	2
4	Подготовка	Договор и постановка задачи подрядчику по сайту	Руководитель	8	1–2	—
КТ1	Контрольная точка	Описания всех позиций утверждены	—	0	4	3
5	Визуальные материалы	Подготовка образцов и организация съёмки	Маркетолог	16	3–4	1
6	Визуальные материалы	Фотосъёмка двенадцати позиций	Внешний исполнитель	—	5	5
7	Визуальные материалы	Обработка изображений и сборка визуального ряда	Дизайнер	24	6–7	6
КТ2	Контрольная точка	Визуальный ряд принят	—	0	7	7
8	Сайт	Разработка структуры и вёрстка каталога	Подрядчик	—	5–8	4
9	Сайт	Наполнение каталога текстами и изображениями	Маркетолог	28	8–9	3, 7, 8
10	Сайт	Настройка аналитики и целей	Подрядчик	—	9	8
КТ3	Контрольная точка	Сайт развёрнут на тестовом окружении с полным каталогом	—	0	10	9, 10
11	Печатные материалы	Макеты каталога и буклета	Дизайнер	36	8–10	3, 7
12	Печатные материалы	Корректура и утверждение макетов	Руководитель	6	10	11
КТ4	Контрольная точка	Материалы отправлены в типографию	—	0	11	12
13	Продажи	Подготовка материалов для обучения менеджеров	Маркетолог	20	10–11	3
14	Продажи	Обучение четырёх менеджеров и проверочный разбор	Технолог	8	12	13
15	Дилеры	Подготовка трёх писем и сегментация базы	Маркетолог	18	11–12	3, 7
16	Запуск	Открытие сайта и отправка первого письма	Руководитель	6	13	КТ3, 15
КТ5	Контрольная точка	Сайт открыт, аналитика собирает данные, менеджеры обучены	—	0	13	14, 16
Р	Резерв	Резерв руководителя проекта	—	—	14	—

Три наблюдения по этой таблице, которые полезнее самой таблицы.

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

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

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

Сервисы для планирования проектов с ИИ

Инструменты делятся на две группы с разной логикой применения, и выбор между ними определяется не качеством модели, а тем, где живут ваши данные о проекте.

Таск-трекеры со встроенным ИИ

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

• Битрикс24 с помощником CoPilot подходит компаниям, которые уже используют платформу как основную рабочую среду. Сильная сторона в связке проектов с задачами по продажам и документооборотом.
• Kaiten с ИИ-функциями работает с канбан-логикой и помогает разбирать встречи, собирать статусы и формулировать задачи. Хорошо ложится на команды, которые ведут поток работ, а не проекты с жёсткой структурой.
• Weeek предлагает помощника для генерации задач и подзадач внутри проектов, удобен небольшим командам за счёт низкого порога входа.
• Яндекс Трекер применяют там, где важна интеграция с остальной инфраструктурой компании и выдерживаются высокие требования к разграничению доступа.

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

Универсальные чат-модели и ИИ-агенты

Здесь вы получаете гибкость и способность к длинному разбору, но платите ручным переносом контекста и результата.

• GigaChat и YandexGPT доступны напрямую, работают с русским языком без потерь и подходят компаниям с требованием хранения данных внутри страны. Для декомпозиции и расчётов по плану их возможностей достаточно.
• Cotype от МТС применяется в корпоративном контуре, когда нужна модель с возможностью развёртывания рядом с внутренними системами.
• Зарубежные модели сильнее в длинных рассуждениях и работе с большими таблицами, но доступ к ним требует отдельного решения по инфраструктуре и несовместим с политиками ряда компаний.

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

Как выбрать сервис под размер проекта и команды

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

1. Где уже ведутся задачи. Если команда живёт в одной системе, встроенный помощник выигрывает за счёт контекста, даже будучи слабее по модели. Второй сервис рядом с первым почти всегда остаётся неиспользованным.
2. Как часто вы планируете. Для проекта раз в квартал достаточно универсальной модели и ручного переноса. Для потока проектов нужна связка, где план уходит в трекер без копирования вручную.
3. Какие данные попадают в запрос. Если в контексте есть цены, условия договоров, персональные данные или технологические детали, выбор сужается до решений с подходящей политикой обработки, и этот фильтр применяется раньше всех остальных.

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

Проверка плана перед запуском

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

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

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

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

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

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

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

Шпаргалка: что передать ИИ, а что проверить самому

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

Отдаём модели	Проверяем сами
Декомпозиция цели на этапы и задачи	Полноту состава работ и уровень дробления
Оценка трудозатрат в трёх вариантах	Сравнение с фактом прошлых проектов
Построение связей и поиск длинной цепочки	Связи, которые следуют из устройства компании
Перевод часов в календарь	Реальную доступность людей с отпусками и другими проектами
Генерация списка рисков с признаками	Вероятности и то, какие риски применимы к вашему контексту
Приоритеты по заданному критерию	Сам критерий и решения о жертвах
Варианты решения перегрузки	Выбор варианта и разговор с людьми
Оформление в таблицу для импорта	Итоговые суммы после загрузки в систему
Черновики писем, статусов, задач для команды	Формулировки, которые уходят заказчику и руководству

Правило, по которому строится эта таблица, простое. Модели достаётся всё, что проверяемо и обратимо. Человеку — всё, где цена ошибки падает на людей и деньги, а проверить правильность до запуска нельзя.

Частые ошибки при планировании через ИИ

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

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

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

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

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

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

Что оставить за человеком

Граница здесь не в сложности задачи и не в объёме данных. Модель прекрасно справляется с расчётами, которые человек делает медленно и с ошибками. Граница проходит там, где решение нельзя проверить до его последствий.

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

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

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

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

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

Частые вопросы об ИИ для планирования проектов

Какая модель лучше подходит для планирования

Разница между современными моделями для этой задачи меньше, чем разница между хорошим и плохим запросом. Для декомпозиции, расчёта трудозатрат и построения связей достаточно любой модели верхнего уровня, включая GigaChat и YandexGPT. Значимое преимущество появляется только на длинных планах с большими таблицами, где важна способность удерживать весь контекст и не терять арифметику. Если выбор упирается в требования к обработке данных, он решается этим фильтром, а не качеством ответов.

Может ли ИИ построить диаграмму Ганта или дорожную карту

Данные для диаграммы — да, саму диаграмму — опосредованно. Модель выдаёт корректную таблицу с задачами, датами и предшественниками, которую система управления проектами отрисовывает сама. В режиме агента с доступом к файлам можно получить готовый документ с дорожной картой, что экономит время на оформлении перед защитой проекта. Рисовать Ганта в чате бессмысленно: он нужен живым, с пересчётом при каждом сдвиге, а это умеет только трекер.

Можно ли планировать по загруженному документу

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

Насколько можно доверять срокам от ИИ

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

Безопасно ли загружать бизнес-планы и внутренние данные

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

Как не собирать план каждый раз с нуля

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

Можно ли составить план сразу на год

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

Заменит ли ИИ проджект-менеджера

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

Модель собирает план за час. Решает, стоит ли по нему идти, по-прежнему человек — и в этом вся разница между быстрым черновиком и проектом, который дошёл до конца.