Безжалостное непрерывное улучшение оргструктуры по SAFe®

Эта статья является вольным переводом статьи Identify Value Streams and ARTs — Scaled Agile Framework.

Нужна быстрая поставка ценности клиенту?
Ломайте преграды между департаментами!
(c) Эдвардс Деминг

Потоки создания ценности (Value Stream) и поезда (Agile Release Trains, ARTs) являются самой важной частью фреймворка SAFe (Scaled Agile Framework). Без правильного организационного дизайна вы столкнетесь с множеством зависимостей и замедлением скорости поставки.

5 шагов дизайна

Нужно пройти 5 шагов для идентификации поездов:

1. Определить операционные Value Stream.
2. Определить системы, которые поддерживают операционные Value Stream.
3. Определить людей, которые разрабатывают и поддерживают эти системы.
4. Определить разработческие Value Stream на основе шагов 1-3.
5. Выбрать поезд(а) (ART), которые будут реализовывать разработческие Value Stream.

Value Stream

Value Stream — это последовательность действий по созданию ценности от первичного запроса до поставки итогового результата клиенту.

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

Время от запроса до получения ценности называется Lead time. Самый простой способ уменьшить Lead time — это выявить работу, которая не приносит ценности, или выявить любые задержки при передаче информации между участниками.

Понятие Value Stream также включает:

• людей, которые выполняют работу;
• системы, которые они используют;
• информацию и материалы, которыми обмениваются участники.

Типы Value Stream

Выделяют два типа Value Stream:

• Операционные Value Stream — это люди и процессы, осуществляющие доставку ценности конечному клиенту. Часто эту деятельность компании называют RUN.
• Разработческие Value Stream — это люди и процессы, которые разрабатывают новые продукты, решения, процессы, системы, услуги компании. Они развивают операционные Value Stream. Именно разработческие Value Stream являются частью портфолио в SAFe. Часто эту деятельность компании называют CHANGE.

Для того, чтобы наиболее оптимальным способом спроектировать разработческие Value Stream, необходимо сначала построить карту операционных Value Stream.

Шаг 1. Определите операционные Value Stream

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

Для определения начните с вопросов из таблицы:

Шаблон описания Value Stream

Этот шаблон описывает общие характеристики, которые полезно определить до анализа Value Stream.

Пример операционного Value Stream предоставления кредитов физическим лицам

Рассмотрим пример из банковской сферы по получению кредита:

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

Эта карта похожа на Customer Journey Map (CJM, карта путешествия потребителя) за исключением того, что цель применения этого инструмента иная. CJM выявляет проблемные области и подсказывает, как увеличить продажи и повысить лояльность клиентов. Операционный Value Stream в SAFe визуализируется для оптимизации организационной структуры.

Шаг 2. Определите системы, которые поддерживают операционный Value Stream

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

Шаг 3. Определите людей, участвующих в разработке

После определения систем давайте оценим количество людей, которые их разрабатывают и поддерживают, а также их местоположение.

Шаг 4. Определите разработческий Value Stream

На следующем шаге мы переходим к определению разработческого Value Stream.

Разработческий Value Stream — это шаги, которые нужно пройти для разработки систем операционного Value Stream. У разработческого Value Stream свои входные триггеры и своя поставляемая ценность. Обычно ценность — это добавленные или измененные возможности продукта, а триггеры — это новые идеи по развитию продукта.

Анализ входящих требований позволяет понять, сколько будет разработческих Value Stream. К примеру, если бОльшая часть требований требует изменения всех систем, вероятно, будет один разработческий Value Stream. А если системы не сильно связаны, то можно разбить Value Stream на несколько (при необходимости).

Как бы вы их не спроектировали, разработческие Value Stream должны быть по максимуму независимы между собой.

Одна из систем в нашем примере разрабатывается внешним вендором, по этой причине его команды не попали ни в один из поездов.

Разработческие Value Stream являются сквозными к организационной структуре

Компании обычно организованы по функциям. Это происходит по нескольким причинам: история развития, функциональное удобство, эффективность централизации людей одной компетенции, география.

Бережливые (Lean) организации нацелены на улучшение всего потока целиком. Это требует понимания, как лучше всего организовать взаимную работу разных частей организации.

Обычно на этом шаге уже понятно, что разработческие Value Stream не помещаются в рамках одного департамента и пронизывают организационную структуру организации.

А в особо крупных компаниях поток создания ценности пронизывает не только границы департаментов, но и стран.

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

Шаг 5. Определение ART

Заключительный шаг — это определение ART, которые реализуют добавленную ценность.

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

Практический опыт показывает, что поезда наиболее эффективны когда:

• Включают 50-125 человек.
• Сфокусированы на конечной ценности.
• Зависимости между поездами минимизированы.
• Поставка разных поездов независима.

Возможны три конфигурации дизайна поезда.

1) Один поезд реализует несколько Value Stream:

2) Один поезд реализует один Value Stream:

3) Для крупного решения необходимо несколько поездов:

Разделение Value Stream на несколько ART

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

Зависимости могут быть продуктовые, а могут быть компонентными, поэтому группировка может быть двух типов:

• Фича-поезд (Feature area ART) может поставлять законченные сквозные фичи (end-to-end). Этот вариант является предпочтительным. Выбрав этот вариант, не забывайте о необходимости архитектурного контроля за состоянием подсистем. Накопление технического долга в связи с погоней за новой функциональностью может приводить деградации скорости в будущем. Часто системный архитектор (или даже небольшая команда) выделены для поддержки целостности платформы.
• Поезд по подсистемам (Subsystem ART) оптимизирован для сохранения архитектурной надежности и переиспользования подсистем и сервисов (актуально для сервис-ориентированных архитектур). Обычно в таком подходе количество зависимостей между командами больше, в том числе между поездами.

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

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

Рассмотрим примеры дизайнов поездов из опыта различных компаний.

У каждого канала свой поезд + есть платформенный поезд:

У каждого продукта свой поезд (внутри поезда охвачены все каналы) + есть платформенный поезд:

По шагам Value Stream без платформенного поезда:

В этом случае каждый поезд отвечает за часть шагов Value Stream, а в развитие платформы вкладываются все 3 поезда.

Выбор оптимального варианта дизайна поездов

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

Воркшоп по дизайну поездов

Для того, чтобы помочь вам в этом процессе, Scaled Agile Inc. дает набор инструментов для проведения воркшопа по идентификации Value Stream и поездов (инструменты для SAFe Program Consultants, SPCs).

Набор инструментов предлагает проверенный, системный подход для оптимизации дизайна с учетом зависимостей, координации и ограничений компании.

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

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

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