Pre-mortem перед запуском фичи

Проведи pre-mortem для {{launch}} ({{launch_date}}).

Идея метода

Команда мысленно переносится на 3 месяца после запуска. Запуск провалился. Каждый отвечает на вопрос: «Почему он провалился?»

Сильнее обычного risk-assessment: люди легче придумывают конкретные причины провала чем абстрактные риски.

Подготовка

• 60-90 мин в календаре
• 6-10 участников (продукт, инженерия, дизайн, support, аналитика, маркетинг)
• Sticky notes / Miro
• Один фасилитатор (не PM проекта — слишком вовлечён)

Структура

0:00-0:05 — Постановка

Фасилитатор объявляет:

«Сегодня — три месяца после запуска {{launch}}. Запуск провалился. Цели не достигнуты, есть негативные последствия для бизнеса. Через 15 минут каждый записывает причины провала молча, индивидуально. Никаких "если только" — представляйте провал как факт».

0:05-0:20 — Silent generation

Каждый записывает причины (1 причина = 1 стикер). Молча.

Категории-подсказки (но не обязательны):

• Технические (баги, performance, infrastructure)
• Продуктовые (не нужно юзерам, не нашли)
• UX (не поняли как использовать)
• GTM (не узнали о запуске, неправильная аудитория)
• Операционные (support не справился, нет docs)
• Внешние (конкурент, регуляция, погода)
• Командные (выгорели, заболели, ушли)

Цель: 8-15 стикеров на человека.

0:20-0:40 — Sharing и группировка

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

Никаких возражений в этой фазе. Только уточняющие вопросы.

0:40-0:55 — Probability × Impact

Каждый кластер оценивается по 2 шкалам (голосование точками):

• Вероятность: Низкая / Средняя / Высокая
• Импакт если случится: Низкий / Средний / Высокий

Топ-приоритеты: высокая × высокий и высокая × средний.

0:55-1:25 — Митигации

Для топ-7 рисков команда генерирует:

• Превентивные действия: что сделать до запуска чтобы снизить вероятность
• Detection: как поймём что это происходит (метрика, alert)
• Reaction: что делаем когда поймали
• Owner: один человек

Формат записи:

Риск: ...
Вероятность × импакт: ...
Превентивно (до launch_date): ...
Detection: метрика X в Grafana
Реакция: ...
Owner: ...
Deadline превентивных мер: ...

1:25-1:30 — Закрытие

• Кто пишет финальный документ (24ч)
• Кто отслеживает митигации до launch_date
• Когда ретро после запуска: сверим что сбылось

После воркшопа

PM выкладывает документ с:

• Топ-10 рисками
• Митигациями + owner-ами + дедлайнами
• Что НЕ берём в работу и почему (low probability × low impact)
• Какие риски остаются accepted

Кого пригласить обязательно

• Support / CS — знают типы жалоб что приходят
• Аналитик — знает что МОЖНО мерить
• DevOps / SRE — знают где обычно ломается
• Не только senior — junior часто видят свежим взглядом

Анти-паттерны

• ❌ «Какие риски есть?» — слабо. Pre-mortem сильнее: «Почему провалилось».
• ❌ Только техническая команда — пропустишь GTM / support риски
• ❌ Митигации без owner-а — никто не сделает
• ❌ Митигации без deadline — забудутся
• ❌ Не вернуться после запуска — теряется learning
• ❌ Фасилитатор спорит — должен быть нейтрален

Ретро после запуска

Через 30 дней — мини-ретро:

• Какие из предсказанных рисков сбылись?
• Какие НЕ предсказали но случились?
• Какие митигации сработали?
• Что добавить в pre-mortem template на следующий раз?

В конце дай

• План воркшопа по таймингу
• Список топ-10 рисков
• Митигации с owner + deadline
• Detection метрики и alerts
• Дата ретро-сессии