Сделайте сомнения полезными до провала: представьте, что конкретный план уже закончился неудачей, независимо соберите причины и превратите обоснованные опасения в действия.
За одну минуту
Premortem проводится, когда план уже существует, но необратимое исполнение ещё не началось. Фасилитатор задаёт будущий провал как свершившийся факт: «Прошло 90 дней после запуска, и проект серьёзно провалился». Каждый участник молча и самостоятельно записывает причины. Затем команда собирает, уточняет и проверяет механизмы, выбирает значимые риски и назначает mitigations, evidence, owners и triggers.
Воображаемый провал временно легитимирует критику, которую подавляют оптимизм, иерархия и momentum. Метод не предсказывает будущее, не даёт надёжную вероятность и не заменяет specialist risk analysis.
Лучше всего: для конкретного, существенного и ещё изменяемого плана.
Не подходит: если план не объяснён, нет психологической безопасности или обязательна формальная количественная assessment.
Какую проблему решает
Команда привязывается к выбранному плану. Авторитет sponsor, sunk cost и желание казаться конструктивным скрывают слабые сигналы. Обычный вопрос «что может пойти не так?» быстро сходится к знакомым рискам. Prospective hindsight и независимая генерация помогают сохранить разное знание до групповой дискуссии.
Когда использовать метод
- есть working plan запуска, миграции, решения или изменения;
- существенные assumptions остаются неопределёнными;
- разные функции видят разные failure mechanisms;
- hierarchy или momentum подавляют dissent;
- ещё можно менять scope, sequence, control или gate;
- результат получит owners и follow-up.
Когда не использовать
- до объяснения плана и intended outcome;
- после реального incident — нужен анализ первопричин;
- вместо FMEA, safety analysis или обязательного assurance;
- для blame или слухов о конкретных людях;
- если откровенность создаёт риск участникам и нет защиты;
- если команда лишена права что-либо изменить.
Входные данные
- plan, outcome, scope, horizon и success criteria;
- assumptions, dependencies, gates и irreversible commitments;
- evidence и known unknowns;
- участники с delivery, customer и control knowledge;
- безопасный silent/anonymous contribution channel;
- владелец risk actions и review.
Пошаговый процесс
1. Обозначьте границы решения
Покажите, что запланировано, что уже решено, что ещё можно менять и как выглядит success.
2. Сформулируйте конкретное неудачное будущее
Выберите дату review и опишите material failure через outcome, не подсказывая причин.
3. Соберите причины независимо
Дайте несколько минут тишины. Одна note — один механизм. Просите condition → mechanism → consequence, а не симптом или виновного.
4. Проведите round-robin
Собирайте по одной идее от каждого за круг. Не обсуждайте и не ранжируйте, пока отдельное знание не стало видимым.
5. Уточните и сгруппируйте
Объединяйте только настоящие дубли. Сохраните существенно разные механизмы и переформулируйте vague claims.
6. Проверьте evidence
Отметьте observed, inferred или speculative; добавьте supporting/contradictory evidence, uncertainty и быстрый способ проверки.
7. Выберите риски для решения
Учитывайте consequence, plausibility, detectability, time to act и reversibility. Не умножайте неоткалиброванные баллы, создавая false precision.
8. Спроектируйте response
Измените plan, проверьте assumption, сократите exposure, добавьте prevention/recovery, установите trigger или проведите authorised risk acceptance.
9. Назначьте ownership
Запишите action, owner, due date, completion evidence, residual risk и escalation. «Наблюдать» требует signal и threshold.
10. Вернитесь к результату на gate
Пересматривайте register перед irreversible commitment и после изменений. Для важных механизмов переходите к PDPC, FMEA или Bow-Tie.
AI и автоматизация
AI может анонимизировать и кластеризовать независимо созданные notes, сравнивать с утверждёнными lessons learned и искать действия без owners. Он не должен заменять человеческое dissent, придумывать probability по частоте слов, раскрывать авторство, отбрасывать редкий catastrophic risk или принимать residual risk.
Визуальная модель
Практический пример
Производитель запускает AI-assisted supplier portal через шесть недель. Suppliers не тестировали exception orders, identity data приходят из двух систем, fallback есть только на слайде. Один механизм: при outage fallback не обрабатывает peak demand. Action: до 18 сентября провести simulation с Operations и пятью suppliers; evidence — completed orders, queue time и error log; запуск ставится на паузу, если agreed peak не обработан за четыре часа.
Ожидаемый результат
- конкретный failed-future scenario;
- independently generated failure mechanisms;
- evidence, uncertainty и priority criteria;
- plan changes, tests, protections и acceptance decisions;
- owners, due dates и observable triggers;
- hand-off к specialist analysis и review gate.
Ошибки
- Обсуждение начинается до independent generation.
- Провал сформулирован слишком общо.
- Получился список виновных.
- Частота упоминания принята за вероятность.
- Риски не имеют действий и владельцев.
- Premortem заменяет обязательный assurance.
Чек-лист качества
- План, success и changeable decisions понятны.
- Failure future конкретен.
- Причины собраны независимо.
- Разные механизмы сохранены.
- Evidence и uncertainty явны.
- Consequence и time to act учитываются.
- Actions имеют owners, dates и triggers.
- High-stakes items переданы specialist analysis.
Шаблон
| Failure mechanism | Evidence / uncertainty | Consequence | Time to act | Response | Owner / due | Trigger / residual risk |
|---|
Используйте workspace после упражнения Premortem: упражнение собирает independent input, а методический пакет доводит его до управляемого решения.
Проверка понимания
Вопрос: редкий catastrophic failure указан несколькими участниками, но probability неизвестна. Что делать?
Ответ: явно эскалировать uncertainty, определить evidence или specialist analysis и не создавать численную точность из количества notes.
Связанные методы
- PDPC — failure branches и countermeasures.
- FMEA — системный анализ failure modes.
- Bow-Tie — threats, top event, consequences и assurance.
- RCA — уже произошедшее событие.
Источники
- Klein, Gary. “Performing a Project Premortem.” Harvard Business Review, 2007. Статья (откроется в новой вкладке).
- Klein, Gary. “The Premortem Technique.” Ресурс автора (откроется в новой вкладке).
- Agency for Healthcare Research and Quality. Premortem Tool (откроется в новой вкладке).