Майк Кон является одним из основателей Agile Alliance и Scrum Alliance, он специализируется на оказании помощи компаниям в освоении и улучшении использования гибких процессов и методов для создания чрезвычайно эффективных команд. Ниже приводим адаптированный перевод его статьи о том, как минимизировать риски проекта еще на стадии планирования.

Майк Кон

«Все, что может пойти не так, пойдет не так». Мы все слышали, что гласит закон Мерфи. Многие из нас когда-то говорили эту фразу, но мало для кого это не пустые слова .

Чтобы подготовится к тому, что может пойти не так, - это провести пре-мортем (пре-мортем – это управленческая стратегия, при которой работник воображает, что его проект провалился - ред. ). Это собрание, проводимое в начале проекта, на котором заинтересованные стороны определяют все возможные проблемы, которые могут повлиять на успешную реализацию этого проекта.

Название происходит от идеи вскрытия проекта, встречи, проводимой в конце проекта, в которой заинтересованные стороны извлекают уроки из того, что прошло хорошо, а что - плохо по завершенному проекту.

Учиться на проблемах в конце проекта - это хорошо, но это приносит пользу только будущим проектам, а для текущего проекта бесполезно.

Пре-мортем переносит это обучение на начало проекта, когда заинтересованные стороны просят подумать обо всем, что может пойти не так во время проекта.

Для Agile-команд  пре-мортем находится на другом конце ретроспективы спринта, но охватывает весь проект, а не отдельный спринт. Это отношение к ретроспективе итерации приводит к тому, что встречу иногда называют будущей или предполагаемой.

Кто должен участвовать?

Успешный пре-мортем должен быть сосредоточен на всем, что может повлиять на успех проекта. Это означает, что вам следует пригласить всех заинтересованных лиц, которые могут помочь выявить или решить эти проблемы.

Вы должны пригласить не только команду разработчиков, владельца продукта, мастера Scrum или тренера. Участвовать должны пользователи, спонсоры проекта и представители других команд. Подумайте также о включении тех, кто занимает важные должности, которые следят за согласованностью и целостностью продукта, например архитекторов, дизайнеров и инженеров баз данных.

Проведение Pre-Mortem

Обычно скрам-мастер или тренер проводят пре-мортем для Agile-команды. При проведении встречи фасилитатор должен выполнить три шага:

1. Во-первых, предложите участникам составить список всех возможных проблем, с которыми может столкнуться проект. Обычно это приводит к тому, что в списке слишком много пунктов, чтобы эффективно проработать каждый из них.
2. Второй шаг - расставить приоритеты и сузить список до десяти основных проблем.
3. На заключительном этапе участники определяют решения этих десяти основных проблем.

Рассмотрим каждый шаг более подробно.

Мозговой штурм потенциальных проблем

Начните пре-мортем, попросив участников встречи представить себе все препятствия между тем, где они сейчас находятся, и успешной реализацией проекта. Если установлен дедлайн, препятствия на пути к выполнению заданий в срок должны быть частью обсуждения. Вводный вопрос может быть таким: «Что может помешать нам успешно реализовать этот проект в следующие 90 дней?»

Судя по опыту, я могу сказать, что это может привести к появлению следующего списка потенциальных препятствий:

1. Ключевые ресурсы выведены из проекта
2. Клиенты не отвечают быстро, когда у нас есть вопросы
3. Новое обещанное оборудование недоступно
4. Четыре новых сотрудника не так продуктивны, как планировалось
5. Сезон ураганов заставляет нас закрыть офис на неделю
6. Руководство не выполняет своего обещания не допускать нас к другой некритической работе.

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

Это должно привести к тому же списку в зеркальном отображении. Это просто другой взгляд, и для некоторых групп это полезно.

Выбор десятки лучших

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

Имея полный список возможных проблем, вы теперь хотите сузить его до десяти основных препятствий на пути к успешной реализации.

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

Я предпочитаю пройтись по списку, разделив элементы на три категории:

1. Точно не в десятке
2. Может в десятке
3. Однозначно в десятке

Определение триггеров и создание планов

Третий и последний шаг - решить, что делать с первой десяткой. Для каждого потенциального препятствия попросите собравшуюся группу определить:

1. Триггер
2. Стратегия смягчения последствий

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

1. Оборудование не установлено и будет доступно до 18 сентября.
2. Предполагаемая дата доставки поставщиком - 4 сентября или позже.
3. Заказ на покупку не отправлен до 1 августа.

Вышеуказанные триггеры перечислены в порядке серьезности. Стратегия смягчения последствий должна соответствовать серьезности триггера.

Например, если у вас нет оборудования до 18 сентября, это настоящая проблема. Стратегия смягчения последствий может заключаться в том, что ИТ-группа (или тот, кто занимается настройкой оборудования) может прийти на выходных, чтобы настроить его.

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

Мониторинг рисков

Недостаточно определить, что может пойти не так в проекте; вы должны внимательно следить за горизонтом, чтобы увидеть, действительно ли возникает какая-либо из этих проблем. Вот здесь и появляются триггеры.

Выявление триггеров полезно: это упрощает мониторинг этих основных рисков. Вместо того, чтобы задаваться вопросом, должен ли кто-то действовать, заранее определите действия и их конкретные триггеры.

На следующем этапе мониторинга рисков, выявленных при предварительном вскрытии, вы также можете создать диаграмму снижения рисков и обновлять ее один раз за итерацию.