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

Базово это выглядит так: – Полгода разработки – “Уже прошли половину пути, сейчас остановиться будет глупо, нужно доделать”. – Выгорела команда – “Давайте еще немного потерпим, я и сам устал, но нужно сделать”. – Потратили 30 миллионов – “30 миллионов уже потрачено, осталось немного, нужно найти бюджет”.

Проблема в том, что менеджер относится к этому как к “фундаменту” или “инвестициям” в будущее.

Увы, но все это невозвратные затраты.

И вопрос нужно ставить так: “Если бы мы сегодня выбирали заново, вложили бы мы оставшиеся деньги и время в этот проект?” Исходя из ответа и должно приниматься решение о продолжении работы над проектом.

Но чтобы определиться, kill-критерий требуется формализовать перед стартом и использовать его в Decision Architecture.

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

Что можно заложить в kill-критерий: – Не подтвердилась ключевая гипотеза. – Метрика принятия (adoption) после пилотной версии ниже ожидаемой. – Проект потерял спонсора. – Появилась технология, которая делает решение устаревшим. – Стратегический приоритет компании изменился.

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

Вас по большому счету и нанимают для того, чтобы определить kill-критерий и вовремя его включать.

Зрелый менеджер честно говорит – “Проект перестает иметь смысл, его нужно закрывать”.

Для незрелого менеджера закрытие – это страх. “Проект закроют, что я буду делать?! Поэтому давайте еще 2–3 месяца поработаем, я верю в проект”.

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