Лучший проект, над которым я работал, провалился катастрофически.
За полгода до запуска.
И именно поэтому в реальности всё прошло идеально — без срывов сроков, без двойного бюджета, без того момента, когда начальство вызывает тебя на ковёр и спрашивает, что, блин, пошло не так.
Странная история, да? Сейчас объясню.
Как мы похоронили проект до его рождения
Летом 2019-го я участвовал в запуске большого проекта. Команда из двенадцати человек, полгода работы, бюджет... ну, скажем так, приличный. План был красивый. На бумаге всё сходилось. Мы даже сделали презентацию с графиками, где кривые росли вверх и направо, как положено.
И вот за три месяца до дедлайна руководитель проекта — назовём его Михаил — собрал всех в переговорке. Я думал, обычная планёрка. Статусы, дедлайны, кто что делает.
Но Михаил сказал странную вещь: "Закройте глаза. Представьте, что мы уже в декабре. Проект запустили. Он провалился. Полностью. Катастрофически. Бюджет съели, продукт работает через раз, клиенты жалуются. Это факт. Открывайте глаза."
Мы открыли глаза и уставились на него, как на сумасшедшего.
Наверное, ни один детектив не обходится без фразы "Вскрытие покажет". Патологоанатом вскрывает тело, смотрит на улики, выясняет причину смерти. Только труп уже холодный. Поздно что-то менять.
А что, если сделать вскрытие ДО смерти? Пока пациент ещё жив и можно всё исправить?
А он продолжил: "Возьмите стикеры. Запишите, почему мы провалились. Не 'может быть', не 'есть риск'. Мы УЖЕ провалились. Почему?"
Почему вскрытие до смерти (pre-mortem) работает
Знаете, что я понял тогда, в той переговорке?
Когда тебя спрашивают "что может пойти не так", ты автоматически включаешь режим оптимизма. Никто не хочет быть тем, кто всё портит. Групповое мышление давит: если все молчат, значит, всё норм, и я промолчу.
Но когда тебе говорят "проект УЖЕ провалился" — психология меняется. Ты не предсказываешь будущее. Ты объясняешь прошлое. А объяснять мы умеем гораздо лучше, чем предсказывать.
Эту технику разработал когнитивный психолог Гэри Кляйн ещё в 2007-м. Назвал её pre-mortem — предсмертное вскрытие. Прикол в том, что исследование 1989 года показало: когда люди мысленно переносятся в будущее и смотрят назад, их способность найти причины провала увеличивается на 30%.
Тридцать процентов, Карл.
И вот эту штуку используют на Wall Street, в армии, у пожарных, в корпоративных советах директоров. Даже Дэниел Канеман — тот самый, нобелевский лауреат, который написал "Думай медленно, решай быстро" — рекомендует pre-mortem как обязательный инструмент для любого серьёзного проекта.
Типичная планёрка выглядит иначе
Вы наверняка бывали на таких встречах.
Руководитель спрашивает: «Есть какие-то опасения по плану?»
Тишина. Все смотрят в экраны ноутбуков.
Кто-то осмеливается: "Ну... может бюджет маловат?"
"Да нет, справимся. Мы и не такое делали."
И всё. Встреча окончена.
Проблема в том, что никто не хочет быть занудой. Никто не хочет сказать вслух: "Ребята, а у нас же нет запасного разработчика, если Серёга заболеет. А у него двое маленьких детей, он болеет каждую зиму." Это звучит как паника. Как недоверие команде.
Поэтому молчим. И через три месяца Серёга заболевает. И проект встаёт.
Pre-mortem снимает это давление. Когда проект УЖЕ провалился (в воображении), указать на проблему — это не паника, это расследование. Ты не портишь настроение, ты разгадываешь детектив.
Как pre-mortem работает на практике
Ладно, вернусь к нашей переговорке.
Михаил дал нам десять минут тишины. Каждый писал на стикерах причины провала. Самостоятельно, без обсуждений. У меня получилось семь причин. Честно — я удивился, сколько всего всплыло. Вещи, о которых я даже не думал раньше.
Потом он собрал стикеры и начал зачитывать по кругу. Никаких дискуссий — просто фиксация на доске.
Я помню, как одна девушка из маркетинга написала: "Мы недооценили, сколько времени займёт согласование с юристами. Запустились на три недели позже."
А наш техлид записал: "Мы не учли технический долг. Старый код замедлил разработку в два раза."
Кто-то написал: "Конкуренты запустили похожий продукт на месяц раньше нас."
Всего набралось двадцать три причины.
Потом Михаил дал каждому три стикера: "Проголосуйте за три самых опасных тигра."
(Забавное слово — "тигры". Сейчас объясню.)
Тигры, бумажные тигры и слоны в комнате
Вот что мы сделали с этими двадцатью тремя причинами.
Михаил разделил их на три группы.
Тигр — реальная угроза, которая убьёт проект, если не принять меры. Например, у нас был тигр: "Нет резервного разработчика на критический модуль." Это не абстрактный риск. Это конкретная дыра в плане.
Бумажный тигр — кажется страшным, но не очень опасен. Кто-то написал: "Конкуренты могут скопировать нашу фичу." Михаил сказал: "Могут. Но у нас преимущество первопроходца. Это бумажный тигр — выглядит опасно, но беззубый."
Слон в комнате — то, о чём все думают, но никто не говорит вслух.
У нас слоном оказалась фраза одного парня: "Наш CEO не верит в этот проект. Если что-то пойдёт не так, он свернёт финансирование."
Тишина в комнате была... плотная.
Михаил посмотрел на нас и кивнул: "Вот. Это и есть слон. Мы все это знали. Но никто не говорил. Теперь — на столе."
Знаете, что произошло дальше?
Мы перестали ходить вокруг да около. Начали обсуждать реальные проблемы. И самое главное — для каждого тигра назначили ответственного, дедлайн и конкретное действие.
Для резервного разработчика — подключили стажёра, чтобы он разбирался в модуле параллельно с основным разработчиком.
Для юридических согласований — начали их на две недели раньше, чем планировали.
Для CEO — Михаил договорился о промежуточной демонстрации, чтобы CEO увидел прогресс и поверил в проект.
Проект запустили вовремя. Бюджет не превысили. Не идеально — косяки были. Но катастрофы не случилось.
Хотите попробовать pre-mortem сами?
Вот как это организовать. Сразу скажу — это не универсальная таблетка. Но работает чаще, чем вы думаете.
Идеальное время — за один-три месяца до запуска. Достаточно рано, чтобы исправить проблемы. Достаточно поздно, чтобы план был конкретным, а не абстрактным.
Вам понадобятся:
готовый план проекта (хотя бы черновой), вся проектная команда, конференц-зал или Zoom, стикеры (или общий документ).
Очень важный момент: не приглашайте топ-менеджеров. Серьёзно. Они задавят дискуссию. Люди начнут думать о политике, а не о проблемах.
Как проводить pre-mortem
Начинается встреча с обзора. Минут десять. Убедитесь, что все понимают цели проекта, основные этапы, бюджет, сроки. Без этого шага люди будут говорить о разном. Кто-то думает, что проект — это новая фича. Кто-то — что целый продукт. Синхронизируйтесь.
Потом включаем хрустальный шар.
Ведущий говорит примерно так: "Закройте глаза. Представьте, что вы переместились на шесть месяцев вперёд. Проект завершён. К сожалению, он провалился. Полностью. Катастрофически. Бюджет превышен в два раза. Сроки сорваны на месяц. Продукт работает через раз. Клиенты жалуются. Это позор для всей компании. Хрустальный шар непогрешим. Провал — это факт. Откройте глаза."
Важно создать драму. Не говорите сухо. Говорите так, будто это реально случилось. Пусть люди почувствуют это.
Дальше — молчаливый брейнсторм. Каждый работает самостоятельно. Записывает причины провала. Минимум пять-семь. Никакой самоцензуры. Никаких обсуждений. Просто пишем на стикерах или в документе.
Дайте людям минут десять. Не торопите. Пусть думают.
---
Потом быстрый сбор идей. По кругу, каждый называет по одной причине. Ведущий записывает на доске. Никаких обсуждений — только фиксация. Никакой критики. Темп важен. Держите энергию высокой. Это как аукцион идей — быстро, динамично, азартно.
Когда идеи иссякнут, переходите к голосованию. Каждый участник получает три стикера (или три голоса в документе) и выбирает топ-3 самых опасных причины.
Не самых вероятных. Не самых интересных. Самых опасных — тех, которые убьют проект наповал.
Для каждой высокоприоритетной причины спросите: что мы можем сделать СЕЙЧАС, чтобы предотвратить? Кто отвечает? Какой дедлайн?
Без этого шага pre-mortem превращается в пустую болтовню. Красивое упражнение, от которого ничего не меняется.
После встречи задокументируйте всё. Обновите проектный план. И — самое главное — каждый месяц проверяйте, не появились ли новые тигры.
Пять способов испортить pre-mortem
Я видел, как люди делают эту технику неправильно. Вот самые частые косяки.
Первый — вы спрашиваете "что может пойти не так" вместо "проект провалился, почему". Разница огромная. Первое — это осторожность. Второе — это факт.
Второй — медленный темп. Кто-то начинает подробно обсуждать каждую идею. Энергия падает. Встреча превращается в нудное совещание. Правильно — быстрый сбор без обсуждений. Обсуждение потом, когда проголосуете.
Третий — доминирование одного человека. Когда старший сотрудник зачитывает весь свой список причин, остальные молчат и кивают. Правильно — по кругу, по одной причине от каждого.
Четвёртый — забывают после встречи. Список создали, повесили на доску и всё. Никто не действует. Правильно — план действий с конкретными шагами, ответственными и дедлайнами.
Пятый — превращение в улучшательство. "А что, если мы добавим вот эту фичу?" Нет. Фокус на провале, а не на том, как сделать лучше. Это не про "что можно улучшить", а про "почему мы уже облажались".
Pre-mortem: реальный кейс
Знакомый запускал онлайн-сервис для малого бизнеса. План был шикарный. Бюджет согласован. Команда горела идеей.
Решили провести pre-mortem за два месяца до запуска. Закрыли глаза. Представили провал. Открыли глаза и начали искать причины.
Всплыло четыре критических момента.
Первое — они недооценили культурные различия своей аудитории. То, что работает в больших городах, может не зайти в регионах. А их основная аудитория была как раз там.
Второе — слабое знание конкурентов. Они думали, что конкуренты слабые, но на деле просто мало о них знали.
Третье — неверная ценовая модель. Покупательная способность аудитории оказалась ниже, чем они предполагали.
Четвёртое — отсутствие поддержки клиентов на том языке, на котором клиенты хотели общаться. Они планировали всё на русском, но часть аудитории говорила на казахском и предпочитала его.
Что они сделали? Наняли местного консультанта из Алматы. Провели углублённое исследование конкурентов — не поверхностное, а реальное, с интервью. Скорректировали цены. Запланировали набор местной команды поддержки.
Результат? Запуск прошёл нормально. Не идеально — были проблемы. Но катастрофы удалось избежать.
Самое интересное:
Команда потом сказала, что все эти проблемы кто-то видел. Кто-то думал о культурных различиях. Кто-то сомневался в цене. Но никто не говорил вслух до pre-mortem.
Почему pre-mortem работает лучше обычного планирования
Вот что я понял за годы работы с проектами.
Большинство проектов проваливаются не из-за непредвиденных обстоятельств. Не из-за форс-мажоров. Не из-за злого рока.
Они проваливаются из-за рисков, которые кто-то в команде видел, но боялся озвучить.
Может, боялся прослыть пессимистом. Может, не хотел портить настроение. Может, думал, что это его личная паранойя, и все остальные всё правильно понимают.
Pre-mortem даёт разрешение говорить о провале. До того, как он случится.
И ещё один момент. Когда мы представляем, что событие УЖЕ произошло, мозг работает иначе. Мы переходим из режима "планирование" в режим "объяснение". А объяснять причины мы умеем гораздо лучше, чем предсказывать будущее.
Это не магия. Это психология.
---
Помните тот проект, с которого я начал? Тот, что провалился катастрофически за полгода до запуска?
Он не провалился в реальности. Провалился в нашей голове. На той встрече с Михаилом. И именно поэтому в реальности всё прошло без катастроф.
Мы увидели тигров заранее.
Вытащили слона из комнаты.
Разобрались с бумажными тиграми.
И спокойно запустили проект в срок.
Забавно, да? Лучший способ избежать провала — сначала провалиться. В воображении. С командой. С конкретными причинами и конкретными решениями.
Другие статьи по схожим тематикам можно найти по карте.
Для быстрого поиска по каналу используйте поисковую систему.