Обычно перед релизом команда задает вопрос: “ну что, все готово?” Проблема в том, что на такой вопрос почти всегда хочется ответить “да”, особенно если дедлайн уже близко.

Pre-mortem работает чуть лучше. Суть простая: мы заранее представляем, что релиз прошел плохо, и разбираем, почему так могло случиться.

😶‍🌫 Формат можно провести за 20–30 минут (мы так иногда делаем, когда на носу огромнейший и сложнейший технический релиз): 1. Представляем, что после релиза что-то пошло не так. 2. Каждый пишет 2–3 причины, почему это могло произойти. 3. Группируем риски: продукт, разработка, тестирование, аналитика, коммуникации. 4. Выбираем, что нужно проверить или доделать до релиза. 5. Фиксируем ответственных и сроки.

😉 Самые полезные вопросы: - какой сценарий мы могли не проверить; - что может быть непонятно пользователю; - где есть зависимость от другой команды; - что будет, если аналитика не сработает; - есть ли план отката; - кто смотрит за релизом после.

Главное не превращать pre-mortem в поиск виноватых. Это просто способ поймать слабые места раньше, чем их поймают пользователи.

Хороший релиз - это не тот, где “мы надеемся, что все ок”. А тот, где команда заранее понимает, что может пойти не так и что с этим делать.