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

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

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

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

Давайте посмотрим, какую информацию о статусе проектов по скраму использовали разные компании. В MegaEnergy мы увидим переход от традиционного отслеживания исполнения работ к отчетности в духе скрама, хотя руководству были неудобны новые способы отслеживания прогресса. Руководителю MegaBank, финансирующему проект, не нравились периодические отчеты скрама. Он хотел получить обобщенное графическое представление о прогрессе проекта. Мы посмотрим, каким образом эта потребность была удовлетворена. В Service1st отчеты участников команды разработки во время ежедневного скрама были настолько общими и абстрактными, что это 15-минутное событие казалось практически бессмысленным. Мы рассмотрим, почему это произошло, и обсудим, как обеспечить достаточный объем информации и деталей в отчетах.

Компания MegaEnergy познакомилась со скрамом через пилотный проект по учету земельных участков, который рассматривался во второй главе. Этот проект уже дважды стартовал и завершался без результатов. ИТ-директор узнал о скраме и убедил своих коллег-менеджеров попробовать. Они считали, что проект по учету земельных участков станет хорошей возможностью оценить применимость скрама в организации: если скрам поможет исправить ситуацию, то будет считаться достойным дальнейших проб в других проектах MegaEnergy.

Команда проекта в MegaEnergy создавала внутренние артефакты: технические задания, архитектуры, модели, код. Если проект не стопорился на разработке этих артефактов, то в самом конце они объединялись и превращались в рабочую систему. Только тогда заинтересованные лица могли увидеть то, что будут в дальнейшем использовать. Заинтересованные лица – это те, кто заинтересован в результатах проекта, включая тех, кто финансирует проект, и тех, кто будет пользоваться разрабатываемой системой.

Руководители проектов в MegaEnergy поддерживали осведомленность заинтересованных лиц и руководства, информируя их о ходе проекта с помощью периодических отчетов. Поскольку традиционные проекты управляются на уровне задач, в этих отчетах описывался процент завершенных задач, отставание от графика, возникшие проблемы и предлагаемые меры реагирования, текущие риски и рекомендуемые способы снижения их вероятности и влияния. Поскольку задачи имеют лишь косвенное отношение к желаемой пользователями функциональности, эти отчеты скорее расстраивали заинтересованных лиц, чем приносили пользу. Затем для отслеживания прогресса в MegaEnergy начали использовать отображение плана проекта в виде диаграммы Ганта. Это ключевой инструмент в управлении проектами на уровне задач. Выявив необходимые задачи, зависимости между ними, исполнителей и ресурсы, с его помощью можно определить итоговый срок завершения проекта и следить за его отклонениями от плана.

На протяжении многих лет в MegaEnergy применялся устоявшийся, очень традиционный и формальный процесс управления проектами, разработанный офисом управления программами, в котором работали высокопоставленные сотрудники, ранее руководившие проектом строительства трубопроводов. Диаграмма Ганта была для них святым Граалем для планирования и контроля над проектом. После первого провала проекта «Участок» они решили повысить степень детальности начального планирования и ужесточить процесс контроля изменений при второй попытке. Они полагали, что первый проект потерпел неудачу, потому что руководство допустило слишком много изменений в первоначальном плане. Услышав это, я вспомнил о данном Эйнштейном определении безумия: повторять одно и то же снова и снова и ожидать других результатов. Удивительно, но это очень распространенный подход. Если управляемый предопределенным подходом проект терпит неудачу, люди часто винят в этом недостаточно строгое следование этому же подходу и делают вывод, что для успеха очередной попытки необходимо лишь усилить контроль и повысить четкость артефактов проекта.

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

Это подкинуло нам задачку. Должны ли мы проводить обучение высшего руководства скраму, включая сотрудников офиса управления программами? Должны ли мы сообщить им о радикально ином подходе, который мы собрались использовать в проекте «Участок»? Должны ли мы вступить с ними в долгую дискуссию о различиях в управлении предопределенным и эмпирическим процессами? Мы знали, что эта дискуссия будет эмоциональной, ведь офис управления программами имел большую историю успеха в MegaEnergy. Их подход использовался для управления гораздо более массивными проектами, чем проект «Участок», а причиной неудач предыдущих двух попыток называли человеческие ошибки, а не недостатки процесса. Как убедить их в обратном?

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