• Архитектура. Это один из самых важных факторов. В то время как Agile-разработка программного обеспечения независимо от архитектуры дает более высокие результаты, чем традиционные методы, монолитные системы могут поставить под угрозу это улучшение. Если пренебрегать проблемами с архитектурой, результаты применения Agile продолжат оставаться не впечатляющими.
• Чрезмерная специализация. Инженеры-программисты часто обладают узкоспециализированными навыками. Обычно мы рекомендуем Agile-командам сосредоточиться на решении проблем клиентов и по возможности поддерживать контакт в течение месяцев или нескольких лет. Но разноплановые технологии предполагают, что навыки, необходимые для работы с бэклогом команды со сложным опытом, могут меняться. Если инженеры узкоспециализированы, компании в конечном итоге получат группы, которые либо будут слишком велики, либо будут вынуждены постоянно менять членов.
• Изолированные подразделения. Обычно разные IT-подразделения отвечают за разные задачи: разработку программного обеспечения, обслуживание систем, поддержку, IT-операции и информационную безопасность. В некоторых отраслях используется еще больше подразделений, например, правового обеспечения. Они работают в своих «бункерах» и отвечают за достижение различных целей. Они часто не ладят друг с другом, в результате чего прогресс замедляется. В технологической Agile-организации все функции выполняются смешанными Agile-командами.
Для чисто цифровых продуктов, где по определению нет физической работы и процессы полностью закодированы в программном обеспечении, Agile-команда может нести полную ответственность за весь продукт. Такие команды, по существу, объединяют инновации и операции. Если нет необходимости переучивать людей для принятия изменений в процессах, инновации в цифровые продукты можно внедрять быстрее. Это объясняет, почему методы Agile так распространены среди таких компаний, как Google, Twitter и Spotify. Но преимущества Agile-разработки программного обеспечения столь же убедительны и для других компаний. Переход от традиционных методов к зрелым гибким командам обычно приводит к повышению производительности и скорости выхода на рынок в три раза быстрее.
Улучшения можно проследить по целому ряду положительных моментов. Сокращение времени ожидания проектных решений и утверждений приводит к меньшим усилиям, затрачиваемым на создание традиционных бизнес-кейсов. Автоматизация связанных с IT задач, таких как тестирование функциональности и безопасности, и тех задач, которые ранее выполняли другие подразделения, приводит к согласованным стимулам за счет полного владения жизненным циклом продукта. Что гораздо важнее, Agile-команды создают функции, наиболее ценные для клиентов и для бизнеса. Как правило, они не тратят время на поиск ответов, которые клиенты не ценят.
Пример исключительно цифрового решения для клиентов: услуга Home Agent RBS – своеобразный ключ к стратегии банка по поддержке клиентов в покупке и владении жильем, а не только в его финансировании. Home Agent позволяет клиентам через мобильное приложение получать помощь по широкому спектру вопросов, связанных с владением жилья, включая определение бюджета и покупку нового дома, его финансирование и рефинансирование, планирование и инвестирование улучшений, а также отслеживание стоимости. Используя Agile-команды, имеющие все необходимые навыки, связанные с пониманием клиентов, разработкой программного обеспечения и сотрудничеством со сторонними партнерами, RBS смогла за четыре месяца разработать и запустить первую версию Home Agent. Решение задачи такой сложности и качества заняло бы по меньшей мере в три раза больше времени при использовании традиционных методов, если бы его вообще удалось реализовать.
Разработка программного обеспечения – это сложная проблема, и чтобы получить эффект от внедрения Agile таким организациям, как RBS, требуется произвести разнообразные изменения, выходящие за рамки принципов и практик, которые мы описали для других целей. Полное рассмотрение требований к эффективной Agile разработке программного обеспечения выходит за рамки нашей книги, но некоторые из них были упомянуты ранее или перечислены в этой главе. Читатели могут найти и другие, более развернутые объяснения, на веб-сайте bain.com/doing-Agile-right, в том числе:
• модульная архитектура, которая позволяет каждой Agile-команде при написании кода минимизировать взаимозависимости с другими группами;
• усовершенствованные инженерные практики и повышенная квалификация технических кадров, что, как правило, требует серьезной подготовки и обучения как сотрудников на переднем плане, так и руководства, наряду с выборочным наймом для увеличения (а иногда и замены) имеющихся талантов;
• сходящиеся бэклоги, когда каждая Agile-команда отвечает за разработку, обслуживание и поддержку программного обеспечения, относящегося к ее продукту. Такая сквозная ответственность создает большую вовлеченность, кроме того, она гораздо более эффективна, чем разделение этих трех видов деятельности между двумя или тремя различными группами;
• DevSecOps, инструменты и методы, позволяющие группам, разрабатывающим программное обеспечение, выполнять большую часть работы по быстрому и безопасному переходу от разработки к производству;
• новые модели провайдеров IT-услуг, часто включающие в себя переключение от фиксированных результатов к фиксированным мощностям (в Agile-командах), а также приверженность низкой текучести кадров среди членов команды;
• пересмотренная стратегия размещения, включающая непосредственную близость и повышение квалификации кадров;
• трансформация функций поддержки и контроля, успешно выполняющие свои функциональные задачи, которая позволит Agile-командам разработчиков действовать в нужном темпе. При этом одним из ключевых моментов является смещение ориентации функциональных групп с коррекции рабочего продукта постфактум, как это часто делается сейчас в обучении Agile-команд разработчиков по созданию изначально подходящего продукта.
Разработка программного обеспечения особенно хорошо подходит для ключевого требования по внедрению масштабированного Agile: разделения больших задач на модульные компоненты, а затем плавной интеграции рабочих потоков. Amazon может развертывать программное обеспечение тысячи раз в день отчасти потому, что ее IT-архитектура была разработана с целью помочь разработчикам делать быстрые и частые выпуски, не ставя под угрозу сложные системы фирмы. Напротив, многие крупные компании ограничены негибкой архитектурой: независимо от того, насколько быстро они программируют, развертывать программное обеспечение они могут только несколько раз в неделю или в месяц.
Создание модульной архитектуры, подобной архитектуре Amazon, может показаться непреодолимым препятствием для многих крупных организаций, которые зависят от монолитных устаревших систем. Однако это можно сделать, применив ориентированные на клиента принципы Agile, которые мы обсуждаем уже несколько глав. Модернизация с помощью небольших шагов, последовательность этих шагов, основанная на преимуществах, которые они предоставляют клиентам, и использование гибких методов разработки программного обеспечения, описанных здесь, сделают путь быстрым, доступным и менее рискованным.
Agile-войны
Еще одно замечание о технологии: существуют десятки Agile-методов, каждый из которых имеет страстных сторонников. Проблема в том, что племена в рамках одной компании в течение длительного времени практикуют различные подходы, и их становится все труднее объединять. У них складывается привычное поведение. Они очерняют фреймворки конкурентов и превозносят свои. Это не только порождает путаницу, но и фактически создает враждебность среди коллег, которые должны строить сбалансированные, согласованные бизнес-системы. Эти дебаты нигде не бывают настолько яростными, как среди сторонников Agile, бережливых и продуктивных методов управления. Мы наблюдали, как ожесточенные споры едва не перерастали в кулачные бои. Понятно, тот, кто пытается разнять драку, всегда при этом получает по голове, но кто-то же должен внести немного здравомыслия в этот хаос! Придется и нам засучив рукава ввязаться в эту перепалку.
Бережливое производство стало источником серьезной неразберихи, поскольку люди применяют этот термин к двум очень разным подходам: системам бережливого производства (также известным как Lean Six Sigma) и бережливой разработке продуктов (также известной как бережливый стартап).
Системы бережливого производства – это инструменты для ведения бизнеса, для умножения качества и эффективности операций. Они повышают соответствие спецификациям, сводя к минимуму изменчивость и сокращая количество отходов. Lean Six Sigma требует не более 3,4 случаев брака на миллион операций. Повышение эффективности достигается за счет постоянного сокращения восьми источников отходов (дефекты, перепроизводство, ожидание, неиспользованные таланты, транспорт, запасы, перемещение и дополнительная обработка).[4] Мы настоятельно рекомендуем использовать методы бережливого производства для улучшения операционной деятельности, но не для управления инновациями. Новшествам нужна изменчивость, даже некоторая неэффективность, для тестирования, обучения и развития. Многие фантасты бережливого производства продолжают предписывать Six Sigma для инноваций, но результаты исследования доказывают, что чем лучше культура устраняет изменчивость, тем хуже она справляется с инновациями.[5]
Бережливый стартап и бережливое управление продуктами – методы Agile-инноваций. Широко известно внедрение системы бережливых стартапов в General Electric.[6] Этот подход сочетает принципы бережливого производства с нестандартным мышлением и Agile-подходами для содействия развития непрерывных инноваций, как это делают успешные стартапы.[7]
Управление продуктами побуждает разработчиков технологий думать о себе как о менеджерах по продуктам или брендам, отвечающим за разработку прибыльных продуктов и решающим важные проблемы клиентов. То есть не просто занимающихся управлен