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