Перейти к содержимому
Библиотека промптов

Промпты Управление проектами

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

  • 50 промптов Управление проектами
  • Копировать или открыть в чате

Подготовка устава проекта

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

Составь устав проекта [название проекта] для [компания]. Цель проекта: [цель]. Заказчик: [заказчик]. Команда: [состав]. Бюджет: [бюджет]. Целевой срок: [срок]. Причина запуска проекта: [контекст].

Структура: контекст и проблема (3 строки), измеримая цель, границы проекта (что включено), границы проекта (что ЯВНО ИСКЛЮЧЕНО: опиши так же подробно, как и включенное, чтобы избежать раздувания рамок), результаты с критериями приемки, этапы с датами, роли и ответственности (кто принимает решения, кто исполняет, кто консультирует, кто информируется), выявленные риски с мерами по каждому из них ([предполагаемые риски]), гипотезы и зависимости.

Сформулируй каждый раздел так, чтобы возможные разногласия проявились СЕЙЧАС, при чтении, а не в середине проекта. Заверши список 3 вопросами, которые комитет должен решить перед запуском.

Превращение заметок в протокол встречи

Краткий протокол с принятыми решениями и назначенными задачами на основе черновиков.

Преврати мои черновые заметки со встречи в структурированный протокол. Встреча: [тема встречи] от [дата], участники: [участники]. Вот мои заметки: [черновик заметок].

Формат на выходе: принятые решения (четкие формулировки с указанием того, кто принял решение), задачи (таблица: задача, ответственный, срок; если чего-то не хватает в заметках, ставь «УТОЧНИТЬ» вместо выдумок), обсужденные вопросы без решения (макс. 2 строки на каждый), перенесенные вопросы с датой следующего обсуждения.

Правила: максимум одна страница, никакой перефразировки, меняющей смысл сказанного, без дипломатичных формулировок, размывающих суть (запрещено писать «было решено двигаться в этом направлении»). Заверши списком пунктов «УТОЧНИТЬ» для рассылки участникам на валидацию.

Декомпозиция проекта и планирование

Переход от цели к графику: этапы, задачи, зависимости и критический путь.

Разбей следующий проект на этапы и составь график работ. Проект: [описание проекта и финальный результат]. Срок: [дата]. Доступная команда: [люди и загрузка, например, 2 человека на 50% времени]. Известные ограничения: [ограничения: согласование с клиентом, зависимость от поставщика, период отпусков].

Действуй так: раздели на рабочие пакеты, каждый из которых дает проверяемый результат (никаких пакетов «координация»), разбей каждый пакет на задачи от 0,5 до 3 дней, выяви зависимости между задачами и критический путь, заложи явный резерв времени на неопределенные задачи вместо скрытых запасов везде.

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

Еженедельный отчет о статусе (Flash Report)

Отчет на одну страницу, который реально читают руководители: статус, факты, нужные решения.

Подготовь еженедельный отчет по проекту [название проекта] для [получатели, например, управляющий комитет]. Данные за неделю: прогресс [сделано vs запланировано], трудности [возникшие проблемы], динамика рисков [риски], освоение бюджета [факт vs план], ожидаемые решения [блокирующие вопросы и срок ожидания].

Строгий формат на одну страницу: «светофор» проекта (зеленый/желтый/красный) с ОДНОЙ фразой, обосновывающей цвет, 3 главных факта недели, прогресс относительно плана (одной строкой по каждому активному этапу), риски и узкие места (только изменения за неделю), ожидаемые решения с указанием ответственного и влияния задержки, приоритеты на следующую неделю.

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

Проведение ретроспективы по итогам проекта

Полная подготовка полезной ретроспективы: план, вопросы и прикладные выводы.

Подготовь план проведения ретроспективы для проекта [название проекта], который завершился [результат: в срок, с опозданием на X, закрыт]. Участники: [участники и роли]. Длительность: [длительность, например, 1,5 часа]. Ключевые моменты: [что прошло хорошо или плохо, возможные конфликты].

Результат: поминутный план (открытие с правилом «ищем причины, а не виноватых», индивидуальный сбор мнений перед общим обсуждением для избежания эффекта конформизма, обсуждение главных пунктов, решения), точные вопросы для ухода от общих фраз («в какой именно момент мы поняли, что сроки сдвигаются? что помешало сказать об этом?»), и техника обсуждения [чувствительная тема] без перехода на личности.

Формат выводов: каждый урок превращается в правило для следующего проекта («теперь мы...») с ответственным за внедрение. Максимум 5 правил: больше никто не применит.

Технико-экономическое обоснование (Go/No-Go)

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

Ты: опытный руководитель проектов. Помоги мне составить обоснование проекта [название проекта] для [компания]. Проблема или возможность в основе: [контекст]. Ожидаемые выгоды: [выгоды]. Максимальный бюджет: [сумма]. Известные альтернативы: [alternatives, включая «ничего не делать»].

Структурируй досье в 6 частях: проблема и цена бездействия, возможные варианты (включая статус-кво) с плюсами и минусами, грубая оценка затрат и сроков по вариантам (широкий диапазон), ожидаемые выгоды с привязкой к измеримым показателям, основные риски каждого варианта, аргументированная рекомендация.

Ограничения: каждая выгода должна быть привязана к проверяемому KPI, иначе классифицируй её как «неизмеримая ставка». Сформулируй 5 критериев для решения Go/No-Go. Заверши списком недостающей информации, которая ослабляет обоснование, и укажи, кто должен её предоставить.

Краткий паспорт малого проекта

Одна страница для фиксации рамок небольшого проекта без лишней бюрократии.

Напиши паспорт проекта на одну страницу для небольшой задачи, не требующей полного устава. Проект: [описание в 2 предложениях]. Заказчик: [заказчик]. Участники: [люди и доступное время]. Желаемый срок: [дата]. Возможный бюджет: [сумма или нет].

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

Ограничения: никакого проектного жаргона, фразы должны быть понятны непрофильному сотруднику с первого раза. Если данных недостаточно, пиши «УТОЧНИТЬ у [имя]» вместо выдумок. Заверши 2 вопросами к заказчику перед стартом.

Подготовка интервью для сбора требований

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

Я начинаю проект [название проекта] для [компания] и мне нужно собрать требования. Кого опрашиваем: [список ролей, например: руководство, конечные пользователи, поддержка, ИТ]. Что проект должен выдать: [предполагаемый результат]. Время на одно интервью: [длительность].

Подготовь для каждой роли адаптированный гайд: 8–10 открытых вопросов от общих к частным, разделяя вопросы о текущей работе (боли, обходные пути, объемы) и о будущих потребностях. Добавь для каждой роли 2 вопроса с подвохом для выявления скрытых нужд, например: «что вы делаете, когда текущий инструмент не справляется?».

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

Написание User Stories и критериев приемки

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

Преврати эти сырые требования в User Stories для команды разработки. Проект: [название и краткое описание]. Пользователи: [профили пользователей]. Заявленные потребности: [список нужд].

Для каждой потребности создай: User Story в формате «Как [роль], я хочу [действие], чтобы [выгода]», 3–5 критериев приемки в бинарном формате (проверяется «да/нет», без слов «быстро» или «удобно» без пороговых значений) и вопросы к заказчику, если потребность слишком размыта.

Ограничения: история должна быть выполнима за несколько дней, иначе предложи её декомпозицию. Выяви «лже-потребности» (решения, замаскированные под нужды) и переформулируй их. Представь результат в таблице: история, критерии приемки, оценка размера (S/M/L), открытые вопросы. Заверши списком зависимостей между историями.

Приоритизация перегруженного бэклога

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

Помоги приоритизировать бэклог проекта [название проекта]. Элементы в очереди: [список запросов с кратким описанием]. Ресурс команды: [мощность, например, 15 человеко-дней в месяц]. Главная цель квартала: [цель]. Заказчики, которые давят сильнее всех: [политический контекст].

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

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

Создание квартальной дорожной карты

Дорожная карта, ориентированная на результат, с обоснованием каждого выбора.

Составь дорожную карту на следующие 2 квартала для [продукт или проект] компании [компания]. Цели на год: [цели]. Кандидаты на разработку: [список идей]. Мощность команды: [размер и доступность]. Обязательства: [несогласуемые сроки перед клиентами или внутренние дедлайны].

Организуй карту по кварталам, формулируя каждую строку как ожидаемый результат, а не функцию («сократить время обработки заявок» вместо «разработать модуль X»). Для каждого квартала: 2–3 ключевых направления, целевой результат, KPI успеха, зависимости.

Ограничения: оставь 20% мощности на непредвиденные задачи и укажи это явно. Перечисли, что намеренно не вошло в план и почему, чтобы пресечь вопросы «а почему не X?». Подготовь две версии: детальную для команды и краткую (5 строк) для руководства. Выдели задачи с размытой ценностью, которые пока нельзя ставить в план.

Реалистичная оценка трудозатрат

Оценка в диапазонах с явными гипотезами и коррекцией «ошибки планирования».

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

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

Ограничения: если есть история похожих проектов, сравни оценку с фактом и объясни разницу. Систематически добавляй «забытые» затраты: исправление багов после приемки, координация, обучение, плановые отсутствия. Представь итог в 3 сценариях с процентом разброса. Если разброс более чем двукратный, укажи, какие данные нужны для снижения неопределенности до фиксации цифр.

Бюджет проекта и ежемесячный контроль

Полный бюджет по статьям with система отслеживания факта и оповещениями.

Составь полный бюджет проекта [название проекта] для [компания]. Внутренние затраты: [человеко-дни по ролям и ставка, если известна]. Внешние закупки и услуги: [список]. Длительность: [срок]. Утвержденный лимит: [сумма].

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

Затем создай систему ежемесячного контроля: таблица «факт vs план» по статьям, переоценка остатка работ (ETC: Estimate to Complete), прогноз на конец проекта (EAC) и 2 порога алертов для информирования спонсора. Заверши списком 3 самых частых причин выхода за бюджет в таких проектах и способами их раннего выявления.

Реестр рисков проекта

Приоритизированный реестр рисков с мерами реагирования и ответственными.

Составь реестр рисков проекта [название проекта]. Контекст: [описание, сроки, ставки]. Предполагаемые риски: [уже известные риски]. Внешние зависимости: [поставщики, другие команды, согласования].

Дополни список типичными рисками для таких проектов, разделив их на 4 группы: человеческие (увольнения, перегрузка, нехватка компетенций), технические, организационные (задержки решений, раздувание рамок), внешние. Для каждого риска: конкретное описание последствий, вероятность (низкая/средняя/высокая), влияние (низкое/среднее/высокое), итоговая критичность, ранний индикатор, мера предупреждения, план Б на случай реализации, ответственный.

Ограничения: формулируй риск как событие («подрядчик задержит поставку на месяц»), а не как общую тему («сроки»). Отсортируй по критичности и оставь топ-10 рисков. Укажи регламент пересмотра: частота и контрольные вопросы.

Карта стейкхолдеров проекта

Матрица влияния и поддержки с планом взаимодействия для каждого участника.

Проведи анализ стейкхолдеров проекта [название проекта] в [компания]. Участники: [список лиц или отделов]. Что изменится для каждого: [влияние]. Уровень поддержки/сопротивления: [контекст].

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

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

План коммуникаций проекта

Кого, о чем, как часто и через какой канал информировать, не перегружая лишним.

Разработай план коммуникаций проекта [название проекта]. Целевые аудитории: [спонсор, команда, пользователи, смежные отделы]. Длительность: [срок]. Ключевые моменты: [вехи, запуск, анонсы]. Каналы: [совещания, почта, интранет, мессенджеры].

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

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

Матрица ответственности RACI

Четкое распределение ролей без дублирования и «белых пятен» в ответственности.

Составь матрицу RACI для проекта [название проекта]. Основные активности: [список задач или результатов]. Участники: [люди или функции]. Известные зоны неопределенности: [контекст, например, двое спорят, кто принимает решение].

Для каждой активности назначь роли: R (Исполнитель), A (Ответственный: только один на строку), C (Консультант: до начала), I (Информируемый: после завершения). Объясни неочевидные назначения одной строкой.

Проверка качества: не допускай двух «A» на одной строке, исключи строки без «R», выяви перегруженных «C» (узкие места) и участников без ролей (кандидаты на исключение). Представь матрицу в таблице, выдели 3 потенциально конфликтные зоны и дай рекомендации по их защите. Сформулируй вопросы для обсуждения матрицы с командой.

Подготовка к кик-офф встрече

План стартовой встречи, которая синхронизирует команду и вовлекает участников.

Подготовь план кик-офф встречи проекта [название проекта]. Участники: [участники и роли]. Длительность: [например, 1 час]. Статус подготовки: [устав утвержден или в работе]. Острые углы: [скептицизм, негативный опыт прошлых проектов].

Результат: поминутный план (зачем проект нужен сейчас, конкретный финал, что вне рамок, кто за что отвечает, вехи, правила работы, вопросы), 3 главных мысли, которые каждый должен вынести со встречи, и способ обсудить [острый угол] без ущерба для настроя.

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

Повестка и ведение управляющего комитета

Встреча, сфокусированная на решениях, а не на пересказе статуса работ.

Подготовь следующий управляющий комитет (SteerCo) проекта [название проекта]. Участники: [члены комитета]. Длительность: [срок]. Статус: [прогресс, проблемы, бюджет]. Нужные решения: [ожидаемые решения с вариантами]. Темы, которые могут увести дискуссию в сторону: [чувствительные темы].

Составь повестку, исходя из решений, а не отчета: каждое решение: это пункт с отведенным временем, подготовленными вариантами (2–3 варианта с плюсами, минусами и рекомендацией) и последствиями переноса решения. Статус проекта: максимум 10 минут на основе заранее разосланного документа.

Подготовь: тайминг повестки, точные формулировки запросов на решение, технику вежливого пресечения дискуссий по [чувствительная тема] и шаблон протокола решений для рассылки в течение 24 часов. Список материалов для рассылки за 48 часов до встречи.

Структура презентации для управляющего комитета

Шаблон презентации для руководства: максимум 10 слайдов о главном.

Разработай структуру презентации для управляющего комитета проекта [название проекта]. Данные за месяц: прогресс [факт vs план], бюджет [факт vs план], риски [динамика], нужные решения [список], ключевые события [факты].

Создай структуру слайд за слайдом (макс. 10): резюме (статус-светофор, главное сообщение, нужные решения), прогресс по этапам с отклонениями, траектория бюджета, изменение оценки рисков, фокус на главной проблеме месяца с вариантами решения, слайды по конкретным решениям, следующие шаги.

Для каждого слайда: заголовок как сообщение («Этап 2 догоняет график», а не «Статус этапа 2»), контент (макс. 5 пунктов) и тезисы для устного выступления. Ограничения: никаких слайдов с контекстом, который все знают; цифры округлены и даны в сравнении (с планом, с прошлым месяцем). Проверка: если прочитают только 1-й слайд, поймут ли суть?

Процесс управления изменениями (Change Management)

Простая схема обработки запросов на изменение рамок проекта без потери контроля.

Настрой процесс управления изменениями для проекта [название проекта]. Контекст: [источник запросов, например, клиент постоянно добавляет «хотелки», руководство меняет приоритеты]. Существующие органы: [совещания, комитеты]. Доступный резерв: [остаток времени и бюджета].

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

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

Переговоры о нереальном дедлайне

Аргументация на основе цифр и варианты действий, когда навязанный срок невыполним.

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

Подготовь: фактологическое доказательство разрыва (трудозатраты vs мощность в простых цифрах), затем 3 честных варианта: успеть к дате за счет сокращения рамок (укажи, что именно выкидываем), сохранить рамки, сдвинув дату, или добавить ресурсы (с указанием стоимости и риска: новые люди не дают результат мгновенно).

Ограничения: никогда не говори «это невозможно» без альтернативы. Не соглашайся на компромисс без пересчета цифр прямо на встрече. Подготовь ответы на 3 типичных возражения: «разберитесь сами» и «там посмотрим». Формат: страница аргументов + таблица сравнения 3 вариантов.

План сокращения отставания проекта

Диагностика задержки и реалистичный план наверстывания без «магического» сжатия графика.

Составь план сокращения отставания для проекта [название проекта], задержка [срок] при дедлайне [дата]. Выявленные причины: [причины]. Остаток работ: [этапы с оценками]. Команда: [состав]. Рычаги: [возможный допбюджет, гибкость рамок].

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

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

Эскалация проблемы без вреда для отношений

Фактологическое сообщение об эскалации с вариантами решения и ценой бездействия.

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

Напиши сообщение: описание блока в 3 строках (факты и даты), конкретные последствия бездействия в цифрах (потерянные дни, деньги, угроза вехам), 2–3 варианта решения с моей рекомендацией, нужное решение и срок.

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

Контроль исполнения задач между встречами

Система мониторинга и напоминаний, которая двигает дела вперед без микроменеджмента.

Организуй систему контроля задач проекта [название проекта] между встречами. Текущая ситуация: [проблема, например: задачи делаются наполовину, напоминания воспринимаются как слежка]. Ритм встреч: [частота]. Инструменты: [таблицы, таск-трекеры, мессенджеры].

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

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

Проектирование дашборда проекта

Индикаторы прогресса, показывающие реальную траекторию, а не иллюзию контроля.

Спроектируй дашборд проекта [название проекта]. Тип проекта: [суть и результат]. Длительность: [срок]. Критические зоны: [например: сжатые сроки, бюджет, качество]. Доступные данные: [трекеры, таймшиты, бюджет].

Выбери макс. 6–8 показателей в 3 блоках: прогресс (факт vs план по завершенным результатам, а не % выполнения задач), здоровье (просроченные задачи, висящие решения, рост рисков), ресурсы (факт vs бюджет, загрузка команды).

Для каждого показателя: определение, источник, частота обновления, порог алерта. Ограничения: исключи субъективные метрики («готовность 80%») в пользу бинарных «сделано/не сделано». Опиши регламент еженедельного просмотра за 15 минут: порядок чтения, вопросы и когда пора бить тревогу выше уровня команды.

Ежемесячный отчет для руководства

Месячное резюме на одну страницу: траектория, арбитраж и алерты.

Напиши ежемесячный отчет по проекту [название проекта] для [получатели, например, совет директоров]. Данные: достижения [что сдано], отклонения [задержки], бюджет [факт vs план], риски [изменения], принятые решения [список], алерты [проблемы].

Формат: одна страница: общая траектория в 2 предложениях (уложимся ли в срок и бюджет, и что изменилось за месяц), достижения месяца (3 пункта с привязкой к вехам), отклонения с причинами и мерами (никаких «голых» проблем без плана решения), бюджет одной строкой с прогнозом, алерты для руководства с четким запросом.

Ограничения: руководство читает десятки таких отчетов, никакой саморекламы и «воды». Плохие новости и отклонения: в начало, а не в конец страницы. Каждый алерт должен содержать запрос на действие (арбитраж, ресурс, решение).

Арбитраж ресурсов между проектами

Метод приоритизации портфеля проектов с наглядными последствиями каждого выбора.

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

Сначала создай честную картину: кто над чем работает в реальных %, и где перегрузка выше 100%. Затем предложи сетку арбитража по критериям: важность для бизнеса, цена задержки, «окно возможностей» (риск безвозвратной потери выгоды), внешние обязательства.

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

Планирование спринта

Спринт-планирование с четкой целью, реалистичной емкостью и обязательствами команды.

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

Структура сессии: расчет реальной емкости (доступное время минус рутина и риски), формулировка цели спринта одной фразой (бизнес-результат, а не список тикетов), выбор задач в рамках емкости (начиная с хвостов прошлого спринта), проверка понимания каждой задачи всей командой.

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

Результативная ретроспектива спринта

Формат короткой регулярной ретроспективы с ротацией методик для вовлечения команды.

Подготовь план ретроспективы спринта команды [команда]. Длительность: [например, 45 мин]. Атмосфера: [контекст: скука, конфликты, новая команда]. Темы: [события спринта]. Итоги прошлых ретроспектив: [статус прошлых решений].

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

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

Регламент полезного Daily Standup

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

Разработай регламент ежедневных встреч для команды [команда]. Текущие проблемы: [например: длится 30 минут, превращается в отчет перед начальником, люди скучают]. Размер команды: [число]. Формат: [офис, удаленка, гибрид].

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

Дай: правила модерации (команда говорит друг с другом, ротация ведущего), фразы для пресечения оффтопа, адаптацию под [формат работы] и 3 признака того, что дейли стал бесполезным, с методами лечения. Заверши сообщением для команды о новом формате, объясняющим «зачем», не обесценивая прошлый опыт.

Создание Definition of Done (Критерии готовности)

Общее понимание «сделанного», исключающее результаты, готовые на 90%.

Помоги команде [команда] определить Definition of Done (DoD) для проекта [название проекта]. Тип результатов: [ИТ-функции, документы, обучение]. Проблемы: [симптомы: задачи возвращаются, разное качество, дыры при приемке].

Сформируй DoD на 3 уровнях: что делает задачу «готовой» (проверка коллегой, тесты, документация, чья приемка), что явно исключено для реалистичности, и допустимые исключения с правилом их фиксации.

Ограничения: макс. 8 критериев, все проверяются «да/нет», только то, что команда может выполнить сама (иначе DoD проигнорируют при первом аврале). Результат: методика внедрения через воркшоп, правило применения к текущим задачам и регламент пересмотра через несколько недель.

Организация пользовательского тестирования (UAT)

План тестирования с приоритетами, правилами классификации багов и протоколом приемки.

Организуй приемочное тестирование (UAT) проекта [название проекта]. Объект: [описание]. Тестировщики: [роли и доступность]. Сроки: [длительность]. Существующие критерии приемки: [список или нет].

Подготовь: план тестирования по реальным сценариям (не по кнопкам, а по бизнес-процессам), описание сценариев (входные данные, действие, результат); приоритизацию (критично для запуска, важно, косметика); правила классификации багов с примерами; процесс исправления и перепроверки.

Шаблон протокола приемки: что проверено, баги по уровням, решение (принято, принято с замечаниями и датами их устранения, не принято) и подписи. Ограничения: тест без реалистичных данных ничего не доказывает: опиши подготовку данных. Замечания должны иметь ответственного, иначе они останутся навсегда.

План запуска и чеклист перехода

Почасовой план запуска с критериями Go/No-Go и стратегией отката.

Подготовь план запуска [результат] для проекта [название проекта]. Целевая дата: [дата]. Пользователи: [кто и сколько]. Окно работ: [время: ночь, выходные]. Участники: [люди и роли]. Возможность отката: [да/нет/частично].

Подготовь: чеклист «до запуска» (техготовность, согласования, анонсы, бэкапы, доступность людей), почасовой план перехода с ответственными и критериями успеха каждого шага, точки принятия решения Go/No-Go (кто и на основании чего), план отката (триггеры и детальные действия) и мониторинг в первые часы/дни.

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

Непрерывность бизнеса при миграции

Организация переходного периода при сосуществовании старой и новой систем.

Организуй непрерывность процессов при миграции с [старая система] на [новая система] в [компания]. Срок перехода: [длительность]. Критичные процессы: [что нельзя останавливать]. Команды: [участники]. Рискованные периоды: [календарь: например, закрытие месяца, сезонный пик].

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

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

Закрытие проекта и извлечение уроков

Чеклист административного, финансового и документального закрытия проекта.

Подготовь закрытие проекта [название проекта], результат которого принят [дата]. Элементы: [подрядчики, бюджет, документация, команда]. Остаточные замечания: [список, если есть].

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

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

Передача проекта новому руководителю

Досье передачи и план вхождения в курс дела без потери темпа и контекста.

Организуй передачу проекта [название проекта] от [уходящий РП] к [новый РП]. Причина ухода: [контекст и срок]. Статус: [прогресс, горячие точки, вехи]. Время на передачу: [срок совместной работы].

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

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

Онбординг нового участника команды

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

Подготовь план интеграции [новичок, роль] в команду проекта [название проекта] с [дата]. Статус проекта: [контекст]. Ожидаемая роль: [задачи]. Доступное время команды на помощь: [ограничение].

Составь план на первые 2 недели: набор материалов для чтения в 1-й день (устав, отчет, риски, глоссарий), 4 встречи с ключевыми людьми и их цели, первая полезная и четко очерченная задача в 1-ю неделю (выбери исходя из [роль]), закрепленный ментор с 10:минутными дейли-синкам.

Ограничения: запрети 15 пассивных встреч «для ознакомления»: новичок учится через дело. Расскажи то, о чем обычно молчат: негласные правила, острые темы, реальные пути принятия решений. График на 2 недели, список чтения и вопросы для проверки интеграции через 15 дней.

Разрешение конфликта в команде

Трехэтапный процесс медиации для устранения напряженности, мешающей проекту.

Помоги разрешить конфликт в моей команде. Контекст: [факты о споре двух людей без оценок] в проекте [название проекта]. Влияние: [скрытие информации, напряженные встречи, задержки]. Моя роль: [РП без админ. ресурса / с админ. ресурсом]. История: [длительность, прошлые попытки].

Предложи схему из 3 шагов: личные встречи (вопросы для понимания версий без принятия сторон, ловушка «судейства»), общая встреча (правила на старте, возврат к фактам при переходе на личности, фиксация 2:3 правил работы), контроль (как проверить соблюдение без явной слежки).

Ограничения: оставайся в роли РП: вопросы HR или дисциплины выноси отдельно. Никто не должен выйти из процесса с ярлыком «виноватого» перед командой. Укажи сигналы, когда пора эскалировать конфликт выше.

Работа с проблемным подрядчиком

Поэтапное исправление ситуации: от фактологического предупреждения до подготовки к замене.

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

Построй градацию: сначала встреча по претензиям (реестр отклонений от договора с датами и источниками; требование плана исправления, а не извинений), затем плотный контроль (короткие вехи, четкие критерии выхода из кризиса, письменные протоколы), и параллельная подготовка альтернативы (если зависимость высокая).

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

Подготовка ТЗ для тендера

Техническое задание, описывающее потребности и ограничения, не диктуя конкретное решение.

Напиши ТЗ для выбора подрядчика на [объект, например: разработка сайта, внедрение CRM] для [компания]. Потребность: [описание проблемы]. Контекст: [ИТ-ландшафт, ограничения]. Бюджет: [диапазон или не указан]. Сроки: [дедлайны].

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

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

Объективное сравнение предложений подрядчиков

Взвешенная матрица анализа предложений для выбора лучшего варианта без эмоций.

Создай матрицу сравнения предложений по [объект тендера]. Предложения: [число и краткая суть: цена, срок, подход]. Наши приоритеты: [например: сроки, поддержка, полная стоимость, надежность]. Сигналы: [впечатления, например: демпинг, шаблонный ответ].

Построй сетку: критерии по группам (понимание задачи, методология, команда, TCO: полная стоимость владения с учетом скрытых расходов, релевантные кейсы, юридические условия), веса критериев, шкала оценок с описанием уровней для снижения субъективности.

Примени сетку к описанным офферам и выдели: необъяснимые разрывы в цене (демпинг часто скрывает урезанные рамки), риск замены команды после тендера, скрытые платежи. Результат: сравнительная таблица, вопросы для уточнения по каждому игроку и аргументированная рекомендация в 5 строках.

План управления изменениями (Change Management)

Сопровождение пользователей по группам: от внутренних амбассадоров до поддержки после запуска.

Разработай план управления изменениями для [проект, например: новый процесс, внедрение ERP] в [компания]. Аудитории: [группы, численность, что меняется]. Опасения: [сопротивление]. График: [даты]. Ресурсы: [время, бюджет, активисты].

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

Этапы: ДО (анонс, сеть амбассадоров: уважаемых коллег, а не просто свободных людей, обучение), ВО ВРЕМЯ (усиленная поддержка, сбор болей, быстрая реакция на баги), ПОСЛЕ (замер реального использования, а не посещаемости курсов, работа с очагами сопротивления).

Ограничения: никакого плана «просто больше писать в почту» без конкретики. У каждого действия есть автор и дата. План в таблице по группам и общий график.

План обучения конечных пользователей

Система обучения по ролям, основанная на реальных кейсах и оценке навыков.

Создай план обучения пользователей для внедрения [инструмент или процесс] в [компания]. Пользователи: [роли, число, уровень ИТ-грамотности, география]. Что должны уметь: [задачи]. Ограничения: [доступность людей, бюджет, дата запуска].

Предложи формат по ролям, а не общий курс: для каждой роли 5–10 ключевых действий из их практики (не обзор всех кнопок), формат (группа, туториал, наставничество на месте), длительность и памятка (одностраничные чек-листы вместо толстых мануалов).

Планируй обучение максимально близко к запуску: через 6 недель всё забудется. Предусмотри план для отсутствующих и систему «суперпользователей» на местах.

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

Коммуникация при кризисе в проекте

Сообщения для всех сторон: от первого сигнала о сбое до отчета об исправлении.

В проекте [название проекта] произошел инцидент: [суть: сбой запуска, потеря данных, остановка сервиса, критическое отклонение]. Последствия: [кто пострадал]. Статус: [что известно, что нет]. Аудитории: [руководство, команда, клиенты, партнеры].

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

Адаптируй под аудитории: руководству нужны последствия и решения, пользователям: как работать сейчас, клиентам: безопасность их данных. Ограничения: никаких спекуляций о причинах до их выяснения, не ищи виноватых публично, не давай невыполнимых обещаний по срокам. Результат: готовые шаблоны и правила «кто кому говорит».

Написание OKR команды

Квартальные цели и измеримые ключевые результаты, согласованные с целями бизнеса.

Помоги команде [команда] компании [компания] составить OKR на [квартал]. Приоритеты компании: [приоритеты]. Текучка/рутина команды: [деятельность]. Идеи/проекты: [обсуждаемое]. Численность: [люди].

Создай макс. 2–3 цели (Objectives): каждая как вдохновляющее, но конкретное изменение состояния (не список задач), привязанное к целями бизнеса. Для каждой цели 2–4 ключевых результата (Key Results): измеримые (от X до Y), измеряющие итог, а не процесс («сократить время X» вместо «внедрить инструмент Y»).

Ограничения: рутинная работа не становится OKR, она управляется отдельно; если KR нельзя измерить сегодня: переформулируй или удали. Укажи цели вне зоны контроля команды. Результат: предложенные OKR, вопросы для воркшопа и регламент контроля (частота, формат 15 минут, действия при отставании).

Квартальный обзор OKR

Подведение итогов: честная оценка, извлеченные уроки и планирование следующего цикла.

Подготовь квартальный обзор OKR команды [команда]. OKR прошлого квартала: [цели, результаты и % достижения]. События: [внеплановые задачи, смена приоритетов, увольнения]. Участники: [кто будет]. Длительность: [срок].

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

Ограничения: обзор: это не оправдание. Никаких слайдов «о контексте», сразу к цифрам. Цель, достигнутая на 100% в первый месяц, говорит о слабой амбиции так же, как 20%: о плохом исполнении. Результат: план встречи, шкала оценки, вопросы для анализа и шаблон итогового сообщения для рассылки.

Проведение Post-Mortem инцидента

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

Подготовь разбор (Post-Mortem) инцидента [описание] от [дата] в проекте [название проекта]. Хронология: [события по часам]. Участники: [люди]. Климат: [контекст: поиск виноватых, напряжение].

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

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

Превращение опыта в стандарты команды

Переход от накопленных уроков к реально применяемым правилам работы.

Помоги превратить накопленный опыт [команда или компания] в стандарты работы. Материалы: [протоколы ретроспектив, итоги проектов, разборы инцидентов, жалобы]. Проблема: [ошибки повторяются, отчеты пишутся «в стол»].

Действуй так: сгруппируй уроки по темам и найди повторяющиеся (это приоритеты для стандартов), преврати каждый урок в правило одной фразой с триггером («при старте проекта мы всегда делаем X»), определи место хранения правил (внутри шаблонов документов и чеклистов, а не в отдельном файле «Мудрость», который никто не открывает).

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

Подготовка к аудиту проекта

Подготовка к проверке: досье, признание слабых мест и сценарии интервью.

Подготовь проект [название проекта] к аудиту/проверке качества от [аудитор: внутренний аудит, клиент, регулятор] на [дата]. Рамки проверки: [что смотрят]. Реальный статус: [сильные и слабые стороны, актуальность документов]. Ставки: [продолжение финансирования, доверие, сертификация].

Организуй подготовку: список документов (устав, решения, риски, протоколы, бюджет) с пометкой, что нужно срочно обновить; вероятные вопросы аудитора; честная позиция по слабым местам: признать, показать, что они под контролем, предъявить план действий с датами.

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

Проверьте промпты Управление проектами на ваших задачах

Скопируйте промпт в GPTPro и сравните ответы Claude, GPT, Gemini и Mistral для вашего бизнеса.

Дополнительные материалы

ИИ-агентПродуктAI-агент для разработки PRD, создания User Stories и ускорения Discovery. Решение для CPO и продукт-менеджеров в российском бизнесе.Смотреть
Специализированный агентУправление проектамиПротоколы совещаний, план проекта, реестр рисков, отчётность в разных форматах: что ИИ-агент снимает с плеч руководителя проекта.Смотреть
ПромптSEO чек-лист перед релизомПроверка сайта до и после деплоя, чтобы не потерять позиции.Смотреть
Агент по моделямChatGPTКак создать ИИ-агента в ChatGPT без кода: режим агента, кастомный GPT, реальные ограничения, метод в 3 шага. Сравните GPT с Claude и Gemini в GPTPro.Смотреть
СтатьяИИ-агент: понятное определение и примерыТермином «ИИ-агент» называют что угодно. Честное определение, реальное отличие от чат-бота, конкретные примеры и регуляторный контекст: что эти инструменты умеют, а что нет, в 2026 году.Смотреть
Категория промптовАнализ данныхЗаставьте цифры говорить: исследование, дашборды, осторожная интерпретация и отчетность.Смотреть