Масштабирование с помощью LeSS Huge

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

Несогласованность действий

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

Разрозненные приоритеты

Без единого фокуса и общего Product Owner’а разные подразделения могут преследовать свои цели, теряя из виду общую картину. В результате продукт распадается на фрагменты: много функций, но нет цельного видения. Команды работают вразнобой, делая части продукта без общей стратегии. Появляется эффект локальной оптимизации: каждый улучшает свой участок.

Потеря фокуса на продукте

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

Бюрократизация процессов

Столкнувшись с масштабированием, компании нередко реагируют увеличением количества правил, ролей и процедур. Казалось бы, это должно навести порядок, но на деле – ещё больше замедляет работу. Дополнительные слои иерархии и специализированные группы создают “узкие места”, очереди на принятие решений, рост затрат и падение мотивации команд. Все эти проблемы взаимосвязаны и подпитывают друг друга.

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

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

Large-Scale Scrum (LeSS) – один из таких подходов, он упрощает структуру организации, стремясь убрать сами причины перечисленных проблем. LeSS Huge – это специальная конфигурация LeSS для действительно крупных продуктовых групп. Он нацелен на то, чтобы адресовать перечисленные боли системно: через изменение организационной структуры и принципов работы, а не просто через локальные “костыли”.

Структура LeSS Huge

LeSS Huge создан специально для случаев, когда над одним продуктом работает более 8 команд (то есть свыше ~50 человек). Это расширение базового LeSS с минимально необходимыми дополнениями для большой масштабности. Даже при десятках команд продукт остаётся единым, с единой "командой" из множества команд, совместно выдающих один интегрированный инкремент за спринт.

Фокус на клиентских ценностях

В LeSS Huge весь продукт разбивается на крупные Области Требований (Requirement Areas). Область требований – это не технический модуль и не отдел организации, а логическая часть продукта, выделенная по признаку ценности для клиента. Иначе говоря, каждая область – это определённая группа функциональностей продукта, которые объединены общей идеей, близкой с точки зрения пользователя. Например, в случае сложной финансовой системы отдельными областями могут быть «Обработка транзакций», «Сервис активов клиентов», «Подключение новых рынков»и т.д. – каждое из этих направлений представляет отдельную ценность для пользователя или бизнеса.

Область Требований – не компонент и не подсистема в инженерном смысле. Это скорее направление потребностей клиента. Элементы бэклога в такой области формулируются как функции или истории, несущие законченную ценность. Например, в области “Поиск и навигация” для e-commerce продуктa элементом бэклога может быть “Реализация фильтрации товаров по характеристикам” – задача, которая затрагивает и фронтенд, и бекенд, и базу данных, но целиком относится к улучшению клиентского опыта поиска. Динамичность областей – еще одно их свойство. По мере развития продукта области требований могут дробиться, укрупняться или меняться, чтобы лучше соответствовать актуальным бизнес-потребностям.

Для каждой Области Требований ведётся Area Backlog – представление общего Product Backlog, отфильтрованное по данной области. Проще говоря, общий Бэклог продукта помечается атрибутом области, и по каждой области мы можем видеть её собственный срез бэклога. Приоритезация требований внутри области – ответственность специального Владельца продукта по области, но при этом все эти кусочки всё равно принадлежат одному общему бэклогу продукта.

Роль Area Product Owner

В классическом LeSS с 2–8 командами по-прежнему есть один Владелец Продукта. Он устанавливает приоритеты в едином бэклоге и работает напрямую со всеми командами. Однако когда масштаб переваливает за определенный порог (больше 8 команд), один человек физически уже не успевает держать в голове весь контекст продукта, общаться со всеми стейкхолдерами и отвечать на вопросы десятков разработчиков. Именно в этот момент и нужен переход к LeSS Huge. Но важно, что в LeSS Huge у каждого компонента теперь свой продукт и свой PO. Вместо этого вводится команда помощников для единого Product Owner’a.

Эти помощники – Area Product Owners (APO), Владельцы продукта по областям. Как следует из названия, каждый APO фокусируется на одной Области Требований и управляет соответствующим Area Backlog. Для команд, работающих в этой области, APO выступает практически как привычный Product Owner: уточняет требования, определяет локальные приоритеты, детализирует истории, участвует в планировании спринта и обзорах в контексте данной области.

При этом в LeSS Huge остаётся один общий Владелец Продукта (Chief PO) на весь продукт. Его зона ответственности – целостная оптимизация продукта, стратегическое направление и связка всех областей между собой. Он же развивает своих Area PO, делегируя им детальную работу. Таким образом, роль PO становится многоуровневой, но не дробящей продукт. Владелец продукта по области фактически делает то же, что и Владелец всего продукта, только в более узкой части. В то же время все APO синхронизируются между собой через общего PO, который следит, чтобы приоритеты во всех областях соответствовали общей продуктовой стратегии. Важно, что APO не конкурируют за ресурсы и внимание, а совместно соотносят свои области с общим направлением развития.

Командное взаимодействие и координация

В LeSS Huge, как и в базовом LeSS, все команды работают над единым инкрементом продукта в общем спринте. Нет разбивки на проекты со своими циклами – спринты синхронизированы по всем областям требований. Это решение заставляет организацию интегрировать результат постоянно, от спринта к спринту, а не складывать части в конце квартала или года. Даже если у вас 15–20 команд, LeSS Huge предполагает одну дату начала и окончания спринта для всех, один Sprint Review, где демонстрируется потенциально выпускаемый продукт, включающий работу всех команд.

Конечно, синхронно работать стольким командам – задача нетривиальная. Ключевую роль играет техническая культура: практики Continuous Integration (CI) и автоматизация позволяют командам ежедневно интегрировать код друг друга и быстро выявлять проблемы. LeSS Huge активно поощряет непрерывную интеграцию на уровне всего продукта. В идеале, добавление новых функций в любой области ежедневно проверяется на совместимость со всем остальным.

Требования стараются разрезать по областям так, чтобы зависимостей между областями было как можно меньше. Внутри каждой области работает от 3 до 8 кросс-функциональных команд, организованных по принципу фиче-команд. Каждая такая команда способна реализовать задачу «под ключ» внутри своей области. Вместо того чтобы строить работу на передаче задачи от аналитиков к разработчикам, потом к тестировщикам и далее, в LeSS формируются стойкие мультидисциплинарные команды, которые сами выполняют все этапы. Узкие специализированные отделы расформировываются, вместо них – автономные команды, способные разобраться и в UI, и в базе данных, и в бизнес-логике. 

Проще говоря, командам в меньшей степени приходится ждать друг друга – большинство вопросов они закрывают сами.

В LeSS Huge активно используются совместные мероприятия по продуктовому бэклогу. Общие встречи по уточнению бэклога (PBR, Product Backlog Refinement) проводятся регулярно с участием нескольких команд одновременно. На таких сессиях команды вместе с главным Product Owner’ами или Area PO разбивают крупные элементы на понятные истории, обсуждают открытые вопросы, оценивают сложности и риски. 

Важно, что PBR в LeSS Huge может проводиться как в масштабах отдельных областей (например, 3-4 команды уточняют свой Area Backlog вместе с APO), так и с участием всех ключевых людей по продукту, когда обсуждаются крупные элементы, затрагивающие несколько областей сразу. После общей очистки бэклога команды в LeSS Huge проводят привычное Планирование спринта (Sprint Planning). Обычно оно делится на две части. 

Первая часть – все Area Product Owner’ы и представители команд встречаются вместе, чтобы ориентировочно решить, какие команды какие элементы из общего бэклога берут в работу в новом спринте. Здесь важно убедиться, что суммарно команды покрыли самые приоритетные задачи продукта. 

Вторая часть – каждая команда детально планирует свою работу уже отдельно в рамках выбранных историй вместе со своим APO.

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

По окончании спринта все команды участвуют в общем обзоре спринта, где стейкхолдерам показывается интегрированный инкремент продукта. Масштаб не служит оправданием, чтобы предъявить частично готовые разрозненные куски – показывается именно цельный продукт, пусть и с неполным набором функций. После обзора проводится ретроспектива – помимо командных ретроспектив LeSS Huge предусматривает общую ретроспективу на уровне всего продукта. Обычно в ней участвуют представители всех команд, Product Owner и Scrum-мастера. Эта встреча посвящена тому, как группы сработались между собой, где были проблемы с координацией и какие системные препятствия мешают командам.

Чем LeSS Huge отличается от обычного LeSS

LeSS Huge вводит только то, что строго необходимо, чтобы масштабировать Scrum-принципы дальше.

Правило базового LeSS

Один продукт = один бэклог = один Product Owner, даже если команд несколько.

Это работало в кейсах до ~8 команд. Но когда команд становится, скажем, 15 или 20, один человек уже не в состоянии эффективно общаться с сотней разработчиков, десятками заказчиков и управлять сотнями элементов бэклога каждый спринт. Организации, игнорирующие этот предел, сталкиваются с двумя сценариями. Либо PO становится узким горлышком, не успевая отвечать командам и обновлять приоритеты, либо фактически другие люди начинают принимать продуктовые решения вместо него, размывая ответственность. LeSS Huge формально отмечает этот порог.

От 8 команд = вводим Requirement Areas и Area Product Owners. 

Это структурное решение: разгрузить мозг одного человека, разделив продуктовую экспертизу по областям, но не дробя сам продукт. LeSS Huge сохраняет единый продукт – один общий PO руководит общей картиной, а APO – его расширенные руки и глаза в каждой части продукта. Глубинная причина, почему так важно сохранить одного Product Owner’а – необходимость целостной оптимизации продукта.

Области требований вместо структурных отделов

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

Область требований – это практически автономный мини-продукт внутри большого, который приносит конкретную ценность пользователю. Команды внутри области обладают всеми навыками, чтобы эту ценность поставлять напрямую. В результате координация требуется внутри областей. Например, если выделена область “Управление аккаунтом клиента” – то 5–6 команд этой области сами решают 90% задач по реализации любой фичи, связанной с аккаунтом. Им редко нужна помощь команд из другой области. В тех случаях, когда межобластная работа всё же нужна, она обычно касается более высокоуровневых элементов и тогда в игру вовлекаются соответствующие APO и главный PO, чтобы объединить усилия.

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

Узкие специализированные компоненты -> требуются тонны внешней координации -> медленно, дорого, непрозрачно. 

Минимум новых ролей и простота структуры

В больших масштабах легко впасть в соблазн создать сложную иерархию: главных менеджеров, программных менеджеров, координаторов по уровням и так далее. 

Кроме введения роли APO, никаких новых ролей не добавляется. Нет должности Руководитель программы или Solution Architect, нет отдельной вертикали руководителей релизов, как RTE в SAFe, или потоковых менеджеров – ничего такого.

 Организация по LeSS Huge становится плоской. Одна продуктовая группа, один Product Owner и несколько его Area PO, и несколько Scrum-мастеров, помогающих всем им совершенствовать процесс. За счёт этого радикально снижается организационная сложность. Меньше людей не занятых созданием ценности, меньше отчётностей и статусов, меньше искусственных границ между командами. LeSS буквально расформировывает лишние контрольные функции, чтобы заставить команды выстраивать прямое взаимодействие. Поначалу это сложно, ведь легче спросить начальника, что делать, чем самим договориться с соседней командой, но в итоге формирует гораздо более зрелую и гибкую организацию.

Дополнительные слои и роли, помимо издержек, вводят иллюзию, что проблемы решаются. Например, найм новых менеджеров проектов для координации. Но координаторы проблемы не устраняют, они лишь превращают явные сбои в форму регламентов и совещаний, где время все равно тратится, только скрыто. LeSS Huge, следуя принципам Lean, выбирает устранение корневых причин вместо управления последствиями. Вместо того чтобы назначить ответственного за межкомандные зависимости, LeSS предлагает убрать сами зависимости через реорганизацию команд и укрупнение контекста областей. В итоге коммуникации становятся короче и быстрее.

Вместо Product Manager → Program Manager → Team

Один уровень Product Owner → Teams

Эволюционный подход к внедрению

Ещё один нюанс LeSS Huge – как его внедрять. Если базовый LeSS рекомендуется внедрять разом, то для LeSS Huge прямолинейный big-bang подход не сработает. Слишком много одновременно нужно изменить в очень большой системе. Поэтому авторы LeSS рекомендуют пошаговое развертывание LeSS Huge. Обычно предлагают два пути на выбор или комбинацию.

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

Либо постепенно расширять границы продукта и ответственности команд. Начать можно даже с одной области или части продукта, а затем увеличивать сферу, в которой команды работают по LeSS-принципам: например, сначала включить одну смежную компоненту в периметр фиче-команд, потом ещё одну, и т.д., пока все нужные компоненты и функции не войдут. Параллельно расширяется Definition of Done продукта.

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

LeSS Huge – это всё тот же Scrum, применённый к очень большому продукту и сохранивший его дух.

Неудачное масштабирование

Теория теорией, но лучше понять ценность подхода помогают реальные примеры.

Специализированные компоненты

Компания быстро росла и команды выстраивали по техническим компонентам – отдельно фронтенд, серверная часть, команда DBA, тестирование и так далее. Но по мере роста продукта выяснилось, что каждая пользовательская функция требует участия всех этих команд. Чтобы выпустить даже небольшое обновление, нужно было синхронизировать 5–7 разных групп. Возникли сложные графики релизов, очереди задач между отделами, постоянные созвоны менеджеров проектов. Темпы разработки упали – большое изменение требовало месяцы согласований. 

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

Как помогает LeSS Huge. Вместо компонентных команд – кросс-компонентные фиче-команды, способные сами выполнять всю работу от UX до базы данных. Вместо разрозненных отделов – продуктовые области, внутри которых зависимость команд друг от друга минимальна. Если бы в вышеописанной компании применили LeSS Huge, то, скажем, 6 команд работали бы вместе над целостным куском функциональности (областью) и имели нужную экспертизу внутри команды, чтобы реализовать любую историю без передачи задачи на сторону. Это устранило бы большую часть очередей – просто некого было бы ждать, команды всё делают сами. 

Там, где зависимости между областями всё же остаются, LeSS Huge предлагает выявлять их заранее на общих PBR и решать через прямое общение команд, а не через многоуровневое администрирование. И самое главное – здесь бы не потребовались множества координаторов и менеджеров. Лишние роли сами отмерли бы за ненадобностью, когда люди начали бы напрямую договариваться. Конечно, перейти сразу от компонентных к фиче-командам непросто – поэтому LeSS Huge рекомендует постепенный переход, например, сначала объединить разработчиков и тестировщиков в одной команде, потом подтянуть аналитиков, и так далее.

Каждая команда сама по себе

Организация, пытаясь быть Agile, дала автономию каждой из множества команд. У каждой команды – свой Product Owner или менеджер, который общается со своими стейкхолдерами и решает, что делать. Сначала команды работали параллельно и каждая выпускала что-то своё. Но вскоре обнаружилось, что продукт перестал быть цельным, разные части системы развивались вразнобой. Например, веб-версия продвинулась в функционале, а мобильное приложение отстало и не поддерживало новые возможности. Одни модули реализовали одну бизнес-логику, а другие – противоречащую ей. Пользователи жаловались на непоследовательность опыта. 

Внутри компании возникли конфликты приоритизаций: отдел А требовал от команды X немедленно сделать функцию P, потому что у них OKR, а отдел B давил на эту же команду X с другим запросом. Без единого Владельца продукта эти споры решались – чей начальник убедительнее. Время и энергия тратились на конкуренцию ресурсов, вместо сотрудничества. В итоге некоторые сильные специалисты покинули команды, разочаровавшись, а оставшимся всё труднее было понимать, куда движется компания.

Руководство, увидев проблему, пыталось ввести “стратегический комитет”, который раз в полгода сверстал бы общий roadmap. Но к тому времени каждый «мини-PO» уже тянул одеяло на себя, и договориться о едином плане было почти нереально. В результате компания за несколько лет так и не выпустила ни одной действительно интегрированной версии продукта – клиент получал либо сырые прототипы, либо обещания.

Как помогает LeSS Huge. В его основе заложен единый продукт с единым бэклогом и единым направлением. Каким бы большим ни был продукт, у него остаётся один Product Owner, отвечающий за целое. В описанном случае LeSS Huge вообще бы не позволил формально появиться множеству несвязанных PO – вместо этого была бы выстроена команда APO вокруг единого PO. Все Area Product Owner’ы регулярно работают с главным PO, синхронизируя приоритеты. Практически это может выглядеть как еженедельные встречи всех APO с Chief Product Owner, где обсуждается прогресс и планы каждой области. 

Кроме того, LeSS Huge предполагает общий Sprint Review – то есть каждые 2-4 недели вся верхушка видит интегрированный результат. Если какой-то модуль отстаёт – это станет очевидно на демо, и общий PO сможет перераспределить внимание. Даже если единый бэклог разделён на части по областям, у главного PO всегда есть полная картина и возможность перетасовать приоритеты между областями. Например, если мобильное приложение начало отставать, главный Владелец продукта может поднять задачи мобильной области выше в общем приоритете или даже перебросить пару команд из другой области временно на усиление мобильной.

Масштабировать, уменьшая сложность

LeSS Huge – это взгляд на масштабирование продуктовой разработки через призму упрощения. Опыт больших компаний показывает, что путь «усложнения ради контроля» ведёт к тупику: организации становятся неповоротливыми, теряют новаторство, а сотрудники – мотивацию. Large-Scale Scrum предлагает иной путь – “большой Scrum” без лишнего.

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

LeSS Huge не обещает, что станет легко – большие продукты по определению сложны. Однако он показывает, как управлять этой сложностью с помощью первоначальных agile-принципов: через людей и их взаимодействие, через работающий продукт, через сотрудничество с заказчиком, через готовность меняться. Упрощая организацию, мы высвобождаем потенциал команд и их ориентированность на результат. 

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