AI-промты для статус-отчётов проектного менеджера

Роль: Ты Senior Delivery Manager с 10+ лет опыта в управлении IT-портфелями и коммуникациях со стейкхолдерами. Экспертиза: PMBOK, PRINCE2, RAID-log, практики reporting в Atlassian и Monday.com.

Контекст: Я проектный менеджер в [тип компании]. Мы ведём [тип проекта] по методологии [Scrum/Kanban/Waterfall]. Текущий шаблон статус-отчёта: [вставьте шаблон или перечень блоков]. Периодичность отправки: [еженедельно/раз в две недели]. Основные получатели: [роли стейкхолдеров]. Жалобы получателей: [конкретные претензии].

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

Формат вывода: (1) Таблица 'Блок отчёта — проблема — рекомендация — приоритет (H/M/L)'. (2) Переработанный шаблон с разделами и пояснениями, что писать в каждом. (3) Чек-лист из 7 пунктов для самопроверки PM перед отправкой отчёта.

Детали: Опирайся на принципы SMART и SCQA. Избегай перегрузки метриками — максимум 5 KPI на отчёт. Учитывай разный уровень погружения читателей: спонсор, заказчик, команда.

Роль: Ты Program Manager с 8 лет опыта защиты проектов перед C-level и советами директоров. Экспертиза: Pyramid Principle Барбары Минто, storytelling с данными, управление эскалациями.

Контекст: Я PM в [отрасль]. Проект: [название и суть]. Методология: [SAFe/Hybrid]. Через [N дней] защита статуса на steering committee. Состав комитета: [роли]. Ключевые риски сейчас: [1-3 риска]. Бюджет: освоено [% от плана], прогноз отклонения [+/-%].

Задача: Подготовить сценарий 15-минутной устной презентации статус-отчёта с акцентом на решения, которые нужны от комитета.

Формат вывода: (1) Тайминг с разбивкой по слайдам (слайд — минуты — ключевой месседж). (2) Полный текст речи PM с переходами. (3) Блок 'Ожидаемые вопросы и ответы' — 5 острых вопросов и заготовленные ответы.

Детали: Используй Pyramid Principle: сначала вывод, затем аргументы. Каждое решение сформулируй как бинарный выбор для комитета. Избегай технического жаргона — аудитория не IT.

Роль: Ты Delivery Director с 12 лет опыта урегулирования кризисных проектов и коммуникации с топ-менеджментом. Экспертиза: модель RACI, техника DESC для сложных разговоров, управление ожиданиями.

Кonтекст: Я PM в [тип организации]. Проект: [название, тип]. Методология: [методология]. Последний статус-отчёт показал: [ключевое отклонение — сроки/бюджет/скоуп]. Блокер: [описание блокера]. Ответственный за разблокировку: [роль/отдел]. Срок до критической точки: [N дней]. Стейкхолдер для эскалации: [должность спонсора].

Задача: Составить эскалационное письмо спонсору, которое корректно поднимает проблему и запрашивает конкретное решение, опираясь на данные из статус-отчёта.

Формат вывода: (1) Тема письма (3 варианта на выбор). (2) Тело письма по структуре DESC: Describe — Express — Specify — Consequences. (3) Вложение-приложение: таблица 'Вариант действия — срок — риск — стоимость'.

Детали: Тон — профессиональный, без обвинений. Максимум 250 слов в теле. Избегай пассивного залога и слов 'возможно', 'наверное'. Каждое утверждение — фактом из отчёта.

Роль: Ты Agile Coach с 7 лет опыта внедрения культуры прозрачной отчётности в распределённых командах. Экспертиза: Scrum Guide 2020, Definition of Done, практики Jira и Azure DevOps.

Контекст: Я PM в [тип компании]. Команда: [размер и состав ролей]. Проект: [тип проекта]. Методология: [Scrum/Kanban]. Проблема: тимлиды и разработчики присылают данные для статус-отчёта нерегулярно, в разных форматах, часто с пропусками по [блокеры/прогресс/риски]. Инструмент трекинга: [Jira/Trello/другое].

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

Формат вывода: (1) Одностраничная памятка 'Что, когда и как присылать PM' с примерами и антипримерами. (2) План воркшопа на 60 минут: агенда, упражнения, итоги. (3) Чек-лист из 6 правил гигиены данных в трекере для поддержания качества отчётов.

Детали: Опирайся на принцип 'один источник правды' — Jira. Избегай бюрократии: максимум 10 минут в неделю на участника. Учитывай разницу между ролями (dev, QA, аналитик).