Кризисные проекты. Как не довести проект до кризиса и как вывести его обратно

Меня зовут Павел Алферов, я профессор бизнес-практики школы управления Сколково. Уже больше 25 лет я помогаю людям бороться со сложностью – ищу разные инструменты борьбы со сложностью мира, сам придумываю эти инструменты и обучаю людей их использованию.

Делаю это в самых разных ролях – сейчас, в основном, преподаю, но ранее сам занимался внедрением тех практик, о которых рассказываю, в крупных российских и международных компаниях: ТНК-BP, X5 Retail Group, «Альфа-групп», ПАО «Интер РАО».

Почти 5 лет поработал в оргкомитете «Сочи 2014» и до сих пор являюсь экспертом Международного олимпийского комитета по планированию и управлению знаниями – проводил на эту тему семинары в Корее, в Китае и Японии.

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

• Управление проектами.

• Управление изменениями.

• Управление знаниями.

• Цифровая трансформация.

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

• Есть ламинарные проекты, которые развиваются планомерно – например, в физике есть ламинарное течение жидкости, когда река течет по равнинной местности.

• И есть проекты кризисные – это когда на пути реки вдруг встречаются пороги, и она перестает течь ровно.

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

И у меня тоже есть некоторый собственный интерес – я бы хотел от вас получить какие-то лайфхаки.

• Начну я с темы, как проект становится кризисным, и что приводит к тому, что проект становится кризисным.

• Поговорим о статистике по кризисным проектам.

• Поговорим о разных видах кризисных проектов.

• Я покажу конкретный кейс – он как раз есть на сайте Инфостарта, и мы с вами вместе попробуем его разобрать.

• Закончу я прототипом фреймворка по работе с кризисными проектами. Я придумал для слова «фреймворк» свой перевод, которым очень горжусь: фреймворк – это схематическая рабочая рамка, сокращенно схерамка. Я пока не придумал готовую схерамку по работе с антикризисными проектами. Но по ней уже есть определенные наработки, хочу с вами ими поделиться.

Почему и как проваливаются проекты

Начнем с темы, почему же проваливаются проекты и как они проваливаются.

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

Не бывает такого, что вчера проект был нормальный, а завтра он провалился. Главный критерий, по которому идет провал (ось Y) – это прогнозы по отклонениям.

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

По мере роста значений отклонений наше отношение к ним меняется:

• Сначала отклонения находятся в рамках нормы и считается, что мы сталкиваемся с вызовами.

• Потом преодоление этих отклонений начинает вызывать определенные усилия.

• Далее – превращается в серьезные проблемы.

• Потом – в кризис.

• Если кризис не разрешен, это приводит к провалу проекта.

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

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

Исследование, о котором я говорю, написал Рикардо Варгас в 2006 году. Несмотря на то, что оно достаточно старое, там хорошо собрана мысль по поводу того, как проект становится провальным.

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

Важные моменты из этого исследования:

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

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

• Варгас выделяет четыре основных сценария реанимации проблемного проекта, пока он не стал провальным:

  • урезать содержание (скоуп проекта);

  • увеличить бюджет, сохранив сроки;

  • увеличить и бюджет и сроки;

  • полная пересборка проекта.

Рассмотрим сценарии реанимации проекта подробнее:

1. Урезать содержание можно сделать по методике приоритизации скоупа проекта MoSCoW. В этой методике все хотелки заказчика делятся на четыре кучки – must-should-could-would. Поэтому по-английски она звучит как MoSCoW, а на русский язык переводится как КВЖД – все хотелки делятся на:

   • К – критические, то, без чего проект вообще можно уже закрывать, если это не сделать, смысла в проекте никакого нет;

   • В – важные, то, что надо держать зубами прямо до последнего;

   • Ж – желательные, то, что в принципе надо бы сделать, если получится;

   • Д – дополнительные, на них смотрим в последнюю очередь.

Если ваш проект пойдет по проблемному сценарию, вам обязательно стоит разделить кусочки скоупа проекта на КВЖД. По-хорошему это надо делать и для обычных проектов. Но для обычных проектов это не всегда получается, а для критических – это критично (извините за тавтологию).

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

3. Увеличить сроки и бюджет. «Если долго мучиться что-нибудь у нас наконец получится».

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

Вот такие были мысли Варгаса. Я еще к этому вернусь.

Что говорит статистика по поводу того, как часто в такую ситуацию попадают проекты?

Эта статистика собрана по знаменитому опросу по теме провалов проектов – Standish Group «CHAOS Chronicles». Этот опрос знаменит тем, что уже больше 25 лет коллеги анализируют провальные проекты. Нет ни одного другого публичного исследования в мире, чтобы столько времени собиралась статистика. Каждые 2-3 года они выпускают обновления. Они опубликовали последние данные по 2020 году, а первый опрос был проведен в далеком 1994 году.

Перед вами график, показывающий ситуацию с проектами в 1994 и 2020 году – это факты. Но на основании фактов можно построить различный маркетинг фактов – я могу их трактовать, как оптимист и как пессимист.

• Надеваю шляпу пессимиста – цифры говорят сами за себя. Я вообще не знаю, что тут обсуждать. Все очень плохо. Пятая часть проектов проваливается! В унитаз спускаются деньги, ничего не достигают. Половина проектов превысили сроки или бюджет. И назвали-то как отвратительно – Challenged. Все плохо, ничего не работает.

• А видите, что тут оптимистичного? Динамика. Коллеги, обратите внимание, к руководству надо приходить с позитивной динамикой. Показывать, что все становится гораздо лучше. Смотрите, раньше проваливалась треть проектов, а сейчас только пятая часть. Раньше только 16% были успешные, а сейчас 35%. Отлично же! Двигаемся, живем.

Если посмотреть на это с точки зрения теории Варгаса, то видно, что:

• Провальные проекты, которые провалились совсем в ноль – сейчас составляют 19% от всех проектов.

• Проблемные проекты – их большинство, это как раз желтый столбик.

Но все-таки, если быть реалистами, можно сказать, что ситуация за последние 30 лет действительно стала лучше:

• Проекты проваливаются меньше.

• Процент Challenged-проектов тоже становится меньше.

• При этом и сам масштаб бедствий уменьшился – превышение сроков уменьшилось в 2 раза, а превышение бюджета уменьшилось в 3 раза.

Очевидно, что человечество научилось лучше управлять проектами. При этом все равно тема проектов, попавших в кризис, остается максимально актуальной. Тем более удивительно, что наука управления проектами им уделяет так мало внимания.

Виды кризисных проектов

Мы с коллегами недавно выпускали исследование о том, какие бывают кризисные проекты. Александр Ожаровский предложил такую простую визуализацию.

• Первый график – это обычный проект, не кризисный. У него все хорошо.

  • Красная линия – это развитие окружения проекта: требования и настроение заказчика, интенсивность работы.

  • Зеленая – это развитие самого проекта: то, как работает его команда, как реагирует на изменения окружения система управления. В обычном проекте все примерно сочетается – зеленая и красная линии идут примерно одинаково.

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

• Третий график – кризисный проект второго типа, в нем кризис нарастает постепенно, расширяется в течение определенного времени. Проект не поспевает за окружающей средой. Это самые сложные проекты, потому что все зависит от вопроса, когда кто-то встанет и скажет: «А король-то голый! У нас на проекте кризис!» Эта ситуация может развиваться месяцами – за это время больной может стать уже неоперабельным.

• И четвертый график – кризисный проект третьего типа. Это когда проекты сразу запускаются как кризисные – сразу разрыв, срочно надо сделать то, что сделать нельзя, но нам надо. Здесь нет такого, чтобы сначала довести до кризиса, а потом решать проблемы – проект сразу запускается как кризисный. Раньше такие проекты назывались мобилизационными, сейчас их чаще называют форсированными.

Опрос

На слайде – результаты небольшого интерактива с залом в процессе доклада.

Первый вопрос – разминочный: «Какое у вас настроение и уровень энергии?»

Второй вопрос: «Участвовали ли вы в кризисных проектах?»

Судя по ответам, тема выглядит достаточно актуальной:

• Большинство прошедших опрос с кризисными проектами сталкивалось.

• Два человека – не проектные.

• И еще несколько человек вообще не сталкивались.

Третий вопрос: «А в каких видах кризисных проектов из тех, что были описаны ранее, вы участвовали?»

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

Последний вопрос: «Какая эмоция у вас возникает, когда вам говорят, что надо поучаствовать в кризисном проекте?»

«Опять», «боль», «вызов», «надо»... Общая идея понятна: «стресс», «усталость», «опять спасать», «грусть» и остальное.

Давайте сойдемся на слове «ВЫЗОВ». Оно не самое большое, но прочитать самое большое слово мне, к сожалению, не позволяют профессорские принципы.

Дальше я буду говорить про кризисные проекты.

Но у меня есть отдельная схерамка по более форсированным проектам. Кому интересно, мы с коллегами из РАНХиГС написали «Форсированные мегапроекты. Российский опыт двух столетий». Мы посмотрели большие проекты, которые запускались в форсированном режиме в самых разных периодах истории нашей страны. И посмотрели на них через призму современных управленческих рамок. Если интересуетесь темой форсированных проектов, рекомендую.

Кейс

А сейчас я хочу рассказать вам о крупном кризисном проекте второго типа.

История проекта описана в статье на Инфостарте. Она довольно типичная. Региональная компания, которая занимается торговлей нефтепродуктами – 14 нефтебаз. Располагается в основном в Красноярском крае, 1603 сотрудника – хорошая, крепкая региональная компания.

137 автостанций, 370 резервуаров для хранения нефтепродуктов. Большие материальные объемы, есть что учитывать.

Вызвали партнера фирмы «1С» – компанию «БИТ:ERP», с просьбой автоматизировать свою деятельность.

Компания «БИТ:ERP» небольшая – 25 сотрудников, распределенных в разных часовых поясах, обычно делает 2-3 крупных проекта одновременно. И есть небольшая линейка своих продуктов.

Попросили сделать достаточно типовой проект – внедрить систему на базе 1С:ERP.

Контур автоматизации широкий: нужно запустить процессы закупок, продаж, склад, учет, казначейство, автотранспорт.

Плюс еще нужно сынтегрировать все это с внешними существующими системами – ЗУП, УАТ и т.д.

И немного доработать функциональность – реализовать «с нуля» отдельный модуль для управления сетями нефтебаз и АЗС, потому что есть бизнес-специфика.

Причем запустить систему нужно во всех филиалах одновременно – в единой облачной базе на 200 пользователей.

Что происходило и как развивалась ситуация:

• Ноябрь 2015 года – запустили проект.

• К маю 2016 года система была готова. Завершили проектирование. Проектное решение было утверждено заказчиком, разработку завершили, тестирование провели. Заказчик дал свои замечания – их исправили, обучили пользователей.

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

• Заказчик принял решение закрыть отношения с исполнителем и отсудить деньги.

• При попытке найти других исполнителей, кто бы еще мог взяться за эту историю, выяснилось, что активистов, которые готовы без денег с нуля взять что-то, что кто-то проектировал, и поправить, нет. Все говорят: «Мы готовы взяться, но только с самого начала». Опять обследование, проектирование и новые деньги, а 60% денег уже потрачено. Понятно, что это произошло не одномоментно. Это выглядит как проект первого типа, но на самом деле это проект второго типа. Явным образом шло расхождение, но в какой-то момент выяснилось, что так дальше идти не может.

• Закончилось все тем, что финансовый директор, спонсор проекта, пригласил руководителя проекта от исполнителя на встречу и задал ему простой вопрос: «Что вы можете предложить в этой ситуации? Мы так понимаем, что найти другого исполнителя нам будет сложно. Давайте дадим вам еще один шанс. Что сделаете?» Исполнитель сказал: «Мы перестроим работу и сделаем все как надо».

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

• Инструменты визуализации стейкхолдеров (Матрица влияние/интерес, тепловая карта, луковичная диаграмма и т.д.)

• Специальная система мотивации участников проекта

• Демо день проекта изменений с демонстрацией промежуточных результатов

• Матрица (реестр) рисков и проблем

• Церемонии Scrum: Планирование спринта, Ежедневный скрам (летучка), Ретроспектива

• Прописанный механизм (процедура) приемки результатов

• Матрица распределения ответственности (RACI)

• Сценарии использования (Use cases)

• Карта влияния (Impact map)

• Ресурсный план, включающий представителей Заказчика

• Создание детального плана проекта в MS Project

• «Бесконечные доски» (Miro, Mural)

Возможные оценки:

• 1 – непонятно, можно ли использовать этот инструмент, информации недостаточно;

• 2 – точно не нужно;

• 3 – скорее не нужно;

• 4 – скорее нужно;

• 5 – точно нужно.

По результатам опроса аудитории доклада:

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

• Не очень популярна система мотивации участников и идея визуализации для зон интересов и влияния стейкхолдеров.

• И совсем не востребована тема бесконечных досок.

Но в целом, если все это обобщить, то большинство выступает за итеративный подход с использованием Agile-инструментов.

Вы не расстраивайтесь, если вы какие-то инструменты не знаете, есть еще одна ссылка – мы с коллегой Андреем Малаховым сделали базу рабочих инструментов и знаний.

Если какие-то из инструментов вам неизвестны, можно зайти на сайт https://brizpm.ru/ и посмотреть описание. Обязательно посмотрите, очень хороший инструмент.

Возвращаясь к кейсу. Чтобы вывести проект из кризиса, коллеги переключились в режим работы по итерациям и включили инструменты Scrum. Но это был не чистый Scrum – они фактически совместили классику с Agile. Они дали заказчику дорожную карту выхода из ситуации, но внутри дорожной карты сделали спринты по Scrum:

• велся бэклог продукта;

• они разбили работу на части, которые были связаны с интеграцией модулей между собой;

• регулярно проводили демонстрации заказчику – они, как и большинство в опросе, совершенно правильно выбрали регулярные демонстрации;

• и проводили регулярные разборы полетов.

Я считаю, что коллеги большие молодцы. Но как вы думаете, что меня смутило как специалиста по управлению, когда я смотрел на управленческие инструменты, которые применяются?

• В управлении проектом самое важное – это управленческие инструменты, которые выделены справа маленькими кружочками.

• А вот Slack, Confluence, Jira – это прекрасно, но это только ИТ-инструменты, чисто айтишный подход, только одна из частей, которые есть в системе управления.

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

Что получилось в результате?

• Они перезагрузились в июне 2016 года, перешли на этот микс – они называли это Scrum, хотя Scrum бы их не одобрил.

• Через два месяца, в августе 2016 года, смогли перейти на уже промышленную эксплуатацию системы.

• В мае 2017 года окончательно закрыли проект – проект реально вытащили.

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

Ключевые итоги

Ключевые выводы доклада:

• Любой проект может попасть в кризис – это никому не зазорно.

• Если проектом управлять правильно, шансы попасть в кризис намного меньше.

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

Условия успеха проекта:

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

• Должен найтись лидер. Это принципиально. Scrum, самоорганизация команды – это все чудесно, но на тонущей подводной лодке демократии нет. Должен быть капитан, который берет на себя ответственность за спасение этого проекта.

• Лидер должен перестроить систему управления.

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

У нас шел нормальный проект, возник кризис – мы можем или закрыть проект, или перейти в формат кризисного управления, который подразумевает четыре шага:

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

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

3. Но если все-таки решили спасать, дальше будет стабилизация ситуации.

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

На слайде показаны элементы системы управления в кризисной ситуации.

Перечислю очень коротко:

• Помните, я говорил, что ИТ-инструменты – это не главное, здесь в списке ИТ-инструменты – третьи снизу. Надо использовать то, что есть. У вас не будет возможности заявить: «А давайте внедрим Jira. Мы никогда ею не пользовались, но раз у нас кризис, наверное, нам в кризис Jira поможет». Не поможет.

• Самое главное в кризисном проекте – это оргструктура и роли. Сделать штаб проекта – это ситуационный центр, который будет быстро принимать решения, распределить ответственность и выдать мандаты. Революционные комиссары ходили с мандатами: «Податель сего может делать то, что нужно для блага революции». Очень важно именно эту организационную часть решить.

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

  • вы должны контролировать проект здесь и сейчас, чтобы эта подводная лодка не потонула;

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

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

• Церемонии – это частые встречи

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

И если интересно посмотреть предварительные результаты фреймворка, схему-рамку по антикризисным проектам, у меня об этом было выступление «Кризисные проекты. Как вытащить бегемота из болота?!» – там я более подробно рассказываю о необходимых действиях для управления в кризисных ситуациях.

Вопросы и ответы

Что делать, если бизнес не готов сказать, что проект кризисный, все плохо и все горит?

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

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

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

Здесь у науки есть ответ. Самый лучший инструмент проектного управления, который работает в российских условиях и позволяет такие истории охватить заранее – это система контрольных точек с прогнозированием рисков.

Вы ставите промежуточные контрольные точки, а потом каждый ответственный за контрольную точку дает прогноз. Красный, желтый, зеленый – три цвета:

• зеленый – зуб даю, все будет сделано вовремя;

• желтый – есть определенные сложности;

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

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

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

Если возвращаться к началу, где вы показывали статистику по результатам Standish Group «CHAOS Chronicles». Вы умолчали, что этот рост на самом деле за счет применения Agile. И в вашем примере тоже решением явилась практика Agile. Так может, с этого надо начинать? Раз Agile такой клевый, давайте сразу начнем с него.

500 лет назад жил очень умный человек. Его звали Макиавелли. Он сказал: «Ничто не хорошо и не плохо само по себе. Все зависит от обстоятельств».

Agile – прекрасный инструмент, но, как показывает уже многолетняя практика внедрения в России, работающий не у всех, не во всем и не везде.

На эту тему у меня есть отдельные выступления и доклады. И не только у меня – было интересное канадское исследование про то, является ли гибрид плохим вторым шансом. Это ровно в рамках вашего вопроса.

• Первый шанс: «Если сдать проект по каскаду не получается, давайте возьмем Agile».

• И второй шанс: «Ну если и по Agile не получается, давайте возьмем гибрид».

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

В приложении к PMBOK 6, где есть 9 вопросов, по которым можно оценить, нужно ли применять на проекте Agile. Например, вопросы:

• Есть ли у тебя профессиональная команда, которая сама знает, что делать?

• Готов ли заказчик принимать продукт частями? Обратите внимание, в приведенном примере проекта он стал готов не сразу. Он вряд ли согласился бы изначально, если бы ему сказали: «Мы тебя будем каждые 2 недели дергать и что-то показывать». Он вполне мог сказать: «Да идите вы нафиг, ребята, я вам не за это плачу, чтобы вы меня дергали. Вы меня спросите, я скажу, а вы сами делаете. Вы что, не профессионалы?»

• И остальные 7 параметров.

Только если ответ на все вопросы – «Да», имеет смысл применять Agile.

Agile не является панацеей, это не серебряная пуля.

По опыту могу сказать, что Agile точно хорошо работает только в двух вещах – это R&D и цифровые продукты, те, которые надолго.

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

Хорошая метафора. К сожалению, единого ответа дать невозможно. Есть такое понятие Risk Tolerance – толерантность к риску, насколько долго мы готовы зажмуриваться и насколько много к нам поступает информации.

В этой ситуации помогает система контрольных точек. Мы так сделали Олимпийские игры. За 7 лет до игр МОК нам дал штуку, которая называется Generic Master Schedule, мастер-план подготовки к играм. Тысяча контрольных точек: за 7 лет до игр должно быть сделано это, за 5 лет – это, за 3 – это, за год – это, и так далее. Причем они не только дали нам этот план, они еще и контролировали его. Это было вообще возмутительно и очень напряжно для коллектива.

Они говорили: «За 5 лет до игр должна быть концепция билетной программы». Мы уверяли, что когда-нибудь сделаем. Они спрашивали: «О, у вас есть какие-то сложности?». Мы говорим: «Да, столько сложностей». Они говорят: «Давайте тогда при встрече наверху мы скажем, что вам нужна помощь?» Мы как представили, что на нас обрушится сверху, сразу сказали: «Не-не-не, никакой помощи не надо. Мы сейчас все сделаем».

Когда ты понимаешь, что пропущенные контрольные точки – это повод напрячься, закипающая вода прямо видна, и ее очень сложно игнорировать.

Если ты собираешь информацию по проекту раз в неделю и видишь, что пропущены такие-то контрольные точки, то какой бы ни был Risk Tolerance, в какой-то момент становится понятно, что дальше так не получится.

А если все время хочется верить, что все хорошо, то гораздо позже может оказаться, что ты уже сварился.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.