Освобождай и властвуй — эффективное управление изменениями в SAFe®

Перевод статьи Effective Change Control «by Release» in SAFe выполнен с разрешения автора Mark Richards.

«Контроль через освобождение… Контроль через предоставление свободы действий в рамках хорошо понятных параметров. Контроль путем доверия процессу. Это не значит, что все идет как попало» — Artful Making: What Managers Need to Know About How Artists Work 1st Edition by Robert Austin (Author), Lee Devin (Author), Eric Schmidt.

В рамках «классической» модели поставки организации используют сочетание контроля этапов работ и детально проработанного плана работ, стоимости и сроков для облегчения управления, контроля за изменениями и мониторинга руководством затрат стратегически важных продуктов.

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

1. Управление инвестициями по горизонтам роста.
2. Оптимизация ценности и целостности решений с помощью распределения ресурсов.
3. Утверждение значимых инициатив.
4. Непрерывное вовлечение Представителей Бизнеса (Business Owners).

Пример определения Lean Budget Guardrails на тренинге Lean-управление портфелем в SAFe

Вступительная цитата взята из одной из книг, оказавших на меня глубокое влияние в начале моей Agile-карьеры — Artful Making (прим. пер. — искусство принятия решений). Понятие «контроль посредством предоставления свободы» было ключевым компонентом моего тренерского инструментария в течение многих лет, особенно в контексте децентрализации. В этой статье я рассмотрю тему «контроля посредством предоставления свободы» в каждом пункте, когда мы определяем «что делать», а затем перейду к инструментам, которые помогут нам во время выполнения PI (Program Increment, Инкремент Программы), когда мы непосредственно «делаем».

Управление инвестициями по горизонтам роста

Этот защитный механизм контролирует процент инвестиций, который может быть потрачен на идеи определенного горизонта. «Освобождение» обеспечивается отсутствием ограничений на рассматриваемые идеи, а «контроль» гарантирует, что инновационные идеи горизонта 3 и привлекательного горизонта 2 не будут вытеснены всепоглощающим «спросом сегодняшнего дня» горизонта 1.

Три горизонта роста — Вестник McKinsey

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

Оптимизация ценности и целостности решений с помощью распределения ресурсов

Еще один инструмент управления на основе процентного соотношения, который обычно применяется на уровне принятия решений и уровне Программ. Классическим сценарием являются цифровые продукты B2B (Business-To-Business) — они часто оказываются перед следующей дилеммой:

• «Без поставщиков B2B мы не сможем привлечь потребителей B2C (Business-To-Consumer) «.
• «Без потребителей B2C мы не сможем заключить контракт с поставщиками B2B».

Этот уровень значительно выше, чем «какую фичу мы должны создать» — это уже стратегический инструмент. «В течение следующих 2 PI мы хотим инвестировать в сеть B2B 70% наших ресурсов». Таким образом, мы достигаем «контроля», указывая процент ресурсов ART (Agile Release Train), который будет потребляться фичами B2B, и «свободы», поскольку на самом деле мы не говорили о том, какие именно фичи B2B должны быть рассмотрены.

Это решение часто не входит в компетенцию Продуктового Менеджмента (Product Management). Оно должно быть одобрено Представителями Бизнеса (Business Owners), руководством Портфеля или ими совместно, но после принятия такого решения они получают свободу действий, чтобы найти лучшие фичи для использования этого потенциала.

Утверждение крупных инициатив

Менеджер Продукта в ART имеет значительные полномочия, когда дело доходит до выбора фич. В зрелом SAFe большинство создаваемых фич являются независимыми, определенными в рамках стратегии продукта, а не полученными посредством декомпозиции Эпиков. Менеджер Продукта уполномочен не только определять фичи и способствовать их приоритезации (с помощью WSJF, Weighted Shortest Job First, Более Ценная и Короткая Работа Сначала), но и нести ответственность за достижение экономических результатов ART, которые оправдывают расходы. В этом есть определенный уровень безопасности и контроля, поскольку мы знаем, что Фича должна иметь количественную, быстро измеряемую выгоду и должна быть небольшой — достаточно небольшой, чтобы уложиться в один PI для одного ART.

Однако, что делать, когда Менеджер Продукта сталкивается с большой идеей — не Фичей, а с Эпиком? Тогда нужна более тщательная проверка: согласование и мониторинг на уровне Портфеля. «Прежде, чем начать двигаться по этому пути, его нужно утвердить».

Менеджер Продукта «освобождается» для реализации ряда небольших ценных инвестиций, но работает под «контролем»: если инвестиции превышают определенный порог, то в процесс должны быть вовлечены более высокопоставленные должностные лица.

Непрерывное вовлечение Представителей Бизнеса

В конце прошлого года я посвятил этому целый пост: Запусти поезд SAFe с правильным бизнесом на борту. Как нам «освободить» Менеджера Продукта для выполнения той работы, для которой он был назначен? Путем обеспечения «контроля» взаимодействия с Представителями Бизнеса для их вовлечения в те моменты, когда устанавливаются ключевые ограничения.

Для этого в SAFe есть 4 четко определенных события «контроля»:

• Представители Бизнеса взаимодействуют для определения стоимости задержек потенциальных фичей и, таким образом, «контролируют» приоритеты, в то же время «освобождая» Менеджера Продукта для поиска фичей, которые необходимо представить для приоритизации.
• Представители Бизнеса сотрудничают для «контроля» решений по поиску компромиссов во время Рецензирования руководством и решения проблем на РI-планировании, при этом «освобождая» команды для выявления необходимых компромиссных решений, а затем утверждают поставленные цели, чтобы установить «контроль» вокруг ожиданий по обязательствам на РI-планировании.
• Системная Демонстрация (с участием Представителей Бизнеса) показывает прогресс за прошедшую итерацию и должна иллюстрировать соответствие соглашению, достигнутому при PI-планировании.
• Демонстрация PI, во время которой Представители Бизнеса оценивают достигнутые результаты по поставленным целям.

За пределами ограничений портфеля

Каждое из этих ограничений обеспечивает контроль над тем, что мы решаем делать на разных уровнях управления: периодичность и детализацию. Однако, что происходит, когда мы непосредственно «делаем»? Или, говоря более традиционным языком, «как мы применяем контроль изменений во время выполнения?”

«Хиппи-agilist” внутри меня начинает нервничать, когда речь заходит о второй половине этого поста. Конечно, я не собираюсь начинать разговор о страшном «запросе на изменение» (change request). А как же второй принцип Agile: «Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества»? К сожалению, я видел, как этим принципом злоупотребляют больше, чем любым другим (причем требование принципа 8: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки” — безусловно, наиболее часто игнорируется — обычно в контексте злоупотребления принципом 2). Слишком часто он интерпретируется так: «Я думал, что это Agile и я могу передумать в любой момент» — не принимая во внимание, что изменение может повлиять на стоимость, сроки или другие обязательства.

Итак, как мы можем предоставить «свободу» принять меняющиеся требования, сохраняя при этом «контроль» для обеспечения ответственного подхода?

Создание защитных ограничений для выполнения ART

У нас есть подсказки для этих элементов управления из Портфеля. Система принятия решений должна учитывать следующее:

• В какой момент команде необходимо передать решение или уведомление на уровень Программы?
• В какой момент ART необходимо передать решение или уведомление Представителям Бизнеса?

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

• Обязательные цели PI (Committed PI Objectives).
• Распределение ресурсов.

Оба элемента контроля были согласованы и утверждены Представителями Бизнеса. В ART предоставлена «свобода» вносить любые изменения в рамках этих элементов управления. Например, предварительно согласовано с Представителями Бизнеса, что если PI столкнется с трудностями, то дополнительными целями (Stretch PI Objectives) можно будет пожертвовать без согласования. Однако, рассмотрим некоторые примеры «пусковых механизмов контроля».

Распределение ресурсов на операционные задачи

Применение распределения ресурсов на BAU (прим. ред. — Business As Usual, операционная деятельность) или внеплановых работ было подробно рассмотрено в моем недавнем посте о BAU и внеплановых работах: Dealing with Unplanned and/or BAU work in SAFe — но для иллюстрации приведу пример с контролем изменений:

• Команде было выделено 10% ресурсов на BAU/внеплановую работу.
• Владелец Продукта теперь «освобожден» от необходимости расставлять приоритеты для любых историй, которые он считает важными (будь то незначительные улучшения, устранение технического долга или исправление мелких производственных дефектов), пока они находятся в пределах 10% от возможностей команды на каждую итерацию.
• В случае, если BAU и внеплановая работа угрожают превысить ограничение ресурсов (например, череда срочных запросов на мелкие улучшения от беспокойных заинтересованных лиц), мы включаем «контроль». Это уже не командное решение, и оно должно быть передано на уровень Программы.
• На уровне Программы может существовать решение «системного уровня», которое все же может быть ограничено в рамках ART. Например, перенаправить часть работы в другую команду или пожертвовать достижением поставленной цели из-за важности внеплановой работы.
• Если не существует решения на уровне ART, которое не ставит под угрозу поставленные цели, и команда программы не может по политическим соображениям отказаться от BAU-работ, решение должно быть передано Представителям Бизнеса для принятия решения: «Готовы ли мы пожертвовать стратегическими целями ради этой внеплановой работы или мы воспользуемся своими исполнительными полномочиями, чтобы отложить внеплановую работу?”

Значительное изменение в поставленной цели

Мы знаем, что команды не берут обязательство выполнить свои планы или истории на PI-планировании — они обязуются достичь поставленных целей. Истории и планы представляют собой текущее видение наилучшего способа достижения целей. Однако, в этой истории есть нечто большее, чем кажется на первый взгляд:

• Несмотря на то, что цели должны быть SMART (прим. ред. — Specific — конкретная, Measurable — измеримая, Attainable — достижимая, Relevant — уместная, Time-bound — ограниченная во времени), они редко бывают таковыми. Это оставляет возможность для открытой интерпретации и Владельцу Продукта легко оказаться в полной мучений ситуации, когда эксперты предметной области, заинтересованные лица и Менеджеры Продуктов утверждают, что в цели есть скрытые аспекты, которые команда не предусмотрела.
• Цели «в контексте системы». Представители Бизнеса принимают «общие цели для ART» и принимают компромиссные решения для оптимизации целого, а не отдельных частей. Неявным в процессе достижения этой цели является то, что план команды отражает примерный процент возможностей команды или ресурсов ART, которые будут затрачены на достижение цели (т.е. в плане было 78 story points, связанных с этой целью). Мы знаем, что оценки — это предположения, но если мы вдруг имеем дело со 150 story points, то, несомненно, нас ждут большие неприятности. Это может произойти из-за неприятных сюрпризов, пропущенных историй или споров об интерпретации, но как бы то ни было, нет сомнений, что мы в этой ситуации страдаем. Будь то дисфункция между Владельцем Продукта и командой, Владельцем Продукта и Менеджером Продукта, или Владельцем Продукта и заинтересованными лицами, эта проблема может нанести ущерб ряду других задач.

Распространенной техникой является установление контроля типа «порог размера». Например, в случае, если общий предполагаемый размер Фичи отличается более чем на 20% от установленного на PI-планировании, это должно быть передано на уровень Программы для рассмотрения. Часто проблему можно решить на уровне Программы с помощью эффективных компромиссных решений (путем корректировки ожиданий, привлечения других команд на помощь или принесения в жертву дополнительных целей). Однако, если проблему решить невозможно, мы оказываемся в ситуации, когда выполнение одной поставленной цели ставит под угрозу одну или несколько других — и это уже решение Представителя Бизнеса. И снова, это должно быть передано на уровень выше. Они могут поддержать сокращение объема работ или пожертвовать другой целью, чтобы сохранить её полный объём.

Цель не может быть достигнута

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

Заключение

Если бы я прочитал эту статью 10 лет назад, мой ответ был бы: «Это слишком структурировано, чтобы быть гибким». За прошедшие годы мои взгляды стали менее упрощенными, поскольку я работал с крупными организациями и государственными учреждениями, которым нужны свидетельства того, что на местах существуют задокументированные механизмы контроля, и которые стремятся к «более простому, менее затратному, но все же надежному подходу».

Но, если честно, больше всего меня мотивирует заниматься этим вопросом помощь «командам, которые страдают». В последние годы я работал с рядом ART, которые испытывали огромные трудности с достижением 50% «предсказуемости релизов», не говоря уже о получении 80% даже при непомерно высоком уровне сверхурочной работы. Существует множество причин, способствующих этому, но бесконтрольное изменение границ проекта является постоянной тому причиной. Команды, пытающиеся сотрудничать со своими Владельцами Продуктов, допускают слишком много изменений в результате появления у Владельцев Продуктов новых ярких идей. Владельцы Продуктов пытаются дать отпор, когда их Менеджер Продукта продолжает пересматривать целевые задачи их Фичей благодаря нечетким целям PI и отсутствующим/неполным критериям приемки (Acceptance Criteria) фич. Владельцам Продукта трудно сказать «нет», когда авторитетные заинтересованные лица предлагают отличные идеи. Это не смешно, и команды не получают удовольствия ни от сверхурочной работы, ни от ощущения неудачи, когда они раз за разом не достигают поставленных целей.

Правда в том, что каждое изменение подразумевает принятие решения, а каждое решение — это принятие компромиссного решения. Команда принимает компромиссное решение, которое приводит к оптимизации на уровне команды, команда Программы принимает компромиссное решение, которое приводит к оптимизации на уровне ART, а Представители Бизнеса оптимизируют еще на более широком уровне. Хорошая дисциплина бэклога и эффективное использование средств контроля, встроенных в SAFe, позволяют принимать правильные компромиссные решения на нужном уровне в нужное время и убедить экспертов в том, что эффективные средства контроля работают!

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.