Введение
Основной тезис модуля
Delivery — это процесс превращения намерения в поставленное, работающее и проверенное изменение.
Человек в роли лида может много знать об архитектуре, хорошо рассуждать о людях, проводить встречи и давать правильные советы. Но если между появлением потребности и работающим изменением постоянно образуется болото, он фактически остаётся старшим разработчиком, который умеет рассуждать о работе, но не умеет проводить её через delivery.
Лид, управляющий delivery, умеет провести работу через весь контур:
- Выявить проблему или потребность.
- Определить требуемое изменение.
- Ограничить объём.
- Найти решение.
- Разделить работу на поставляемые части.
- Реализовать изменение.
- Проверить его.
- Поставить изменение в рабочую среду.
- Подтвердить работоспособность поставленного изменения.
Управление delivery — это не способность «пинать людей» и не искусство увеличивать количество закрытых задач. Лид удерживает причинность потока:
- Где работа вошла?
- В каком состоянии она находится?
- Что должно произойти дальше?
- Почему этого не происходит?
- Какое решение отсутствует?
- Кто или что является зависимостью?
- Какой риск уже материализуется?
- Что можно поставить раньше?
- Что подтвердит работоспособность изменения?
Главный вопрос модуля:
Способна ли команда последовательно превращать неизвестность в работающее поставленное изменение, не подменяя продвижение активностью?
Активность, output, deployment, release и outcome
Прохождение работы через delivery-контур нельзя определять количеством совершённых действий. Работа может активно двигаться, при этом изменение ещё не быть произведено, развёрнуто или выпущено, а выпущенное изменение — не привести к ожидаемому эффекту.
Поэтому важно различать несколько разных понятий:
| Понятие | Что это означает | Наблюдаемый факт |
|---|---|---|
| Активность | Выполняемая работа, которая сама по себе ещё не означает появления поставляемого изменения | Команда две недели разрабатывала новый checkout |
| Output | Появился произведённый объект или изменение: код, API, экран, документ, pipeline | Созданы endpoint, интерфейс и интеграция с платёжным сервисом |
| Deployment | Изменение технически развёрнуто в целевой среде | Новая версия checkout развёрнута в production, feature flag выключен |
| Release | Изменение стало доступно тем, для кого оно предназначено | Новый checkout включён для 5% пользователей |
| Outcome | Возник эффект от использования поставленного изменения | Доля успешно завершённых оплат выросла с 71% до 78% |
При этом outcome уже находится за границей delivery.
Лид должен различать эти понятия и не выдавать одно за другое.
1. Начинать не с задачи, а с требуемого изменения
Большая часть delivery-проблем закладывается до начала разработки. В команду приходит не проблема, а уже выбранная кем-то форма решения:
- Добавить кнопку.
- Сделать новый микросервис.
- Перенести данные в Redis.
- Добавить AI.
- Переписать checkout.
- Интегрироваться с партнёром.
Если команда принимает такую формулировку непосредственно как задачу, она начинает производить форму, не установив требуемый результат.
Перед декомпозицией лид должен отделить само требуемое изменение от уже предложенного способа его реализации.
Для этого необходимо установить:
- какое состояние создаёт проблему и для кого;
- что именно должно измениться в наблюдаемом поведении системы, пользователя или процесса;
- почему существующее поведение не позволяет получить требуемый результат;
- какие части предлагаемого решения действительно следуют из требований, а какие появились как предварительные технические или продуктовые предположения;
- какие ограничения уже существуют и должны сохраняться независимо от выбранного решения;
- где проходит граница текущего изменения и что сознательно остаётся за ней;
- какая неизвестность сильнее всего влияет на возможность поставить и выполнить работу.
Например, запрос «добавить повторную оплату заказа» ещё не определяет требуемое изменение. Из него непонятно, создаётся ли новый заказ, должен ли сохраняться остаток, сколько времени пользователь может повторять оплату, какие способы оплаты разрешены, что происходит при нескольких попытках и какой результат должна видеть поддержка.
После прояснения запрос должен быть зафиксирован уже не как название feature, а как небольшой delivery brief.
Минимальный delivery brief
Проблема:
Пользователь не может завершить уже созданный заказ после отклонения первоначальной оплаты.
Получатель результата:
Пользователь, чья оплата существующего заказа была отклонена.
Требуемое изменение:
Пользователь должен в течение 30 минут выбрать другой способ оплаты и завершить существующий заказ без повторного бронирования.
Критерии результата:
- заказ не дублируется;
- остаток сохраняется на время повторной попытки;
- повторное списание невозможно;
- статус оплаты наблюдаем для поддержки.
Обязательные ограничения:
Повторная попытка должна работать внутри существующего заказа и не должна создавать новое бронирование.
Критическая неизвестность:
Необходимо установить, поддерживают ли используемые платёжные интеграции повторную попытку оплаты для существующего заказа без создания новой платёжной сущности.
Не входит в текущий объём:
Изменение процесса первоначальной оплаты и переработка checkout целиком.
Теперь у команды появляется определённый объект изменения, с которым можно дальше работать в delivery. До этого существовало только название feature и предполагаемая форма решения.
Некоторые команды формализуют достаточность такого прояснения как Definition of Ready: договорённость о том, какой степени определённости достаточно для начала реализации.
Но если Definition of Ready превращается в формальный чеклист, команда может начать проверять наличие заполненных пунктов вместо того, чтобы проверять, достаточно ли она понимает требуемое изменение.
2. Декомпозиция и slicing: как разделять работу
Декомпозиция — это разделение требуемого изменения на составные части и конкретные действия, необходимые для его реализации.
При разделении нужно решить, где провести границы между частями. Определение этих границ называют slicing.
Горизонтальный и вертикальный slicing
Плохая декомпозиция часто повторяет устройство технологии:
- Спроектировать таблицы.
- Создать backend endpoint.
- Реализовать frontend.
- Написать тесты.
- Настроить deployment.
Каждый пункт может быть выполнен отдельно, но ни один не создаёт пользовательского результата. Работа формально движется, а проверить целое можно только в конце.
Такой способ разделения работы называют horizontal slicing, или горизонтальным срезом: границы проходят по техническим слоям или видам работы.
Другой принцип — vertical slicing, или вертикальный срез: работа делится по частям требуемого изменения, а необходимые технические изменения выполняются внутри каждого среза.
Например, большую feature повторной оплаты можно разрезать так:
Срез 1: пользователь видит причину неуспешной оплаты и может повторить попытку той же картой.
Срез 2: пользователь может выбрать другую сохранённую карту.
Срез 3: пользователь может добавить новый способ оплаты.
Срез 4: поддержка видит историю попыток и причину отказа.
Каждый такой срез может потребовать изменений в UI, API, данных, интеграциях, тестах и наблюдаемости. Техническая работа не исчезает, но оказывается внутри части требуемого изменения.
По каким основаниям проводить границы вертикальных срезов
Основания для выбора границ среза могут быть разными:
- пользовательский сценарий;
- тип пользователя;
- основной и исключительные пути;
- бизнес-правила;
- интеграции;
- платформа или канал;
- география;
- объём данных;
- степень автоматизации;
- риск или неизвестность.
Признаки хорошего вертикального среза
Хороший вертикальный срез:
- может быть завершён и проверен без реализации остальных срезов;
- достаточно мал, чтобы команда быстро дошла до проверки результата.
Такое разделение позволяет раньше интегрировать изменение и получить обратную связь. Каждый завершённый срез может обнаружить риск или неизвестность и дать информацию для следующих решений.
Именно поэтому vertical slicing уменьшает размер ставки: объём работы, который команда должна завершить, прежде чем сможет проверить результат и скорректировать дальнейшее движение.
3. MVP: минимальный контур проверки смысла
MVP часто превращают либо в оправдание плохого качества, либо в уменьшенную копию всего будущего продукта.
Подмена 1:
«Это MVP, поэтому можно без тестов, наблюдаемости и нормальной обработки данных».
Подмена 2:
«Для MVP нужны все основные функции, только немного проще».
MVP — это минимальный целостный контур, достаточный для проверки главной гипотезы или получения первого реального результата.
Минимальность относится к объёму проверяемого предположения, а не к уровню инженерной ответственности.
Если MVP работает с реальными деньгами, он всё равно обязан исключать повторное списание. Если обрабатывает персональные данные, требования безопасности не становятся необязательными. Если включён для пользователей, команда должна иметь способ увидеть отказ и остановить изменение.
Для определения MVP нужно спросить:
- Какую единственную гипотезу мы проверяем?
- Какой минимальный пользовательский путь для этого необходим?
- Что можно сделать вручную за границей пользовательского опыта?
- Какие сегменты пока можно исключить?
- Какие качества системы являются неотменяемыми?
- Как будет собрана обратная связь?
- Как будет принято решение после проверки?
MVP не является автоматически первой версией feature. Иногда первая поставка нужна не для проверки продуктовой гипотезы, а для снятия технического риска. Тогда честнее назвать её technical walking skeleton, spike, pilot или ограниченной миграцией — в зависимости от функции результата.
4. Definition of Done: единая граница завершённости
Без общей Definition of Done слово «готово» означает для разных участников разные состояния:
Разработчик: код написан.
Reviewer: pull request принят.
QA: изменение проверено.
Product: пользователь может воспользоваться функцией.
Operations: изменение наблюдаемо и может быть восстановлено после отказа.
Definition of Done описывает состояние изменения, при котором оно соответствует установленным для продукта требованиям качества.
Возможная Definition of Done
Изменение считается Done, если:
- реализованы согласованные acceptance criteria;
- код прошёл review;
- автоматические проверки успешны;
- необходимые уровни тестирования выполнены;
- миграции данных проверены;
- соблюдены требования безопасности;
- добавлена необходимая наблюдаемость;
- обновлены значимые контракты и документация;
- изменение интегрировано в рабочее состояние продукта;
- оно находится в состоянии, пригодном для выпуска.
Конкретная Definition of Done зависит от продукта и характера изменения. Нельзя механически скопировать один checklist для банковской транзакции, внутреннего отчёта и экспериментального прототипа. Но нельзя и менять смысл Done под давление срока.
Если часть обязательного качества переносится «на потом», работа не стала законченной. Команда создала последующую работу и должна назвать её прямо.
Done не равно Release
Изменение может соответствовать Definition of Done, но ещё не быть доступно пользователям. Например, оно уже развёрнуто в production, но остаётся выключенным feature flag или ожидает отдельного продуктового решения о выпуске.
Поэтому важно различать две границы:
Done: изменение соответствует установленной границе качества и пригодно к выпуску.
Release: изменение стало доступно тем, для кого оно предназначено.
Если между Done и Release возникает значительный разрыв, лид должен видеть его отдельно и понимать, почему уже готовое изменение остаётся невыпущенным.
5. Видеть поток работы
Локальное состояние отдельных задач не показывает систему delivery. Десять карточек могут одновременно иметь статус In Progress, но ни одна из них не приближаться к завершению.
Лиду необходимо видеть не только состояние каждой задачи, но и путь изменения через всю систему delivery: где работа находится, где действительно изменяется, где ожидает, куда возвращается и перед какими состояниями начинает накапливаться очередь.
Для анализа такого потока можно использовать Value Stream Mapping.
Например, поток может проходить через следующие состояния:
Запрос → прояснение → готово к реализации → разработка → review → проверка → Done → deployment → release
Конкретная последовательность зависит от продукта и организации delivery. В одной системе deployment и release происходят практически одновременно, в другой между ними может существовать отдельная граница: изменение уже развёрнуто в production, но ещё не включено пользователям.
Для каждого состояния важно установить:
- что означает вход в него;
- что означает выход;
- кто или что может перевести работу в следующее состояние;
- какая работа реально выполняется внутри состояния;
- сколько времени объект непосредственно обрабатывается;
- сколько времени он просто ожидает;
- куда и по каким причинам работа возвращается;
- какая очередь образуется перед состоянием;
- какое ограничение пропускной способности существует.
Value stream mapping позволяет увидеть не только последовательность действий, но и время ожидания, handoff между участниками, возвраты и места накопления работы. Начальная карта не обязана описывать процесс во всех деталях: её достаточно уточнять там, где обнаруживается задержка, очередь или другое ограничение потока.
Время работы и время ожидания
Feature может пройти через delivery за двадцать календарных дней, хотя непосредственная работа над ней заняла только несколько дней:
| Состояние | Работа | Ожидание |
|---|---|---|
| Уточнение требования | 4 часа | 2 дня до ответа партнёра |
| Разработка | 2 дня | 1 день из-за переключения разработчика |
| Code review | 2 часа | 3 дня в очереди |
| QA | 1 день | 4 дня до свободного QA |
| Release | 1 час | 6 дней до release window |
В такой системе требование «разрабатывать быстрее» почти не изменит общий срок прохождения изменения. Основная длительность находится в ожидании, очередях, handoff и правилах перехода между состояниями, поэтому ускорение отдельных операций мало влияет на общий поток.
WIP: незавершённая работа
Work in Progress — это работа, которая уже начата, но ещё не достигла своей границы завершения.
Чем больше одновременно начатой работы находится в системе, тем больше объектов конкурируют за ограниченное внимание и пропускную способность участников процесса.
Избыточный WIP создаёт:
- переключение контекста;
- длинные очереди;
- скрытые блокировки;
- позднюю интеграцию;
- устаревание принятых решений;
- большое число почти готовых задач;
- размытие реального приоритета.
Лид не должен стремиться загрузить каждого человека на сто процентов. Полная локальная загрузка участников может уменьшать пропускную способность всей системы: у людей не остаётся пространства помочь завершить уже начатую работу, провести review, снять блокировку или быстро отреагировать на изменение ситуации.
Цель delivery — не максимизировать количество начатой работы, а увеличивать завершение значимых изменений.
6. Управление зависимостями
Зависимость — это условие, без которого работа не может перейти в следующее необходимое состояние.
Зависимости бывают:
- техническими — API, данные, инфраструктура, библиотека;
- организационными — решение другой команды, доступ, согласование;
- продуктовыми — выбор поведения или приоритета;
- внешними — партнёр, поставщик, регулятор;
- временными — другая работа должна завершиться раньше;
- знаниевыми — необходим человек, который понимает конкретную область.
Само наличие зависимости не является управлением. Запись blocked by Team B только называет состояние.
Для значимой зависимости нужно определить:
- что именно требуется;
- от кого;
- к какому моменту;
- как подтверждается договорённость;
- что делает наша команда до получения результата;
- есть ли альтернативный путь;
- когда ожидание становится риском срока;
- кто инициирует эскалацию.
Стратегии работы с зависимостью
Лид может:
- устранить зависимость изменением границы решения;
- заменить синхронную зависимость стабильным контрактом;
- перенести зависимую часть в более поздний срез;
- поставить ранний contract test или stub;
- совместно провести discovery;
- получить временный fallback;
- изменить порядок работ;
- явно принять зависимость как риск;
- эскалировать конфликт приоритетов владельцам соответствующего уровня.
Плохое управление зависимостью выглядит как пассивное ожидание. Нормальное — как изменение плана вокруг известного ограничения.
7. Неизвестность, риски и spikes
Delivery происходит не в известной реальности, а внутри частично известной. Поэтому риск нельзя добавить в конце как формальный раздел отчёта. Он влияет на способ декомпозиции, последовательность работы и точность прогноза.
Риск — это не просто «что-то может пойти не так». Для управления нужно определить:
| Поле | Вопрос |
|---|---|
| Событие | Что именно может произойти? |
| Причина | Почему это возможно? |
| Последствие | Что изменится для результата? |
| Вероятность | Насколько это правдоподобно сейчас? |
| Воздействие | Насколько велик ущерб сроку, объёму или качеству? |
| Сигнал | Как мы поймём, что риск приближается? |
| Действие | Что уменьшаем заранее? |
| Владелец | Кто следит и действует? |
Пример
Слабая формулировка:
Есть риск с внешним API.
Рабочая формулировка:
Документация партнёра не определяет поведение при повторной доставке callback. Если callback будет доставлен повторно, текущая модель обработки может выполнить повторную смену статуса заказа и привести к некорректному состоянию заказа.
Для снижения риска до начала основной реализации необходимо:
- проверить поведение API в sandbox;
- реализовать идемпотентную обработку callback;
- получить письменное подтверждение контракта от партнёра.
Владелец: Анна.
Контрольная точка: вторник, 22 июля.
Spike
Spike — ограниченное по времени исследование, предназначенное для уменьшения конкретной неизвестности.
Нормальный spike имеет:
- Вопрос: что именно мы должны узнать?
- Timebox: сколько времени тратим?
- Выход: какое решение, измерение, прототип или перечень ограничений должен появиться?
- Следствие: как результат изменит план?
Spike без вопроса и условия завершения легко превращается в бесконечное исследование. Его результатом не обязана быть production-реализация, но обязано стать уменьшение неизвестности, влияющей на решение.
8. Работа с блокерами
Блокер — это не красная метка на карточке, а препятствие, из-за которого работа не может продолжить необходимое движение.
Для каждого блокера лид должен установить:
- что именно остановлено;
- какой следующий переход невозможен;
- почему;
- кто способен изменить ситуацию;
- какое действие уже сделано;
- когда ожидается ответ;
- что можно продолжить независимо;
- когда требуется изменить scope или последовательность;
- когда нужна эскалация.
Уровни реакции
- Локальное разрешение — команда сама меняет решение или порядок работы.
- Координация — требуется договорённость с конкретным владельцем зависимости.
- Изменение среза — заблокированная часть отделяется, остальное поставляется.
- Эскалация — владельцы зависимостей имеют конфликтующие приоритеты, который команда не уполномочена разрешить.
- Пересмотр результата — препятствие разрушает исходную гипотезу или делает решение нецелесообразным.
Эскалация не должна означать «пожаловаться начальству». Нормальная эскалация передаёт решение на уровень, где существуют необходимые полномочия:
- какой результат заблокирован;
- каким решением;
- какие варианты уже исследованы;
- каковы последствия каждого варианта;
- до какого момента решение необходимо.
9. Планирование как построение следующего управляемого горизонта
План не является обещанием, что реальность полностью совпадёт с представлением команды. План — это текущая модель движения к результату, которая должна изменяться при получении новой информации.
В delivery-плане должны быть видимы:
- требуемый результат;
- ближайший поставляемый срез;
- последовательность следующих срезов;
- критические зависимости;
- риски и неизвестности;
- контрольные точки;
- условия изменения scope;
- способ проверки результата.
Три горизонта
- Текущий горизонт — что команда делает сейчас и что должно завершиться следующим.
- Ближайший горизонт — какие срезы и решения последуют после текущего результата.
- Дальний горизонт — направление и крупные части, которые пока содержат значительную неизвестность.
Ошибка — требовать одинаковой детализации от всех горизонтов. Чем дальше находится работа, тем меньше оснований расписывать её до технических задач. Подробный дальний план часто создаёт не предсказуемость, а ложную форму известности.
Полная теория оценок и forecasting рассматривается в отдельном модуле «Планирование, оценки и управление неопределённостью». Здесь лид использует план как инструмент текущего управления потоком, а не как систему долгосрочного обещания дат.
10. Проверка результата и корректировка дальнейшего движения
Появление реализованного изменения не завершает получение информации о нём. До реализации команда работает с требованиями, предположениями, моделями и прогнозами. Работающий результат позволяет проверить их на самой системе и на взаимодействии с теми, для кого изменение создавалось.
Поэтому проверка результата является отдельной частью управления delivery.
Её функция состоит не в том, чтобы подтвердить, что команда выполнила запланированную работу, а в том, чтобы установить:
- произошло ли требуемое изменение: соответствует ли фактическое поведение тому, которое было определено до реализации, и работает ли целый сценарий;
- какие свойства и ограничения результата проявились только после реализации;
- какие предположения подтвердились, а какие потребовали пересмотра;
- какие новые неизвестности и риски появились.
Полученная информация должна быть достаточной для решения о дальнейшем движении, а не только для констатации «работает» или «не работает».
Кто должен участвовать в проверке
Чтобы получить необходимую для решения информацию, к проверке должны быть привлечены те, чьё знание необходимо для оценки результата.
Это могут быть:
- product owner или другой владелец продуктового решения;
- пользователи;
- поддержка;
- operations;
- security;
- аналитики;
- представители зависимых команд;
- владельцы внешних интеграций;
- другие стейкхолдеры, способные обнаружить существенное свойство результата.
Не каждое изменение требует участия всех перечисленных ролей. Важно определить, чьё знание необходимо именно для этого результата.
Техническое изменение инфраструктуры может проверяться инженерами эксплуатации и владельцами зависимых сервисов. Изменение пользовательского сценария может требовать продуктовой проверки или наблюдения за реальным использованием. Изменение финансового процесса может требовать участия специалистов, отвечающих за соответствующие бизнес-правила.
Корректировка дальнейшего движения
Полученная при проверке информация может по-разному изменить дальнейшее движение.
Требуемое изменение подтверждено.
Команда продолжает движение по существующему плану.
Обнаружено локальное несоответствие.
Необходимо исправить конкретную часть реализованного результата.
Изменилось понимание требуемого изменения.
Необходимо пересмотреть границы feature или следующие запланированные срезы.
Выбранный способ реализации не позволяет получить требуемое изменение.
Необходимо выбрать другой способ реализации.
Обнаружен новый риск или ограничение.
Необходимо учесть его влияние на последующую работу и при необходимости изменить план.
Таким образом, проверка результата замыкает контур между реализацией и следующим управленческим решением.
Подмена проверки результата
Проверка перестаёт выполнять свою функцию, когда превращается в демонстрацию проделанной работы.
Признаки подмены:
- участники показывают только заранее выбранный успешный сценарий;
- вопросы воспринимаются как критика команды;
- обнаруженные несоответствия откладываются за пределы обсуждения;
- решение считается окончательным независимо от увиденного;
- демонстрация используется для подтверждения объёма выполненной работы;
- после появления новой информации план не меняется.
В таком случае событие сообщает о деятельности команды, но не используется для управления delivery.
11. Изменение системы работы
Delivery-проблемы возникают не только внутри отдельных задач. Одна и та же задержка, ошибка или потеря информации может воспроизводиться потому, что её создаёт сама организация работы.
Если каждое изменение три дня ожидает code review, проблема находится не в конкретной задаче.
Если требования регулярно уточняются только после начала реализации, проблема не заканчивается на очередном неверно понятом требовании.
Если одна команда постоянно ждёт решения другой команды, отдельная эскалация может снять конкретный блокер, но не устранить устройство системы, которое воспроизводит эту зависимость.
Поэтому лид должен управлять не только прохождением конкретной работы, но и изменением самой системы, через которую эта работа проходит.
От единичного события к воспроизводящему механизму
Не каждое отклонение требует изменения процесса.
Если один deployment задержался из-за разового отказа внешней инфраструктуры, причиной может быть конкретное событие.
Но если одинаковые задержки возникают регулярно, необходимо искать механизм, который их воспроизводит.
Полезные вопросы:
- Где работа регулярно теряет время?
- Какая очередь возникает снова?
- Какие решения систематически принимаются слишком поздно?
- Где информация теряется при передаче между участниками?
- Какие зависимости постоянно превращаются в блокеры?
- Какие дефекты обнаруживаются только на позднем этапе?
- Где возникает повторная работа?
- Какое правило создаёт ненужное ожидание?
- Какое распределение ответственности оставляет решение без владельца?
- Какое ограничение пропускной способности повторно задерживает поток?
Объектом анализа становится не человек, допустивший конкретную ошибку, а механизм, благодаря которому одинаковое состояние может возникать снова.
Найти причину недостаточно
Обнаруженная системная проблема сама по себе ещё ничего не меняет.
Формулировки:
- «review долго идёт»;
- «требования плохие»;
- «другая команда постоянно тормозит»;
- «QA подключается поздно»;
- «слишком много встреч»
описывают наблюдаемое состояние, но не определяют управленческое действие.
Необходимо установить:
- какое поведение системы наблюдается;
- каким механизмом оно воспроизводится;
- на какую часть delivery оно влияет;
- что именно можно изменить;
- кто способен изменить это;
- какой эффект ожидается;
- как будет проверено, что изменение действительно сработало.
Изменение должно быть конкретным
Например, команда обнаружила, что pull request в среднем несколько дней ожидает начала review.
Недостаточное решение:
Нужно быстрее делать review.
Эта формулировка не изменяет устройство системы.
Конкретное изменение может выглядеть иначе:
Команда ограничивает количество одновременно открытых pull request и перед началом новой работы сначала помогает завершить уже ожидающий review срез.
Или:
Для изменений до определённого размера вводится правило review в течение текущего рабочего дня, а крупные изменения должны разбиваться до открытия pull request.
В обоих случаях изменяется конкретный элемент системы работы.
Изменение системы является гипотезой
Даже разумное изменение процесса не следует считать правильным только потому, что команда договорилась его внедрить.
У изменения есть предполагаемая причинность:
Если изменить X, должно измениться Y.
Например:
Если ограничить количество одновременно начатой работы, уменьшится очередь перед review и сократится cycle time.
Это предположение необходимо проверить наблюдением.
Поэтому для изменения системы полезно определить:
Проблема: какое повторяющееся поведение наблюдается.
Изменение: что конкретно команда делает иначе.
Ожидаемый эффект: какое поведение системы должно измениться.
Период проверки: когда появится достаточно данных для оценки.
Сигнал: по какому наблюдаемому признаку будет понятно, что изменение работает.
Не превращать улучшение системы в накопление инициатив
Работа над процессом тоже создаёт Work in Progress.
Если после каждого обсуждения появляется несколько новых инициатив:
- переписать процесс refinement;
- поменять branching strategy;
- ввести новые встречи;
- изменить шаблон задач;
- перестроить CI;
- добавить новые метрики;
- изменить правила review,
команда может создать второй backlog, который сам перестанет завершаться.
Поэтому изменения системы также необходимо ограничивать.
Лучше выбрать конкретный механизм, изменить его и проверить эффект, чем одновременно начать перестраивать весь delivery-контур.
Подмена изменения системы
Изменение системы подменяется, когда обсуждение заканчивается без изменения воспроизводящего механизма.
Типичные варианты:
- участники перечислили проблемы, но не определили действие;
- действие сформулировано как пожелание «быть внимательнее»;
- ответственность перенесена на отдельных людей без изменения условий работы;
- принято слишком много улучшений одновременно;
- изменение внедрено, но никто не проверяет его эффект;
- одна и та же проблема обсуждается цикл за циклом в неизменном виде.
Разговор может быть полезен сам по себе: участники могут обнаружить конфликт, перегрузку, потерю информации или другое состояние, которое раньше оставалось невидимым.
Но для управления delivery этого недостаточно. Обнаруженное состояние должно привести к изменению элемента системы, который способен повлиять на его повторное возникновение.
Улучшение delivery происходит не тогда, когда команда лучше описала свою проблему, а тогда, когда она изменила механизм, который эту проблему воспроизводит, и проверила результат изменения.
12. Контроль прогресса без микроменеджмента
Микроменеджмент появляется, когда лид пытается получить управляемость через постоянное наблюдение за действиями людей:
- Что ты делал вчера?
- Сколько процентов готово?
- Почему задача ещё не закрыта?
- Когда закончишь?
- Почему тебя не видно в чате?
Проблема не в самом праве задавать эти вопросы. Проблема в объекте контроля: лид наблюдает человека вместо движения работы.
Объектом контроля должно быть само движение работы: какой результат должен появиться, где работа находится сейчас, что влияет на её дальнейшее движение, как новая информация меняет прогноз и какое действие необходимо.
Контроль строится вокруг следующих уровней.
1. Результат
Главный вопрос:
Какой ближайший проверяемый результат должен появиться?
Лид контролирует не объём совершённых действий, а появление состояния, которого раньше не существовало и которое можно проверить.
Без определённого ближайшего результата невозможно понять, является ли происходящая активность продвижением.
2. Состояние потока
Необходимо понимать, где находится работа и какой переход должен произойти дальше:
- Какой срез находится в работе?
- Что стало ближе к завершению?
- Что должно завершиться следующим?
- Какой переход должен произойти следующим?
- Где работа не движется?
- Сколько работа находится в текущем состоянии?
Такой контроль позволяет увидеть не только факт незавершённости, но и конкретное место, в котором движение работы замедлилось или остановилось.
3. Риски и зависимости
Текущее состояние работы необходимо рассматривать вместе с условиями, способными остановить или изменить её дальнейшее движение:
- Что может остановить ближайший результат?
- Какая зависимость сейчас влияет на движение работы?
- Какой сигнал риска уже появился?
- Какого решения не хватает?
- Кто способен принять это решение?
Здесь лид контролирует не абстрактный список рисков и зависимостей, а те из них, которые способны повлиять на ближайший результат или уже влияют на него.
4. Изменение прогноза
Новая информация может изменить дальнейший план:
- Что мы узнали с прошлого обновления?
- Что из прежних предположений изменилось?
- Как новая информация меняет scope?
- Нужно ли изменить последовательность следующих срезов?
- Изменилась ли ожидаемая дата?
- Требуется ли новая контрольная точка?
Прогноз не должен сохраняться только потому, что однажды был зафиксирован. Если изменилось известное состояние работы, должно быть видно, как это повлияло на дальнейшее движение.
5. Необходимое действие
После определения состояния работы и его влияния на прогноз команда должна понять, что необходимо изменить в текущем действии:
- Какая помощь необходима сейчас?
- Какое решение необходимо получить?
- Нужно ли изменить порядок работы?
- Можно ли продолжить другую часть независимо?
- Нужно ли нескольким участникам объединить усилия вокруг одного среза?
- Нужно ли временно прекратить начало новой работы и помочь завершить уже начатую?
- Требуется ли изменить техническое решение, границу среза или способ взаимодействия с зависимостью?
- Требуется ли эскалация?
Контроль прогресса не заканчивается обнаружением того, что работа движется медленно, остановилась или отклонилась от первоначального плана. Полученная информация должна изменить действие команды.
Вопрос «Почему ты ещё не сделал задачу?» направляет контроль на человека.
Вопрос «Что сейчас необходимо изменить, чтобы этот срез перешёл в следующее состояние?» направляет внимание на работу и позволяет команде определить необходимое совместное действие.
Команда не сообщает лиду набор индивидуальных активностей. Участники совместно устанавливают состояние работы, обнаруживают препятствия, пересматривают прогноз и определяют, что необходимо сделать дальше.
Таким образом, контроль прогресса образует последовательность:
ближайший результат → состояние работы → риски и зависимости → изменение прогноза → необходимое действие.
13. Активность не равна продвижению
Команда может быть полностью занята и при этом ничего не доводить до результата.
Признаки активности без продвижения
- растёт число начатых задач;
- проводятся дополнительные встречи, но после них не появляются решения;
- участники постоянно переключаются;
- создаются документы, не приводящие к решению;
- переписывается одна и та же часть кода;
- блокеры обсуждаются, но не приводят к действию;
- задачи длительное время остаются на уровне «готово на 90%»;
- локальные компоненты завершаются, но целый сценарий не собирается;
- команда сообщает объём сделанного, но не может назвать изменившееся состояние работы.
В такой ситуации лид должен возвращать внимание от количества действий к их результату:
- Что изменилось?
- Что теперь стало возможно?
- Какой результат появился?
- Какая часть стала доступна для проверки?
- Какой блокер или риск был снят?
- Какое решение позволило работе двигаться дальше?
- Что приблизилось к Done, deployment или release?
Это не обесценивание труда. Проблема возникает тогда, когда система потребляет усилия команды, но не превращает их в завершение работы.
14. Метрики потока
Метрики нужны не для создания рейтинга людей, а для обнаружения поведения системы.
Базовые 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 превратился в очередь или задачи стали чаще возвращаться после позднего тестирования.
15. DORA-метрики
DORA выделяет пять метрик software delivery performance. Они описывают способность системы проводить изменения в production быстро и стабильно и объединяются в две группы: throughput и instability. (DORA Metrics)
Throughput
Throughput показывает способность системы проводить изменения до production.
1. Change lead time
Время от фиксации изменения в системе контроля версий до успешного deployment в production.
Важно отличать эту метрику от полного lead time, рассмотренного в предыдущем разделе. DORA change lead time начинается с commit и не включает время от появления потребности до начала технической реализации.
Если требование два месяца ожидает прояснения или начала разработки, DORA change lead time этого не покажет.
2. Deployment frequency
Количество deployment за определённый период или время между deployment.
Метрика показывает, насколько часто система способна проводить изменения в production.
3. Failed deployment recovery time
Время восстановления после deployment, который привёл к отказу и потребовал немедленного вмешательства.
Эта метрика отличается от широкого MTTR: она относится именно к восстановлению после проблемы, вызванной изменением в production, а не к любому инциденту независимо от причины. (DORA: история метрик)
Instability
Instability показывает, насколько часто проведение изменений создаёт необходимость немедленного исправления или дополнительной незапланированной работы.
4. Change fail rate
Доля deployment, после которых требуется немедленное вмешательство, например rollback, hotfix, fix forward или patch.
5. Deployment rework rate
Доля незапланированных deployment, выполняемых для исправления проблем, обнаруженных в production.
Метрика делает видимой повторную работу после поставки изменений. Система может иметь высокую частоту deployment, но часть этих deployment будет не продвижением продукта, а исправлением последствий предыдущих изменений.
Граница DORA-метрик
DORA-метрики измеряют software delivery performance, а не весь delivery-контур.
Они позволяют увидеть:
- насколько быстро изменения проходят технический участок до production;
- насколько часто система способна выполнять deployment;
- насколько часто deployment приводит к отказу;
- насколько быстро система восстанавливается после такого отказа;
- какая доля deployment возникает из-за повторной работы.
Но они не показывают время от появления потребности до первого commit, ожидание продуктовых решений до начала реализации или outcome выпущенного изменения.
Поэтому DORA-метрики не заменяют метрики полного потока, рассмотренные в предыдущем разделе. Они измеряют более узкий участок системы delivery.
Как использовать DORA-метрики
DORA рекомендует рассматривать метрики в контексте конкретного приложения или сервиса и наблюдать их изменение во времени. Сравнение существенно разных систем может скрывать различия в их устройстве и условиях работы. (DORA Metrics)
DORA также предостерегает от нескольких подмен:
- превращения метрики в обязательную цель;
- выбора одной «главной» метрики;
- сравнения принципиально разных приложений и сервисов;
- разделения ответственности за метрики между development и operations;
- использования метрик для соревнования команд;
- построения сложной системы измерения вместо улучшения самой delivery-системы.
Метрики должны помогать обнаруживать ограничения системы и проверять эффект изменений в способе работы.
Их основной управленческий вопрос:
Как меняется способность конкретной системы быстро и стабильно проводить изменения в production?
Итоги модуля
Лид удерживает не занятость команды, а прохождение работы через систему от потребности до поставленного и проверенного изменения.
Он должен уметь:
- прояснить исходный запрос и определить требуемое изменение;
- провести границу текущего изменения;
- разделить большую feature на поставляемые срезы;
- выделить минимальный проверяемый контур;
- определить границу завершённости;
- видеть состояния потока, очереди, ожидание и незавершённую работу;
- выявлять неизвестности и управлять рисками;
- управлять зависимостями и блокерами;
- строить ближайший управляемый горизонт и перестраивать план при получении новой информации;
- проверять появившийся результат и использовать полученную информацию для следующих решений;
- изменять элементы системы работы, которые воспроизводят задержки, повторную работу и другие delivery-проблемы;
- контролировать прогресс через движение работы, а не через постоянное наблюдение за действиями людей;
- отличать активность от продвижения;
- измерять поведение потока и способность системы проводить изменения.
Главное различение модуля
Лид не обеспечивает результат тем, что заставляет каждого человека двигаться быстрее.
Лид обеспечивает результат тем, что делает видимым и управляемым движение самой работы.
Команда может быть занята и не двигаться. Она может написать много кода и не поставить изменение. Может завершить отдельные технические части, но не собрать проверяемый результат. Может выполнить первоначальный scope и после проверки обнаружить, что требуемое изменение не достигнуто.
Поэтому вопрос лида не заканчивается на «что сделано?».
Он последовательно удерживает другие вопросы:
- Какой результат должен появиться?
- Где работа находится сейчас?
- Что должно перейти в следующее состояние?
- Что мешает этому переходу?
- Что осталось неизвестным?
- Какой риск или зависимость влияет на движение?
- Что изменилось после выполненной работы?
- Что подтвердилось при проверке результата?
- Как новая информация меняет дальнейший план?
- Какое действие необходимо следующим?
- Какой элемент системы работы необходимо изменить, если одна и та же проблема воспроизводится?
Именно эта способность превращает управление разработкой из контроля человеческой активности в управление технической причинностью.
