SAFE 6.0 и восемь практик ускорения потока: взгляд изнутри

Недавно вышло обновление SAFe 6.0, и вместе с ним — блок, посвящённый оптимизации потока работы. Среди нововведений выделяются восемь практик ускорения потока. Сегодня разберём их подробнее с экспертом — Алексеем Ионовым, SAFe-тренером и владельцем консалтинговой компании «Ионов и партнёры».

О спикере

Алексей работает с SAFe с 2017 года и за это время обучил более 2000 специалистов. Его проекты охватывают как российский рынок, так и зарубежные компании (в частности, Беларусь и крупные команды в Польше для банковского сектора). Среди клиентов — известные организации, где масштабные внедрения SAFe дали ощутимый результат.

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

Личное

За рамками консалтинга у Алексея есть заметные хобби. Например, он построил копию Lamborghini Countach — проект, который занял первые места на выставке «Автоэкзотика». Кроме того, он увлекается скейтсерфингом и экспериментирует с электроникой: сам разработал и запрограммировал контроллер, управляющий всеми системами его автомобиля.

SAFE 6.0 и работа с потоком

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

SAFe предлагает пять ключевых направлений:

• Фасилитация картирования потока ценности (Value Stream Mapping).
• Создание Kanban-систем.
• Измерение потока.
• Оптимизация через восемь ускорителей.
• Формирование мышления, ориентированного на поток.

Сегодня мы остановимся на четвёртом пункте — восьми ускорителях.

Практика 1. Визуализация и ограничение незавершенной работы (WIP-лимиты)

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

На уровне команд

Тут практика воспринимается проще всего. Kanban давно знаком разработчикам, и настройка WIP-лимитов редко вызывает отторжение.

На уровне ART (Agile Release Train) и Solution Train

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

• отсутствие ясных приоритетов на уровне продуктовой разработки;
• опасения, что визуализация приведёт к росту внешних требований («раз вы показали, что делаете три задачи, значит, можете взять ещё пять»).

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

Практический старт

SAFe не диктует конкретных техник установки лимитов. Подходы могут быть разными:

• оценка текущей загрузки и постепенное снижение WIP;
• использование практик из Kanban-метода;
• обучение через практические упражнения (например, упрощённые «фичебаны», где команды наглядно видят пользу ограничения работы в процессе).

Важно: лимиты нельзя зафиксировать «раз и навсегда». Их нужно постоянно пересматривать и улучшать по мере развития команды и системы.

Практика 2. Устранение узких мест

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

Книга Голдратта «Цель» до сих пор остаётся хорошим вводным материалом: она ясно объясняет, почему именно работа с ограничениями даёт наибольший эффект для системы.

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

Технические и организационные аспекты

Интересный нюанс — многие технические и технологические ограничения на деле оказываются организационными. Например:

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

Здесь вступает в силу ключевой принцип гибкой разработки — прямая коммуникация face-to-face. Простое выстраивание эффективных коммуникаций часто снимает то, что считалось «узким местом».

Практическая реализация

Чтобы работать с узкими местами объективно, нужно их измерять и отслеживать:

• в Kanban-системе можно вводить буферные столбцы для переходов между исполнителями;
• применять концепцию «барабан–канат–буфер» из теории ограничений;
• использовать статейную базу SAFe 6.0, где на каждом уровне фреймворка (Team Flow, ART Flow, Portfolio Flow) приводятся конкретные рекомендации.

Динамика ограничений

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

Опыт внедрения

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

Практика 3. Минимизация передач и зависимостей

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

Почему это важно

• Внутри одного ART договориться проще, чем с внешними подразделениями.
• Внешние зависимости (особенно с другими поездами или регуляторами) несут больший риск и требуют больше времени.
• Чем меньше таких связей, тем выше скорость потока.

Подходы к работе

• Компетенции команд. Продукт-менеджеры и владельцы продукта должны хорошо понимать, какие компетенции есть в командах ART, чтобы при написании фич и историй минимизировать зависимости.
• Планировочная доска. На PI Planning нужно отслеживать «верёвочки», пересекающие границу поезда, — именно они самые рискованные.
• Классификация зависимостей. В SAFe все они называются просто «зависимостями», но на деле могут тянуться от разных типов артефактов: бизнес-фичи, архитектурные фичи, исследовательские, инфраструктурные или регуляторные.

Почему выделено в отдельную практику

Устранение узких мест — тема широкая. Но так как зависимости и передачи оказывают критическое влияние на скорость потока, в SAFe 6.0 их вынесли в отдельный ускоритель.

Практика 4. Получение быстрой обратной связи

Короткие циклы обратной связи — один из столпов гибкой разработки, и SAFe делает на этом особый акцент.

Распространённый миф

Считается, что в SAFe команды не общаются с клиентом напрямую. На самом деле это не так:

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

Зачем нужна скорость

• Проверка гипотез «малой кровью»: вместо того чтобы вкладывать большие ресурсы в идею, нужно быстро получить сигнал от клиента.
• Избежание «pet projects» — инициатив, запущенных исключительно по прихоти руководителя.
• Ускорение принятия решений по технологическим вопросам: вместо долгих дискуссий проще дешёвым экспериментом проверить, какая архитектурная гипотеза работает.

Практика 5. Работа малыми партиями

SAFE рекомендует планировать партии работы так, чтобы они умещались в рамки каденции:

• история должна завершаться в итерацию;
• фича — в PI;
• поезд — завершать набор фич в рамках PI.

Чем меньше партия, тем быстрее обратная связь и ниже риск «заморозить» ценность в незавершённой работе.

Экономический аргумент

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

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

Задача менеджмента — осознать: «стоимость хранения» применима и к интеллектуальной собственности.

Практика 6. Сокращение длины очереди

Эта практика связана с законом Литтла: время прохождения задачи через систему прямо пропорционально длине очереди. Чтобы ускорить поток, нужно уменьшать количество зависимых и «застрявших» элементов.

Ключевая идея

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

На практике это требует грамотной декомпозиции:

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

Практика 7. Нахождение в зоне

Речь идёт о создании условий, при которых люди достигают состояния высокой концентрации и эффективности. Этот термин восходит к работам Михая Чиксентмихайи («Поток») и Дэна Пинка («Драйв»).

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

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

Что важно в SAFE:

• оставлять команды в покое на время итерации;
• минимизировать вмешательства «эффективных менеджеров»;
• фиксировать рамки PI и итераций: либо выполняем в них, либо переносим, но не раздуваем.

Практика 8. Исправление устаревших политик

SAFE подчёркивает: многие барьеры для потока лежат не в технологиях, а в политиках и регламентах.

Когда корректировать

• На старте трансформации. Уже на первых мероприятиях становится ясно, какие регламенты мешают.
• Регулярно. На ретроспективах нужно анализировать не только процессы команд, но и систему управления в целом.

Типичные проблемы

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

Что почитать

Алексей Ионов рекомендует книгу Джона Коттера «У нас это делают не так» — она ярко показывает, как привычные практики могут саботировать изменения.

Итоги

В SAFe 6.0 восемь ускорителей потока связаны между собой:

• визуализация и WIP-лимиты;
• устранение узких мест;
• минимизация передач и зависимостей;
• получение быстрой обратной связи;
• работа малыми партиями;
• сокращение длины очереди;
• нахождение в зоне;
• исправление устаревших политик.

Эти практики дают эффект не по отдельности, а в совокупности. SAFE 6.0 предлагает не только инструменты, но и мышление, ориентированное на поток ценности.