Project management — 70% коммуникации и 30% планирования. ИИ снимает рутину коммуникационной части: статус-апдейты, повестки митингов, протоколы, обработка задач из бэклога, разбор incidents. Стратегические решения по проекту остаются за PM, но всё, что вокруг — пишется в 5 раз быстрее.
Внутри — 7 шаблонов под главные задачи проджект-менеджера: скоупинг нового проекта, kickoff-митинг, статус-апдейт стейкхолдерам, повестка стендапа и daily, retrospective после спринта/проекта, эскалация проблемы, проектный пост-мортем.
Для проектного управления это не про «агенты делают за вас» — это про «скорость подготовки артефактов». Если вы тратили час на retrospective повестку, теперь тратите 10 минут на промпт + 15 минут на редактуру. Аналогично с протоколами и статусами. Освободившееся время — на разговоры с людьми.
📐 Скоупинг нового проекта
Помоги выгрузить из заказчика все необходимые детали для скоупинга нового проекта. Что я знаю на старте: Заказчик: [внутренний / внешний клиент]. Запрос (своими словами): [как клиент сформулировал]. Кто будет делать: [команда + размер]. Дедлайн (если назван): [дата]. Бюджет (если назван): [сумма / диапазон]. Помоги собрать чек-лист уточняющих вопросов в 6 категориях: 1) Цели и success criteria: Какую конкретную бизнес-задачу решаем. Как поймём, что проект успешен (метрики). Что произойдёт, если НЕ сделаем. 2) Scope: Что входит в проект. Что НЕ входит (явно перечислить). Какие фичи MVP vs Nice-to-have. 3) Стейкхолдеры: Кто принимает решения по продукту. Кто принимает решения по бюджету. Кто конечные пользователи. 4) Технические ограничения: Существующая инфраструктура / зависимости. Интеграции с другими системами. Compliance / regulatory. 5) Тайминг и риски: Реалистичный дедлайн. Что блокирует прямо сейчас. Известные риски и допущения. 6) Процесс: Кто согласовывает результат. Частота статусов. Канал коммуникации. Принцип: задавай конкретные вопросы, не «расскажите про ваши пожелания». Лучше «опишите 1 типичный сценарий использования шаг за шагом». В конце — собери черновик project brief на 1 страницу с разделами: Goal, Scope (in/out), Stakeholders, Constraints, Success metrics, Timeline.
Раздел «что НЕ входит в scope» — самое ценное в скоупинге. Без него scope creep съест проект: каждый новый стейкхолдер добавит «ещё одну маленькую штуку», и через месяц вы делаете в 3 раза больше за тот же бюджет. Явный список «out of scope» позволяет ссылаться на него на каждой итерации: «это вне scope, обсудим в следующей фазе».
🚀 Kickoff-митинг проекта
Подготовь повестку и материалы для kickoff-митинга нового проекта. Контекст: Проект: [название + 1 фраза]. Длительность: [N недель / месяцев]. Команда: [кто и в какой роли]. Стейкхолдеры на митинге: [роли]. Есть готовый project brief: [да / нет]. Структура kickoff (60–90 мин): 1) Welcome + представления (5 мин) — кто кто. 2) Контекст и why (10 мин) — зачем проект, что произойдёт, если получится / не получится. 3) Проект brief (15 мин) — scope, цели, success metrics. Каждый стейкхолдер озвучивает своё понимание. 4) Roles & responsibilities (10 мин) — RACI matrix или просто «кто за что отвечает». 5) Timeline & milestones (15 мин) — ключевые даты, dependencies. 6) Communication & process (10 мин) — где общаемся, как часто статусы, как решаются спорные вопросы. 7) Risks & open questions (10 мин) — что беспокоит каждого участника. 8) Next steps & first commitments (5 мин) — конкретные действия каждого до следующей встречи. Подготовь: - Повестку с временем по разделам. - 3–5 главных вопросов, которые должны быть отвечены к концу митинга. - Шаблон протокола (для записи решений и action items). - Список людей, кому отправить summary после митинга. Принцип kickoff: лучше провести его правильно один раз, чем потом всю жизнь разгребать недоговорённости. 90 минут kickoff экономят 10 часов координации.
Пункт 7 «Risks & open questions» — пункт, который отличает кикофф «галочка» от кикофф «реально работающий». Если каждый участник проговорит, что его беспокоит, вы получите карту рисков на старте, а не будете натыкаться на них через 6 недель. Главное — записать всё, не обещать решить прямо сейчас.
📊 Статус-апдейт стейкхолдерам
Подготовь статус-апдейт по проекту [НАЗВАНИЕ] для стейкхолдеров. Контекст: Период с прошлого статуса: [неделя / две / месяц]. Аудитория: [руководство / клиент / вся компания]. Канал: [email / Slack / Confluence страница]. Что произошло за период: Достижения: [3–5 фактов с цифрами]. Блокеры / риски: [1–3 факта]. План на следующий период: [3–5 действий]. Нужна помощь: [запросы решений или ресурсов]. Структура статуса (формат TLDR): 1) RAG status: 🟢 / 🟡 / 🔴 — общий статус проекта. 2) TLDR (1 фраза) — главный месседж недели. 3) Прогресс vs плану — % выполнено vs % планировалось. 4) Достижения за период — 3–5 буллетов, конкретно. 5) Блокеры и риски — что мешает, что может пойти не так. 6) Что требует решения — конкретные запросы стейкхолдерам с дедлайном. 7) План на следующий период. Принципы: Главное — в первых трёх строках. Большинство стейкхолдеров читают только их. 🔴 — честно, не маскируя. Лучше плохая новость рано, чем сюрприз в дедлайн. Конкретные числа, не «работа идёт по плану». Запросы — с конкретными именами, кто должен принять решение, и к какому сроку. Запрет: «всё хорошо, идём по графику» (пустой апдейт), смешивание технического жаргона с бизнес-контекстом, длина больше 1 экрана.
Главное в статус-апдейте — RAG-статус и TLDR в первых строках. Стейкхолдеры — руководители — не будут читать 2 страницы. 🟢 / 🟡 / 🔴 + одна фраза TLDR должны давать им 90% картины. Кто хочет деталей — листает дальше. Кто не хочет — закроет с пониманием статуса.
☕ Daily standup и его повестка
Я веду команду, помоги настроить эффективные дейли стендапы. Контекст: Размер команды: [N человек]. Тип проекта: [продуктовая разработка / консалтинг / агентство / etc]. Текущая боль: [почему дейли не работает — слишком долгие / превращаются в статусы / люди отключаются]. Помоги собрать формат: 1) Цель дейли (одна фраза): координация и расчистка блокеров на сегодня. НЕ статус-апдейт для руководителя. 2) Структура (15 минут максимум): Каждый отвечает на 3 вопроса: - Что я закончил вчера. - Что планирую сегодня. - Где мне нужна помощь / что блокирует. 3) Правила работы: Стоя — естественный таймер. Никаких «пока вы говорите я проверю Slack». Технические дискуссии — в parking lot, обсуждаются после дейли. Если человек 3 дня подряд говорит «работаю над тем же» — разбор после дейли. 4) Что делать если дейли разваливается: Слишком длинно: рестрикция «3 минуты на человека», таймер. Превращается в статус: явно напомнить, что аудитория — не руководитель, а команда. Люди не приходят: пересмотри время / формат / актуальность. Кажется бесполезным: проведи ретроспективу формата. 5) Альтернативы дейли: Если команда мало взаимозависима — дейли можно заменить async-стендапом в Slack-канале. Если команда распределённая — проверь время для разных часовых поясов. Запрет: Дейли по 30+ минут. Дейли как статус для PM (это работа PM, а не команды). Технические разборы внутри дейли — это убивает время тех, кому это не релевантно.
Главная ошибка дейли — превращение его в «статус для PM». Тогда команда отчитывается перед руководителем, а не координируется между собой. Признак: люди говорят «я сделал X», а не «я сделал X, никто на этом не блокирован». Альтернатива — async-стендап в Slack: каждый пишет три ответа, обсуждают только при необходимости. Освобождает 15 минут × 5 дней = 1 час 15 минут на человека в неделю.
🔄 Retrospective после спринта
Помоги провести retrospective команды после спринта / проекта. Контекст: Что закончили: [спринт N / проект]. Длительность: [сколько недель]. Размер команды: [N]. Главные результаты: [что удалось / не удалось]. Атмосфера в команде сейчас: [позитивная / выгоревшая / напряжённая]. Структура retrospective (60–90 мин): 1) Set the stage (5 мин) — напомнить цель ретро (улучшить процесс, не обвинить людей), правила безопасности (blameless). 2) Сбор данных (15 мин) — фактический обзор: что было запланировано, что сделано, что нет, ключевые метрики. 3) Сбор ощущений (15 мин) — каждый пишет на стикерах в трёх категориях: - Что хорошо работает (continue) - Что плохо работает (stop) - Что попробовать (start) 4) Группировка и обсуждение (20 мин) — сгруппировать похожие, обсудить топ-3 по голосованию. 5) Action items (10 мин) — конкретные действия с ответственными и дедлайнами. **Не больше 3 за ретро**, иначе никто не сделает. 6) Закрытие (5 мин) — каждый одной фразой: что унёс с ретро. Принципы blameless retro: Фокус на процессе, не на людях. «Какая система привела к этому?», не «кто виноват?». Психологическая безопасность — молчащая команда не значит согласная. Подготовь: Фасилитаторскую повестку. Шаблон Miro / FigJam доски с тремя колонками. Список наводящих вопросов на случай молчания. Шаблон протокола с action items. Запрет: ретро как поиск виноватого, ретро без записи action items, повторение одних и тех же action items от ретро к ретро (значит, никто не делает).
Лимит «не больше 3 action items за ретро» — критичен. Команда обычно выдаёт 10–15 идей улучшений, и наивный PM записывает все. Через месяц 0 из 15 не сделано. Лучше 3 конкретных, измеримых, с ответственными — у которых есть шанс реально случиться. Затем следующее ретро — следующие 3.
🚨 Эскалация проблемы
Мне нужно эскалировать проблему руководству / клиенту. Помоги сформулировать. Контекст: Проблема (одна фраза): [конкретно]. Когда обнаружена: [дата]. Что уже пробовали: [действия команды]. Почему сами не справимся: [ресурсы / полномочия / решение]. Что нужно от стейкхолдера: [конкретно — решение / ресурс / приоритет]. Срочность: [часы / дни / недели]. Структура эскалации: 1) Subject — короткий, передающий суть и срочность: «[Срочно / Важно / Информативно] Проект X: блокер с Y». 2) TLDR — одна фраза, что произошло и что нужно решить. 3) Контекст — короткий бэкграунд (2–3 фразы), без воды. 4) Что я уже сделал — конкретные действия (показать, что не сразу побежал к руководителю). 5) Что мне нужно — конкретное решение / ресурс / эскалация выше. 6) Что произойдёт, если не решим — последствия в конкретных цифрах / сроках. 7) Альтернативы (если есть) — 1–2 варианта с trade-off. 8) Срок ответа. Тон: Профессиональный, не паникующий. Не обвиняющий («команда X не сделала») — фактический «X не готов, потому что Y». Без «к сожалению» и других извинений — это профессионалы, решающие проблему вместе. Принципы эскалации: Эскалируй один раз, на правильный уровень. Не CC всех на всякий случай — это снижает приоритет письма. Если получаешь запрос «можешь ещё подождать?» — назови конкретную дату, после которой уже нельзя. Запрет: эскалация без альтернатив (выглядит как перекладывание ответственности), эмоциональные оценки коллег / процесса, многословие.
Раздел «что я уже сделал» — критичен. Без него руководитель будет думать, что вы пришли с первой же сложностью. С ним — видит, что вы исчерпали свои возможности и просите помощь осознанно. Раздел «альтернативы» поднимает вашу позицию: вы не приносите проблему, вы приносите решение, которое требует выбора.
📜 Пост-мортем после завершения проекта
Проект [НАЗВАНИЕ] завершён. Помоги провести пост-мортем для извлечения уроков. Контекст: Длительность проекта: [месяцев]. Команда: [N человек, роли]. Бюджет: план vs факт. Сроки: план vs факт. Scope: достигнут полностью / частично / выше плана. Качество результата: [по чьей-то оценке]. Структура пост-мортема: 1) Резюме проекта (1 страница): Что должны были сделать. Что сделали. Что не сделали и почему. 2) Цифры: Бюджет план / факт / отклонение в %. Срок план / факт / отклонение в %. Команда — не было ли перегруза, ротации, выгораний. Качество — баги в проде, клиентский фидбэк. 3) Что прошло хорошо (3–5 факторов): Что повторить в следующих проектах. 4) Что прошло плохо (3–5 факторов): Конкретно, без обвинений. Какая системная причина (не «человек X недоработал», а «процесс Y не покрывал случай Z»). 5) Уроки на следующий проект: Конкретные изменения в процессе. Что включить в стандарт работы. Что попросить у руководства (ресурсы, полномочия, инструменты). 6) Распространение: Кому отправить пост-мортем (команда, руководство, соседние команды, клиент?). Какая часть — публичная, какая — только внутренняя. Принципы: Blameless — фокус на системе, не на людях. Действенно — каждый «урок» должен превращаться в конкретное изменение. Ловит и хорошие моменты — без этого читается как разнос. Запрет: пост-мортем как формальность («проект завершён, написал отчёт»), пост-мортем без action items на следующий проект, обвинение конкретных людей.
Принцип blameless post-mortem — фундамент культуры обучения. Если ошибки наказываются, команда перестаёт их признавать, и следующий проект повторяет те же грабли. Если ошибки исследуются как системные сбои («процесс не покрывал X»), команда учится. Раздел «что повторить» — важен не меньше «что исправить»: успешные практики так же подвержены забыванию, как ошибки.