Улучшение потока с помощью Мастерской Решения Проблем

13 февраля 2025

Авторы статьи: Odile Moreau, Strategic Advisor & SPCT, Scaled Agile Inc. и Rune Christensen, Strategic Advisor & SPCT, Scaled Agile Inc.

Мастерская решения проблем

Зачем нужно улучшать поток с помощью мастерской решения проблем?

Мастерская SAFe по решению проблем (Problem-solving workshop, PSW) входит в программу мероприятия «Инспект-Адапт» (Inspect & Adapt, I&A). Основная цель мероприятия – поддержать одну из ключевых ценностей SAFe — неустанные улучшения внутри Релизного Поезда (Agile Release Train, ART). Проведение мастерской предоставляет командам время и пространство, чтобы подумать об основных препятствиях, с которыми они сталкиваются, и совместно найти способы улучшений и решения проблем.

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

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

Статья предназначена для тех, кто обычно фасилитирует мастерскую по решению проблем – это обычно SPC, RTE, Скрам Мастера / Коучи Команд, лидеры Центра Lean-Agile Мастерства (Lean-Agile Center of Excellence, LACE) и члены Офиса Управления Ценностью (Value Management Office, VMO).

Мы надеемся, что подход, который описывается в этой статье, поможет вам сделать мероприятие интересным и не «пресным».

Представляем Канву «Ускорение потока»

Мастерская решения проблем в нашем случае будет выстраиваться вокруг Канвы «Ускорение потока», которая показана на рисунке 1. Процесс Дизайн-мышления помогает заполнить эту канву, требуя сфокусироваться как на понимании проблемы, так и на поиске решения.

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

Рисунок 1: Канва «Ускорение Потока»

Канва «Ускорение потока» состоит из трех разделов:

1. Изучение проблемы
Здесь мы рассматриваем проблемы, с которыми может сталкиваться Релизный Поезд (Agile Release Train). Выявленные проблемы являются результатом изучения одной или нескольких метрик потока. Здесь мы исследуем корневую причину и чётко описываем, какое влияние изучаемая проблема оказывает на поток ценности.

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

3. Улучшения
Наконец, поезд (Agile Release Train) формулирует один или несколько элементов улучшений, которые ART и отдельные команды в его составе команды могут применить в течение предстоящего Интервала Планирования (Planning Interval, PI).

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

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

Готовимся к проведению мастерской по решению проблем

Исходя из нашего опыта, мы рекомендуем выполнить следующие действия перед семинаром:

  1. Выбрать подходящие метрики потока
  2. Сформулировать проблему в письменном виде
  3. Зафиксировать влияние, которое оказывает проблема
  4. Довести эту информацию до сведения всех членов ART и его заинтересованных лиц

Выбор подходящих метрик потока

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

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

В таблице на рисунке 2 кратко описаны метрики, которые поезд (Agile Release Train) может выбрать для отслеживания. Более полное объяснение каждой метрики потока см. в статье «Метрики SAFe».

Рисунок 2: Шесть метрик потока

При этом мы не предлагаем одновременно использовать все 6 метрик потока. Мы скорее рекомендуем RTE выбрать те метрики, которые помогут прежде всего выявить проблемы и управлять производительностью.

Формулирование проблемы

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

На рисунке 3 приведены примеры распространённых проблем, которые выявляются на основании использования конкретных метрик потока.

Рисунок 3: Связывание метрик потока с потенциальными проблемами

ПРИМЕР:

На протяжении всего Интервала Планирования (PI) RTE отслеживал метрики потока. На мероприятии «Синхронизация Коучей» (Coach Sync) он/она представил полученные результаты своим коллегам. По мере выполнения итераций участники заметили снижение эффективности потока с 9% до 6%.

Одновременно с этим Скрам Мастер из Команды ИИ увидел, что его команда не справляется со многими входящими запросами, что приводит к задержкам в доставке внутри всего ART.

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

RTE и Скрам Мастера использовали таблицу на рисунке 3 для сопоставления выбранной метрики потока с проблемами, возникшими в течение Интервала Планирования (PI).

Результатом мероприятия «Синхронизация Коучей» стало решение о том, что необходимо сосредоточиться на метрике «Эффективность Потока». Первоначальная формулировка проблемы звучит так: «В этом Интервале Планирования наши команды столкнулись с серьезными задержками из-за того, что наша команда ИИ не могла справиться со всеми входящими запросами».

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

Формулируем влияние проблемы

Мы обнаружили, что формулировка влияния, которое оказывает проблема, («заявление об оказываемом влиянии») является чрезвычайно важным элементом для успешного изучения проблемы. Это гарантирует, что мы основываемся на фактах о последствиях проблемы, а также создаёт ощущение срочности в поиске решений для неё.

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

ПРИМЕР:

Проводим Мастерскую решения проблем

Начало мастерской

В начале мастерской RTE представляет проблему (их может быть несколько), над которой будет работать Релизный Поезд (ART).

Мы рекомендуем здесь представить следующие данные из рассмотренной выше Канвы Ускорения Потока: 1) информация о метриках потока, 2) формулировка проблемы, которую необходимо решить, и 3) данные о её влиянии на бизнес организации. Таким образом, участники будут точно знать, какие проблемы необходимо решить, и смогут выбрать ту проблему, которая их больше всего волнует.

Во время мастерской (PSW) заполняются следующие разделы:

  1. Изучение Проблемы: Дальнейшее изучение проблемы и выявление корневой причины.
  2. Поиск Решения: определение возможных шагов для устранения корневой причины.
  3. Раздел улучшений: Создание элементов улучшения для их дальнейшей приоритизации в беклоге.

Примечание: как правило, Мастерская решения проблем занимает около 90 минут. При этом объём времени, необходимый на проведение мероприятия, будет зависеть от размера поезда (ART) и количества команд в нём.

Определение корневой причины

Прежде чем приступить к поиску решения, нам необходимо убедиться, что мы работаем над истинно корневой причиной проблемы. Проведение Анализа Корневых Причин (АКП) крайне важно для анализа и выявления основных причин проблемы. Чтобы изучить и выбрать наиболее вероятную корневую причину, мы рекомендуем сначала применить технику «5 почему», а затем провести анализ Парето.

ПРИМЕР:

 

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

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

Заполняем раздел «Поиск Решения»

В разделе канвы «Поиск Решения» необходимо выполнить четыре действия:

  1. Определить подходящий ускоритель (может быть несколько ускорителей) потока на основе корневой причины выявленной проблемы
  2. Определить результат, который мы хотим получить от применения этого ускорителя потоков
  3. Описать, где и как можно использовать ускоритель/и потока для достижения желаемого результата
  4. Определить метрики, которые будут использоваться для измерения желаемого результата

Определение ускорителей потока

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

Рисунок 4. Связывание метрик потока с выявленными проблемами и ускорителями потока для устранения проблем

Один из подходов к выбору наиболее подходящих ускорителей потока заключается в применении концепции Дизайн-мышления о последовательности: сначала дивергенция (изучение) и только затем (!) конвергенция (определение).

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

Мы рекомендуем ограничить количество ускорителей потока, на которых вы хотите сосредоточиться.

Определение желаемого результата

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

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

Неспособность определить чёткие результаты может привести к появлению анти-паттернов, таких как:

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

ПРИМЕР:

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

Определение отдельных элементов улучшений

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

По мере того, как идеи начинают преобразовываться в необходимость конкретных действий, команды определяют элементы работы для включения их в беклог. В зависимости от усилий, которые, по мнению команды, требуются для их выполнения, это могут быть новые элементы беклога различного масштаба: Истории, Фичи или Эпики.

Мы рекомендуем командам ограничиться одним или двумя элементами улучшений. Затем команда презентует эти элементы всем остальным командам внутри ART. Отдельно выделяется время для ответов на вопросы. Обычно после этого весь ART переходит к голосованию за то, какие элементы улучшений следует «взять в работу». Результаты фиксируются в Канве.

ПРИМЕР:

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

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

В соответствии с принятыми решениями обновляется Канва:

Примечание: Опытные поезда (ART) могут применять технику WSJF для выбора 3 основных действий, которые будут помещены в беклог улучшений.

Во время Мастерской решения проблем часто выявляются возможности для значительных улучшений. Обычно эти элементы улучшений попадают в соответствующий беклог уровня Команды, ART или непосредственно в LACE для дальнейшего уточнения и планирования.

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

Заключение

Мы рекомендуем держать фокус на ускорении потока во время проведения Мастерской решения проблем. Это позволит повысить эффективность Agile Release Train за счет выявления и устранения неэффективности процессов. Совместное использование метрик потока и ускорителей потоков в SAFe создает подход, основанный на фактических данных и ориентированный на непрерывную доставку ценности и улучшение процессов.

Канва «Ускорение Потока» помогает неустанно совершенствоваться. Сосредоточившись на релевантных метриках и соотнося их с выявленными проблемами, команды могут точно определить корневые причины проблем и разработать эффективные решения, сохраняя динамику выполнения работ и обеспечивая высококачественные результаты.

Мы хотели бы поблагодарить всех, кто внес свой вклад в тестирование Канвы различными способами. Эта статья является результатом всех ваших отзывов!

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Enhance ART Performance with the Accelerating Flow Problem-Solving Workshop».

Дополнительно почитать по теме:

Статья «Как обеспечить непрерывное движение ценности»

Статья «Метрики SAFe»

Статья «Мероприятия SAFe»

Другие статьи в блоге:

4 свойства продукта в современной продуктовой разработке
Свойства продукта: желаемый (desirable), осуществимый (feasible), жизнеспособный (viable) и устойчивый (sustainable).
Эпик
Что такое Эпик? Шаблоны "Заявление гипотезы Эпика" и "Бережливый бизнес-кейс" для определения Эпика. Оценка стоимости и продолжительности работ над Эпиком. Цикл "Lean Startup" для реализации Эпиков.
Разница между DoR, DoD, NFR, критериями приёмки и Канбан политиками?
Стандарты артефактов (DoR), Определение Выполненности (DoD), критерии приёмки, нефункциональные требования, Канбан политики: в чём разница, кто устанавливает, примеры.