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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не нужен:

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

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

Причины без проверки. Яркий сценарий звучит убедительно, даже если он маловероятен. Оценка вероятности и проверка допущений обязательны.
Ритуал без последствий. Если после сессии план не изменился ни в одной строке, следующий премортем будет пустым.
Тот же круг людей. Команда, которая полгода работает над планом, разделяет одни и те же слепые пятна. О том, как это происходит с данными, — в разборе confirmation bias. Позовите поддержку, продажи, юриста, человека из соседней команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

Gary Klein. «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». Journal of Behavioral Decision Making, 2(1), 25–38, 1989 — полный текст платный, в статье использована аннотация.
Gary Klein. «The Pre-Mortem Method». Psychology Today, 14 января 2021 — обновлённая процедура, оценка по вероятности, ущербу и лёгкости предотвращения, эксперимент Veinott, Klein, Wiggins (2010).
«The premortem» — учебный конспект на corporate.jcx.au: разбор того, что исследование 1989 года измеряло число причин, а не их точность, и обзор последующих экспериментов.