Текст книги "Agile, который работает. Как правильно трансформировать бизнес во времена радикальных перемен"

Что значит масштабировать Agile?

Есть очень простое определение масштабирования Agile: это постоянное создание новых Agile-команд. Увеличить их число до пятидесяти, ста или более. Расширить сферу применения Agile, чтобы Agile-команды функционировали в разных частях организации. Научиться использовать группы команд, занимающиеся очень большими проектами. Мы встретили много разных примеров подобного масштабирования, и большая часть комментариев касается успешной реализации этого подхода. Мы называем это масштабированный Agile, и на данный момент как раз-таки его обычно реализуют в типичных крупных организациях.

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

Масштабированный Agile

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

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

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

Время, которое требуется Agile-команде, чтобы осуществить инновацию, определяется двумя факторами: временем, необходимым для работы над инновацией, и временем, потраченным на ожидание других. Время ожидания включает в себя задержки, вызванные такими операционными процессами, как календари стратегического планирования, процессы согласования решений, циклы бюджетирования и финансирования, графики выпуска программного обеспечения, правовые или нормативные ограничения, процессы распределения персонала и десятки других факторов. Эффективность потока компании рассчитывается путем деления рабочего времени на сумму рабочего времени плюс время ожидания (Рис. 2–1). Эмпирические данные показывают, что эффективность потока для большинства компаний редко превышает 15–20 %. Таким образом, даже если благодаря Agile скорость работы увеличится на одну пятую, общая скорость внедрения инноваций на предприятии может увеличиться только на 3 или 4 %. Это едва заметная разница. Более того, когда компании увольняют оперативный и обслуживающий персонал, чтобы платить за Agile-команды без изменения бизнес-процессов, остается меньше людей для выполнения того же количества работы.

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

Вот показательный пример и реальный аналог опыта Irresistible Snacks. Крупная финансовая компания, которую мы исследовали, запустила пилотный проект по созданию следующего мобильного приложения с использованием Agile-методов. Конечно, первым шагом было формирование команды. Для этого надо было направить бюджетную заявку на разрешение и финансирование проекта. Она вошла в пакет документов, предлагаемых к утверждению в следующем процессе годового планирования. После нескольких месяцев анализа компания наконец одобрила финансирование. В ходе пилотного проекта было разработано эффективное приложение, которое высоко оценили клиенты, и команда гордилась своей работой. Но прежде чем выпускать приложение, необходимо было провести оценку его уязвимости в рамках традиционного каскадного процесса. Это длительная процедура, в ходе которой тестируется документирование, функциональность, эффективность и стандартизация компьютерного кода, и очередь на нее была длинной. Затем приложение надо было интегрировать в основные IT-системы, что означало еще один каскадный процесс с шестимесячным или девятимесячным лагом. В итоге общее время выпуска сократилось совсем незначительно.

Так как же справляться с такими серьезными вызовами? Это цель Agile-предприятия.

Agile-предприятие

Agile-предприятие – это нечто большее, чем просто совокупность команд. Это тщательно сбалансированные операционные модели, которые используют Agile-методы для (1) надежного и эффективного ведения бизнеса, (2) его изменения с целью извлечения пользы из непредсказуемых возможностей и (3) гармонизации двух видов деятельности. Поэтому руководители, стремящиеся создать такое предприятие, подходят к процессу масштабирования с другим мышлением. Они не пытаются отделить Agile-команды от остальной организации, как если бы эти две группы были врагами. Они также не пытаются поместить всех сотрудников в Agile-группы. Хотя инновационные Agile-команды – это важный элемент Agile-предприятия, в них обычно входит только 10–50 % сотрудников. Большая часть работы и большинство людей в подобных системах сосредоточены на управлении бизнесом – операциях, поддержке и контроле.

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

Компания Bosch, ведущий мировой поставщик технологий и услуг с более чем 400 000 сотрудников и деятельностью в шестидесяти с лишним странах, приняла этот подход. Когда руководители начали понимать, что традиционное управление «сверху вниз» неэффективно в быстро меняющемся глобализированном мире, организация стала одним из первых последователей Agile-методов. Но оказалось, что разные сферы бизнеса требовали разных подходов, и первая попытка Bosch масштабировать Agile привела к культуре раздора, в которой полные энтузиазма новые подразделения управлялись Agile-командами, а традиционные функции оставались в стороне, что ставило под угрозу задачи целостной трансформации. В 2015 году члены правления во главе с CEO Фолькмаром Деннером решили выстроить единый и целостный подход к Agile-командам. Правление выступило в качестве руководящего комитета, а руководителем работ был назначен Феликс Иероними, инженер-программист, ставший экспертом Agile.

Поначалу Иероними рассчитывал управлять работой так же, как Bosch управляла большинством проектов: с целью, намеченной датой завершения и регулярными отчетами правлению о состоянии дел. Но такой подход оказался несовместимым с принципами Agile, а подразделения компании весьма скептически отнеслись к еще одной программе, организованной руководством. Поэтому команда сменила тактику. «Руководящий комитет превратился в рабочий комитет, – рассказал нам Иероними. – Дискуссии стали гораздо более интерактивными». Команда составила и упорядочила список корпоративных приоритетов, который регулярно обновлялся, и сосредоточилась на постоянном устранении барьеров для повышения гибкости. Члены комитета рассредоточились, чтобы вовлечь в диалог руководителей подразделений. «Стратегия превратилась из ежегодного проекта в непрерывный процесс, – сказал Иероними. – Члены правления разделились на небольшие Agile-команды и протестировали различные подходы – некоторые с участием “владельца продукта” и “Agile-мастера” – для решения сложных проблем или работы над основными темами. Например, одна группа разработала проект десяти новых принципов лидерства, опубликованный в 2016 году. Они лично были довольны повышением скорости и эффективности. Такой опыт не приобретешь, читая книги». Сегодня Bosch работает, комбинируя Agile-команды и традиционно структурированные подразделения. Но, по данным компании, почти все сферы деятельности приняли ценности Agile, сотрудничают эффективнее и быстрее адаптируются ко все более динамичным рынкам. В следующих главах мы более подробно расскажем о Bosch.

Создание Agile-предприятия не означает полного отказа от бюрократии. Любой, кто размышляет об этом, должен пройти знаменитый тест Ф. Скотта Фицджеральда на наличие первоклассного интеллекта: «Свидетельство первоклассного интеллекта – способность удерживать в голове две противоположные идеи и сохранять при этом возможность действовать».^[2] Безусловно, такой мыслительный процесс нужен и самой организации.

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

Проще говоря, Agile-предприятие – это кросс-функциональная команда. Руководители Agile-предприятия должны надежно и эффективно управлять бизнесом, менять его, чтобы извлекать пользу из непредсказуемых возможностей, и гармонизировать оба вида деятельности. Эта точка зрения согласуется с китайской философией двойственности – инь и янь. Операции и инновации – это взаимодополняющие и взаимозависимые виды деятельности, которые нуждаются друг в друге. Трения, сдержки и противовесы – это особенности, а не недостатки здоровой операционной системы (Рис. 2–2). Поэтому мы постоянно подчеркиваем идею баланса. Конечно, правильный баланс варьируется в зависимости от отрасли, компании и деятельности в рамках бизнеса. Управление НИОКР[11]11
  НИОКР – научно-исследовательские и опытно-констуркторские работы, направленные на получение новых знаний и их применение при создании нового продукта или технологии.


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

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

Более эффективный способ – мыслить и создавать видение так, как это делает Agile-команда.

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

Самые простые истории пользователей выглядят примерно так, как показано на Рис. 2–3. Более сложные версии больше похожи на Рис. 2–4.

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

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

Таксономия (иерархическая классификация) команд

Точно так же, как Agile-команды составляют бэклог работ, которые предстоит выполнить в будущем, компании, успешно масштабирующие Agile, обычно начинают с создания корпоративного бэклога и таксономии команд. Она определяет ключевые решения для клиентов, а также бизнес-процессы и технологии, которые их поддерживают. Затем решается, где следует создать команды и как координировать или связывать критически взаимозависимые подразделения. На первом этапе определяются все виды опыта, способного существенно влиять на решения, поведение и удовлетворенность внешних и внутренних клиентов. Как правило, их выделяют около десяти. Например, один из основных опытов розничного клиента – это покупка и оплата продукта, что, в свою очередь, можно разделить на несколько конкретных видов (например, выбор способа оплаты, использование купона, погашение баллов лояльности, завершение оформления заказа и получение чека). На втором этапе исследуются взаимосвязи между этими опытами клиентов и ключевыми бизнес-процессами (например, улучшенные процедуры оформления заказа для сокращения времени ожидания), направленные на уменьшение дублирующих обязанностей и расширение сотрудничества между командами процессов и группами взаимодействия с клиентами. Третий шаг фокусируется на разработке технологических систем (например, улучшенных приложений для мобильных касс) для совершенствования бизнес-процессов, поддерживающих группы, занимающихся клиентским опытом.

Таксономия бизнеса стоимостью 10 миллиардов долларов может выявить от 250 до 1000 или более потенциальных команд. Эти цифры звучат устрашающе, и руководители высшего звена часто не хотят даже думать о таких больших изменениях («Как насчет того, чтобы попробовать две или три команды и посмотреть, что получится?»). Но ценность таксономии в том, что она поощряет исследование трансформационного видения, разбивая деятельность на небольшие шаги, которые можно в любое время прервать, перенаправить или прекратить. Это также помогает руководителям выявлять ограничения. После того как будут определены команды, которые можно создать, и типы людей, которые понадобятся для их комплектации, следует задать себе вопрос: «А есть ли у нас эти люди? Если да, то где они?» Таксономия выявляет пробелы в кадрах, а также типы людей, которых следует нанять или переобучить, чтобы эти должностные пробелы восполнить. Руководители также смогут понять, насколько каждая потенциальная команда вписывается в цель повышения качества обслуживания клиентов.

Таксономия USAA, например, очевидна каждому, кто работает на этом предприятии. «Если у вас нет хорошей таксономии, вы получите избыточность и дублирование, – сказал нам операционный директор Карл Либерт, когда мы готовили эту книгу. – Я хочу войти в зал и спросить: “Кто владеет опытом смены адреса участника?” И я хочу получить четкий и уверенный ответ от команды, у которой этот опыт есть, независимо от того, звонит ли нам участник, входит ли он на наш сайт с ноутбука или же использует наше мобильное приложение. Я не ищу виноватых. Я не жду ответов, начинающихся со слов “Это сложно”». Цель таксономии USAA – выяснить, как можно, не создавая путаницы, привлечь нужных людей к нужной работе. Это особенно важно, когда иерархические организационные структуры не согласуются с поведением клиентов. Например, многие компании имеют отдельные структуры и отдельные показатели прибылей и убытков для онлайн и офлайн-операций, а клиентам нужен отлично интегрированный омниканальный опыт. Четкая таксономия, которая позволяет создавать правильные кросс-организационные команды, делает такое согласование возможным.

Вы, наверное, задаетесь вопросом: «Как мне оплатить эти команды?» Решение в большинстве случаев заключается в сокращении непродуктивной инновационной деятельности и преобразовании непрерывных инновационных инициатив в Agile-команды. Часто таксономия показывает, что около трети существующих инновационных команд работает над тем, чего клиенты не хотят, или тем, что команды не смогут предоставить. Использовавшиеся ранее процессы не давали возможности остановить такую деятельность, пока не будет потрачен бюджет. Agile позволяет это изменить. Для команд, которые продолжат работать, методы Agile должны повысить производительность по крайней мере на 20 %, а иногда и значительно сильнее. По мере того как Agile-команды будут переходить к преобразованию бизнес-процессов и технологий, эффективность будет расти.