Отправной точкой всегда должно быть создание определенного клиентского опыта, например, подача заявки на ипотечный кредит или развитие определенных возможностей, например, проверки заявленных доходов и активов клиентов. Как правило, клиентский опыт – это лучший инструмент для определения решения, поскольку обычно проще всего связать чувства клиента с его ценностями. Но возможность – в некоторых ситуациях предпочтительная конструкция, например, когда она лежит в основе многих различных переживаний или когда основываться на опыте нецелесообразно. Как опыт, так и возможности часто пересекают границы между подотделами и департаментами, поэтому эффективные команды опираются на все затронутые подразделения. Когда решения становятся достаточно объемными, чтобы охватить больше одной группы, компания может разбить их на модульные компоненты. Так каждая команда может тестировать варианты с клиентами и действовать независимо, тем самым обеспечивая максимально возможный контроль и скорость.
В Главе 2 мы обсудили преимущества структурирования Agile-команд вокруг таксономии связанных решений. Это справедливо для клиентских решений, которые управляют процессами и технологиями. Например, ведущая американская компания по медицинскому страхованию разработала таксономию, основанную на пяти портфелях: участников программы, работодателей, поставщиков медицинских услуг, брокеров льгот и сотрудников. Каждый из пяти владельцев портфеля выступает в качестве главного менеджера по продуктам полного набора опыта и возможностей, входящих в этот портфель. Некоторые из них, например, обработка претензий, охватывают несколько портфелей и управляются главным владельцем ресурса. Такая структура позволяет компании создавать дорожные карты управления для крупных решений, требующих участия нескольких команд, и помогает руководить взаимозависимостями между ними.
Изменения в решениях для клиентов, процессах и технологиях сильно взаимозависимы, поэтому группа, ответственная за инновации в любой из этих областей, часто уполномочена изменять все три. Если эта задача оказывается слишком велика для одной команды, к ее решению подключаются другие альянсы. Но как уже было сказано в Главе 5, большинство компаний считают, что постоянные команды более эффективны для создания инноваций, чем проектные.
Для Agile-изобретений фундаментальное значение имеет обучение на основе исследований. Но экспериментирование с инновациями в решениях для клиентов сопряжено с некоторыми проблемами. Бюрократия стремится к четким, стабильным, предсказуемым операциям. Большинство традиционных операционных групп не настроены на внесение небольших и частых изменений в процессы. Это относится и к традиционным IT-группам – они не могут быстро адаптировать функциональность своих систем. Есть и более серьезные проблемы. Многие компании, особенно в регулируемых отраслях, имеют длительные и сложные процедуры, которым необходимо следовать, прежде чем кто-либо сможет изменить процессы или технологию. Иногда им не хватает аналитических и технических навыков, необходимых для разработки тестов и измерения результатов так, чтобы оптимизировать обучение. Руководители и менеджеры часто обеспокоены тем, что неудачные тесты создадут значительный риск для клиентов.
Давайте рассмотрим эти ситуации подробнее.
Инновация процессов
В RBS понимали, что изменения в решениях для клиентов должны приводить к изменениям в процессах. Например, консультант по ипотечным кредитам, проверяющий точность информации в электронной заявке, должен был работать совсем иначе, чем консультант, проверяющий бумажное заявление. При внедрении электронной заявки на ипотеку банку необходимо было перестроить процессы, используемые ипотечными брокерами.
Так как же Agile-командам следует внедрять инновационные процессы? В некотором смысле процессные инновации очень похожи на любые другие Agile-нововведения. Вы начинаете с клиента и работаете в обратном направлении, чтобы решить его потребности инкрементным, итеративным способом. Вы достигаете этого с помощью наделенных полномочиями междисциплинарных команд. Однако в других отношениях такой подход сопряжен с более высоким уровнем сложности. Компании считают оба метода действенными.
Современные программные системы обычно строятся как микросервисы – небольшие модульные функциональные блоки с четко определенными интерфейсами. Любой системный разработчик может его использовать, просто зная функцию выполнения и понимая интерфейсы. Операционные возможности могут быть спроектированы таким же образом. Например, процессу корпоративной недвижимости могут быть заданы такие параметры, как количество людей, которых она должна разместить, тип работы, которую выполняют эти люди, и требования к местоположению. Ей может быть поставлена задача определить конкретный объект и заключить контракт на помещение, которое будет соответствовать его спецификациям. Такая модульная структура позволяет Agile-команде улучшить функциональные возможности, не беспокоясь о вмешательстве в другие части организации.
У внешних клиентов есть выбор, у каких компаний покупать. А внутренняя возможность позволит определить, насколько она соответствует мировому классу, предоставив другим частям организации возможность использовать внешних поставщиков. Для этого компетенции должны быть способны взаимодействовать друг с другом в модульном режиме. На примере с недвижимостью внешний поставщик также может предложить оказать услугу, и компания сравнит результаты. Некоторые организации идут дальше и поощряют внутренние возможности для выхода на внешний рынок. Один из наиболее известных примеров – Amazon Web Services (подробнее об AWS см. Главу 8). Внешний коммерческий успех – это чуть ли не лучший показатель возможностей мирового класса.
Если вы работаете в команде, занимающейся инновацией процессов, вы можете обнаружить и некоторые другие различия. Вашими основными клиентами могут быть сотрудники, которые работают, чтобы угодить внешним клиентам. Возможно, вам придется работать с обеими группами. Команда по подаче заявок на ипотеку в RBS получала информацию как от внутренних консультантов по ипотечным кредитам, так и от внешних клиентов. В других случаях вам потребуется создавать возможности, которыми будут пользоваться несколько внутренних клиентов. Это может потребовать настройки отдельных решений для каждого из двух сегментов или согласия на нелегкие компромиссы.
Одному производителю промышленного оборудования с пятьюдесятью заводами по всему миру при модернизации систем цепочки поставок необходимо было учесть технологические различия между этими предприятиями, даже несмотря на стремление к стандартизации. Часто Agile-инновации процессов требуют значительного изменений технологий. Найти людей, особенно владельцев продуктов, которые обладают необходимыми деловыми и инновационными навыками, непросто. Для успеха нужны особые люди и команды. Создавая кадровый состав координаторов «пути клиента», в RBS приложили значительные усилия, чтобы высвободить людей с необходимым набором навыков и развить их в других.
Еще одна проблема заключается в управлении связи с операциями. Трудно изменить вещи, которые спроектированы так, чтобы быть стабильными. Это требует эффективных путей передачи лучших идей командам, ответственным за инновации в процессах и технологиях, и их внедрения в операции. Компании могут использовать различные методы. Владельцы продуктов могут исходить из процессов, требующих изобретений, что обеспечивает как соответствующие практические знания, так и рост доверия к команде. Менеджеры и операционные работники, действующие на переднем плане, могут присутствовать на спринтерских обзорах в качестве ключевых заинтересованных сторон. Владельцы продуктов могут тратить столько времени, сколько необходимо, на обсуждение с этими представителями идей по улучшению прототипов. Некоторые из них могут быть делегированы в инновационные команды для работы над тестированием изменений. Оперативный персонал должен иметь возможность презентовать свои идеи через автоматизированную систему, при необходимости с личным контролем. И все вместе, инновационные и операционные команды, должны использовать одни и те же бизнес-показатели, например, рост выручки, операционные расходы, надежность или индекс лояльности клиентов (NPS), чтобы обеспечить правильные стимулы. Наша рекомендация: размещать инновационные команды в тех подразделениях, которые они обслуживают, что также способствует скорейшему принятию изменений подразделениями.
Технологическая инновация
Agile быстрее всего распространился среди технологических новаторов, особенно инженеров-программистов. Что делает его таким эффективным подходом в разработке программного обеспечения? Проблемы, которые необходимо решить, сложны, а ответы изначально неизвестны. Требования к продукту, скорее всего, будут меняться. Работа может быть модульной и выполняться постепенно. Возможно тесное сотрудничество с конечными пользователями для получения быстрой обратной связи от них. Тестирование может быть автоматизировано. Показатели успеха при использовании традиционных (каскадных) методов невелики. Но его ценность высока, особенно с учетом растущей важности цифровых решений для клиентов.
Существуют организации с большим количеством технологических Agile-команд, но не так много технологических Agile-организаций. Отделы активно внедряют Agile в разработку программного обеспечения, но большинство из них не успевают за изменениями, необходимыми в бизнес-процессах и удовлетворении запросах клиентов. Вы уже знаете некоторые из причин этого разочаровывающего несоответствия. Это и отказ от учета потребностей покупателя при принятии решения, и нисходящие «одним махом» распоряжения, ведущие к половинчатому, непоследовательному принятию практик Agile. Это и руководители, которые говорят о трансформации, но не меняют собственный стиль управления. Это и жесткое, медленное, утомительное планирование, бюджетирование и анализ. Это и ограниченная политика вознаграждений, продвижения по службе, которые подрывают ценности Agile. Но есть и другие факторы, характерные для разработки программного обеспечения.