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