Текст книги "Эпоха Agile"

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

За последние годы члены SD Learning Consortium обменивались визитами, чтобы понять условия, необходимые для успешного внедрения Agile[51]51
  Посещения компаний состоялись в 2015 году при содействии Learning Consortium for the Creative Economy, организатором выступила Scrum Alliance. В 2016–2017 годах они прошли при содействии SD Learning Consortium.


[Закрыть]. В каждом успешном кейсе мы обнаружили, что компания начинала с общих принципов и использовала опыт предшественников, а затем разрабатывала набор практик в соответствии с собственными потребностями (а порой и брендами) и корпоративной культурой. Хотя универсального рецепта успеха не существует, мы заметили поразительное сходство некоторых управленческих практик. Далее описаны главные характеристики.

Общие практики Agile-микрокоманд

1. Работа над мини-блоками. Чтобы справиться со сложностью и непредсказуемостью, задачу по возможности разбивают на блоки. В каждом из них содержится нечто потенциально ценное для потребителя или конечного пользователя. Каждый можно реализовать за короткий цикл; при таком подходе даже в сложных и крупных проектах виден прогресс или его отсутствие. В исключительных случаях компания устанавливает общий темп – обычно одну, две или три недели. В повседневности же каждая команда самостоятельно определяет себе подходящий ритм.

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

2. Маленькие кросс-функциональные команды. Работа обычно выполняется в автономных кросс-функциональных микрокомандах. Каждая из них выполняет что-то потенциально ценное для потребителя. Размер команд варьируется. Одно из главных правил – «семь плюс-минус два». В одних компаниях команды состоят из 10–12 человек, в других они меньше. Порой эти объединения называются иначе, например блоками или группами, а слово «команда» применяется к более крупному проекту.

3. Ограничение объема незавершенной работы. В Agile-менеджменте команды учатся концентрироваться на том объеме работы, который можно выполнить за короткий цикл. Если ограничить объем незавершенной работы, снижается количество ее очередей. Излишний незавершенный объем преобладает в командах, которые только начали внедрять Agile. Также он характерен для вспомогательных подразделений, в которых обычно образуется очередь из задач, требующих решения.

4. Автономность команд. В начале каждого короткого цикла составляется план работы, а дальше команды сами решают, как его выполнить. Руководство компании определяет базовые «дорожные правила», но исполнители свободны в выборе метода действий. «Дорожные правила» также варьируются: некоторые организации придерживаются фреймворка Scrum: работа в спринтах, в общем темпе, чтобы расширить возможности координации между командами. В других организациях право выбора предоставляется команде. Во всех компаниях, которые нам удалось посетить, действуют положения по управлению командой и ее подотчетности, но способ выполнения отдан на откуп команде.

5. Достижение стадии готовности. Лакмусовой бумажкой успешного внедрения Agile является завершение командой своего участка работы полностью и регулярно к концу каждого цикла. Дробление на мини-блоки позволяет командам доводить задачу до состояния «готово», а не «практически завершено». Сама идея достижения стадии «готово» на первый взгляд кажется примитивной, но на самом деле она оказывает на процесс решающее влияние. Одна из причин медлительности больших бюрократических структур заключается в большом количестве частично завершенных заданий, в которых часто прячутся нерешенные проблемы, добавляющие еще больше работы, когда к ним возвращаешься. Переключение контекстов – очень дорогая когнитивная функция.

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

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

7. Ежедневные стендапы. Независимо от используемых Agile-практик универсальным ритуалом всех компаний, которые мы посетили, считались ежедневные стендапы. Команды ненадолго встречаются, чтобы обсудить, насколько далеко они продвинулись, и выявить препятствия, которые нужно устранить. Регулярные обсуждения помогают членам командного «роя» сообща решить проблему, а не бороться с ней поодиночке. Такая форма сотрудничества нужна самим командам, а не менеджерам. Стендапы – это не разновидность контроля.

8. Полная прозрачность. Использование «бумажных источников информации»[52]52
  Доски со стикерами задач. Прим. науч. ред.


[Закрыть] стало неожиданным открытием во время наших посещений объектов. Фактически любой мог попасть на рабочее место сотрудников и сразу узнать статус работы и источник потенциальных проблем.

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

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

Такой метод работы возник из практического опыта и обширного экспериментирования. Продуктивен ли он? Google считает, что да. «Высшее руководство компании долгое время полагало, что сильные команды создаются путем объединения лучших специалистов», – говорит Абир Даби, менеджер из подразделения People Analytics в Google. Но на деле оказалось, что это не так. Подробное исследование, получившее название «Аристотель», показало, что состав команды мало влияет на ее продуктивность. Влияние оказывают пять ключевых факторов, поддерживаемых практиками Agile-управления[53]53
  J. Rozovsky. The Five Keys to a Successful Google Team // re: Work (blog). November 17, 2015, https://rework.withgoogle.com/blog/fivekeys-to-a-successful-google-team; C. Duhigg. What Google Learned from Its Quest to Build the Perfect Team // New York Times. February 25, 2016, https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html.


[Закрыть].

1. Психологическая безопасность. Можем ли мы брать риск на себя, не чувствуя неуверенности или смущения?

2. Зависимость. Можем ли мы полагаться друг на друга в том, что касается качественного и своевременного выполнения работы?

3. Структура и ясность. Ясны ли цели, роли и планы работы в нашей команде?

4. Воздействие работы. Важна ли наша работа для каждого из нас?

5. Значимость работы. Верим ли мы в то, что наша работа значима?

Результатом организации работы в соответствии с Agile становится не только ее более быстрое выполнение. В отличие от традиционных компаний, где полностью вовлечен в работу лишь каждый пятый сотрудник, в компании, практикующей Agile, все сотрудники находятся в состоянии потока. Термин «поток», введенный в оборот Михаем Чиксентмихайи, означает глубокое вовлечение, фокус и радость от процесса работы. Желая доставить радость пользователям или клиентам, исполнители «заставляют свой мозг работать».

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

Хотя в методах управления Agile-компаний явно заметно сходство, каждая из них разработала уникальную комбинацию практик. Интересен опыт Menlo Innovations, компании, занимающейся проектированием и разработкой ПО. Это детище увлеченного CEO Ричарда Шеридана и сооснователя Джеймса Гобеля расположено в Энн-Арборе, Мичиган. В основном компания работает в секторе B2B, зачастую с партнерами из очень важных отраслей, например здравоохранения. Приятный факт: Menlo всегда рада гостям. Вы можете приехать в Энн-Эрбор и побывать в этой компании будущего.

Люди приезжают в Menlo, чтобы научиться практикам Agile и бережливого производства. «Мы, разработчики, нужны для того, чтобы создавать продукт, который восхитит мир, обрадует людей, – говорит Шеридан. – Все, что мы называем Agile, или бережливым производством, или другими процессами, при хорошем исполнении отвечает на вопрос: как мы служим другим?»

«При этом мы позаимствовали кое-что из многих концепций, – объясняет Шеридан. – Вот почему вы нечасто услышите здесь слово Agile. Люди изучают наш опыт и говорят: “Ваша компания кажется очень гибкой. Почему вы не называете ее Agile?” Мы так работаем не потому, что хотим быть Agile, а потому, что своими продуктами хотим радовать мир».

Все началось 20 лет назад, когда Шеридан, на тот момент менеджер в компании, производящей ПО, устал от неудачных организационных практик. В своей фирме он поставил конкретную цель: положить конец страданиям разработчиков ПО[54]54
  S. Denning. The Joy of Work: Menlo Innovations // Forbes.com. August 2, 2016, http://www.forbes.com/sites/stevedenning/2016/08/02/the-joy-of-work-menlo-innovations.


[Закрыть].

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

Между тем слово «радость» в ХХ веке обычно не ассоциировалось с работой. Последняя могла быть эффективной или продуктивной – но чтобы радостной? Сама мысль об этом изначально казалось нелепой.

Однако вот уже 15 лет Menlo Innovations занимается именно этим – обеспечивает условия, радующие как исполнителей (разработчиков ПО), так и заказчиков. «Мы не верим ни на секунду, – подчеркивает Шеридан, – что можно служить другим и не заботиться при этом о своей команде. Поэтому мы создали систему, которая в первую очередь сосредоточена на помощи другим и на создании отличных результатов. Но для этого нам нужно было изменить способ разработки и создания ПО».

Цель по организации дружелюбного рабочего пространства, поставленная Шериданом, означает создание супернадежного кода. Его невозможно сломать, и он не нуждается в исправлениях. «В последний раз критическая ситуация, связанная с ПО, возникла у нас в 2004 году, – вспоминает Шеридан. – Зато нам пришлось наблюдать нечто подобное у одного из своих клиентов, с которым мы только начали работать. Это был конец света! Группа сотрудников той компании запустила крупный проект, который готовился много лет, и он оказался катастрофическим. Люди работали по ночам и выходным, пытаясь исправить ситуацию. Неудача серьезно отразилась на их бизнесе и снизила объем продаж их продуктов на рынке».

Menlo же создала среду, свободную от сбоев. Когда сотрудники Menlo увидели, что произошло в компании клиента, они сказали: «Ого, так вот как выглядит экстренная ситуация!». Они никогда не сталкивались с подобным.

«Мы создаем свободу посредством тирании, – говорит Шеридан. – Мы действительно создали радостную среду, и наши сотрудники любят свою работу. Они полностью вовлечены. Однако мы также насадили тиранию, избавившись от неопределенности. В нашем мире люди знают, с кем и для кого они работают. Они знают, над чем они работают и в каком порядке нужно это делать. В этом суть тирании. В остальном – полная свобода. Я предупреждаю: “Теперь вы свободны в том, чтобы делать любимую работу. Никто не будет заглядывать вам через плечо, вмешиваться и спрашивать, над чем вы сейчас трудитесь и как обстоят дела”».

«У нас есть процесс, – продолжает Шеридан, – и команды верят в него, поэтому мы не нуждаемся в “полицейских”, которые будут проверять, работают ли сотрудники. Процесс понятен им и нашим клиентам. Командная работа обязательна. Претворяя в жизнь идею работы в микрокомандах, мы создаем свободу для сотрудничества».

* * *

Как Menlo удается создавать «безаварийное программное обеспечение»? Возможно, ответ кроется в постоянстве команды. Многие компании вроде Microsoft и Ericsson практикуют Agile-менеджмент и прикладывают усилия к объединению членов команд, добиваясь их сходства со спортивными. Каждый знает навыки коллег и их характерные особенности. Более того, люди, создающие код, понимают его и в состоянии его поддерживать. Если возложить на них ответственность за решение проблем с качеством («багов»), у них появится стимул не ошибаться вначале. В подобных компаниях команда рассматривается практически как продукт.

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

Сотрудники Menlo выполняют работу в очень коротких рабочих циклах. Каждый длится всего неделю, после чего состав команд меняется. «Из-за этой смены каждая команда имеет дело с кодом, который был написан кем-то другим на прошлой неделе, – поясняет Шеридан. – Мы моментально тестируем его на предмет надежности и удобства в сопровождении. Новая команда должна понять этот код, чтобы эффективно внести изменения. Если что-то непонятно, новые “хозяева кода” обращаются к команде, которая писала его. Возможно, эти люди сидят за соседним столом.

В результате мы имеем действительно понятный, надежный и простой в сопровождении – и самое главное, безаварийный – код».

Второй особенностью Menlo является подход к найму персонала. Многие компании пытаются найти кандидата, который соответствует вакансии на 100 %. Они ищут кого-то точно с теми навыками, которые им требуются, например знанием Python 4.6, Oracle 9.1.1.1 и так далее.

Menlo поступает обратным образом. Она стремится создать культуру сотрудничества, приспосабливаемости, прозрачности и доверия. «Все начинается с наших практик найма, – говорит Шеридан. – Если наши люди не будут соответствовать нашей культуре, мы не сохраним ее в будущем. Когда нам нужны новые работники, мы организуем “быстрое свидание” соискателей со старожилами. Вопрос звучит следующим образом: хотел бы ты трудиться бок о бок с этим человеком? При положительном ответе мы приглашаем кандидата на работу на день, затем на неделю и на месяц. Если наши сотрудники не разочаровываются, мы берем его».

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

Третьей поразительной особенностью Menlo является работа в парах. Для традиционных менеджеров ситуация, когда два сотрудника сидят за одним компьютером, по определению непродуктивна и неэффективна. (Многие из них считают, что работа в парах сокращает продуктивность в два раза.) Шеридан же утверждает обратное: по его словам, при работе в парах продуктивность повышается в 10 раз в отличие от работы поодиночке.

Ранее в своей карьере Шеридану приходилось встречаться с боссами, которые были уверены: если два человека работают вместе, то как минимум один из них отлынивает. В Menlo думают иначе. Это не единственная компания, практикующая работу в парах. Но такие организации по-прежнему встречаются редко.

Четвертая поразительная особенность Menlo заключается в том, что ключевую роль в работе играют антропологи. «К сожалению, индустрия программного обеспечения создает технологии, не учитывающие потребности людей, а потом их считают “тупыми пользователями”, – сетует Шеридан. – В Menlo действует другой подход. Мы хотим создать программное обеспечение, которое не требует руководств по использованию или служб технической поддержки. Для этого мы изучаем интересы тех, кому служим. Мы называем эту практику “хайтек-антропологией”. Наши антропологи, исповедующие эмпатию, сострадание и особые методы исследований, “отправляются в мир”. Они анализируют не только среду, но и лексикон, рабочий процесс, привычки, страхи и мечты людей. Все эти знания задействуются при разработке программного обеспечения».

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

Как уже говорилось, Закон микрокоманды предполагает работу короткими циклами. В Microsoft и Ericsson он составляет три недели, в Menlo – одну неделю. И это не предел. Рассмотрим Etsy, онлайн-рынок товаров ручной работы. Впервые услышав об этом стремительно растущем миллиардном бизнесе, в рамках которого ежедневно внедряется более 30 инноваций, я представил, под каким прессом находятся работники. И был поражен тем, насколько реальность отличается от моих фантазий. Все оказалось с точностью до наоборот: непрерывная поставка используется в Etsy не только для ускоренного создания инноваций. Оно также помогает преодолеть чрезмерный стресс на рабочем месте.

Семь лет назад Etsy меняла код каждые две-три недели – довольно часто по сравнению с другими компаниями того времени. Например, Salesforce выпускал обновления три раза в год, а Microsoft Office – раз в два года. Как и многие субъекты рынка, Etsy создала отдельную группу для разработки ПО и отдельную – для его поставки. Действовала следующая схема: разработчики создавали новое ПО, операторы внедряли ряд изменений, которые разработчики объединяли вместе. Сотрудники Etsy часто задерживались в офисе сверхурочно, особенно когда обнаруживался сбой, а это происходило регулярно. Так же часто возникали длительные простои. Причина отчасти заключалась как раз в том, что ПО писала одна группа, а вводила его в действие и управляла им другая.

В 2010 году руководство Etsy решило изменить ситуацию. Оно обязалось ни много ни мало «ввести инновации или умереть». Компания поставила целью устранение препятствий, не позволяющих улучшать и масштабировать сайт. Справедливости ради надо отметить, что уже на тот момент этот сайт был огромным: ежемесячное количество уникальных просмотров превышало 60 млн. Менеджеры Etsy понимали, что преобразования должны включать в себя не только написание качественного кода, но и улучшение адаптируемости и сокращение сроков ожидания отклика в случае проблем. Планировалось также создать сильную команду разработчиков, которые смогут трудиться без авралов. Как и многие Agile-компании, Etsy исповедовала принципы «автономии, мастерства и целеустремленности», сформулированные Дэниелом Пинком[55]55
  D. H. Pink. Drive. New York: Riverhead Books, 2009.


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

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

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

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

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

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

Зато инновации создаются стремительно: число внедренных на сайте изменений доходит до тридцати в день, порой увеличивая продажи на миллионы долларов. Изменения внедряются небольшими инкрементами[56]56
  Инкремент продукта (Product increment) – ощутимый результат работы одного спринта. Прим. науч. ред.


[Закрыть] на безумной скорости в рамках главной стратегии.

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

Рационален ли такой подход? В 2015 году Etsy заявила о своем преобразовании в акционерное общество. Время покажет, поставил ли этот шаг под угрозу корпоративную культуру. Уже сегодня наблюдаются тревожные признаки давления инвесторов, желающих максимизировать акционерную стоимость. Если Etsy не сумеет справиться с этим давлением, ей придется пожертвовать стабильностью в угоду краткосрочной финансовой выгоде. Как и у Spotify, конкурирующей с Apple Music, ее единственный шанс выжить – обгонять конкурентов в плане инноваций, которые приносят радость клиентам.

Сталкиваясь с Agile-командами, традиционные менеджеры часто презрительно фыркают: «Команды? Ничего нового. У нас всегда были команды. Эта идея даже отдаленно не нова».

В какой-то степени они правы. Как отмечалось в главе 1, разговоры о пользе командного подхода в науке об управлении ведутся уже практически век. При этом многие команды являются таковыми только на словах. Их лидеры ничем не отличаются от других бюрократических боссов. Стоит ли после этого удивляться низким результатам их деятельности?

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

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

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

Но зачастую эти разговоры состояли из пустых клише, представляя собой лишь сказки о волшебной корпорации[57]57
  S. Denning. From CEO Takers to CEO Makers // Forbes.com. August 20, 2014, http://www.forbes.com/sites/stevedenning/2014/08/20/from-ceo-takers-to-ceo-makers-the-great-transformation.


[Закрыть].

На этом «романтическом» фоне основатели Agile-менеджмента умышленно выбирали приземленные и даже пугающие термины: Scrum, scrum-мастер, владелец продукта, Канбан, графики сгорания, рабочее программное обеспечение, спринты, стендапы. Работа должна была быть не просто «готова», а «готова, готова, готова». В таком языке нет намека на волшебство, сказку или фальшивый братский дух. Он не похож на высокопарный слог демагогов. Приверженцы Agile стремились к решению накопившихся проблем и хотели предоставить людям возможность работать, не отвлекаясь на второстепенные задачи. Внимание уделялось реальному опыту, устранению препятствий и постоянному повышению ценности для клиентов в условиях нарастающей сложности[58]58
  В большинстве случаев движение Agile избежало дискуссий о «новой эпохе», о «следующей ступени человеческого сознания», о которых писал Фредерик Лалу в своей книге «Открывая организации будущего» (М.: Манн, Иванов и Фербер, 2015). Оно также осталось в стороне от лингвистических крайностей движения холакратии, сторонники которого порой предлагают отказаться от названий процессов, менеджеров и иерархии. См. S. Denning. No Managers, No Hierarchy, No Way // Forbes.com. April 18, 2014, https://www.forbes.com/sites/stevedenning/2014/04/18/no-managers-no-hierarchy-no-way; S. Denning. Making Sense of Zappos and Holacracy // Forbes.com. January 15, 2015, https://www.forbes.com/sites/stevedenning/2014/01/15/making-sense-of-zappos-and-holacracy; S. Denning. Is Holacracy Succeeding at Zappos // Forbes.com. May 23, 2015, https://www.forbes.com/sites/stevedenning/2015/05/23/is-holacracy-succeeding-at-zappos. Иерархия по-прежнему сохраняется в Agile-управлении, но в большинстве случаев речь идет об иерархии компетенции, а не иерархии власти.


[Закрыть].

Как следствие, работа Agile-команд полностью отличается от работы традиционных команд XX века.

• Язык команд XX века был романтичным, язык Agile-команд – приземленный и прагматичный.

• Команды XX века стремились работать над линейными проблемами, которые они гарантированно могли решить. Agile-команды принимают неизмеримую сложность и нелинейность постоянно меняющейся среды за базовое условие игры.

• Команды XX века с трудом справлялись с масштабными проблемами. Использование платформ и сетей позволяет Agile-командам успешно работать в бесконечно большом масштабе.

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

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

Голос потребителя зачастую терялся в иерархических противостояниях между соревнующимися подразделениями и различными направлениями менеджмента. Нужно было изменить правила игры: отказаться от вертикальной динамики конфликта с нулевым результатом и перейти к взаимовыгодной горизонтальной динамике – повышению ценности путем сотрудничества и совместного решения проблем. Команды XX века зачастую были сосредоточены на самих себе. Сторонникам Agile предстояло направить свое внимание наружу с помощью постоянного создания ценности для клиента. Как эта задача выполнялась на практике?