Факапы в бизнесе: почему «надо делать систему» не работает

Как разбирать факап по шагам

Сбой на проекте — сорванный срок, упавший сайт, ошибка в отгрузке — вызывает желание сразу найти виноватого или пообещать «систему». Оба пути ничего не меняют. Работает спокойный разбор в три шага.

Разбор лучше назначить в течение одного-двух дней, пока детали свежие. Позже люди начинают защищаться и переписывать историю.

Хронология и факты

Сначала восстанавливаю, что произошло и когда: кто что сделал, какие сообщения отправлял, в какой момент заметили проблему. Без оценок. Хронология часто сама показывает слабое место, например что ошибку видели за два дня до сбоя, но никто не отвечал за реакцию.

Причина: метод «пяти почему»

Метод придумал Сакити Тоёда, основатель Toyota Industries, и он стал частью производственной системы Toyota. На каждый ответ задаётся вопрос «почему?», пока не дойдёшь до причины, которую можно исправить. «Клиент получил не тот товар» — почему? Менеджер выбрал не ту позицию — почему? В карточке два похожих артикула — почему? И так далее. Обычно хватает четырёх-пяти итераций.

Одно конкретное изменение

Итог разбора — не «улучшить коммуникацию», а одно действие с ответственным и сроком. Поправить инструкцию. Добавить пункт в чек-лист. Настроить уведомление. Ровно то, что в посте говорят люди, которые действительно исправят ситуацию.

Шаблон записи разбора

Разбор стоит сохранять письменно в одном месте, например в базе знаний или карточке проекта. Мне хватает пяти полей:

• что произошло и как это заметили;
• хронология с датами и временем;
• причина, найденная через «пять почему»;
• одно изменение, ответственный и срок;
• дата, когда проверим, что изменение сработало.

Разбор без поиска виноватых

В ИТ этот подход называют blameless postmortem. Его подробно описали инженеры Google в книге «Site Reliability Engineering». Смысл простой: разбор ищет причины в процессах, а не в людях.

Если за ошибку наказывают, люди начинают её скрывать. Следующий сбой становится больше и обнаруживается позже. Когда разбор безопасен, сотрудник сам приходит и говорит: «вижу, что сбой дала вот эта инструкция». Ответственность при этом никуда не девается: она смещается с вины на исправление.

Ответственность сотрудников звучит в формулировках

По речи легко отличить тех, кто будет делать, от тех, кто снимает с себя задачу. Я слушаю глаголы и подлежащее.

Как растить ответственность сотрудников

• Спрашивать «что ты предлагаешь?», а не давать готовое решение.
• Закреплять за каждым действием одного человека: если ответственных двое, их нет ни одного.
• Отмечать тех, кто сам пришёл с ошибкой и планом, а не тех, кто её лучше спрятал.
• Возвращаться к договорённостям из разбора через неделю-две.

Ошибки после сбоя, которые повторяют факап

• Разбирать на эмоциях в тот же час. Люди защищаются, факты теряются.
• Ограничиться извинением перед клиентом без изменения процесса.
• Принять пять решений сразу. Ни одно не доводят до конца.
• Писать регламент на десять страниц, который никто не прочитает.
• Не проверять через месяц, работает ли изменение.

Когда большая система всё-таки нужна

Я не против систем. Против пустого слова «надо». Если одинаковые сбои повторяются каждый месяц в разных проектах, точечные чек-листы уже не спасают: нужен процесс с владельцем, метриками и регулярной проверкой.

Признак такой ситуации простой. В журнале разборов одна и та же причина встречается три-четыре раза за квартал. Тогда за систему берётся конкретный человек, у него есть срок, бюджет времени и право менять правила для всех команд. Без этих трёх условий «система» остаётся фразой на планёрке.

Даже тогда я начинаю с малого. Сначала один процесс в одной команде на месяц, потом проверка, работает ли, и только после этого раскатка на всех. Большие системы, внедрённые разом по всей компании, обычно тихо умирают через полгода, потому что их никто не успел приспособить к реальной работе.

Чек-лист вместо большой системы

«Делать систему» звучит солидно, но мозг не знает, с чего начать. Чек-лист — минимальная система, которую можно сделать за час.

Сила чек-листов хорошо видна по медицине. В 2009 году исследование Всемирной организации здравоохранения в восьми больницах показало: после внедрения хирургического чек-листа из 19 пунктов смертность снизилась примерно с 1,5% до 0,8%. Атул Гаванде описал эту историю в книге «Чек-лист».

В проекте всё скромнее, но принцип тот же. Пять-семь пунктов перед релизом, отправкой счёта или запуском рассылки. Каждый пункт появился после конкретного сбоя. Так система вырастает из факапов сама, без громких обещаний.

Чек-лист не должен разрастаться. Если в нём больше десяти пунктов, его начинают пролистывать не глядя. Лучше раз в квартал вычеркнуть то, что стало привычкой, и оставить только пункты, на которых реально ошибаются.