# Премортем: как найти причины провала проекта до его запуска

> Премортем (pre-mortem) — анализ рисков проекта до запуска: сценарий на 45 минут, роль руководителя, шаблон «причина → сигнал → страховка → владелец».

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/premortem-analiz-proval-do-zapuska/

Премортем (pre-mortem) — это анализ рисков проекта до запуска, в котором команда исходит из того, что проект уже провалился, и объясняет, почему. Вопрос «почему это провалилось?» снимает с людей неловкость: критиковать план больше не нужно, нужно объяснить случившееся. Знаменитые «+30%» из статьи Кляйна — это рост числа названных причин, а не их точности: премортем расширяет список рисков, а отбирать важные всё равно команде.

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

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

Ниже — откуда метод, почему он работает, готовый сценарий фасилитации, шаблон для перевода причин в действия и чек-лист рисков для запуска AI-фич и агентов.

## Что такое премортем и откуда метод

Метод описал психолог Гэри Кляйн в статье «Performing a Project Premortem» в Harvard Business Review, сентябрь 2007 года. Кляйн исследует, как люди принимают решения в реальных условиях: он автор книги «Sources of Power» (MIT Press, 1998).

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

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

В цикле продуктового решения премортем стоит в самом конце, перед запуском. Сначала команда выбирает между объяснениями — например, через [анализ конкурирующих гипотез](/blog/ach-analiz-konkuriruyushchih-gipotez/), — а потом проверяет на прочность выбранный план. Весь цикл из восьми методов собран в обзоре [продуктовых решений при неопределённости](/blog/produktovye-resheniya-pri-neopredelennosti/).

## Почему на «что может пойти не так?» команда молчит

У молчания две причины: социальная и когнитивная. Премортем бьёт по обеим.

### Разрешение говорить плохие новости

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

Премортем снимает этот риск: провал объявлен как факт, и участник больше не «против плана» — он помогает объяснить, что случилось. Неочевидная причина в такой рамке — вклад в общее дело, а не нападка на автора плана.

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

### Проспективная ретроспектива: что на самом деле значат 30%

Когнитивная опора метода — **проспективная ретроспектива** (prospective hindsight): представить будущее событие так, будто оно уже произошло. Кляйн ссылается на исследование Деборы Митчелл, Джея Руссо и Нэнси Пеннингтон 1989 года.

В HBR Кляйн пишет, что приём на 30% повышает способность *правильно* определять причины будущих исходов. Оригинальное исследование 1989 года закрыто платным доступом, поэтому дальше — по его аннотации и учебному разбору.

По аннотации, на объяснения сильнее всего влияла уверенность, что событие случилось: объяснения точно случившихся событий были длиннее и чаще опирались на конкретные эпизоды, а сама временная перспектива (будущее или прошлое) почти ничего не меняла. Учебный разбор на corporate.jcx.au уточняет: измеряли **число** причин (примерно +30%), а их точность не проверяли.

Для премортема это даже лучше: работает именно «провал как факт», а не грамматика вопроса.

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

```text
Обычная критика:  «Что может пойти не так?»   → риск как предположение, его нужно отстаивать
Премортем:        «Почему это провалилось?»   → провал как факт, нужно объяснение
```

Ещё одно подтверждение пользы метода — эксперимент Вейнотт, Кляйна и Уиггинса (2010): 178 студентов критиковали план университета на случай вспышки гриппа H1N1. По словам Кляйна, в группе премортема самоуверенность (overconfidence) в плане снизилась сильнее, чем при простой критике или списке «за и против». Измеряли уверенность, а не успех проектов — это стоит держать в голове.

## Как провести премортем за 45 минут: сценарий фасилитации

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

**До встречи.** Команда уже видела план: Кляйн проводит премортем после того, как план представлен. Ведущий заранее формулирует, что значит «провал» в цифрах: «через полгода фичей пользуются меньше 5% активных клиентов» или «агента отключили после первого квартала».

1. **0:00–0:05 — рамка.** Ведущий называет дату в будущем и объявляет: «Сейчас апрель. Проект провалился. Полностью, без оговорок». Никаких «а вдруг» — провал подаётся как факт.
2. **0:05–0:12 — тихое письмо.** Каждый сам, молча, пишет все причины провала, какие может придумать. Особенно те, о которых обычно не говорят вслух: политика, приоритеты руководства, слабые места соседней команды, собственные сомнения.
3. **0:12–0:27 — круг.** Каждый по очереди называет одну новую причину, её записывают на доску, и круги идут, пока списки не опустеют. Обсуждать и опровергать нельзя, можно только уточнять формулировку.
4. **0:27–0:32 — группировка.** Ведущий склеивает дубли и сводит причины в кластеры: технология, люди, рынок, деньги, процессы, внешние зависимости.
5. **0:32–0:38 — оценка.** Каждую причину оценивают по трём осям, которые Кляйн добавил позже: вероятность, ущерб, лёгкость предотвращения. Быстрее всего — голосование точками. На выходе 5–7 причин в работу.
6. **0:38–0:45 — владельцы.** Для каждой отобранной причины: ранний сигнал, страховка, владелец, срок. Это та самая таблица из следующего раздела.

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

## Роль руководителя на премортеме

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

Что делать руководителю:

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

Если руководитель сам автор плана, фасилитацию лучше отдать нейтральному человеку — например, продакт-менеджеру соседней команды.

## Шаблон: от причин провала к владельцам и страховкам

Список причин без владельцев — это просто тревога, записанная на доску. Каждая отобранная причина превращается в строку таблицы:

| Причина провала | Ранний сигнал | Страховка | Владелец | Срок |
|---|---|---|---|---|
| Что произошло, сформулировано как факт из будущего | Что мы увидим раньше всего, в метрике или событии | Что меняем в плане сейчас или включаем при сигнале | Один человек, не команда | Когда страховка готова |
| <что случилось к <дата>> | <метрика> выше/ниже <порог> <период> | Профилактика: <…>; триггер: <…> | <один человек> | <дата> |

Правила заполнения:

- **Сигнал должен быть наблюдаемым.** «Пользователи недовольны» — не сигнал. «Доля ответов агента, отредактированных оператором, выше 30% две недели подряд» — сигнал. Порог задаёт команда — это её допущение, а не норма.
- **Страховка бывает двух типов.** Профилактика меняет план сейчас (ограничить права агента). Триггер срабатывает по сигналу (откатить на ручной режим). Для дорогих рисков нужны оба.
- **Один владелец на строку.** Он следит за сигналом и инициирует страховку, даже если исполнять её будут другие.
- **Неизвестные причины — в проверку.** Если команда не знает, насколько риск реален, это непроверенное допущение. Его место на [карте допущений](/blog/assumption-mapping-karta-dopushcheniy/), а решение о том, стоит ли платить за проверку, помогает принять [расчёт ценности информации](/blog/value-of-information-hubbard/).

## Пример премортема: запуск AI-агента в B2B SaaS

Пример условный, все числа — для иллюстрации.

Компания делает сервис для бухгалтерий и готовит AI-агента для поддержки. Агент отвечает на тикеты, а в пилоте может сам продлевать подписку и делать возврат до 10 тыс. ₽. Критерий провала, озвученный в начале: «Через три месяца агента отключили, поддержка вернулась к ручному режиму».

После круга и голосования осталось пять причин:

| Причина провала | Ранний сигнал | Страховка | Владелец |
|---|---|---|---|
| Агент сделал серию ошибочных возвратов, финансы потребовали отключить его | Возвраты агентом без запроса клиента в логах; жалобы бухгалтерии | Возвраты только через подтверждение оператора первые 8 недель; дневной лимит на сумму | Руководитель поддержки |
| Стоимость диалога выросла в разы на длинных тикетах, юнит-экономика ушла в минус | Средняя стоимость тикета растёт неделя к неделе; доля диалогов длиннее 20 сообщений | Обрезка и сжатие контекста; передача человеку после N сообщений; бюджетный алерт | Техлид |
| Качество на реальных тикетах оказалось хуже, чем на тестовом наборе | Расхождение оценок качества на проде и на eval-наборе | Пополнять eval-набор свежими тикетами каждую неделю; разметка выборки с прода | ML-инженер |
| Операторы перестали проверять ответы агента, ошибки ушли клиентам | Время проверки ответа падает, доля правок оператором стремится к нулю | Выборочный аудит 5% ответов вторым человеком; намеренно подмешанные ошибочные ответы для проверки внимания | Старший оператор |
| Клиенты из крупных аккаунтов потребовали отключить агента для них | Запросы «соедините с человеком» от ключевых клиентов | Флаг отключения агента на уровне аккаунта; аккаунт-менеджер предупреждает крупных клиентов заранее | Руководитель аккаунтинга |

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

## Чек-лист рисков для запуска AI-фичи и агентов

Ниже — частые категории риска для AI-продуктов, без претензии на статистику. Их стоит проверить на любом премортеме AI-фичи. Если команда не назвала ни одной причины из списка, спросите о ней прямо.

- [ ] **Действия без подтверждения.** Агент может что-то необратимо сделать: отправить письмо, списать деньги, удалить данные, изменить настройки клиента. Где человек подтверждает действие и где стоит лимит?
- [ ] **Рост стоимости вместе с контекстом.** Цена запроса зависит от длины контекста, а он растёт с каждым шагом диалога или агентного цикла. Посчитана ли стоимость на длинных сценариях, а не на средних?
- [ ] **Eval-набор не похож на реальный трафик.** Тестовые примеры собрали до запуска, и в них нет опечаток, смешанных языков, вложений, злых клиентов. Как набор будет обновляться после запуска?
- [ ] **Пользователи перестают проверять результат.** Чем чаще модель права, тем меньше внимания к её ответам — и тем дороже редкая ошибка. Как вы узнаете, что проверка превратилась в формальность?
- [ ] **Нет пути назад.** Процесс перестроили под агента, и без него поддержка уже не справляется. Можно ли откатиться на ручной режим за день?

## Премортем vs постмортем vs реестр рисков

Три инструмента часто путают, хотя отвечают они на разные вопросы и работают в разное время.

| | Премортем | Постмортем | Реестр рисков |
|---|---|---|---|
| Когда | До запуска или перед необратимым решением | После инцидента или завершения проекта | На всём протяжении проекта |
| Вопрос | «Почему это провалилось?» (воображаемый провал) | «Что произошло и почему?» (реальный провал) | «Что может случиться и что мы с этим делаем?» |
| Вход | План проекта | Факты, хронология, данные | Риски из всех источников |
| Выход | Изменения в плане, сигналы, владельцы | Корневые причины, уроки, задачи на исправление | Живой список с оценками и статусами |

Работают они в связке. Премортем — удобный способ наполнить реестр рисков на старте, а постмортем проверяет, угадал ли премортем. Для постмортема хорошо подходит [диаграмма Исикавы](/blog/isikawa-diagram/): она раскладывает реальную проблему на причины по категориям.

## Когда премортем не нужен и где он ломается

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

**Не нужен:**

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

**Где ломается:**

- **Причины без проверки.** Яркий сценарий звучит убедительно, даже если он маловероятен. Оценка вероятности и проверка допущений обязательны.
- **Ритуал без последствий.** Если после сессии план не изменился ни в одной строке, следующий премортем будет пустым.
- **Тот же круг людей.** Команда, которая полгода работает над планом, разделяет одни и те же слепые пятна. О том, как это происходит с данными, — в разборе [confirmation bias](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/). Позовите поддержку, продажи, юриста, человека из соседней команды.

## Как внедрить премортем за неделю: чек-лист руководителя

- [ ] **День 1.** Выберите ближайший проект, где ошибка после запуска будет стоить больше месяца работы команды.
- [ ] **День 1.** Сформулируйте критерий провала в цифрах и дату, к которой он «наступил».
- [ ] **День 2.** Назначьте фасилитатора — не автора плана. Пригласите 5–10 человек, включая хотя бы одного из смежной функции.
- [ ] **День 3.** Проведите сессию по 45-минутному сценарию. Руководитель не защищает план и высказывается последним.
- [ ] **День 4.** Владелец проекта вносит изменения в план и рассылает таблицу «причина → сигнал → страховка → владелец».
- [ ] **День 5.** Сигналы заведены в дашборд или алерты, страховки — в бэклог с датами.
- [ ] **Через месяц.** Проверьте, сработал ли хоть один сигнал и что сделал владелец.

Один вопрос команде, который быстро покажет, нужен ли премортем: «Какую причину провала вы бы назвали, если бы никто не узнал, что это сказали вы?»

## Частые вопросы

### Чем премортем отличается от мозгового штурма рисков?

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

### Сколько людей звать на премортем?

У Кляйна числа нет; на практике (это совет статьи) хватает 5–10 человек, которые знают проект изнутри. Обязательно включите тех, кто будет жить с последствиями: поддержку, эксплуатацию, продажи. Если участников больше дюжины, круг затягивается — по совету статьи, лучше разделить их на две группы и объединить списки.

### Можно ли провести премортем удалённо или асинхронно?

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

### Как часто проводить премортем?

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

### Доказано ли, что премортем работает?

Доказательная база скромная. По учебному разбору исследования 1989 года, подача события как уже случившегося увеличивала число названных причин примерно на 30%, а их точность не проверяли; аннотация самой работы называет главным фактором уверенность в исходе. Эксперимент 2010 года показал, что премортем сильнее снижает самоуверенность в плане, чем простая критика, а влияние на итоговый успех проектов в этих работах не измеряли.

## Источники

- Gary Klein. [«Performing a Project Premortem»](https://hbr.org/2007/09/performing-a-project-premortem). *Harvard Business Review*, сентябрь 2007.
- Deborah J. Mitchell, J. Edward Russo, Nancy Pennington. [«Back to the future: Temporal perspective in the explanation of events»](https://doi.org/10.1002/bdm.3960020103). *Journal of Behavioral Decision Making*, 2(1), 25–38, 1989 — полный текст платный, в статье использована аннотация.
- Gary Klein. [«The Pre-Mortem Method»](https://www.psychologytoday.com/ie/blog/seeing-what-others-dont/202101/the-pre-mortem-method). *Psychology Today*, 14 января 2021 — обновлённая процедура, оценка по вероятности, ущербу и лёгкости предотвращения, эксперимент Veinott, Klein, Wiggins (2010).
- [«The premortem»](https://corporate.jcx.au/premortem) — учебный конспект на corporate.jcx.au: разбор того, что исследование 1989 года измеряло число причин, а не их точность, и обзор последующих экспериментов.