Руководители проектов в MegaEnergy поддерживали осведомленность заинтересованных лиц и руководства, информируя их о ходе проекта с помощью периодических отчетов. Поскольку традиционные проекты управляются на уровне задач, в этих отчетах описывался процент завершенных задач, отставание от графика, возникшие проблемы и предлагаемые меры реагирования, текущие риски и рекомендуемые способы снижения их вероятности и влияния. Поскольку задачи имеют лишь косвенное отношение к желаемой пользователями функциональности, эти отчеты скорее расстраивали заинтересованных лиц, чем приносили пользу. Затем для отслеживания прогресса в MegaEnergy начали использовать отображение плана проекта в виде диаграммы Ганта. Это ключевой инструмент в управлении проектами на уровне задач. Выявив необходимые задачи, зависимости между ними, исполнителей и ресурсы, с его помощью можно определить итоговый срок завершения проекта и следить за его отклонениями от плана.
На протяжении многих лет в MegaEnergy применялся устоявшийся, очень традиционный и формальный процесс управления проектами, разработанный офисом управления программами, в котором работали высокопоставленные сотрудники, ранее руководившие проектом строительства трубопроводов. Диаграмма Ганта была для них святым Граалем для планирования и контроля над проектом. После первого провала проекта «Участок» они решили повысить степень детальности начального планирования и ужесточить процесс контроля изменений при второй попытке. Они полагали, что первый проект потерпел неудачу, потому что руководство допустило слишком много изменений в первоначальном плане. Услышав это, я вспомнил о данном Эйнштейном определении безумия: повторять одно и то же снова и снова и ожидать других результатов. Удивительно, но это очень распространенный подход. Если управляемый предопределенным подходом проект терпит неудачу, люди часто винят в этом недостаточно строгое следование этому же подходу и делают вывод, что для успеха очередной попытки необходимо лишь усилить контроль и повысить четкость артефактов проекта.
Высшее руководство, в том числе управляющий комитет проекта «Участок» и офис управления проектами, знали, что во время третьей попытки будет опробовано что-то новое. При этом работающие в офисе управления программами люди не были знакомы ни с управлением эмпирическим процессом, ни со скрамом. Однако они не возражали против нового подхода, если проект будет контролироваться принятым в MegaEnergy способом – с помощью диаграмм Ганта.
Это подкинуло нам задачку. Должны ли мы проводить обучение высшего руководства скраму, включая сотрудников офиса управления программами? Должны ли мы сообщить им о радикально ином подходе, который мы собрались использовать в проекте «Участок»? Должны ли мы вступить с ними в долгую дискуссию о различиях в управлении предопределенным и эмпирическим процессами? Мы знали, что эта дискуссия будет эмоциональной, ведь офис управления программами имел большую историю успеха в MegaEnergy. Их подход использовался для управления гораздо более массивными проектами, чем проект «Участок», а причиной неудач предыдущих двух попыток называли человеческие ошибки, а не недостатки процесса. Как убедить их в обратном?
В скраме менеджеры измеряют и отслеживают требования, а не задачи. Требования перечислены в порядке приоритета в бэклоге продукта и сгруппированы в предполагаемые спринты и релизы. Бэклог продукта в начале спринта отличается от бэклога продукта в начале следующего спринта, поскольку окружающие бизнес-условия могут привести к его изменению или переупорядочению. Некоторые элементы бэклога могут быть не завершены в ходе спринта и перенесены в следующий спринт. Первоначально запланированный состав релиза продукта может быть изменен: владелец продукта вправе добавить, перегруппировать, изменить или удалить требования из состава релиза. Предварительно запланированные спринты могут изменить свой состав: элементы могут быть добавлены или удалены из бэклогов спринтов, поскольку появляются новые сведения о размерах отдельных элементов, их приоритетах или о производительности команд разработки.
Для большинства заинтересованных лиц и руководителей отчеты в скраме сдвигают привычную парадигму. Обычно базовый план фиксируется, а любые отклонения от плана рассматриваются как нежелательные. Периодические отчеты руководству показывают, насколько фактическое состояние проекта соответствует базовому плану. Вместо этого скрам сообщает о несоответствиях плану, реакциях на эти несоответствия и влиянии на план проекта. Скрам приветствует изменения и предоставляет отчеты, отслеживающие изменения и их влияние на проект.