Промпты для премортема: риски до запуска проекта помогают команде увидеть вероятные причины провала заранее, пока решения ещё можно изменить. Премортем — это разбор воображаемого провала будущего проекта. Команда описывает проект, представляет, что он уже не достиг цели, и выписывает причины такого исхода. Нейросеть ускоряет черновой перебор причин, группировку и перевод в меры. Ручной вклад команды остаётся первым шагом.
Что такое премортем и почему он идёт до старта
Премортем строится вокруг предположенного будущего провала. Команда собирается до запуска и задаёт вопрос: что могло бы привести этот проект к неудаче. В корпусе Microsoft prompts-for-edu описан промпт-коуч, который ведёт студента через премортем: сначала просит кратко описать текущий проект, затем предлагает представить причины его провала и способы их предотвратить, отвечая только вопросами. Авторы материала — Ethan R. Mollick и Lilach Mollick. В том же документе названы исследователи Deborah J. Mitchell и Gary Klein, работы которых лежат в основе метода.
Ключевой механизм здесь — prospective hindsight, взгляд назад из воображаемого будущего. В описании промпта-коуча сказано, что премортемы делают безопасным высказывание сомнений на этапе планирования: часть команды не решается говорить о тревогах, часть слишком вложена в проект, чтобы замечать возможные проблемы. Воображаемый провал снимает часть этого давления: обсуждается гипотетический сценарий.
В playbook Atlassian премортем описан как командная встреча с таймингом по шагам. Подготовка занимает 5 минут, вводная — 5 минут, молчаливый брейншторм — 10 минут, группировка похожих идей — 5 минут, голосование по угрозам — 5 минут, голосование по факторам успеха — 5 минут, фиксация действий — 5 минут. Время обсуждения согласуйте по числу отобранных тем. Для удалённых команд предлагается видеоконференция с демонстрацией экрана, для очных — доска или большой лист бумаги, стикеры, маркеры и таймер.
Разница между премортемом и постмортемом лежит во времени. Постмортем разбирает уже случившееся, премортем работает с тем, что ещё не произошло. Отсюда следует практическое требование: все причины на входе помечаются как гипотезы. В учебном примере ниже это правило зашито прямо в первый промпт.
Три промпта: причины, группировка, меры
Три промпта решают три разные задачи и запускаются последовательно. Первый собирает независимые причины, второй группирует их по механизму, третий переводит выбранные причины в меры. Ниже — готовые формулировки для копирования.
Промпт, чтобы получить список возможных причин провала:
Представь, что [проект] не достиг цели. По этим вводным предложи возможные причины; каждую пометь гипотезой. Не выдумывай произошедшие сбои.
Промпт, чтобы сгруппировать причины и увидеть пробелы в данных:
Сгруппируй причины по механизму, покажи недостающие данные. Число повторов не доказывает важность причины.
Промпт, чтобы превратить причины в меры:
Для трёх причин предложи ранний сигнал, превентивное действие, владельца и срок.
Что менять под себя: в первом промпте подставьте описание своего проекта вместо [проект], добавьте известные вводные — сроки, участников, зависимости. Во втором промпте укажите, какие данные у вас уже есть, чтобы модель отметила именно пробелы. В третьем промпте задайте число причин, с которым готовы работать, и формат срока.
Вариации той же задачи, если базовых трёх мало:
- Промпт для асинхронного сбора: попросить модель сформулировать вопросы, на которые каждый участник отвечает письменно до общей встречи.
- Промпт для проверки допущений: попросить выписать утверждения о проекте, которые считаются верными без проверки, и предложить способ проверки каждого.
- Промпт для голосования: попросить свести причины в короткий список для распределения голосов внутри команды.
- Промпт для контр-сценария: попросить описать, что должно совпасть, чтобы проект дошёл до цели, и какие из этих условий под вашим контролем.
В playbook Atlassian для голосования каждому участнику дают три голоса, и он может распределить их свободно: все три на одну карточку, два и один, или по одному на три разные. Для очных команд голоса отмечают точками на стикерах. Этот приём переносится в текстовый формат: список причин из второго промпта уходит команде, каждый расставляет три голоса, три темы с наибольшим числом голосов идут в обсуждение.
Порядок важен. Если запустить третий промпт сразу, модель предложит меры для причин, которые команда ещё не проверяла своими глазами. Первый и второй шаги дают материал, третий работает с отобранным.
Гипотезы риска и произошедшие события
Различие между гипотезой и фактом определяет, что можно записать в реестр. Гипотеза — это предположение о будущем: платформа может не выдержать нагрузку, участник может забыть о встрече. Произошедшее событие — это то, что уже случилось и имеет след: тестовый вход не прошёл, напоминание не доставлено. Смешение этих категорий портит реестр, потому что меры для гипотетической причины и для случившегося сбоя разные.
В промпте-коуче из корпуса Microsoft есть прямое указание: не описывать, как проект провалился, и не предполагать, был ли провал тяжёлым или мягким. Модель задаёт вопросы и ждёт ответа студента. Это защита от подмены гипотезы выдуманным событием: если модель начнёт рассказывать, что именно сломалось, читатель получит ложную уверенность в знании причин.
Практическое правило для команды: каждую строку реестра помечайте меткой. Гипотеза получает статус «предположение», событие — статус «наблюдение» с датой. В учебном примере ниже все причины — гипотезы, потому что проект не запускался.
| Признак | Гипотеза риска | Произошедшее событие |
|---|---|---|
| Время | Относится к будущему | Уже случилось |
| Доказательство | Нужна проверка | Есть след или запись |
| Формулировка | «Может не выдержать» | «Тестовый вход не прошёл» |
| Мера | Превентивная, до запуска | Корректирующая, после сбоя |
| Владелец | Назначается заранее | Назначается по факту |
В playbook Atlassian есть отдельная подсказка: если с потенциальным риском связаны количественные данные, например стоимость или время, эти данные добавляют к описанию риска. Для гипотезы это означает, что оценку стоит явно отделять от результата измерения. В учебном примере вероятности и ущерб не вычисляются по вымышленным данным.
Отдельно стоит развести премортем, проверку допущений и разбор инцидента по пяти «почему». Премортем работает с будущим провалом. Проверка допущений работает с утверждениями, которые приняты без доказательства. Разбор инцидента работает с уже случившимся сбоем. У каждого свой вход и свой реестр, и переносить гипотетические причины в журнал наблюдений нельзя.
Собственная попытка команды до обращения к ИИ
Первый шаг делает команда своими руками. В промпте-коуче из корпуса Microsoft модель ждёт ответа студента на каждый вопрос и не выдаёт готовый разбор. Этот порядок сохраняется и при работе с нейросетью: сначала участники пишут причины сами, потом модель расширяет список.
В playbook Atlassian брейншторм устроен как десять минут молчаливой записи ответов на вопросы. Вопросы для колонок там сформулированы так: что может помешать уложиться в срок, что поможет проекту идти по графику, что нужно проекту и чего у нас нет, что у нас уже есть из необходимого, какие уроки дали прошлые проекты, что вызывает беспокойство, что вызывает воодушевление. Подсказка к playbook предлагает переформулировать вопросы под конкретную роль, например «что не даёт спать [руководителю QA]». Молчаливый формат снижает эффект первого голоса, когда остальные подстраиваются под самое громкое мнение.
Практический порядок для команды:
- Каждый участник пишет причины провала письменно, без обсуждения.
- Списки собираются в один документ.
- Только после этого причины отдаются модели для расширения и группировки.
- Команда сверяет ответ модели со своим списком и отмечает, что она пропустила.
Четвёртый шаг даёт главную пользу: расхождение между списком команды и ответом модели показывает слепые зоны. Если модель назвала причину, которой нет ни у кого, её нужно проверить до включения в выводы.
Учебный пример. Проект: вебинар на 40 регистраций, старт 20 ноября. Вводные: напоминание одно, платформа не протестирована, ответственный за технический сбой не назначен. Все вводные и даты учебные, вебинар не запускался, пример вымышлен и составлен для обучения. Собственный список команды до ИИ: платформа не готова, участник забыл о вебинаре, некому разбирать сбой. Эти три строки команда написала сама, и они задают рамку для ответа модели.
Реестр причин, сигналов, мер и владельцев
Реестр — итоговый документ премортема. Он собирает причину, ранний сигнал, превентивное действие, владельца и срок. В playbook Atlassian подсказка про владельца сформулирована прямо: назначение ответственного и срока повышает шансы, что действие будет выполнено. Финальный шаг playbook требует, чтобы у каждого действия были владелец и дедлайн, а сам документ премортема сохранялся в общем пространстве команды.
Учебный реестр по проекту вебинара:
| Причина (гипотеза) | Ранний сигнал | Превентивное действие | Владелец | Срок |
|---|---|---|---|---|
| Платформа не готова | Нет успешного тестового входа | Провести репетицию | Ира | 18 ноября |
| Участник забыл | Доставка напоминания не проверена | Проверить доставку | Олег | 19 ноября |
| Некому разбирать сбой | Резервный ведущий не назначен | Назначить резерв | Ира | 18 ноября |
Каждая строка читается как проверяемое обязательство: сигнал можно увидеть, действие можно выполнить, владелец назван, срок стоит. Вероятности и ущерб в таблице отсутствуют, потому что вычислять их по вымышленным данным нельзя.
В playbook Atlassian обсуждение устроено так: на первые три темы с наибольшим числом голосов ставят таймер на десять минут и за это время придумывают минимум одно действие по снижению риска, затем переходят к следующей карточке. Подсказка предлагает во время обсуждения спросить, что является противоположностью этого риска, и построить план от воображаемого успеха. После обсуждения действия переносят в проектный трекер, например Jira, а документ премортема периодически пересматривают, чтобы держать риски в поле внимания.
Для распределённых команд playbook предлагает асинхронный вариант: документ рассылают с дедлайном, участники отвечают на вопросы, помечают темы для обсуждения и записываются на конкретные задачи. Для скрам-команд есть сжатая версия во время планирования спринта, чтобы обсудить помехи до принятия обязательств.
Проверка реестра перед закрытием встречи:
- У каждой причины есть метка «гипотеза» или «наблюдение».
- У каждой меры есть владелец и дата.
- Ни одна мера не сформулирована как «быть внимательнее».
- Сигнал можно заметить до наступления срока.
- Документ сохранён там, где команда его найдёт.
Частые вопросы
Что такое премортем проекта простыми словами?
Премортем — это разбор воображаемого провала будущего проекта. Команда представляет, что запуск уже не достиг цели, и выписывает причины такого исхода. Разбор идёт до старта, пока решения можно изменить. В корпусе Microsoft описан промпт-коуч, который ведёт студента через такой разбор вопросами.
Чем премортем отличается от постмортема?
Постмортем разбирает уже случившееся, премортем работает с тем, что ещё не произошло. Отсюда разница в доказательствах: у постмортема есть следы и записи, у премортема — только предположения. В описании промпта-коуча сказано, что премортемы проводят, чтобы защититься от болезненного постмортема.
Сколько промптов нужно для премортема?
Три промпта закрывают основные шаги: сбор независимых причин, группировка по механизму, перевод выбранных причин в меры. Первый промпт требует помечать каждую причину гипотезой. Второй показывает недостающие данные и предупреждает, что число повторов не доказывает важность причины. Третий выдаёт сигнал, действие, владельца и срок.
Нужно ли писать свои причины до запроса к нейросети?
Собственный список команды идёт первым шагом. В промпте-коуче из корпуса Microsoft модель ждёт ответа студента на каждый вопрос и не выдаёт готовый разбор. В playbook Atlassian брейншторм устроен как десять минут молчаливой записи ответов. Расхождение между списком команды и ответом модели показывает слепые зоны.
Что должно быть в реестре рисков после премортема?
Реестр собирает причину, ранний сигнал, превентивное действие, владельца и срок. В playbook Atlassian подсказка требует назначать ответственного и дедлайн для каждого действия. Финальный шаг playbook предписывает сохранить документ в общем пространстве команды и периодически к нему возвращаться. Действия переносят в проектный трекер для отслеживания.