«Знал бы, где упасть»: как устроить проекту премортем до запуска

Представьте, что ваш проект уже провалился. Запуск сорван, бюджет потрачен, команда разбирает ошибки, а руководитель пытается понять, в какой момент всё пошло не так. Теперь хорошая новость — ничего этого ещё не произошло. До запуска осталось несколько недель, и у вас есть возможность предотвратить часть проблем. Именно на таком мысленном эксперименте построен премортем — метод, который помогает обнаружить слабые места проекта до того, как они превратятся в реальные неприятности.

Сначала похороны, потом работа

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

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

Допустим, команда готовится запустить новый сайт. Дизайнер знает, что часть макетов ещё не согласована. Разработчик предполагает, что подключение формы заявки займёт больше времени, чем указано в плане. Маркетолог понимает, что рекламные материалы пока не готовы.

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

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

Не «мы можем не успеть запустить сайт», а «мы запустили сайт с опозданием, потеряли часть заявок и не достигли запланированного результата».

Теперь участникам необходимо восстановить причины произошедшего. Причём не защищать собственные решения, а искать убедительные объяснения неудачи.

Этот подход называется премортемом (premortem) — своеобразным разбором ошибок до того, как они произошли.

В отличие от привычного анализа рисков, здесь используется психологический приём prospective hindsight — взгляд на будущее событие так, словно оно уже осталось в прошлом.

Исследователи Дебора Митчелл, Джей Руссо и Нэнси Пеннингтон изучали, как подобное изменение перспективы влияет на объяснение событий. Их работа стала одной из научных основ метода Кляйна.

Но никакой мистики в премортеме нет. Он не позволяет предсказывать будущее. Его задача — помочь людям сформулировать сомнения, которые при обычном обсуждении могут остаться невысказанными.

Как за 30 минут найти слабые места проекта

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

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

Рассмотрим сценарий короткой 30-минутной встречи.

Шаг 1. Объявите проект провалившимся — 3 минуты

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

Например:

Сегодня 15 декабря. Сайт запущен, но проект признан неудачным. Часть функций работает неправильно, заявки теряются, запуск не дал ожидаемого результата. Попытайтесь объяснить, почему так произошло.

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

Это снимает необходимость сначала убеждать окружающих, что определённая проблема вообще возможна.

Шаг 2. Дайте каждому подумать самостоятельно — 4 минуты

Теперь каждый участник записывает возможные причины провала. Желательно не меньше трёх, хотя искусственно заполнять список не нужно.

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

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

На этом этапе допустимы даже неприятные формулировки: «Мы неправильно оценили сроки», «Заказчик не получил ожидаемый результат», «Никто не проверил передачу заявок». Главное — чтобы они описывали конкретную возможность, а не абстрактное «что-нибудь сломалось».

Шаг 3. Соберите версии, не устраивая защиту проекта — 7 минут

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

Предположим, в нашем учебном примере появились такие ответы:

• Дизайнер — окончательные макеты согласовали слишком поздно.
• Разработчик — интеграция формы заявки с системой обработки обращений не прошла полноценную проверку.
• Маркетолог — рекламную кампанию запустили до проверки всех посадочных страниц.
• Менеджер — команда не договорилась, кто отвечает за итоговую приёмку сайта.
• Тестировщик — проверки проводили по отдельным функциям, но никто не прошёл весь путь пользователя от заполнения формы до получения заявки менеджером.

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

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

Шаг 4. Выберите причины, которые действительно заслуживают внимания — 5 минут

После сбора идей нужно отделить конкретные риски от маловероятных предположений.

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

Совсем другая ситуация с формой заявки, которую ещё ни разу не проверяли на реальном сценарии отправки данных.

Для первоначального отбора можно использовать три критерия:

1. Последствия. Насколько серьёзно событие повлияет на результат проекта.
2. Основания для опасений. Есть ли уже известная зависимость, непроверенное решение или другая конкретная причина беспокоиться.
3. Управляемость. Можно ли сейчас предпринять действие, которое снизит вероятность проблемы или уменьшит её последствия.

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

Шаг 5. Превратите опасения в действия — 8 минут

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

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

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

Продолжим пример с запуском сайта.

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

Шаг 6. Зафиксируйте решения — 3 минуты

В последние минуты встречи ведущий проверяет, что у каждого приоритетного риска появился ответственный, понятное следующее действие и срок проверки.

Остальные идеи не удаляются. Их сохраняют для дальнейшего наблюдения, но не превращают автоматически в новые поручения.

В результате за полчаса команда получает не перечень страхов, а несколько конкретных изменений, которые стоит внести в первоначальный план.

Самая полезная часть премортема начинается после встречи

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

Через неделю выясняется, что проверку так и не выполнили. Исполнитель занимался срочными доработками, руководитель считал вопрос закрытым, а в общем плане осталась только старая задача «Настроить форму».

Формально премортем состоялся. Практической пользы оказалось немного.

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

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

Возьмём риск с потерей заявок. Его можно оформить следующей карточкой.

Карточка — Проверить передачу заявок перед запуском

Риск: форма на сайте сообщает об успешной отправке, но данные не доходят до менеджера.

Ранний сигнал: тестовая заявка отсутствует в системе обработки обращений.

Исполнитель: разработчик, отвечающий за интеграцию.

Дата: до утверждения готовности сайта к запуску.

Чек-лист:

• Отправить тестовую заявку с заполненными обязательными полями.
• Проверить, появилась ли она в системе.
• Убедиться, что передались все необходимые данные.
• Проверить сценарий с ошибкой отправки.
• Передать результат ответственному за приёмку.

Вложения в карточке можно использовать для результатов проверки, скриншотов или технического описания. После успешного выполнения она перемещается в «Проверено».

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

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

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

Канбано сейчас полностью бесплатен, причём количество досок, карточек и пользователей не ограничено. Можно создать отдельное пространство для рисков одного проекта, подключить участников и проверить подход без покупки лицензий и собрать доску для премортема.

Как не превратить премортем в соревнование пессимистов

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

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

Поэтому после сессии важно избегать трёх ошибок.

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

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

Третья — считать проведённую сессию гарантией успеха. Премортем помогает обнаруживать возможные проблемы. Он не отменяет тестирование, контроль качества, согласования и обычную работу с рисками. Более того, часть будущих обстоятельств команда объективно не сможет предвидеть.

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

Проверьте проект ещё раз, когда появятся новые обстоятельства

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

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

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

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

Остальная работа остаётся обычной работой над проектом. Премортем не должен становиться отдельной бюрократической системой, которую приходится обслуживать ради неё самой.

Начните с проекта, который ещё можно спасти

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

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

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

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