Сообщить об ошибкеКороткий ответ
Нужно разобрать запуск по фактам (что было запланировано, что произошло, на каком этапе и почему возникло отклонение) без поиска виноватого, зафиксировать конкретные изменения процесса или чек-листа, которые предотвратят повторение проблемы, и назначить ответственного за внедрение этих изменений с проверкой на следующем запуске.
Как это работает подробнее
пост-мортем обычно строится по структуре «что планировалось → что произошло → где возникло расхождение → почему → что изменить в процессе»; важно фокусироваться на системных причинах (отсутствие проверки, нехватка времени на тест), а не только на непосредственном исполнителе ошибки.
Что использовать на практике
- На практике. разбор без конкретных action items (кто, что и к какому сроку меняет в процессе) превращается в формальность, которая не предотвращает повторения проблемы — выводы должны быть зафиксированы письменно и проверены на следующем похожем запуске, чтобы подтвердить, что изменение действительно сработало.
- Пример. После неудачного запуска кампании (креатив не прошёл через A/B-тест из-за нехватки времени, в итоге выбран неоптимальный вариант) пост-мортем фиксирует: «Причина — тестовая фаза была пропущена из-за сжатых сроков клиента. Изменение: для кампаний с запуском быстрее 5 дней тестовая фаза сокращается до 2 дней, но не пропускается полностью». Проверка: на следующем быстром запуске тестовая фаза действительно проведена, даже в укороченном виде.
Подводные камни
- Частые ошибки. фокус на поиске виноватого сотрудника вместо анализа процесса, что снижает готовность команды честно разбирать ошибки в будущем; формулировка выводов в общем виде («надо быть внимательнее») без конкретного изменения в чек-листе или процессе.