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

Измеряйте совещания

Предположим, вам нужно принять решение. Вы договариваетесь о совещании. Допустим, на встрече двадцать человек и решение принимается за час. Спросите себя: во сколько оно обошлось? Посчитаем стоимость одного только времени: сколько денег вы потратили за час. А теперь посчитаем все бесполезные совещания, которые прошли у вас на этой неделе.

Мой друг раньше работал в университете из Лиги плюща. Иногда он говорил мне, что приходит на совещания, даже не зная, зачем он там. А если и знает, то совещания длятся вечность. Упражнения ради мы решили посчитать. Каждая встреча, по нашим выкладкам, стоила около тысячи долларов. За ту неделю он был по меньшей мере на десяти – пятнадцати совещаниях. Делаем выводы.

На деле все даже хуже: решения, которые принимаются на совещаниях, с высокой вероятностью будут отклонены. По данным Standish Group, так происходит более чем с 40 % подобных решений. Предположим, решение принимается за одно совещание и мероприятия проходят раз в неделю. За неделю первое решение уже начинает внедряться, а каждый из тех, кто его принял, передумал. Принимается новое. Это не только потеря недели времени, но и переделка всей уже выполненной работы. Все равно что копать ямы и тут же их засыпать. Сизифов труд.

Согласно исследованию Standish Group, это случается по двум причинам: из-за тех, кто был на совещании, и тех, кого там не было. Решение, к которому приходят в комнате, обычно принимается самым громким человеком в аудитории. Он бульдозером едет по всем, кто стоит на пути. И когда совещание закончено и люди возвращаются к своим рабочим местам, они порой говорят: «Хм, по здравом размышлении я не вполне согласен с тем решением. На следующей неделе подниму этот вопрос».

А еще есть те, кто не пришел на совещание. Возможно, они и не должны были, но чувствуют, будто им это необходимо. Почему их не спросили? В следующий раз они определенно придут, чтобы быть услышанными.

По словам Джима Джонсона, каждый раз проект становится на день ближе к провалу. Каждый день задержки повышает вероятность неудачи. По дню за раз: медленный марш к катастрофе.

Какие решения принимать

Scrum направлен на поиск того, что нас замедляет. Он показывает такие факторы. Подносит их к свету. Конечно, когда проблемы продолжают возникать от спринта к спринту, а команда справедливо ожидает, что они начнут решаться, некоторые говорят, что проблема в Scrum, а не в самой неполадке. И они всегда неправы.

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

Один из радикальных примеров проталкивания решений – компания Mirai Industry. Она производит оборудование для электромонтажа: распределительные блоки, кабели, изоляторы и т. п. В отличие от большинства японских компаний, она не следует ринги полностью. Основал компанию и долгое время занимал пост CEO до самой своей смерти 30 июля 2014 года Акио Ямада. Он считал, что сама идея ринги несуразна, и запретил ею пользоваться. «Делайте свою работу так, как считаете нужным, – говорил он своим сотрудникам. – Пусть те, кто выполняет работу, принимают решения». «Я дурак, – писал Ямада в своей книге The Happiest Company to Work For («Самая счастливая компания для работников»). – Как же я могу решать?» Он часто узнавал о новых офисах продаж, открывающихся в Японии, только когда видел чью-то новую бизнес-карту. Сотрудники сами решали, запустить ли новый офис, снимали помещение в здании, нанимали и обучали новичков. Если бы Ямада не позволил людям самим принимать решения, они бы тратили уйму энергии, убеждая руководителей в том, чего те просто не понимали.

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

Я знаю совет одного крупного банка, в котором более сорока человек. Это комитет управления рисками, и любое предложение по любому вопросу должно получить его одобрение. Члены совета часами спорят на убийственно длинных телефонных конференциях. К тому времени, как они принимают решение, становится уже неясно, кто предложил идею и какую проблему надо решить в первую очередь. Именно поэтому никого не могут обвинить, если решение окажется плохим. Комитет был создан, чтобы защитить банк, который до этого принял несколько неосмотрительных решений и в результате был оштрафован государством на десятки миллионов долларов. Руководители не хотели, чтобы это случилось снова. Именно поэтому они собрали всех этих важных людей в комитет, как будто заявив регулирующим структурам: «Смотрите, наш руководитель убеждается, что мы не будем больше так делать». Однако комитет управления рисками остановил не только плохие решения, а все скопом. Теперь принятие решения может занять месяцы. А когда эти десятки людей его наконец одобряют, оказывается, что в него инвестировано столько политического капитала, что оно просто не может оказаться неверным. Это невозможно, учитывая, сколько менеджеров высшего звена бросили свои интеллектуальные ресурсы на решение проблемы. Должно быть, в неудаче виноваты те скверные люди, которые работают на местах и не смогли внедрить решение. В финансовом секторе невероятно часто встречаются комитеты управления рисками такого типа, к сожалению.

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

Здесь такое не сработает

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

Я часто провожу открытые занятия. И поражаюсь тому, насколько разные люди туда приходят. Банкиры, производители, издатели, создатели биопрепаратов для исследователей, поставщики услуг, преподаватели, работники НКО. Мои студенты почти всегда представляют многообразие индустрий, специальностей и ролей.

Но если вы один из скептиков, то я поделюсь с вами историей человека, который применил Scrum там, где ставки намного выше, движение быстрее, а право на ошибку намного меньше, чем в том, чем вы занимаетесь. Скорее всего.

Коммандер военно-морского флота США Джон Хаас связался со мной пару лет назад. Незадолго до того он принял командование подразделением с супом из букв вместо названия, EODMU2 (Explosive Ordnance Disposal Mobile Unit 2, или Мобильный отряд по обезвреживанию боеприпасов № 2), и хотел использовать Scrum в своем подразделении. Он желал двигаться быстрее, с лучшим качеством в одной из самых требовательных сред на планете.

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

Джон решил управлять своей командой, к которой предъявляются одни из самых высоких требований в армии, с помощью Scrum. Учитывая специфику деятельности, у людей вроде Джона редко берут интервью. Однако я отправил ему список из дюжины вопросов о Scrum и его работе. Он согласился ответить на девять из них по электронной почте. Я не хочу переиначивать его слова, поэтому поделюсь с вами письмом, которое он мне прислал.

Ответ начинается с такой ремарки.

Высказанное в данном письме мнение принадлежит его автору и необязательно представляет точку зрения Экспедиционного боевого командования военно-морского флота, Министерства ВМС, Министерства обороны или Правительства США.

Когда вы впервые узнали о Scrum?

Впервые я услышал о Scrum, когда готовился к службе на командной должности. Я связался с менторами и составил список литературы с информацией по лидерству, управлению, коммуникации, эмоциональному интеллекту и т. д. Именно тогда я нашел упоминания о Scrum. Когда я увидел название, я решил узнать больше, изучив книгу «Scrum. Революционный метод управления проектами». Это было примерно два года назад, и тогда я занялся изучением Agile и фреймворка Scrum.

Что вдохновило вас использовать Scrum для отряда по обезвреживанию боеприпасов?

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

Внедрение Scrum соответствовало всем этим требованиям.

Чтобы начать эксперимент, не требовалось вложения средств; внедрение Scrum было сопряжено с низкими рисками; он носил временный характер, и его легко было бы отменить, если бы он оказался неэффективен; в него были встроены такие метрики, как скорость для оценки эффективности. Измеряя продуктивность еженедельно, можно отслеживать изменения показателей скорости команды.

Как вы структурировали Scrum? Что вы использовали?

Мы структурировали работу, последовательно внедряя Scrum – все роли, события и артефакты фреймворка. Scrum-мастером стал наш строевой офицер корабельной службы, владельцем продукта – командир корабля, а в команду вошли остальные ключевые штабные должности. Состав группы менялся со временем, и мы в итоге поняли, какие продукты поддерживает каждый член командования.

Вы сразу увидели результат?

Сначала команда показывала скорость 4 балла в день, но показатель стабильно рос до 50 баллов в день. Сразу же улучшились коммуникации, приоритизация, выполнение задач.

Какие элементы стали наиболее значимыми? Почему?

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

Временные рамки также стали неотъемлемой частью нашей жизни.

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

Можете привести пример того, что вы не могли сделать ранее, но чего добились с помощью Scrum?

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

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

Что вызывало сложности? Вы что-то меняли?

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

Пройдемся по спринту. Как и где проходило каждое событие?

Спринт начинается в понедельник утром, когда мы собираемся все вместе на встрече по синхронизации. Это позволяет нам получить обратную связь от всех команд, служащих под общим командованием.

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

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

Изменится ли что-то после того, как ваша служба завершится?

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

Задумайтесь над тем, что вы только что прочли. Оставим в стороне военный контекст и сосредоточимся на основных пунктах. Это не армейская дисциплина, это пример работы Scrum в сложной, запутанной и непредсказуемой среде.

Хаас и его команда всегда были высококвалифицированны и мотивированы. Поскольку они служат в спецподразделениях, они по умолчанию лучшие из лучших. Однако после внедрения Scrum Хаас и его команда зафиксировали повышение продуктивности с 4 до 50 баллов в день за восемнадцать месяцев. Это рост на 1250 %.

И хотя их работа высокотехнологична, это не история стартапа, занимающегося программным обеспечением, не история команды, создающей продукт. В определенном смысле это компания, оказывающая услуги с узкоспециализированным, опасным и летальным способом поставки. Поскольку я работал с Джоном, на моих занятиях был стабильный поток служащих войск специального назначения ВМС. А это люди, которые прежде всего сосредоточены на результатах. Они решительно отказываются от того, что не делает их более быстрыми или более эффективными.

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

На краю хаоса

В Анн-Арборе, городе, где расположен Университет штата Мичиган, в начале 1980-х на программе бакалавриата учился студент, захваченный идеей моделирования жизни внутри компьютера. Его звали Кристофер Ленгтон, и он начал заниматься тем, что назвал клеточными автоматами.

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

Здесь можно быстро запутаться. Я опущу подсчеты, но Ленгтон категоризировал наборы правил в зависимости от степени изменений, которые они порождают. Он назвал этот параметр лямбдой. Чем он выше, тем больше изменений вызывает набор правил. Чем ниже, тем меньшим количеством изменений она управляет. Тут и случаются по-настоящему интересные события. Если лямбда слишком мала, вся система замирает и становится статичной. Если слишком велика, то система скатывается в хаос. Между двумя этими состояниями – переходная зона. Правила не могут быть слишком жесткими, поскольку это парализует систему, или слишком свободными, ведь это повергает ее в хаос. Должно быть ровно столько структуры, сколько достаточно для того, чтобы оставаться на краю хаоса.

Край хаоса, как оказалось, описывает множество разных вещей. Он интересен не только с точки зрения математики и вычислений. Он описывает то, что называется сложными адаптивными системами. Именно здесь вы можете увидеть производительность системы, только если она работает. Даже если вы полностью понимаете каждую часть системы, только в случае взаимодействия подсистем вы увидите ее общие свойства. И заранее предсказать, какими они окажутся, невозможно.

Мой отец говорит, что божественное чудо направило создание Scrum. Он управлял крупным каскадным проектом в банке, когда прочел работу Ленгтона. Он говорит, что оттуда узнал, почему проект опаздывал на годы и бюджет оказался превышен на десятки миллионов долларов. Управление на краю хаоса, на котором Ленгтон увидел самую высокую скорость эволюции цифровой жизни, – как раз то, для чего разработан Scrum.

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

И вот тут возникает проблема с проблемами. Не только клеточные автоматы действуют сложными адаптивными путями; то же касается экономики, экологии, нейрологии, команд и даже самого общества. Если правила слишком жесткие, ничего не меняется. Культура замирает. Ничего нельзя сделать. Структура в итоге гибнет. Именно это произошло в конце 1980-х с СССР. Долгое время страна была стабильна, а затем внезапно разрушилась. Но если правила слишком свободны, вы получите хаос. Беспорядки на улицах. Каждый сам по себе. Никакой сплоченности в обществе.

Если же структуры достаточно для того, чтобы балансировать на краю хаоса, происходят интересные события. Расцветает креативность, и ею можно управлять. Создаются и применяются идеи. Соседствуют свобода выражения и контроль на местах для ее фокусирования.

Другая странность систем такого типа в том, что очень маленькие изменения могут динамически и нелинейно распространиться. Иными словами, если вы скорректируете одну маленькую деталь, может измениться вся система. Именно это позволяет отдельным элементам самоорганизовываться для динамичного решения проблем. И именно это делает невозможным определение начала дальнейших процессов, хотя и может казаться, что результат предопределен заранее. Возьмем в качестве примера Войну за независимость. Сейчас кажется очевидным, что рано или поздно колонии бы взбунтовались, сбросили английское правление и основали США. Но если вы обратитесь к современным военным источникам, то обнаружите интересное: никто и понятия не имел, что произойдет дальше. Пока события не поглотили колонистов, никакого плана не было. И их успех висел на волоске.

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

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

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

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

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

Международная нефтяная компания попросила нас поработать с некоторыми из ее команд, которые решили, что им нужно пробурить несколько новых скважин. Для инженеров была проработана система фаз проекта, которые нужно проходить, а сама система требовала запредельного объема планирования и документации и очень, очень большого числа встреч. Затем приехали коучи Scrum Inc. и сформировали scrum-команды из обычных команд. Мы сказали руководству: «Хватит говорить им, что делать. Станьте наставниками. Каждый член команды – личность, и они работают вместе, чтобы достичь своей цели, а их цель – поставить новые скважины. Дайте им свободу, чтобы они могли это сделать». Конечно, командам нужно было создать определенные документы и провести необходимые исследования. Но они поняли, что нужно для принятия решения о бурении. Мы попросили их рассказать, что они сделали на каждой фазе проекта, и поместить информацию на стену так, чтобы каждый мог ее увидеть. Затем, игнорируя эти традиционные шаги и фокусируясь на доставляемой ценности, они смогли определить приоритеты – увидеть, как работать вместе и доставлять ценность инкрементально. Они взяли жесткую систему проектных фаз, которая ограничивала их, и превратили ее в гибкий бэклог, с которым можно начинать действовать.

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

Scrum сосредоточен на недетерминированной и сложной динамике систем и использует это. Он доставляет ценность не за счет централизованного принятия решений в одном месте, а за счет передачи решений к вершинам графа, где находится знание – к командам или владельцу продукта, – и работа выполняется без промедления. Это осмысленная система с определенной целью. Или, как ее назвал Ленгтон, детерминированный хаос[13]13
  Langton C. // Lewin R. Complexity: Life at the Edge of Chaos. New York: Macmillan, 1990. P. 12.


[Закрыть].