Стоит признать, что пожары бывают даже на проектах, план которых великолепен и надёжен, как швейцарские часы. Делюсь своим подходом к кризисным ситуациям. В нём смешались лучшие практики из разных источников. От кайдзена до личного опыта.
1. Признать проблему, оповестить команду и бизнес-заказчика / пользователей
«Спасибо, кэп!», — возможно скажете вы, но удивитесь, если обратите внимание, как много команд этого не делают, пока дым над проектом не становится виден уже из космоса. Это важнейший этап в разрешении любой проблемы или конфликта. Если не делать этого, то высока вероятность превратиться в персонажа рассказа «Голый король». Уверены, вы не хотите оказаться в такой ситуации.
2. Чётко описать сложившуюся ситуацию текстом
Пока песец находится в нашей голове, он очень аморфный и может изменяться в зависимости от настроения. Не менее важно, песец в головах у людей разный, а значит, что наши усилия по его приручению могут быть кардинально разными, а ведь именно в моменты его пришествия важно, чтобы все действовали в едином порыве.
3. Оперативно снять негативные симптомы
Необходимо как можно скорее устранить критические последствия и восстановить целевой ход проекта и операций. Мы намеренно использовали слово «критические», то есть те, которые не позволяют двигаться работе дальше или необратимо влияют на качество проекта или клиентского опыта. Если есть достаточное количество ресурсов, то следующий шаг можно вести параллельно с этим.
4. Определить причину и вероятность повторения в будущем
Что повлекло за собой нештатную ситуацию? Какое стечение обстоятельств стало зачатком этого инцидента? Крайне важно определить это, так как от этого зависит то, во что мы будем инвестировать деньги, время и ресурсы. Стало ли причиной инцидента извержение спящего вулкана в один момент с парадом планет, или систематические недоработки бизнес-аналитиков в части пользовательских историй?
То есть нужно определить частоту повторения, и определить тип причины:
- системная и управляемая;
- системная и неуправляемая;
- несистемная и управляемая;
- несистемная и неуправляемая.
Конечно, не забудьте прикинуть цену последствий такого события и стоимость устранения.
5. Устранить причину и/или организовать мониторинг, обновить базу знаний
Определив тип причины и стоимость её устранения, определяем набор действий:
- изменение среды;
- устранение причины;
- реализация защиты;
- организация мониторинга;
- наполнение базы знаний.
Поясним. В случае невозможности управлять причиной — нет смысла пытаться её устранить. Нужно менять окружение или создавать защиту. В случае фактической невозможности повторения ситуации — достаточно пополнить базу знаний. Все ваши действия должны быть оправданы с точки зрения бизнеса.
6. Сообщить об итогах (причина, действия, средства мониторинга и защиты) команде и бизнес-заказчику / пользователям
Считаем это важным аспектом работы команды и специалистов. Не нужно прятать сложности. Намного эффективнее дать возможность чувствовать работу команды, проекта или продукта, имея возможность получать обратную связь.
Дайте свою оценку. Согласны с таким подходом или у вас есть дополнения?