Компании часто неверно интерпретируют отдельные положения Скрама, когда разрабатывают большие продукты. Особенно часто встречается непонимание роли Владельца Продукта. Структура “одна команда один Владелец Продукта”, которую я часто вижу, выглядит примерно так:
Мы называем эту модель Copy Paste Scrum и она вызывает целый ворох проблем:
- Зависимости между командами и вынужденную координацию;
- Отсутствие сквозных приоритетов и работу над менее важным;
- Хрупкость системы;
- Оторванность разработчиков от бизнеса и клиентов;
В общем случае Copy Paste Scrum — фейковый Скрам. В этой статье я объясню почему, а затем мы разберемся в том, как разрабатывать большие продукты, используя Скрам профессионально.
Зависимости между командами и вынужденная координация.
В модели Copy Paste Scrum команды часто образуются вокруг архитектурных систем и компонентов (“платформа”, “CRM”, “BI”), внутренних бизнес процессов (“процессинг”, “биллинг”), технологий (“Android”, “iOS”, “Web”). Появляются искусственные зависимости, которые увеличивает Time-2-Market. “Владельцы Продуктов” становятся координаторами зависимостей. Могут существовать специальные встречи, называемые “PO Sync”-и. Это искусственная сложность. Управлять зависимостями не нужно, от них следует избавляться.
Напоминаю, что в профессиональном Скраме у команд нет зависимостей:
Команды разработчиков являются кросс-функциональными и обладают всеми необходимыми навыками, необходимыми для создания продукта (Скрам Гайд).
Отсутствие сквозных приоритетов и работа над менее важным
Несмотря на то, что Chief Product Owner (CPO) имеет собственный “Бэклог Продукта”, этот артефакт не сквозной. Он представляет коллекцию индивидуальных “Бэклогов Продуктов” команд и определяется их загрузкой, а не потенциальной ценностью для организации и ее клиентов.
В разработке комплексных продуктов наши желания по реализации функциональности всегда превышают возможности и текущие ресурсы, поэтому важно фокусироваться на самом ценном.
Продуктовые группы, работающие с несколькими очередями требований, всегда занимаются менее важным с точки зрения всей организации.
Эту мысль иллюстрирует картинка ниже. Порядок элементов в настоящем сквозном Бэклоге Продукта, приоритезированном с точки зрения самого ценного для организации, никогда не совпадает с порядком элементов в нескольких очередях. В модели Copy Paste Scrum команды всегда сфокусированы не на самом важном с точки зрения организации.
Хрупкость системы
Что такое организационная гибкость? Мне нравится определение Майкла Биддла:
Бизнес-гибкость — это способность быстро и эффективно адаптироваться под любые виды изменений, доставляя при этом максимум ценности и клиентского опыта.
Модель Copy Paste Scrum нельзя назвать гибкой, потому что при значительном изменении рынка команды не способны “подхватить” работу у других команд. Они могут выполнять только конкретные типы фич. Дело в том, что фактическая цель Copy Paste Scrum — эксплуатация экспертизы людей и фокус на выхлопе (outputs), а не организационная гибкость и максимизация бизнес-ценности.
Оторванность команд от бизнеса и рынка
Модель Copy Paste Scrum стимулирует “Владельцев Продуктов” заниматься “пережевыванием” требований, оформлением их в артефакты, а затем передачей их командам. Это отдаляет разработчиков от бизнеса и рынка. Напомню принципы Аджайл Манифеста:
Лучшие архитектуры, требования и дизайн рождаются у самоорганизующихся команд. Бизнес и разработка должны работать вместе ежедневно.
Почему мы удивляемся, что разработчики не понимают потребностей клиентов, не испытывают к ним эмпатии и плохо погружены в доменную область? Мы своими руками делаем из них “кодеров”, выполняющих инструкции, которые им скармливают “Владельцы Продуктов”.
Фейковый Скрам
Руководство по Скраму описывает организационный дизайн в миниатюре. Скрам-команда кросс-функциональна, самоорганизованная, не имеет зависимостей и каждый Спринт может поставлять на рынок готовую функциональность. Этот дизайн реализует ценности и принципы Аджайл Манифеста.
Copy Paste Scrum сохраняет традиционную организацию, лишь взяв на вооружение терминологию Скрама.
Copy Paste Scrum — это фейковый Скрам.
Он не меняет организационный дизайн и увеличивает продуктивность отдельных частей системы, не оптимизируя ее целиком. Давайте посмотрим, как можно помочь организациям быть адаптивными на самом деле, а не просто заявлять об этом.
Профессиональный Скрам
Неверно масштабировать Скрам и его элементы (роли, артефакты, процессы). Это подход вызывает усложнение системы управления. Что если мы будем масштабировать продукт, а не Скрам?
Тогда относительно небольшая продуктовая группа размером 50-70 человек имеет простую структуру:
В профессиональном Скраме Бэклог Продукта и Владелец Продукта всегда один, независимо от количества команд.
Несколько Скрам-команд часто работают вместе над одним и тем же продуктом. Один Бэклог Продукта используется для описания предстоящей работы (Руководство по Скраму).
Как разгружается Владелец Продукта
Один Владелец Продукта управляет порядком Бэклога Продукта, отвечая за видение и стратегию развития продукта. Ему помогают команды, которые занимаются уточнением элементов Бэклога Продукта напрямую со стейкхолдерами (пользователи, клиенты), со-создавая с ними функциональность. Так они снимают нагрузку с Владельца Продукта, оставляя за ним видение и стратегию.
Команды кросс-функциональные и кросс-компонентные. В идеале они могут взять любой элемент Бэклога Продукта и доставить его на рынок. Команды коллективно владеют кодовой базой и ежедневно интегрируются, быстро обнаруживая конфликты в коде и устраняя их. Команды отвечают за координацию между собой, используя различные практики.
Гигантские продукты
При дальнейшем масштабировании продукта количество сегментов пользователей и комплексность возрастает. Скрам Гайд не дает ответа на вопрос, как вести разработку гигантских продуктов. Можно воспользоваться Скрам-паттерном Value Areas.
Команды группируются вокруг областей требований (Value Areas) и продолжают независимо поставлять ценность на рынок. Области требований возглавляет бизнес-эксперты, называемые Area Product Owner (APO), работающие с 4-8 командами. Области могут формироваться вокруг клиентских сегментов (B2B, B2C), пользовательского пути (“Joining”, “Supporting”, “Paying”) или рынков (“платежи СНГ”, “Европейские платежи”). Владелец Продукта может перебрасывать команды между областями, поддерживая адаптивность организации.
Движение к совершенству
В основе Скрама лежат идеи бережливого мышления (Lean Thinking). В частности, принцип постоянного движения к совершенству. Профессиональный Скрам устанавливает высокую планку для организаций, моделируя систему, которой тяжело соответствовать, но к которой можно и нужно стремиться. Очень возможно, что, прочитав эту статью, вы чувствуете себя растерянным или разочарованным. Не расстраивайтесь, потому что Скрам — это инструмент непрерывного улучшения.
Скрам показывает относительную эффективность управления вашим продуктом и методов работы, чтобы вы могли постоянно улучшать продукт, команду и рабочую среду (Руководство по Скраму, 2017).
Постепенно меняя систему работы и организационный дизайн, возможно создавать более гибкие и успешные организации, в которых работа может быть наполнена большим смыслом.
Основные мысли статьи
- Модель “Одна команда один Владелец Продукта” вызывает ряд проблем: зависимости, работу над менее важным, хрупкость системы, оторванность команд от бизнеса и рынка;
- Не нужно управлять зависимостями, избавляйтесь от них;
- Продуктовые группы, работающие с несколькими очередями требований и “Владельцами Продуктов”, сфокусированы на менее важном с точки зрения всей организации.
- Copy Paste Scrum стимулирует “Владельцев Продуктов” занимаются “пережевыванием” требований, оформлением их в артефакты, а затем передачей их команде, что отдаляет разработчиков от рынка и клиентов.
- В профессиональном Скраме Бэклог Продукта и Владелец Продукта всегда один, независимо от количества команд.
- В гигантских продуктах команды могут группироваться вокруг областей требований (Value Areas).
