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

Снова вспомним основателя производственной системы Toyota Тайити Оно. Он придумал классификацию потерь – вещей, которые замедляют систему. Он разделил их на три группы: м у да, мура и мури. «М у да» переводится с японского как «отсутствие результатов» – незаконченная работа. «Мура» – «непостоянство, неравенство»; изначально это термин из ткацкого производства, который относится к зацепкам на ткани. «Мури» – «отсутствие причины». В эти три группы входит все, что мешает выполнению работы, например перепроизводство, ожидание, логистика, абсурдные ожидания и т. д.

Худшим типом потерь для Оно, в любом контексте, было незаконченное производство. Часто его называют незавершенной работой (Work-in-progress, WIP). Это худшая форма потерь, поскольку вы тратите время, деньги и усилия, но ничего не получаете взамен. Работа не доводится до готовности.

Решение проблемы – переход к тому, что Оно называет «производством по принципу непрерывного потока», а я – «сделать дело, и быстро». У любой scrum-команды в бэклоге есть 10–20 элементов, которые они обязались выполнить за спринт. И почти в каждой компании, куда я приходил, все эти элементы начинали выполнять, но ни одного не доводили до готовности.

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

Представьте себе экипаж механиков «Формулы-1». Если вы ни разу не видели, как они работают, изучите видео в интернете. Впечатляет. Гоночный автомобиль въезжает на заправочно-ремонтный пункт и полностью останавливается. Когда гоночный болид тормозит, он тут же отстает от гонки, поэтому команде нужно починить и выкатить машину обратно на трассу настолько быстро, насколько возможно. Как только машина с визгом останавливается, двадцать человек немедленно принимаются за работу. Чтобы поменять колесо, нужна слаженная работа трех человек: один с помощью пневматического пистолета снимает болты, удерживающие покрышку, второй снимает колесо, третий надевает новое. Важна каждая десятая доля секунды. А это только колеса; другие люди регулируют автомобиль, заправляют его, производят все манипуляции, необходимые для того, чтобы уже через несколько секунд вытолкнуть машину обратно на трассу.

В этом суть методики роя – полная концентрация команды на доставке ценности, возвращении машины на трассу. И того же вы хотите от своих scrum-команд.

Тэмми признаёт, что в 3M HIS у команд еще есть проблемы с кросс-функциональностью и использованием методики роя. Команды, которые работают над их облачными сервисами, могут это делать, поскольку так было задумано изначально. В унаследованной ими системе невероятно сложно разделять работу.

«Закон Конвея, верно», – говорит она. Продукт отражает организационную архитектуру. Но они вносят изменения. В 3M HIS сейчас намного меньше подразделений, все команды отчитываются перед отделами исследований и разработки и уже не разнесены по всей компании. Они вкладывают значительные силы и средства в переход к облачным технологиям и в создание моделей услуг. Но на все это нужно время. За один день такого не сделаешь.

«Когда я думаю о нашей трансформации, – задумчиво говорит Тэмми, – я вспоминаю о том, как вы постоянно говорили, что это путешествие. Первый год или два все действительно воодушевлены. А потом становится сложно». Они в ударе, поскольку сначала решаются простые проблемы. Затем вы сталкиваетесь со сложными: структурой организации, архитектурой продукта. Вы движетесь вперед, у вас есть большие планы на трансформацию. Но это не всегда легко.

[36]

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

Именно поэтому четко выделите время на неожиданности и не берите больше работы, чем та, что укладывается в обозначенные границы. Если работа превышает отведенные рамки, отмените спринт [37].

Алекс Шейв – один из коучей в Scrum Inc. Впервые он столкнулся со Scrum около десяти лет назад. Он говорит, что когда увидел шаблон буфера на отвлечения, то сразу понял, что должен так работать. В июле 2007 года его наняли в компанию финансовых услуг – не лучший карьерный ход на тот момент. Тогда финансовый рынок США столкнулся с рекордным обвалом впервые со времен Великой депрессии. Шейв присоединился к команде, которая создавала инструменты для трейдеров, и оказался в том же кабинете, что и ведущий разработчик команды. Сосед по офису был хорошим парнем – они поладили и оба усердно трудились. Менялось то, над чем они работали. Причем часто. Однажды один из семи партнеров компании говорил: «Вот это важнее всего». А через неделю или даже на следующий день другой партнер мог захотеть что-то совершенно другое. Не слишком много сфокусированности. Но Алекс не задумывался над этим. Его команда выполняла запросы и не слышала в свой адрес ничего, кроме похвал.

Затем пришло время ежегодных отчетов. Его сосед по офису вернулся с отчетной встречи, хлопнул дверью и ударил головой по их общему столу. В начале года команде поручили огромный и важный проект, который за все это время не сдвинулся ни на йоту. Поскольку он был ведущим разработчиком, руководитель отчитал его и сказал, что в этом году они «эффективно добились ничего». Для Алекса самым странным в ситуации было то, что они трудились вместе, в одной комнате, в одной команде, полгода, все время говорили о работе, жаловались на нее, но он ни разу не слышал об этом проекте. Они усердно трудились и делали то, что их просили. Никто из партнеров не хотел саботировать проект; они просто не понимали, что, отвлекая их важными запросами, они создали условия, в которых команда не смогла даже сфокусироваться на проекте, не говоря уже о том, чтобы закончить его. Взяли ли они на себя ответственность за свои действия? Нет. В фиаско они винили ведущего разработчика.

Я слишком часто вижу такие ситуации. Менеджмент, продажи, поддержка постоянно отвлекают команды и просят их бросить все, чтобы выполнить одну важную задачу, которая только что появилась. Затем, когда они отправляются на обзор спринта, конечно, ничего не сделано. И менеджеры думают, что команда непроизводительна.

Решение этой и многих других проблем в Scrum – сделать стоимость решений наглядной. Иногда и правда возникают чрезвычайные ситуации, с которыми нужно справляться немедленно. Но не все ситуации такие. Именно поэтому команде не нужно загружать себя полностью, лучше выделить часть времени на формирование буфера на отвлечения. Допустим, обычно команда доводит до готовности 20 элементов бэклога за спринт. Значит, в следующем спринте им нужно взять 15 элементов, оставив резерв для подстраховки.