Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Марк позвонил мне в конце 2017 года, чтобы сказать, что они не только сделали это, но и что все вышло иначе, чем если бы они действовали традиционными методами. Традиционный способ управления проектами в Scrum – каскадная модель. При ее использовании руководители стараются распланировать весь проект до его начала. Собираются все возможные требования – иногда их тысячи. Я видел документы с требованиями, стопка которых, если их распечатать, в высоту достигала метра. Подписывая ее, люди пребывают во взаимно согласованной иллюзии о том, что кто-то действительно прочел все это, и только потом команда менеджеров проекта делит работу на фазы. «Сначала мы сделаем эту часть, – говорят они, – и это займет две недели». И рисуют полосочку в верхней части диаграммы Ганта[12]. «Затем мы приступим к следующей фазе; она займет два месяца». Тут они рисуют еще одну полоску на графике, ниже и правее предыдущей. И так далее. Похоже на очень красивый водопад. Эта цветная диаграмма может тянуться месяцами, даже годами. Я видел такие графики высотой тридцать сантиметров и длиной несколько метров. Они в самом деле бывают произведением искусства. Восхитительно. Но они всегда ошибаются. Всегда. Ведь ничто не идет по плану. Никогда. Всегда что-то случается, и приходится менять график. То, что нужно, не поставляется вовремя. Проект затягивается. А значит, и диаграмма неверна. Но она не может быть неверна. Поэтому компании нанимают людей, чтобы диаграмма выглядела реальной, ведь реальность меняется. Это базовый человеческий недостаток: «Если я хорошо подумаю над этим, я смогу устранить ошибку». Но это иллюзия контроля.

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

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

У каждого владельца продукта была команда. Или команда команд. Марк сказал, что только отделы IT-исследований и разработок использовали Scrum в полной мере. Такой уровень координации все равно оказался крайне важным для проекта. Что было главным? Владельцы продуктов постоянно собирались вместе, чтобы координировать усилия, делиться знаниями, обращаться друг к другу за помощью и изменять приоритет элементов бэклога по мере поступления новой информации. Например, если финансовому отделу нужны были данные по зарплатам, они обращались к бэклогу продукта за полной интеграцией, и каждая команда получала данные о том, что ей нужно сделать, чтобы ее часть работы считалась готовой.

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

Они работали недельными спринтами. Каждую среду они просматривали бэклог, определяли приоритетность задач на следующую неделю, оценивали усилия, необходимые для реализации каждого элемента, который, по их мнению, они могут выполнить за один спринт, и начинали работу. Они не всё делали так, как я рассказывал: отводили на ежедневный Scrum по 15 минут трижды в неделю, а не каждый день. Так, они встречались по пятницам, чтобы сообщить, что все в порядке, затем собирались в понедельник. И каждую среду, прежде чем планировать следующую неделю, они проверяли, сколько работы готово на самом деле из того, что было запланировано.

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

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