Agile, который работает. Как правильно трансформировать бизнес во времена радикальных перемен — страница 23 из 43

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

Например, идеи Amazon Prime и Amazon Web Services пришли «снизу вверх» вне обычного цикла планирования. Они не считались стратегическим приоритетом, но становились важными по мере их успеха. Требовалось увеличение финансирования. Неудачи в Amazon открывают двери для других возможностей. Когда смартфон Fire Phone потерпел на рынке фиаско, компания не ощутила недостатка в идеях для финансирования с лучшей отдачей. (Подробнее об Amazon мы поговорим в Главе 8.)

2. ОНИ ФИНАНСИРУЮТ ПОСТОЯННЫЕ КОМАНДЫ, А НЕ ПРОЕКТЫ, ЕСЛИ ВОЗМОЖНОСТИ ОСТАЮТСЯ АКТУАЛЬНЫМИ

Agile-команды бывают двух типов. Проектные группы занимаются проблемами или возможностями, с которыми реально справиться достаточно быстро, в течение недель или месяцев. Постоянные команды (часто называемые командами разработчиков продуктов) занимаются важными задачами клиентов, на решение которых могут уйти годы. Как любит говорить Джефф Безос: «Клиенты всегда удивительно недовольны, даже когда утверждают, что счастливы и что бизнес процветает. Даже когда они еще не знают, что получат, они хотят чего-то лучшего, и ваше желание порадовать клиентов заставляет вас постоянно что-то изобретать».2 По мере изменения потребностей клиентов и развития решений постоянные группы десятки раз в течение нескольких лет меняют направление деятельности. Никто не хочет, чтобы команды обращались за утверждением всякий раз, когда им нужно скорректировать приоритеты. Если они найдут лучшее решение для клиентов, то должны его использовать. И наоборот, если не находят хорошего пути или проблема больше не важна, команду следует перенаправить на другую задачу или вовсе расформировать.

Долговечность и расширение возможностей постоянных Agile-групп делает их эффективными и результативными Иноваторами, поскольку они лучше узнают друг друга, своих клиентов, а также процессы и системы, которые обслуживают этих клиентов. На сайте bain.com/doing-Agile-right можно найти более подробное описание планирования, бюджетирования и анализа для постоянных команд.

3. ОНИ СВЯЗЫВАЮТ ФИНАНСИРОВАНИЕ С КОНЕЧНЫМИ РЕЗУЛЬТАТАМИ

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

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

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

Конечно, предприятия сталкиваются с разными проблемами. Поэтому каждое разрабатывает процедуры бюджетирования, соответствующие его потребностям. Один из примеров – Royal Bank of Scotland (RBS), компания, о которой более подробно мы расскажем в Главе 7. Несколько лет назад лидеры подразделения персонального банковского обслуживания начали создавать постоянные Agile-команды, привязанные к конкретному опыту клиентов. К сожалению, препятствием стала принятая в RBS модель бюджетирования, финансирования и управления. Во-первых, она была разработана для финансирования только традиционных проектов. Она требовала огромной детализации функций, затрат и результатов, поэтому на подготовку уходило много времени, а это мешало командам адаптироваться по мере того, как они больше узнавали о поведении клиентов. Поскольку группы распускались в конце каждого проекта и заново формировались для нового, они редко могли использовать преимущества совместной работы в течение длительного времени. Наконец, процесс утверждения изменений был обременительным, что задерживало результаты и делало тестирование и обучение непрактичным.

Поэтому руководители RBS начали менять свою модель бюджетирования и финансирования. Первым шагом стало определение областей деятельности клиентов, например, покупка жилья и владение им. Далее нужно было создать постоянные команды, каждая из которых была сосредоточена на одном опыте работы с клиентами, например, оспаривании взимания платы с кредитной карты. У каждой области деятельности клиентов есть соглашение о планируемых итогах работы, таких как рост выручки, снижение затрат или увеличение индекса потребительской лояльности (Net Promoter Score), которых собственник обязуется достичь в обмен на запрошенные ресурсы. Каждый владелец «пути» получает средства для выполнения обязательств по его договору. Эта система позволяет членам команд управлять своим бэклогом для достижения целей. С тех пор как она была внедрена в подразделении для физических лиц RBS, количество бизнес-кейсов, разработанных за год, сократилось с восьмидесяти до шести, что высвободило значительное количество времени и сил. RBS планирует и дальше развивать эту модель, чтобы финансирование деятельности и команд постоянно осуществлялось и корректировалось по мере изменения приоритетов клиентов и бизнес-возможностей.

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

Agile-анализ

Анализ – это неотъемлемая часть цикла «планирование-действие-проверка-корректировка». Ежеквартальный, ежемесячный или даже еженедельный анализ дает возможность часто сравнивать фактические и ожидаемые результаты. Это позволяет понять, следует ли вносить коррективы в планы и бюджеты или действия, направленные на их выполнение. Но и в этом случае Agile-предприятия действуют по-своему. Участники обмениваются информацией прозрачным и неформальным образом, не тратя впустую время и усилия на подготовку блестящих презентаций. Они скорее используют анализ для обновления планов и бюджетов. Их главная цель – способствовать, а не препятствовать расширению возможностей Agile-команд. Аналитики стремятся предоставить информацию, необходимую для управления всем спектром бизнес-соображений. Так группы могут самостоятельно анализировать темы, которые в бюрократической организации рассматривались бы контрольными функциями или другими руководителями. Это помогает избежать чрезмерного управления «сверху вниз».

Например, бюджетами всегда будут управлять финансовые отделы. Но менеджерам не следует все время подвергать сомнению решения Agile-инициаторов. «Наш финансовый директор постоянно перекладывает ответственность на наделенные полномочиями Agile-команды, – говорит Ахмед Сидки, руководитель отдела управления разработками в компании по производству видеоигр Riot Games. – Он говорит: “Я здесь не для того, чтобы управлять финансами компании. Вы руководители команд. Я – консультант”. В повседневной деятельности в помощь Agile-командам назначаются финансовые партнеры. Они не контролеры, а больше похожи на инструкторов, которые задают трудные вопросы и делятся знаниями и опытом. Но в конечном итоге именно руководитель команды принимает решения, исходя из того, что лучше для тех, кто использует игры Riot».3

Riot Games – компания, основанная на цифровых технологиях, с большим опытом использования Agile. Но ведь и банк RBS преследует похожую цель, адаптируя свой процесс ежеквартального пересмотра бюджета, чтобы расширять возможности своих Agile-команд. Вместо анализа расходов на проект и степени его завершенности в сравнении с бюджетом, ежеквартальный анализ теперь включает в себя ценные обсуждения, касающиеся деятельности клиента и соглашений о результатах работы команды, в том числе и набор согласованных измеримых результатов. Координаторы сообщают о достигнутых результатах и о тех, что не были реализованы, обсуждая причины и стремясь внести свой вклад в улучшение. Этот сдвиг в фокусе анализа способствовал гораздо большей вовлеченности и удовлетворенности лидеров и их команд. На момент написания книги в RBS соглашения о результатах работы инновационных команд по изменению бизнеса были разграничены от соглашений команд по ведению бизнеса. Но банк планировал создать единый набор целей и обязательств для обоих типов групп, созданных для каждого «пути» клиента. Также разрабатывались изменения в управлении, призванные еще больше повысить гибкость команд. Они включают в себя с