Delivery: как доводить работу до результата - Деконструкция реальности

Основной тезис модуля

Delivery — это способность команды превращать намерение в поставленное, работающее и проверяемое изменение реальности.

Лид без delivery может много знать об архитектуре, хорошо рассуждать о людях, проводить встречи и давать правильные советы. Но если между появлением задачи и работающим результатом постоянно образуется болото, он остаётся философствующим старшим разработчиком.

Лид с delivery умеет провести работу через весь контур:

проблема или потребность
→ прояснённый результат
→ ограниченный объём
→ решение
→ поставляемые части
→ реализация
→ проверка
→ production
→ подтверждение результата

Это не способность «пинать людей» и не искусство увеличивать количество закрытых задач. Лид удерживает причинность потока:

Где работа вошла?
В каком состоянии она находится?
Что должно произойти дальше?
Почему этого не происходит?
Какое решение отсутствует?
Кто или что является зависимостью?
Какой риск уже материализуется?
Что можно поставить раньше?
Что докажет появление результата?

Главный вопрос модуля:

Способна ли команда последовательно превращать неизвестность в работающий результат, не подменяя продвижение активностью?

Что именно называется delivery

Delivery часто сужают до выпуска релиза. Но deployment — только один переход внутри более длинного процесса.

Если код попал в production, но пользователь не может завершить сценарий, delivery не закончен. Если feature технически работает, но не решает исходную проблему, команда произвела output, но не достигла ожидаемого outcome. Если результат готов, но неделями ждёт согласования или ручного релиза, техническая реализация завершена, а поток поставки — нет.

Нужно различать четыре уровня:

Активность:
люди совершают действия.

Output:
появился произведённый объект — код, API, экран, документ, pipeline.

Delivery:
изменение доступно в рабочей среде тому, для кого оно создавалось.

Outcome:
изменение произвело ожидаемый эффект или позволило проверить исходную гипотезу.

Например:

Уровень	Наблюдаемый факт
Активность	Команда две недели разрабатывала новый checkout
Output	Созданы endpoint, интерфейс и интеграция с платёжным сервисом
Delivery	Новый checkout включён для 5% пользователей в production
Outcome	Доля успешно завершённых оплат выросла с 71% до 78%

Лид должен видеть все четыре уровня и не выдавать один за другой.

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

Не "обновить Kafka".

А:
"перевести кластер на поддерживаемую версию,
сохранив обработку сообщений,
обеспечив откат
и устранив риск прекращения security updates".

Граница с предыдущим модулем

Модуль «Команда как инженерная система» отвечал на вопрос:

Как устроен субъект, который должен производить результат?

Этот модуль отвечает на другой вопрос:

Как работа проходит через этого субъекта и становится результатом?

Здесь объект анализа — не состав команды, не распределение знаний и не типы команд, а единица изменения и её движение.

Команда как система:
функция, границы, способности, решения, знания, автономность.

Delivery как поток:
вход работы, состояния, очереди, ожидания, зависимости,
поставляемые части, проверка и выход в production.

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

1. Начинать не с задачи, а с требуемого изменения

Большая часть delivery-проблем закладывается до начала разработки. В команду приходит не проблема, а уже выбранная кем-то форма решения:

Добавить кнопку.
Сделать новый микросервис.
Перенести данные в Redis.
Добавить AI.
Переписать checkout.
Интегрироваться с партнёром.

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

Перед декомпозицией лид должен вскрыть запрос:

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

Минимальный delivery brief

Проблема:

Пользователь или получатель результата:

Текущее поведение:

Требуемое изменение поведения:

Признак успешного результата:

Обязательные ограничения:

Критическая неизвестность:

Не входит в текущий объём:

Пример:

Мутный запрос:
"Нужно добавить повторную оплату заказа".

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

Успех:
заказ не дублируется,
остаток сохраняется на время повторной попытки,
повторное списание невозможно,
статус оплаты наблюдаем для поддержки".

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

2. Декомпозиция: превратить намерение в управляемую работу

Декомпозиция — не механическое дробление большой задачи на маленькие технические операции. Её цель — сделать причинность работы видимой и получить части, которыми можно независимо управлять, проверять и по возможности поставлять.

Плохая декомпозиция часто повторяет устройство технологии:

1. Спроектировать таблицы.
2. Создать backend endpoint.
3. Реализовать frontend.
4. Написать тесты.
5. Настроить deployment.

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

Более сильная декомпозиция проходит через несколько уровней:

Требуемый результат
→ пользовательские или операционные сценарии
→ поставляемые вертикальные срезы
→ необходимые технические изменения
→ конкретные действия

Вопросы декомпозиции

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

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

3. Slicing: поставляемые срезы вместо технических слоёв

Slicing — это способ разрезать большую feature на части, каждая из которых проходит через необходимые слои и создаёт законченное изменение поведения.

Горизонтальный разрез

Сначала база данных.
Потом backend.
Потом frontend.
Потом тестирование.
Потом интеграция.

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

Вертикальный разрез

Срез 1:
пользователь видит причину неуспешной оплаты
и может повторить попытку той же картой.

Срез 2:
пользователь может выбрать другую сохранённую карту.

Срез 3:
пользователь может добавить новый способ оплаты.

Срез 4:
поддержка видит историю попыток и причину отказа.

Каждый срез может включать минимальные изменения в UI, API, данных и наблюдаемости, но даёт проверяемое поведение.

Способы разрезания feature

Feature можно резать:

по пользовательским сценариям;
по типам пользователей;
по основному и исключительным путям;
по бизнесовым правилам;
по каналам или платформам;
по географии;
по объёму данных;
по уровню автоматизации;
по интеграциям;
по степени риска;
по режиму включения через feature flag.

Примеры:

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

Не автоматическая обработка всех исключений,
а основной путь плюс ручной fallback.

Не миграция всех клиентов,
а один сегмент с возможностью отката.

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

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

Признаки хорошего среза

Его можно объяснить через изменение поведения.
Его можно проверить отдельно.
Он уменьшает риск или неизвестность.
Он не требует завершения всей feature для интеграции.
Его можно включить ограниченно.
Его завершение даёт новую информацию.

4. MVP: минимальный контур проверки смысла

MVP часто превращают либо в оправдание плохого качества, либо в уменьшенную копию всего будущего продукта.

Подмена 1:
"Это MVP, поэтому можно без тестов, наблюдаемости и нормальной обработки данных".

Подмена 2:
"Для MVP нужны все основные функции, только немного проще".

MVP — это минимальный целостный контур, достаточный для проверки главной гипотезы или получения первого реального результата.

Минимальность относится к объёму проверяемого предположения, а не к уровню инженерной ответственности.

Если MVP работает с реальными деньгами, он всё равно обязан исключать повторное списание. Если обрабатывает персональные данные, требования безопасности не становятся необязательными. Если включён для пользователей, команда должна иметь способ увидеть отказ и остановить изменение.

Для определения MVP нужно спросить:

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

MVP не является автоматически первой версией feature. Иногда первая поставка нужна не для проверки продуктовой гипотезы, а для снятия технического риска. Тогда честнее назвать её technical walking skeleton, spike, pilot или ограниченной миграцией — в зависимости от функции результата.

5. Definition of Ready: достаточность для начала, а не бюрократический пропуск

Definition of Ready — договорённость команды о том, какая ясность необходима, чтобы брать работу в реализацию с приемлемым уровнем неизвестности.

Важно: Definition of Ready не является официальным артефактом или commitment в Scrum Guide. В официальной модели Product Backlog Item считается достаточно готовым для выбора, когда может быть завершён внутри Sprint; необходимая прозрачность обычно появляется через refinement. (Scrum Guide)

Следовательно, DoR — дополнительная практика команды, а не обязательный элемент Scrum и не универсальный стандарт.

Возможный Definition of Ready

Работа может быть взята в реализацию, если:

- понятна проблема или требуемый результат;
- определён основной пользовательский сценарий;
- известны acceptance criteria;
- названы обязательные ограничения;
- выявлены критические зависимости;
- неизвестность либо допустима, либо вынесена в spike;
- объём помещается в управляемый горизонт;
- команда понимает, как проверить результат;
- определено, что не входит в текущий объём.

DoR становится вредным, когда превращается в стену между Product и командой:

"Задача не соответствует шаблону — возвращаем аналитику".

"Пока Product не опишет всё до последнего поля, разработчики не думают".

"Любая неизвестность означает, что задача не готова".

В сложной работе полная известность до начала невозможна. Цель DoR — не устранить неизвестность, а сделать её видимой и решить, можно ли с ней входить в работу.

6. Definition of Done: единая граница завершённости

Без общей Definition of Done слово «готово» означает для каждого участника разное:

Разработчик:
код написан.

Reviewer:
pull request принят.

QA:
проверено на тестовой среде.

Product:
пользователь может воспользоваться функцией.

Operations:
изменение наблюдаемо и может быть восстановлено.

Definition of Done должна описывать состояние изменения, при котором оно соответствует требуемым для продукта мерам качества. В Scrum Guide Definition of Done является формальным описанием состояния Increment; работа не считается частью Increment, пока этой границы не достигла. (Scrum Guide)

Возможная Definition of Done

Изменение считается Done, если:

- реализованы согласованные acceptance criteria;
- код прошёл review;
- автоматические проверки успешны;
- необходимые уровни тестирования выполнены;
- миграции данных проверены;
- соблюдены требования безопасности;
- добавлена необходимая наблюдаемость;
- определён способ rollback или безопасного отключения;
- обновлены значимые контракты и документация;
- изменение интегрировано с основной веткой;
- оно находится в состоянии, пригодном для выпуска.

Конкретный DoD зависит от продукта. Нельзя механически скопировать один checklist для банковской транзакции, внутреннего отчёта и экспериментального прототипа. Но нельзя и менять смысл Done под давление срока.

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

Done не всегда равно Delivered

В некоторых системах Increment может соответствовать DoD, но ещё не быть включён пользователям. Например, выпуск управляется feature flag или отдельным продуктовым решением.

Тогда лид должен видеть две границы:

Done:
изменение технически и качественно пригодно к выпуску.

Delivered:
изменение реально доступно получателю результата.

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

7. Видеть поток работы

Локальное состояние задач не показывает систему delivery. Десять карточек могут иметь статус In Progress, но ни одна не приближаться к завершению.

Поток нужно рассматривать как последовательность состояний:

Запрос
→ прояснение
→ готово к реализации
→ разработка
→ review
→ проверка
→ готово к выпуску
→ production
→ проверка результата

Для каждого состояния важно установить:

что означает вход;
что означает выход;
кто может изменить состояние;
какая работа реально выполняется;
сколько времени объект обрабатывается;
сколько времени он просто ожидает;
куда работа возвращается;
какая очередь образуется перед состоянием;
какое ограничение пропускной способности существует.

DORA в руководстве по value stream mapping рекомендует отображать шаги потока, время ожидания, handoff между участниками и места накопления работы; карта должна начинаться достаточно просто и уточняться там, где обнаружена проблема. (DORA: Value Stream Mapping)

Время работы и время ожидания

Feature может быть завершена за двадцать календарных дней, хотя непосредственная работа над ней заняла четыре дня:

Состояние	Работа	Ожидание
Уточнение требования	4 часа	2 дня до ответа партнёра
Разработка	2 дня	1 день из-за переключения разработчика
Code review	2 часа	3 дня в очереди
QA	1 день	4 дня до свободного QA
Выпуск	1 час	6 дней до release window

Требование «разрабатывать быстрее» почти не изменит общий срок. Основная длительность находится в ожидании, очередях и правилах перехода.

WIP: незавершённая работа

Work in Progress — это работа, в которую система уже вложила внимание, но ещё не превратила в результат.

Избыточный WIP создаёт:

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

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

Цель delivery:
не максимизировать начало работы,
а увеличивать завершение значимых изменений.

8. Управление зависимостями

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

Зависимости бывают:

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

Само наличие зависимости не является управлением. Запись blocked by Team B только называет состояние.

Для значимой зависимости нужно определить:

Что именно требуется?
От кого?
К какому моменту?
Как подтверждается договорённость?
Что делает наша команда до получения результата?
Есть ли альтернативный путь?
Когда ожидание становится риском срока?
Кто инициирует эскалацию?

Стратегии работы с зависимостью

Лид может:

устранить зависимость изменением границы решения;
заменить синхронную зависимость стабильным контрактом;
перенести зависимую часть в более поздний срез;
поставить ранний contract test или stub;
совместно провести discovery;
получить временный fallback;
изменить порядок работ;
явно принять зависимость как риск;
эскалировать конфликт приоритетов владельцам соответствующего уровня.

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

9. Неизвестность, риски и spikes

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

Риск — это не просто «что-то может пойти не так». Для управления нужно определить:

Поле	Вопрос
Событие	Что именно может произойти?
Причина	Почему это возможно?
Последствие	Что изменится для результата?
Вероятность	Насколько это правдоподобно сейчас?
Воздействие	Насколько велик ущерб сроку, объёму или качеству?
Сигнал	Как мы поймём, что риск приближается?
Действие	Что уменьшаем заранее?
Владелец	Кто следит и действует?

Пример:

Не:
"Есть риск с внешним API".

А:
"Документация партнёра не описывает повторную доставку callback.
Если callback может приходить повторно,
текущая модель создаёт риск двойной смены статуса заказа.

До начала основной реализации:
проверить поведение в sandbox,
заложить идемпотентный обработчик,
получить письменное подтверждение контракта.

Владелец: Анна.
Контрольная точка: вторник, 22 июля".

Spike

Spike — ограниченное по времени исследование, предназначенное для уменьшения конкретной неизвестности.

Нормальный spike имеет:

Вопрос:
что именно мы должны узнать?

Timebox:
сколько времени тратим?

Выход:
какое решение, измерение, прототип или перечень ограничений должен появиться?

Следствие:
как результат изменит план?

Spike без вопроса и условия завершения легко превращается в бесконечное исследование. Его результатом не обязана быть production-реализация, но обязано стать уменьшение неизвестности, влияющей на решение.

10. Работа с блокерами

Блокер — это не красная метка на карточке, а препятствие, из-за которого работа не может продолжить необходимое движение.

Для каждого блокера лид должен установить:

Что именно остановлено?
Какой следующий переход невозможен?
Почему?
Кто способен изменить ситуацию?
Какое действие уже сделано?
Когда ожидается ответ?
Что можно продолжить независимо?
Когда требуется изменить scope или последовательность?
Когда нужна эскалация?

Уровни реакции

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

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

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

11. Планирование как построение следующего управляемого горизонта

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

В delivery-плане должны быть видимы:

требуемый результат;
ближайший поставляемый срез;
последовательность следующих срезов;
критические зависимости;
риски и неизвестности;
контрольные точки;
условия изменения scope;
способ проверки результата.

Три горизонта

Текущий горизонт:
что команда делает сейчас и что должно завершиться следующим.

Ближайший горизонт:
какие срезы и решения последуют после текущего результата.

Дальний горизонт:
направление и крупные части, которые пока содержат значительную неизвестность.

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

Полная теория оценок и forecasting рассматривается в отдельном модуле «Планирование, оценки и управление неопределённостью». Здесь лид использует план как инструмент текущего управления потоком, а не как систему долгосрочного обещания дат.

12. Scrum-события как контуры управления delivery

Planning, refinement, daily, review и retrospective имеют смысл только тогда, когда каждое событие меняет состояние понимания, плана или системы работы.

Scrum Guide определяет события как формальные возможности для inspection и adaptation, а не как ритуалы отчётности. В частности, Daily Scrum предназначен для проверки продвижения к Sprint Goal и корректировки ближайшего плана, Sprint Review — для проверки результата и определения будущих изменений, Sprint Retrospective — для повышения качества и эффективности. (Scrum Guide)

Курс не должен превращать Scrum в единственно возможную религию delivery. Но различение функций событий полезно и за пределами Scrum.

Refinement

Функция: превратить будущую работу из названия в достаточно понятный объект решения.

Вход:
непрояснённая потребность или крупный backlog item.

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

Подмена: коллективное чтение заранее написанных задач и выставление story points.

Planning

Функция: выбрать ближайший результат и построить реальный план его достижения.

В Scrum Sprint Planning связывает три вопроса: почему Sprint ценен, что может быть завершено и как выбранная работа будет выполнена. (Scrum Guide)

Подмена: менеджер раздаёт задачи и заполняет загрузку каждого человека.

Daily

Функция: проверить, приближается ли команда к цели, и скорректировать совместное действие.

Полезные вопросы:

Что стало ближе к Done?
Что должно завершиться следующим?
Где работа не движется?
Какая помощь или решение нужны сегодня?
Нужно ли изменить порядок или объединить усилия?

Подмена: поочерёдный отчёт каждого человека лиду о вчерашней активности.

Review

Функция: исследовать появившийся результат вместе со стейкхолдерами и изменить дальнейший план на основании увиденного.

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

Retrospective

Функция: изменить саму систему производства результата.

Где мы потеряли время?
Какая неизвестность обнаружилась слишком поздно?
Какая очередь выросла?
Какое правило мешало?
Что воспроизводит одну и ту же проблему?
Какое конкретное изменение проверим следующим циклом?

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

Чувства и отношения могут быть реальными данными о системе, но retrospective не выполнила функцию, если после разговора не появилось проверяемое изменение.

13. Контроль прогресса без микроменеджмента

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

Что ты делал вчера?
Сколько процентов готово?
Почему задача ещё не закрыта?
Когда закончишь?
Почему тебя не видно в чате?

Проблема не в самом праве задавать эти вопросы. Проблема в объекте контроля: лид наблюдает человека вместо движения работы.

Контроль delivery строится вокруг четырёх уровней.

1. Результат

Какой ближайший проверяемый результат должен появиться?

2. Состояние потока

Какой срез находится в работе?
Какой переход должен произойти следующим?
Сколько работа находится в текущем состоянии?

3. Риски и зависимости

Что может остановить результат?
Какой сигнал уже появился?
Кто должен принять решение?

4. Изменение прогноза

Что мы узнали с прошлого обновления?
Как новая информация меняет scope, порядок или ожидаемую дату?

Нормальный status update

Цель:
дать пользователю возможность повторить неуспешную оплату
без создания нового заказа.

Появившийся результат:
основной повторный платёж проходит в test environment;
идемпотентность подтверждена contract tests.

Текущий срез:
повтор той же картой и сохранение существующего заказа.

Блокер:
sandbox партнёра не возвращает один из production-статусов.

Действие:
отправлен конкретный пример партнёру;
параллельно реализуем обработку через зафиксированный fallback.

Риск:
если контракт не будет подтверждён до 22 июля,
выпуск ограничим одним поддержанным статусом,
остальные направим в ручную обработку.

Следующая контрольная точка:
готовность среза к ограниченному production rollout — 24 июля.

Такой update передаёт состояние реальности и позволяет действовать. Процент готовности без описания оставшейся неизвестности почти ничего не сообщает.

14. Активность не равна продвижению

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

Признаки активности без продвижения

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

Лид должен возвращать разговор от усилий к изменению состояния:

Что вчера было невозможно, а сегодня стало возможно?

Какой риск был уменьшен?

Какое решение появилось?

Какая работа пересекла границу Done?

Какая часть доступна для проверки?

Что конкретно приблизилось к production?

Это не обесценивание труда. Напротив, оно защищает труд команды от растворения в системе, которая потребляет усилия, но не производит завершения.

15. Метрики потока

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

Базовые flow-метрики

Lead time

Время от появления или принятия запроса до поставки результата. Точная начальная точка должна быть явно определена.

Cycle time

Время от начала активной работы над объектом до его завершения.

Throughput

Количество завершённых единиц работы за период. Единицы должны быть сопоставимыми по смыслу; простое число Jira issues легко искажается способом нарезки.

Work in Progress

Количество одновременно начатой, но незавершённой работы.

Work item age

Сколько времени текущая незавершённая работа уже находится в потоке.

Flow efficiency

Отношение времени активной обработки к полному времени прохождения. Низкая flow efficiency показывает, что работа в основном ждёт.

Blocked time

Время, в течение которого работа не могла продолжаться из-за известного препятствия.

Rework

Работа, которую пришлось выполнять повторно из-за дефекта, поздно обнаруженной неизвестности или несогласованности.

Каждая метрика должна приводить к вопросу о системе. Например, растущий cycle time не означает автоматически, что разработчики стали медленнее. Возможно, увеличился batch size, review превратился в очередь или задачи стали чаще возвращаться после позднего тестирования.

16. Актуальные DORA-метрики

По состоянию на 20 июля 2026 года DORA использует пять метрик software delivery performance, а не исторический набор из четырёх метрик. Переход от четырёх к пяти произошёл в 2024 году, когда была добавлена deployment rework rate. (DORA: история метрик)

DORA группирует текущие метрики в два фактора: throughput и instability. (DORA Metrics)

Throughput

1. Change lead time

Время от фиксации изменения в системе контроля версий до успешного deployment в production.

Метрика показывает не весь продуктовый lead time от появления идеи, а конкретный технический участок потока. Если требование два месяца ждало до первого commit, DORA change lead time этого не обнаружит — поэтому DORA-метрики необходимо дополнять картой полного delivery flow.

2. Deployment frequency

Количество deployment за период или время между deployment.

Высокая частота сама по себе не создаёт ценность, но обычно показывает способность системы выпускать небольшие изменения без тяжёлого отдельного события.

3. Failed deployment recovery time

Время восстановления после неуспешного deployment, потребовавшего немедленного вмешательства.

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

Instability

4. Change fail rate

Доля deployment, после которых требуется немедленное вмешательство — например, rollback или hotfix.

5. Deployment rework rate

Доля незапланированных deployment, выполняемых для исправления production-дефектов.

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

Как использовать DORA-метрики

DORA прямо предостерегает от нескольких подмен:

превращения метрики в обязательную цель;
выбора одной «главной» метрики;
сравнения принципиально разных приложений и команд;
разделения метрик между development и operations;
соревнования команд;
построения сложной измерительной системы вместо реального улучшения. (DORA Metrics)

Правильный вопрос:

Как меняется способность конкретной системы
безопасно, быстро и эффективно проводить изменения?

Неправильный:

Какая команда лучше по единому корпоративному рейтингу?

DORA-метрики измеряют software delivery performance, но не доказывают продуктовую ценность изменения. Можно очень быстро и стабильно поставлять ненужные features. Поэтому они должны соединяться с наблюдением outcome, пользовательского поведения и смысла работы.

Системные дисфункции delivery

1. Максимизация занятости

Каждому человеку назначают отдельную задачу, чтобы никто не простаивал. В результате растёт WIP, задачи ждут review и интеграции, а помочь завершить чужую работу некому.

2. Большая feature одним пакетом

Команда несколько недель строит все слои и сценарии одновременно. Интеграция и пользовательская проверка происходят в конце, когда стоимость изменения решения максимальна.

3. Вечные 90 процентов

Основная реализация закончена, но остаются миграция, сложное исключение, observability, security review или внешнее согласование. Процент создаёт впечатление близости результата, хотя неизвестность сосредоточена именно в оставшейся части.

4. QA как конечный фильтр

Разработчики передают крупный batch в QA, после чего обнаруживаются несогласованные сценарии и начинается возврат работы. Quality становится стадией после разработки, а не свойством потока.

5. Release как отдельный проект

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

6. Backlog как склад обещаний

В backlog попадает всё когда-либо пожеланное. Сам факт существования записи воспринимается как обязательство реализации, приоритет теряет смысл, refinement расходуется на поддержку мёртвых элементов.

7. Скорость по story points как результат

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

8. Daily как отчёт начальнику

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

9. Блокер без действия

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

10. Скрытая незапланированная работа

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

11. Завершение по границе подразделения

Backend считает работу законченной после API, frontend — после интерфейса, QA — после проверки. Пользовательский сценарий не принадлежит никому и собирается только перед релизом.

12. Метрика вместо реальности

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

Практический разбор

Исходная ситуация

Команда должна реализовать повторную оплату неуспешного заказа.

Product сформулировал запрос так:

"Нужна кнопка повторной оплаты.
Желательно закончить за две недели,
потому что мы теряем пользователей".

Известно:

заказ резервирует ограниченный товар;
резерв снимается через 30 минут;
платёжный провайдер присылает асинхронные callback;
callback может задерживаться;
поведение повторной доставки callback не подтверждено;
мобильное приложение обновляется медленнее web;
поддержка сейчас не видит историю попыток;
команда раньше не реализовывала смену способа оплаты внутри заказа.

Шаг 1. Определить результат

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

Шаг 2. Назвать неотменяемые ограничения

- идемпотентность списания;
- сохранение связи с существующим заказом;
- ограничение временем резерва;
- наблюдаемость статусов;
- возможность отключить новый путь;
- согласованность с callback провайдера.

Шаг 3. Выделить неизвестность

Критическая неизвестность — поведение callback при повторной попытке и повторной доставке. До построения полной feature команда проводит timeboxed spike и создаёт contract tests.

Шаг 4. Разрезать работу

Срез 1:
web-пользователь повторяет оплату той же картой;
включение только для сотрудников через feature flag.

Срез 2:
ограниченный production rollout для 5% web-пользователей;
поддержка видит историю попыток.

Срез 3:
выбор другой сохранённой карты.

Срез 4:
добавление новой карты.

Срез 5:
поддержка мобильного приложения после обновления клиента.

Шаг 5. Зафиксировать зависимости

Зависимость	Действие	Контрольная точка	Альтернатива
Контракт callback	Запрос партнёру + sandbox spike	22 июля	Идемпотентная обработка всех повторов
Мобильный клиент	Согласовать версию API	25 июля	Сначала web-only rollout
История для поддержки	Определить минимальные поля	21 июля	Временный внутренний endpoint

Шаг 6. Определить Done для первого среза

- повторная попытка использует существующий заказ;
- повторный callback не создаёт двойного перехода;
- резерв корректно истекает;
- ошибки видимы пользователю;
- метрики попыток и результатов доступны;
- поддержка видит correlation ID;
- feature flag позволяет отключить путь;
- rollback проверен;
- contract и integration tests проходят;
- срез включён для внутренней группы.

Шаг 7. Определить способ проверки результата

Технически:
успешность сценария, дубликаты, ошибки callback,
время обработки, зависшие статусы.

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

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

Практическое задание: Delivery Flow Map и Delivery Plan

Участник выбирает одну завершённую или текущую feature и восстанавливает её реальный путь от запроса до результата.

1. Определение результата

Исходный запрос:

Проблема:

Получатель результата:

Требуемое изменение поведения:

Проверяемый признак результата:

Не входит в текущий объём:

2. Декомпозиция

Основной сценарий:

Исключительные сценарии:

Технические контуры:

Критическая неизвестность:

Первый сквозной срез:

Последующие срезы:

3. MVP или другой тип первой поставки

Какую гипотезу или способность проверяет первая поставка:

Почему этого объёма достаточно:

Какие качества нельзя уменьшать:

Кто получит первый результат:

Как будет принято решение о следующем шаге:

4. Definition of Ready

Что должно быть известно до начала:

Какая неизвестность допустима:

Что требует spike:

Какие зависимости должны быть подтверждены:

5. Definition of Done

Функциональный результат:

Качество:

Тестирование:

Безопасность:

Наблюдаемость:

Документация и контракты:

Rollback или выключение:

Граница между Done и Delivered:

6. Карта потока

Для каждого состояния нужно указать:

Состояние	Условие входа	Условие выхода	Владелец действия	Работа	Ожидание	Возвраты
Запрос
Прояснение
Разработка
Review
Проверка
Выпуск
Проверка результата

7. WIP и очереди

Сколько работы начинается одновременно:

Где скапливается очередь:

Какие объекты стареют:

Где нужна WIP-граница:

Что команда должна перестать начинать и начать завершать:

8. Зависимости

Зависимость:
Требуемый результат:
Владелец:
Контрольная дата:
Альтернативный путь:
Условие эскалации:

9. Риски

Риск:
Причина:
Последствие:
Вероятность:
Воздействие:
Ранний сигнал:
Предварительное действие:
Владелец:

10. Управляющий ритм

Что должно происходить на refinement:

Что должно решаться на planning:

Что проверяется ежедневно:

Что проверяется на review:

Какое изменение системы выносится на retrospective:

11. Метрики

Полный lead time:

Cycle time:

Work item age:

Blocked time:

WIP:

Deployment frequency:

Change lead time:

Change fail rate:

Failed deployment recovery time:

Deployment rework rate:

Признак продуктового или операционного outcome:

12. Status update

Цель:

Появившийся результат:

Текущий срез:

Блокер или зависимость:

Действие:

Изменение риска или прогноза:

Следующая контрольная точка:

Критерии выполненного задания

Delivery-разбор считается выполненным, если:

исходный запрос отделён от требуемого изменения;
активность, output, delivery и outcome не смешаны;
feature разрезана на проверяемые сквозные части;
первая поставка уменьшает конкретную неизвестность или создаёт результат;
MVP не используется как оправдание нарушения обязательного качества;
DoR описывает достаточность, а не требует полной известности;
DoD создаёт общую границу завершённости;
показаны не только состояния, но и время ожидания между ними;
найдены очереди, возвраты и незавершённая работа;
каждая критическая зависимость имеет действие и условие эскалации;
риски сформулированы через события и последствия;
события команды имеют конкретные управляющие функции;
progress update сообщает изменение реальности, а не перечень активности;
DORA-метрики используются для исследования системы, а не оценки людей;
существует отдельный признак продуктового или операционного результата.

Что лид должен унести из этого модуля

Лид удерживает не занятость команды, а прохождение работы через систему.

Он должен уметь:

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

Главное различение модуля:

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

Лид обеспечивает результат тем,
что делает видимым и управляемым движение самой работы.

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

Поэтому вопрос лида не заканчивается на «что сделано?».

Он последовательно спрашивает:

Что изменилось?
Что теперь доступно?
Что подтверждено?
Что осталось неизвестным?
Что должно перейти в следующее состояние?
Что мешает этому переходу?
Какой следующий минимальный результат мы способны поставить?

Именно эта способность превращает управление разработкой из контроля человеческой активности в управление технической причинностью.