Управление проектами в условиях катастрофических сбоев

#рецепт Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare? Часть 1 Дорогой читатель, последние три дня урок катастрофы для многих. Яндекс сообщил о повреждении ЦОДов в Сасове и Калуге, затем во Владимире. При мне был также блэкаут, что перенёс концерт Канье, а сбой Cloudflare не только лишил клиентов доступа к сайтам, ну и случился прямо перед демо моего крупного OSS . Общее: ключевая опора проекта исчезает помимо твоей воли Проджектов учат управлять рисками: заболеет тестировщик -> сдвинется релиз. Человека можно заменить. А если недоступна вся команда и взять людей негде? Катастрофа редкое, часто невообразимое событие с последствиями на уровне компании и её репутации. Такое не внесёшь в реестр рисков и не добавишь в буфер пару дней. Нас не учат, что делать, когда план уже бессмысленен, люди сильно теряются Поэтому до кризиса я бы спрашивал себя не только "что может сломаться?", но и "что будет, если сутки нет платежей, связи с подрядчиком или доступа к продукту?". Вынести руководству варианты: резервный банк стоит столько-то; без него останавливаются платежи. Покупаем резерв или сознательно принимаем простой: предупреждаем клиентов, переключаем людей на другие задачи. Пусть ответственный за последствия подтвердит выбор печатно, что да принимаем, кто решил, когда пересмотрим. Хороший пример рекомендаций на такое в https://www.gov.uk/government/publications/orange-book, как муниципалитет должен реагировать на алярмы Проджект не может единолично принять риск для всей компании Когда катастрофа случилась, прежние сроки и обещания перестают быть планом. Нужен кризисный режим: эскалировать, назначить лидера с правом менять ресурсы, сроки и обязательства, фиксировать новые приоритеты и решения Есть полномочия -> действуй. Нет -> собери подтверждённые факты и неизвестное, назови ответственных, время следующего обновления и последствия для старых обязательств. Даже просто в моменте когда пахнет жареным дернуть лидов на синк посреди дня уже отлично, всегда можно извиниться если произошла ошибка, но такая реакция может сильно помочь в случае беды. Прокоммунцируй со стейкхолдерами, скажи: "Релиз в пятницу не состоится. Сейчас команда восстанавливает платежи; остальные сроки пересмотрим завтра, будем держать в курсе изменений" Хороший проджект должен понимать - людей очень пугает неопределенность и неизвестность. Страху отлично противодействуют: эмпатия, искренность, уважение, подотчетность и уверенность. Без ИБД Гасится паника: всем виден порядок действий, инженеров не дёргают лишними запросами. У Google SRE для этого отдельно разведены командование, восстановление и коммуникации Если вы сейчас вытаскиваете сервисы или людей из такого кризиса, сил вам