2.1 Flow Framework

Обзор и мотивация

Flow Framework это управленческая и структурная модель, созданная Миком Керстеном и опубликованная в его книге 2018 года Project to Product. Она существует, чтобы ответить на вопрос, на который чистые метрики конвейера ответить не могут: не только насколько быстро и насколько безопасно код движется от коммита к продакшену, но и какого рода ценность вообще движется через конвейер, и отражает ли эта смесь фактическую стратегию бизнеса. Фреймворк рассматривает доставку программного обеспечения как поток создания ценности, полную последовательность действий, превращающую идею в ценность, получаемую клиентом, напрямую заимствуя из традиции картирования потока создания ценности бережливого производства.

Эта книга использует Flow Framework как организующую структуру части 2. Тема 2.2 вводит его четыре элемента потока, темы 2.3 и 2.4 вводят его пять метрик потока, тема 2.8 прослеживает эти метрики до их происхождения в классическом картировании потока создания ценности Lean, а тема 2.10 покрывает метрики DORA как более узкий, сфокусированный на конвейере справочный фреймворк, с которого эта часть больше не начинает. Это намеренный выбор, а не отрицание исследований DORA. DORA измеряет пропускную способность и стабильность системы с настоящей статистической строгостью, но молчит о вопросе, который на самом деле больше всего волнует бизнес-лидера: учитывая всё, что инженерная организация отгрузила в этом квартале, сколько из этого было новой ценностью для клиента, а сколько тихо поглотилось исправлением дефектов, управлением рисками или погашением долга. Flow Framework существует конкретно для того, чтобы сделать эту смесь видимой.

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

Ключевые принципы

Поток создания ценности единица измерения, а не команда или конвейер. Он охватывает путь от клиентской или бизнес-потребности до доставленного результата, пересекая любые границы команд, которые фактически пересекает работа.
Элементы потока делают видимым «что», а не только «насколько быстро». Четыре категории темы 2.2, функции, дефекты, риски и долг, превращают неявное решение о приоритизации в явное, измеримое.
Распределение мощности между элементами потока игра с нулевой суммой. Больше мощности, потраченной на один тип элемента, это меньше мощности, доступной для других; фреймворк делает этот компромисс видимым, а не оставляет его неявным.
Пять метрик потока отвечают на бизнес-вопросы, а не только на инженерные. Они спроектированы так, чтобы быть представленными нетехнической заинтересованной стороне, а не оставаться внутри инженерной команды.
Управление потоком создания ценности должно быть непрерывным, а не разовым упражнением картирования. Статические карты потока создания ценности устаревают; фреймворк построен так, чтобы инструментироваться из инструментов, которые команды уже используют.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Только метрики конвейера (DORA, тема 2.10)	Просто, хорошо проверено, дёшево инструментировать из существующих данных CI/CD	Молчит о том, какого рода ценность доставляется
Полное внедрение Flow Framework	Связывает доставку с бизнес-стратегией; делает смесь ценности видимой и обсуждаемой	Требует честной карты потока создания ценности и последовательной дисциплины классификации элементов потока
Статическое, разовое картирование потока создания ценности	Дёшево, быстро выполнить как упражнение на воркшопе	Быстро устаревает; производит снимок, а не живую метрику
Непрерывное, интегрированное с инструментами управление потоком создания ценности	Живые, всегда актуальные данные; масштабируется по многим потокам создания ценности	Требует настоящей работы по интеграции инструментария заранее

Центральное напряжение: разборчивость для бизнеса против усилий на инструментирование. Метрики конвейера дёшевы, потому что конвейер уже производит данные; метрики потока создания ценности требуют честной карты всего процесса и дисциплинированной привычки классификации в момент приёма, которую метрики конвейера никогда не требовали. Разрешайте это напряжение, начиная с одного потока создания ценности, а не всей организации сразу, правильно картируя его, и только потом интегрируя отслеживание элементов потока в существующие инструменты, а не пытаясь провести единовременный развёртывание сразу по всем командам.

Вопросы для обсуждения в команде

Могли бы мы прямо сейчас нарисовать точную карту потока создания ценности для нашего важнейшего продукта, или мы гадали бы относительно нескольких передач? Большинство организаций никогда на самом деле не проходили этот путь от начала до конца. Попробуйте это упражнение честно и отметьте каждое место, где группа расходится во мнениях о том, что на самом деле происходит, потому что это расхождение само по себе диагностично.
Если бы мы классифицировали всё, что наша команда отгрузила в прошлом квартале, на функции, дефекты, риски и долг, удивил бы результат наше продуктовое руководство? Большинство команд никогда не делали это разделение явным, и ответ часто раскрывает бремя обслуживания или проблему долга, ранее невидимую в простом подсчёте «доставленных стори-пойнтов».
Есть ли у нас настоящий, интегрированный с инструментами способ отслеживать элементы потока, или это потребовало бы, чтобы кто-то вручную классифицировал и переклассифицировал работу? Ручная система быстро деградирует под реальной нагрузкой; интегрированная с инструментами нет. Честно оцените, какую именно вы на самом деле готовы поддерживать.
Когда наша карта потока создания ценности в последний раз менялась, и обновили ли мы наши метрики, чтобы это отразить? Реорганизации и миграции инструментария тихо делают карту потока создания ценности недействительной, и мало какие организации вспоминают пересмотреть её, когда это происходит.
Представляются ли наши метрики потока когда-либо напрямую бизнес или продуктовым заинтересованным сторонам, или они остаются внутри инженерии? Самое большое преимущество фреймворка над метриками, ограниченными только конвейером, именно в этом разговоре, и пропуск его лишает большей части ценности фреймворка.
Что потребовалось бы, чтобы кто-то подделал нашу классификацию элементов потока, не делая ничего нечестного на бумаге? Пройдите через то, как команда под давлением доставки могла бы тихо переобозначить работу с долгом или риском как функции, чтобы выглядеть более продуктивной, и обсудите, заметили бы вы это сейчас.

Отраслевой взгляд

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

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

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

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

Примеры

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

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

Бизнес-кейс: мотивация, ROI и TCO

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

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

Антипаттерны и ловушки

Отношение к картированию потока создания ценности как к разовому воркшопу, который никогда не пересматривается: карта устаревает в момент изменения организации, а метрика, вычисленная против устаревшей карты, измеряет не то.
Построение параллельной, вручную поддерживаемой системы отслеживания элементов потока: быстро деградирует под реальной нагрузкой; вместо этого интегрируйте с существующими инструментами.
Классификация элементов потока ретроспективно, а не при приёме: вектор манипулирования в сердце этой темы. Под давлением доставки команда может тихо переобозначить работу с долгом или риском как функции постфактум, чтобы выглядеть более продуктивной перед заинтересованными сторонами, которые видят только диаграмму распределения потока, без того, чтобы кто-либо вообще принял явное видимое решение это сделать. Страховка требовать классификацию при приёме, до того как результат известен, и периодически проверять выборку классифицированных элементов относительно того, что фактически сделало лежащее в основе изменение, та же дисциплина аудита, которую тема 1.2 требует для каждой метрики в этой книге.
Удержание метрик потока только внутри инженерии: лишает фреймворк его главного преимущества, общего словаря с бизнес-заинтересованными сторонами.
Картирование организационной структуры вместо фактического потока создания ценности: скрывает межкомандные передачи, часто являющиеся крупнейшим источником задержки.
Внедрение фреймворка по всей организации до его проверки на одном потоке создания ценности: рискует крупной инвестицией в метрики, которым никто не доверяет, потому что лежащая в основе карта никогда не была подтверждена как точная.

Модель зрелости

Уровень 1, Инициация: Карта потока создания ценности не существует; работа отслеживается как общие заявки без классификации элементов потока.
Уровень 2, Развитие: Один поток создания ценности был картирован, и элементы потока классифицируются неформально, но отслеживание ручное и применяется непоследовательно.
Уровень 3, Стандартизация: Классификация элементов потока интегрирована в существующий инструментарий и применяется последовательно при приёме по основным потокам создания ценности.
Уровень 4, Управление: Распределение потока регулярно пересматривается с бизнес-заинтересованными сторонами, а карты потока создания ценности активно поддерживаются актуальными по мере изменения организации.
Уровень 5, Оркестрация: Организация намеренно распределяет инженерные инвестиции между потоками создания ценности, используя данные потока, и может указать на конкретные стратегические решения, бюджет на сокращение долга, реструктуризацию команды, принятые потому, что фреймворк сделал ранее невидимый компромисс видимым.

Идеи для обсуждения

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

Основные выводы

Flow Framework из Project to Product Мика Керстена измеряет, какого рода ценность движется через конвейер доставки, а не только насколько быстро работает сам конвейер.
Поток создания ценности, а не команда или конвейер, единица измерения фреймворка, и честное его картирование предшествует любому инструментированию.
Классификация элементов потока при приёме, а не постфактум, это страховка против центрального вектора манипулирования этой темы: тихого переобозначения работы с долгом или риском как функций, чтобы выглядеть более продуктивной.
Связывайте метрики потока с существующими инструментами, Jira, Azure DevOps, GitHub, а не с параллельной ручной системой отслеживания, которая не переживёт реальную нагрузку.
Представляйте данные потока напрямую бизнес-заинтересованным сторонам; этот разговор, а не внутренний инженерный дашборд, главное преимущество фреймворка над метриками, ограниченными только конвейером.

Источники и дальнейшее чтение

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016.

2.1 Flow Framework

Обзор и мотивация

Ключевые принципы

Рекомендации

Картируйте ваш поток создания ценности, прежде чем что-либо инструментировать

Свяжите метрики потока с инструментами, которые ваши команды уже используют

Представляйте распределение потока напрямую бизнес-заинтересованным сторонам, а не только инженерному руководству

Относитесь к четырём элементам потока как к настоящей таксономии, а не формальности

Пересматривайте вашу карту потока создания ценности при изменении организации, а не по фиксированному расписанию