Вопрос «Кто-нибудь видит риски?» часто приводит к короткому обсуждению и успокаивающему ответу. Премортем проекта ставит вопрос острее: «Представьте, что проект уже провалился. Что произошло?» Такой взгляд даёт участникам конкретную историю для разбора, пока план ещё можно изменить.
Результатом встречи должны стать несколько изменений в проекте: предположение, которое нужно проверить, дополнительная мера защиты, сигнал для наблюдения или обязательство, которое стоит пересогласовать.
Когда проводить премортем проекта
Проводите такую сессию, когда план уже достаточно определён, но дорогостоящие или труднообратимые обязательства ещё не приняты. Поводом может стать внедрение, миграция, мероприятие или запуск с участием нескольких команд. Если проект существенно изменился, вернитесь к затронутым рискам, а не повторяйте всю встречу по шаблону.
Премортем рассматривает будущее через воображаемую неудачу. Ретроспектива разбирает то, что уже произошло. Реестр рисков хранит риски и позволяет отслеживать их со временем. Результаты сессии могут пополнить реестр, но она не заменяет технические испытания, проверку договоров или профессиональный анализ безопасности.
Методика премортема Atlassian предлагает исследовать риски проекта через самостоятельную генерацию идей, обсуждение и действия с назначенными ответственными. Ниже этот общий подход применяется к сценарию запуска с особым вниманием к ранним предупреждающим сигналам.
Опишите неудачу так, чтобы её можно было представить
Избегайте формулировки «Всё пошло плохо». Назовите временной горизонт и значимый результат. Для переноса службы поддержки в новую систему подойдёт такой сценарий: «Прошёл месяц после перехода. Клиенты всё ещё пишут на старые адреса, сотрудники не могут найти предыдущие переписки, и команда вернулась к прежней системе».
Это условный сценарий для упражнения, а не прогноз. Он задаёт общую отправную точку, не подсказывая участникам, какие причины нужно придумать. Если ограничиться фразой «Мы сорвали срок», можно упустить проект, который запущен вовремя, но не решает задач пользователей.
Заранее поделитесь текущим планом проекта, ожидаемым результатом и известными ограничениями. Пригласите тех, кто внедряет изменения, и тех, кому предстоит с ними работать. При миграции поддержки сотрудники и администраторы могут заметить сценарии отказа, которых не видит заказчик проекта.
Проведите сессию без спора о правоте
В начале объясните: критика касается плана, а не компетентности его авторов. Попросите каждого самостоятельно записать возможные причины неудачи, по одной на заметку. Руководителям стоит высказать свою версию после остальных. Иначе доска может превратиться в список доводов в пользу первого мнения старшего по должности.
Прочитайте заметки до их группировки. «Обучение не завершено» и «Сотрудники не могут отвечать на нестандартные вопросы» могут быть связаны, но это не одно и то же. Первое касается прохождения обучения, второе — способности выполнять работу. Слишком раннее объединение может скрыть детали, по которым можно действовать.
Для каждой группы уточните, как именно будет развиваться неудача. Замените «плохую коммуникацию» цепочкой: «Новый адрес для связи сообщили только в рассылке; клиенты отвечают в старых переписках; после переключения старый почтовый ящик никто не проверяет». Так у команды появится несколько точек, в которых можно вмешаться.
Пример: перевод службы поддержки в новую систему
Следующая условная доска показывает, как история неудачи превращается в набор решений. Имена и даты добавит реальная проектная команда; указанные роли — примеры того, кому можно поручить ответственность.
| Возможная причина | Ранний предупреждающий сигнал | Предлагаемая мера | Ответственный — подтвердить |
|---|---|---|---|
| История прежних переписок перенесена не полностью | В выборке перенесённых обращений отсутствуют вложения или ссылки | Сверить типовые обращения до разрешения на переключение | Руководитель миграции |
| Клиенты продолжают писать на старые адреса | Участники пилота отвечают в прежних почтовых цепочках | Предусмотреть контролируемый переходный канал и понятные сообщения клиентам | Операционная команда поддержки |
| Сотрудники знают интерфейс, но не порядок работы с исключениями | Учебные обращения постоянно требуют вмешательства администратора | Отработать нестандартные случаи и определить порядок эскалации | Ответственный за обучение |
| Откат описан, но выполнить его нельзя | Никто не может объяснить, как сохранятся новые переписки | Проверить процедуру восстановления до одобрения запуска | Технический ответственный |
Обратите внимание: «миграция провалилась» — это результат, а не причина. И «следить за проектом» ещё не мера, пока не определено, за чем наблюдать и какое решение должно последовать.
Расставляйте приоритеты без выдуманной точности
Обсудите последствия, основания считать риск реальным и самый поздний момент, когда команда ещё успеет отреагировать. Риск, последствия которого легко устранить на следующей неделе, отличается от риска, заметного только после необратимого переключения. Если для оценки вероятности нет оснований, отметьте её как неизвестную, а не придумывайте точный процент.
Голосование помогает выделить опасения для обсуждения, но само по себе не должно определять окончательные меры. Специалист может заметить серьёзный сценарий отказа, который получит мало голосов лишь потому, что остальные его не понимают. Попросите объяснить логику и передайте вопрос соответствующему эксперту.
Выбирайте действия под конкретное решение. Перед масштабным внедрением полезно проверить перенос на выборке данных. Переписывать все учебные материалы может быть преждевременно, если короткая тренировка сначала покажет, что главная проблема — права доступа.
Разделяйте предотвращение и план реагирования
Профилактическая мера снижает вероятность неудачи или тяжесть её последствий ещё до события. План реагирования определяет, что команда сделает при наступлении заданного условия. Поддержка может заранее сверить перенесённые записи — это профилактика. Она также может установить условия переноса запуска или восстановления сервиса — это план реагирования.
Условие должно быть наблюдаемым. «Если всё выглядит плохо» заставляет договариваться под давлением. «Если на репетиции не удаётся обработать обязательный тип обращения» даёт ответственному за запуск конкретное основание для оценки. Порог должен исходить из требований проекта к сервису, а не из произвольного числа, скопированного из примера.
Фиксируйте значимые решения в журнале решений, в том числе указывайте, кто вправе принять остаточный риск. Сессия не должна незаметно передавать эти полномочия тому, кто ведёт встречу.
Не теряйте неудобные вопросы после встречи
Некоторым участникам трудно публично критиковать сроки, предложенные заказчиком проекта. Дайте возможность сообщить об опасениях до встречи и вернитесь к нерешённым разногласиям после неё. Не обещайте анонимность, если выбранный способ сбора замечаний её не обеспечивает.
Используйте матрицу RACI, если ответственность за действие остаётся неясной. На доске премортема оставьте более простой набор полей: риск, сигнал, мера, ответственный и дата следующего решения. Добавьте ссылку на реальную задачу по выполнению, чтобы не вести два конкурирующих учёта прогресса.
Откройте Boardmix и разместите в верхней части холста сценарий неудачной миграции поддержки. Ниже создайте четыре колонки из примера: «Возможная причина», «Ранний предупреждающий сигнал», «Предлагаемая мера» и «Ответственный — подтвердить». Причину и соответствующую меру держите в одной строке. Для неполной истории переписок свяжите неудачную проверку выборки обращений с задачей по сверке, за которую отвечает руководитель миграции. До одобрения переключения проверьте эту задачу и остальные неустранённые сигналы. Если обязательных вложений по-прежнему нет, у ответственного за запуск есть конкретная причина отложить переход.
