Delivery Manager в IT: управление поставкой продукта от идеи до релиза

Курс о роли Delivery Manager в IT: как организовать процесс разработки и поставки, управлять рисками, сроками, качеством и ожиданиями стейкхолдеров. Рассмотрим практики Agile/Lean, метрики, управление командой и выстраивание эффективного delivery-потока.

1. Роль Delivery Manager и зона ответственности в IT

Роль Delivery Manager и зона ответственности в IT

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

> "Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." (The Scrum Guide)

Scrum (и другие agile-подходы) помогает создавать ценность, но не гарантирует, что поставка через множество команд и контуров будет предсказуемой сама по себе. Delivery Manager как раз и закрывает разрыв между созданием и поставкой.

Что такое delivery в IT

Delivery в IT — это процесс доведения изменения до пользователей или до следующего потребителя (например, внутренней платформы или интеграционного контура) так, чтобы изменение:

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

    • Важно различать:

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

    • Кто такой Delivery Manager

    Delivery Manager — это менеджер, который обеспечивает сквозную поставку результата через команды и контуры.

    Его фокус:

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

    • Delivery Manager обычно не “владелец продукта” и не “руководитель разработки” в классическом смысле. Он помогает системе работать так, чтобы ценность доезжала до пользователей.

    Где находится роль в организации

    Роль зависит от контекста:

  • В продуктовой компании Delivery Manager часто работает рядом с Product Manager или Product Owner, помогая планировать и поставлять инкременты.
  • В заказной разработке Delivery Manager может быть связующим звеном между аккаунтом, проектом и несколькими командами.
  • В enterprise-среде Delivery Manager часто управляет поставкой через несколько подразделений: разработка, тестирование, безопасность, инфраструктура, архитектура, бизнес.

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

    Сравнение Delivery Manager с соседними ролями

    | Роль | Главная цель | Основной фокус | Типичные артефакты | |---|---|---|---| | Product Manager / Product Owner | Что и зачем делать | Ценность, приоритеты, гипотезы, бэклог | Видение, roadmap, backlog, критерии ценности | | Engineering Manager / Team Lead | Как делать качественно и устойчиво | Люди, инженерные практики, архитектурные решения, качество кода | План развития команды, техдолг, практики, стандарты | | Scrum Master / Agile Coach | Эффективность команды в фреймворке | Процесс внутри команды, события Scrum, улучшения | Улучшения процесса, working agreements | | Project Manager | Выполнить проект по треугольнику ограничений | Сроки, бюджет, содержание, контракт, отчетность | План проекта, бюджет, RAID, отчеты | | Delivery Manager | Довести изменения до релиза управляемо | Сквозной поток, зависимости, релизная готовность, предсказуемость | План поставки/релизов, карта зависимостей, риск-лог, статус, метрики потока |

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

    Зона ответственности Delivery Manager

    Ниже — типовые области ответственности. В каждой компании границы могут отличаться, но структура чаще всего похожа.

    Управление потоком поставки от идеи до релиза

    Delivery Manager организует и поддерживает поток работы так, чтобы задачи проходили этапы без лишних ожиданий и сюрпризов:

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

    • Цель — чтобы работа меньше “зависала” между командами, средами и согласованиями.

    Планирование, прогнозирование и управление ожиданиями

    Delivery Manager отвечает за реалистичную картину поставки, а не за “оптимистичные обещания”. Обычно это включает:

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

    • Важно: Delivery Manager не обязан “гарантировать дату любой ценой”, но обязан обеспечить управляемость и прозрачность.

    Управление зависимостями и кросс-командная координация

    Большая часть проблем поставки в IT — не в коде, а в связях:

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

    • Delivery Manager делает зависимости видимыми, назначает владельцев по их закрытию и следит за сроками. Часто помогает договориться о правилах интерфейсов и о релизной дисциплине.

    Управление качеством поставки и релизной готовностью

    Delivery Manager не заменяет QA и не “принимает код”, но отвечает за то, чтобы готовность к релизу была обеспечена как система. Типовые элементы:

  • Определение критериев готовности (например, Definition of Done и релизные чек-листы).
  • Поддержка стратегии тестирования (что тестируем где, кто отвечает за регресс, какие автоматизации критичны).
  • Контроль обязательных проверок перед выпуском (безопасность, производительность, совместимость, миграции).

    • Управление рисками, проблемами и изменениями

    Delivery Manager ведет риски и проблемы так, чтобы команда и стейкхолдеры не узнавали о них “в последний день”. Практика обычно включает:

  • Регулярный обзор рисков и планов реагирования.
  • Эскалации, когда зависимость не закрывается.
  • Управление изменениями объема поставки (что убираем, что переносим, что режем на версии).

    • Полезный формат — простой RAID-лог: Risks, Assumptions, Issues, Dependencies.

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

    Delivery Manager выстраивает регулярную коммуникацию:

  • Кто принимает решения и в какие сроки.
  • Где смотреть актуальный статус.
  • Что является сигналом “мы не успеваем”.

    • Хорошая коммуникация — это не “частые статусы”, а понятные правила и единый источник правды.

    Улучшение системы поставки

    Delivery Manager помогает улучшать процесс поставки на уровне системы:

  • Убирает повторяющиеся причины задержек.
  • Помогает автоматизировать путь до релиза (совместно с инженерами и DevOps).
  • Вводит и поддерживает метрики потока.

    • Цель — не “процесс ради процесса”, а снижение стоимости задержки и увеличение надежности релизов.

    Границы ответственности

    Delivery Manager обычно не является:

  • Владельцем продуктовой стратегии и приоритетов (это зона Product Manager / Product Owner).
  • Прямым руководителем всех участников поставки (если нет линейных полномочий).
  • Человеком, который “делает за всех”, закрывая пробелы руками вместо устранения причины.

    • Но Delivery Manager обязан поднимать проблемы, делать их видимыми и доводить до решения через договоренности, фасилитацию и эскалации.

    Типовой цикл поставки и контрольные точки

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

    Типовые контрольные точки, которые часто держит Delivery Manager:

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

    • Артефакты Delivery Manager

    Артефакты зависят от культуры компании, но чаще всего используются:

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

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

    Метрики успеха: как понять, что delivery работает

    Метрики нужны, чтобы управлять системой, а не “оценивать людей”. Один из самых известных наборов для оценки поставки — DORA-метрики:

  • Deployment Frequency: как часто поставляем изменения.
  • Lead Time for Changes: как быстро изменение проходит путь до продакшена.
  • Change Failure Rate: как часто релиз приводит к деградации и требует исправлений.
  • Time to Restore Service: как быстро восстанавливаемся после инцидента.

    • Описание подхода и метрик можно посмотреть на сайте DORA.

    В дополнение к DORA в компаниях часто полезны метрики потока:

  • WIP: объем незавершенной работы.
  • Cycle Time: время от старта работы до готовности.
  • Доля задач, заблокированных зависимостями.

    • Delivery Manager помогает договориться о корректных определениях метрик, чтобы сравнение было честным.

    С кем Delivery Manager взаимодействует чаще всего

    Ключевые группы:

  • Бизнес-стейкхолдеры: ожидания, приоритеты, критерии успеха.
  • Product-роль: содержание поставки и ценность.
  • Инженерные лиды: технические риски, качество, архитектурные ограничения.
  • QA и безопасность: критерии качества, обязательные проверки.
  • DevOps/платформа/инфраструктура: среды, CI/CD, релизные процедуры.
  • Поддержка и операции: мониторинг, инциденты, readiness, коммуникации пользователям.

    • Хороший Delivery Manager снижает стоимость коммуникаций: меньше встреч “на всякий случай”, больше ясных правил и прозрачных артефактов.

    Первые шаги Delivery Manager в новой команде или проекте

    Практичный план, который часто дает быстрый эффект:

  • Зафиксировать цель поставки и критерии успеха.
  • Составить карту стейкхолдеров и расписание ключевых синхронизаций.
  • Визуализировать текущий поток (стадии, очереди, где чаще всего стопорится работа).
  • Собрать и сделать видимыми зависимости и риски.
  • Договориться о минимальном релизном процессе и чек-листе.
  • Настроить прозрачный статус и единый источник правды.

    • Итоги

    Delivery Manager — это роль про управляемую поставку: предсказуемость, зависимость-менеджмент, релизную готовность, прозрачность и улучшение системы доставки.

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

    2. Delivery-модель: SDLC, Agile, Lean и выбор подхода

    Delivery-модель: SDLC, Agile, Lean и выбор подхода

    Delivery Manager отвечает за управляемую поставку от идеи до релиза: предсказуемость, риски, зависимости, готовность к выпуску и прозрачную коммуникацию. Чтобы это работало, нужна понятная delivery-модель — договоренность о том, как именно изменения проходят путь от запроса до продакшена.

    Эта статья связывает роль Delivery Manager (из предыдущей темы) с практическим выбором подхода: SDLC, Agile и Lean. Главная мысль: “правильного” подхода для всех не существует; есть подход, подходящий вашему контексту, и набор осознанных компромиссов.

    Что такое delivery-модель и зачем она нужна

    Delivery-модель — это набор правил и практик, который отвечает на вопросы:

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

    • Для Delivery Manager модель важна потому, что она задает:

  • Контрольные точки (quality gates, approvals).
  • Ритм планирования и релизов.
  • Механику управления WIP (незавершенной работой) и очередями.
  • Формат статусов для стейкхолдеров.

    • Если модель не проговорена, обычно происходит следующее: команды “живут по Agile”, а внешние контуры (безопасность, инфраструктура, бизнес-приемка) — по “водопаду”, и поставка становится непредсказуемой.

    SDLC: базовая рамка жизненного цикла

    SDLC (Software Development Life Cycle) — это жизненный цикл разработки ПО: типовые стадии, через которые проходит изменение от идеи до эксплуатации.

    Важно: SDLC — не равно “водопад”. SDLC описывает что вообще должно случиться (в каких-то вариантах), а модель разработки описывает как это организовано во времени и управлении.

    Типовые стадии SDLC (названия могут отличаться):

  • Инициация и формулирование потребности.
  • Анализ и уточнение требований.
  • Проектирование решения (функционально и технически).
  • Реализация (код, конфигурации, инфраструктура как код).
  • Тестирование (функциональное, регресс, безопасность, производительность).
  • Развертывание (релиз) и миграции.
  • Эксплуатация, мониторинг, поддержка.
  • Улучшения и управление техдолгом.

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

    Классические модели SDLC и их влияние на delivery

    Waterfall (каскадная модель)

    Waterfall — последовательная модель: сначала требования, потом дизайн, потом реализация, потом тестирование, потом релиз.

    Сильные стороны:

  • Удобно для жестких контрактов и фиксированного объема.
  • Легче согласовывать заранее (особенно в регулируемых средах).

    • Слабые стороны:

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

    • Роль Delivery Manager в таком контексте часто ближе к управлению вехами, очередями согласований, качественными “воротами” и изменениями объема.

    V-model (V-образная модель)

    V-model — вариант каскада, где каждой стадии спецификации соответствует стадия тестирования (например, системным требованиям — системные тесты).

    Полезно, когда качество и трассируемость критичны (например, “что требовали” → “как проверили”).

    Риск для поставки: если тестовые артефакты и среды не готовы вовремя, то “правая сторона V” превращается в узкое место.

    Iterative / Incremental (итеративная и инкрементальная разработка)

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

    • Эти модели чаще дают более раннюю обратную связь и позволяют управлять рисками через ранние интеграции.

    Spiral (спиральная модель)

    Spiral — развитие через циклы, где на каждом витке явно управляют рисками (прототипирование, оценка, планирование следующего витка). Это полезно при высокой неопределенности и технологических рисках.

    Agile: когда важнее адаптивность и обратная связь

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

    Ключевые идеи хорошо выражены в Agile Manifesto.

    Важно различать:

  • Agile как ценности и принципы.
  • Scrum, Kanban и другие фреймворки как конкретные реализации.

    • Scrum как delivery-ритм

    Scrum задает регулярный цикл (спринт) и события, которые помогают синхронизировать ожидания и делать инкремент. Формальное определение Scrum: The Scrum Guide.

    Когда Scrum помогает поставке:

  • Есть четкий поток “идея → бэклог → спринт → инкремент”.
  • Команда умеет “закрывать” работу до состояния готовности (Definition of Done).
  • Интеграции и релизные активности встроены в процесс, а не вынесены “в конце”.

    • Когда Scrum не спасает delivery:

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

    • Тогда Delivery Manager дополняет Scrum системным управлением зависимостями, релизной дисциплиной и сквозными метриками.

    Kanban как управление потоком

    Kanban — подход, который фокусируется на визуализации потока, ограничении WIP и управлении временем прохождения работы.

    Практическая ценность для delivery:

  • Появляется управляемость очередей (что “в работе”, что “ждет”, что “заблокировано”).
  • Легче находить узкие места и снижать время ожидания.

    • Ориентир по базовым принципам и практикам: Kanban Guides.

    Kanban часто хорошо работает в:

  • Поддержке и сопровождении.
  • Платформенных и инфраструктурных командах.
  • Командах с нерегулярным входящим потоком.

    • Agile в enterprise: типичная ловушка

    Частый анти-паттерн: Agile внутри команд + Waterfall между командами. В итоге:

  • Внутри спринта все “почти готово”.
  • В релизном контуре работа стоит неделями.

    • Delivery Manager в enterprise-контексте обычно отвечает за то, чтобы “между командами” тоже появился управляемый поток: общие критерии готовности, понятные интеграции, общий релизный календарь и прозрачные зависимости.

    Lean: фокус на ценности и устранении потерь

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

    В контексте IT Lean чаще всего проявляется не как “процесс”, а как принципы, которые улучшают любой процесс.

    Типовые “потери” в поставке:

  • Ожидание согласований, доступов, сред.
  • Переключение контекста из-за множества параллельных задач.
  • Частичные готовности: “код готов”, но тесты не готовы; “тесты готовы”, но нет среды.
  • Дефекты, найденные поздно, которые создают дорогую переделку.

    • Инструменты Lean-мышления, полезные Delivery Manager:

  • Визуализация потока и очередей.
  • Ограничение WIP.
  • Управление размером партий (меньше изменений за релиз — ниже риск).
  • Постоянные улучшения на основе причин задержек, а не симптомов.

    • DevOps и CI/CD как часть delivery-модели

    DevOps — это не “команда DevOps”, а набор практик, которые сближают разработку и эксплуатацию ради более надежной и быстрой поставки.

    CI/CD (Continuous Integration / Continuous Delivery) — автоматизация интеграции и доставки изменений.

    Delivery Manager обычно не “строит пайплайны” руками, но обязан понимать, как CI/CD влияет на:

  • Время прохождения (lead time) до продакшена.
  • Стабильность релизов.
  • Повторяемость и управляемость процедур (меньше ручных шагов — меньше случайных ошибок).

    • Как выбрать подход: критерии, а не религия

    Выбор delivery-модели — это решение с учетом ограничений. Удобно смотреть на контекст через несколько осей.

    !Схема помогает выбрать подход под контекст: неопределенность, риски, частота релизов и зависимости.

    Ключевые вопросы для выбора

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

    • Пример “матрицы выбора”

    | Контекст | Что обычно подходит | Почему | |---|---|---| | Высокая регуляторика, нужна трассируемость требований и проверок | V-model или Waterfall с сильными quality gates | Проще обеспечить доказуемость и контроль | | Высокая неопределенность, много исследовательской работы | Iterative/Spiral, прототипирование | Управление рисками и быстрые проверки гипотез | | Продукт, важна скорость обратной связи, можно поставлять часто | Agile (Scrum) + DevOps/CI/CD | Короткие циклы и регулярные инкременты | | Поток мелких задач, поддержка, много срочных входящих | Kanban + WIP limits | Управление очередью и предсказуемость потока | | Много команд и интеграций, релизы “сборкой” | Гибрид: Agile внутри команд + общий релизный контур + Lean-практики потока | Нужна сквозная координация и управление зависимостями |

    Гибридные модели: реальность большинства компаний

    Чаще всего Delivery Manager работает не в “чистом Scrum” и не в “чистом Waterfall”, а в гибриде.

    Типовой рабочий гибрид:

  • Внутри команды разработки — Agile (часто Scrum).
  • Между командами — синхронизация по интеграциям и зависимостям.
  • Релизы — по календарю релизных окон или по готовности, но с чек-листом.
  • Управление потоком и очередями — Kanban-элементы.
  • Улучшения и снижение потерь — Lean-подход.

    • Ключевой риск гибрида: если правила “стыков” не определены, система становится непредсказуемой.

    Что именно должен зафиксировать Delivery Manager в delivery-модели

    Ниже — практичный список того, что обычно дает наибольший эффект.

    Единые определения готовности

  • Definition of Ready: что должно быть уточнено, чтобы работу можно было брать в разработку.
  • Definition of Done: что значит “сделано” для команды.
  • Release readiness: что значит “можно выпускать” для организации.

    • Сквозной поток и статусы

  • Набор стадий “от идеи до релиза” (не слишком детально, но чтобы отражать реальность).
  • Правила перехода между стадиями.
  • Отдельный статус “blocked” и причина блокировки.

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

  • Список критичных зависимостей (с владельцами и сроками).
  • Регулярная синхронизация по интеграциям.
  • Процедура эскалации, если зависимость не закрывается.

    • Релизный контур

  • Релизный календарь или правила релиза “по готовности”.
  • Релизные роли и ответственность (кто инициирует, кто подтверждает, кто откатывает).
  • План коммуникации релиза.

    • Метрики, которые поддерживают выбор модели

    Полезно договориться о метриках потока, чтобы управлять системой, а не “ощущениями”:

  • Lead time: сколько времени проходит от запроса до продакшена.
  • Cycle time: сколько времени задача находится “в работе”.
  • WIP: сколько задач одновременно в процессе.
  • Доля заблокированных задач и причины блокировок.

    • Если организация зрелая, дополнительно опираются на DORA-метрики (частота деплоев, время изменений, доля неуспешных изменений, время восстановления): DORA.

    Частые ошибки при выборе и внедрении подхода

  • Выбирать фреймворк вместо решения проблемы.
  • Измерять успех “соблюдением ритуалов”, а не результатом поставки.
  • Пытаться “ускориться”, увеличив WIP, а не убрав узкие места.
  • Не учитывать релизный контур (безопасность, инфраструктуру, операции).
  • Делать тяжелые артефакты “на всякий случай”, не связывая их с решениями.

    • Итоги

    Delivery-модель — это не про “какой Agile правильный”, а про то, как в вашем контексте обеспечить управляемую поставку.

  • SDLC дает язык стадий и контрольных точек.
  • Agile дает ритм обратной связи и адаптивность.
  • Lean дает фокус на потоке и устранении потерь.
  • DevOps/CI/CD делают поставку повторяемой и быстрой.

    • Задача Delivery Manager — собрать это в работоспособную систему: договориться о правилах “стыков”, сделать зависимости и риски видимыми и обеспечить предсказуемый путь от идеи до релиза.

    3. Планирование, оценка и управление сроками и бюджетом

    Планирование, оценка и управление сроками и бюджетом

    Delivery Manager отвечает за управляемую поставку от идеи до релиза: предсказуемость, прозрачные риски, управляемые зависимости и понятные ожидания. В предыдущих темах мы разобрали роль Delivery Manager и то, как delivery-модель (SDLC, Agile, Lean и гибриды) задает правила потока и контрольные точки. Теперь добавим практический слой: как планировать поставку, оценивать сроки и стоимость и управлять изменениями так, чтобы прогноз был честным и полезным.

    Важный принцип: планирование и оценка в delivery — это не попытка “угадать дату”, а способ уменьшить неопределенность и договориться о правилах принятия решений.

    Термины: план, оценка и прогноз

    В delivery часто смешивают три понятия. Их полезно разделять.

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

    • Delivery Manager в зрелой организации стремится смещаться от “оценок-обещаний” к “прогнозам-на-данных”.

    Что именно мы пытаемся контролировать

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

  • Объем (scope): что именно войдет в релиз.
  • Сроки (time): когда это должно оказаться в продакшене.
  • Бюджет (cost): сколько это будет стоить.
  • Качество и риски (quality/risk): какие проверки обязательны, какой допустим риск.

    • Классическая ошибка — “фиксировать все сразу”: фиксированный объем, фиксированная дата, фиксированный бюджет и при этом “еще сделайте качественно”. Обычно система выдерживает максимум две жесткие фиксации, а остальное становится зоной компромисса.

    Уровни планирования в delivery

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

  • Инициатива/эпик: зачем делаем, какой ожидаемый эффект, какие ограничения и допущения.
  • Релизный план: какие инкременты попадут в какой релиз, какие вехи до релиза (интеграция, UAT, security review, миграции).
  • План на итерацию/спринт (если Scrum) или план пополнения потока (если Kanban): что берем в работу сейчас.
  • Ежедневное управление потоком: блокировки, зависимости, состояние сред, готовность к тестам и релизу.

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

    !Горизонты планирования и артефакты delivery

    Как построить реалистичный план поставки

    Практический алгоритм, который подходит и для Agile-гибридов, и для более “каскадных” контуров.

  • Зафиксировать цель и критерии успеха: что изменится после релиза и как это измерим.
  • Определить границы объема: что точно входит, что точно не входит, что под вопросом.
  • Нарезать объем на поставляемые инкременты: так, чтобы каждый инкремент имел ценность или хотя бы снижал риск (например, ранняя интеграция).
  • Нанести вехи SDLC и quality gates: дизайн/архитектура (если нужно), тестирование, безопасность, миграции, UAT, релизное окно.
  • Собрать зависимости: команды, системы, доступы, среды, внешние поставщики.
  • Согласовать календарные ограничения: релизные окна, freeze-периоды, праздничные дни, доступность ключевых людей.
  • Заложить управление рисками: буферы, альтернативные сценарии, условия эскалации.
  • Договориться об изменениях: как меняем объем/дату/бюджет, кто принимает решение.

    • План становится управляемым, когда у него есть владельцы вех, сроки закрытия зависимостей и правила пересмотра.

    Оценка: что именно оцениваем и в каких единицах

    В delivery встречаются три разных объекта оценки:

  • Трудозатраты (effort): сколько человеко-дней/часов нужно.
  • Длительность (duration): сколько календарного времени пройдет до готовности.
  • Стоимость (cost): сколько денег будет потрачено.

    • Переход от трудозатрат к длительности почти всегда ломается на реальности: ожидания сред, очереди на тестирование, внешние согласования и параллельные задачи. Поэтому Delivery Manager часто дополняет “инженерную оценку” оценкой потока.

    Базовая формула стоимости

    В простейшем виде стоимость можно представить как:

    Где:

  • — стоимость работ.
  • — ставка (стоимость часа/дня команды или подрядчика).
  • — трудозатраты.

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

    Техники оценки: что выбрать в каком контексте

    Ниже — популярные техники и их смысл для Delivery Manager.

    | Техника | Что дает | Когда уместна | Типичные риски | |---|---|---|---| | Экспертная оценка | Быстрое приближение | Ранние стадии, мало данных | Сильно зависит от эксперта и скрытых допущений | | Аналоги (reference class) | Оценка по похожим кейсам | Есть история поставок | Плохая сопоставимость, если контекст другой | | Декомпозиция (bottom-up) | Детализация работ и зависимостей | Когда нужно управлять вехами и рисками | Долго, ложная точность | | Story points / Planning Poker | Командное согласование сложности | Scrum-команды, регулярные итерации | Сложно переводить в сроки без данных потока | | T-shirt sizing | Грубая классификация размера | Портфель/roadmap, много инициатив | Слишком грубо для релизного обещания | | Трехточечная оценка | Явно учитывает неопределенность | Высокие риски, новые интеграции | Требует дисциплины в допущениях | | Throughput-based (по пропускной способности) | Прогноз на данных потока | Kanban, стабильный поток, есть метрики | Нужны качественные данные и одинаковые “единицы работы” |

    Трехточечная оценка как способ говорить о рисках

    Трехточечная оценка заставляет явно проговорить диапазон:

  • Оптимистично (O): если все идет идеально.
  • Наиболее вероятно (M): реалистичный сценарий.
  • Пессимистично (P): если реализуются основные риски.

    • Часто используют приближение ожидаемого значения по PERT:

    Где:

  • — ожидаемая оценка.
  • — оптимистичная оценка.
  • — наиболее вероятная.
  • — пессимистичная.

    • Delivery Manager ценит этот подход не за математику, а за эффект: команда и стейкхолдеры видят, какие риски “раздувают” срок, и могут заранее выбрать стратегию снижения риска.

    Прогнозирование сроков: от “обещаний” к вероятностям

    Оценка становится прогнозом, когда она:

  • опирается на исторические данные (cycle time, throughput, доля блокировок);
  • учитывает очереди и внешние контуры;
  • регулярно обновляется;
  • выражается не одной датой, а диапазоном или вероятностью.

    • Прогноз “по потоку” в реальной delivery-модели

    Если у вас Kanban-элементы и видимый поток, практичный вариант:

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

    • Технически это часто делают через Монте-Карло, но Delivery Manager важно не название метода, а управленческий результат: появляется разговор о вероятности и условиях, а не о “точной дате”.

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

    Контрольные точки и “готовности”

    Из предыдущей статьи про delivery-модель важны определения:

  • Definition of Ready: что нужно, чтобы начать.
  • Definition of Done: что значит “сделано” в команде.
  • Release readiness: что значит “можно выпускать” для организации.

    • Для сроков это критично: если “готово” в команде не означает “готово к релизу”, план будет систематически оптимистичным.

    Буферы: где они действительно нужны

    Буфер имеет смысл закладывать не “на всякий случай”, а в местах с понятной природой неопределенности:

  • интеграции с внешними системами;
  • миграции данных;
  • безопасность и compliance-проверки;
  • UAT и бизнес-приемка;
  • релизные окна и freeze-периоды.

    • Хорошая практика — держать буфер как управленческую сущность: кто может “тратить” буфер и по каким правилам.

    Управление критическим путем

    Даже в Agile-гибриде полезно понимать, какие работы формируют минимально возможный срок (критический путь). Обычно это:

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

    • Delivery Manager регулярно задает вопрос: что сегодня является самым ранним ограничением даты релиза? — и устраняет его или эскалирует.

    Управление бюджетом: модели, сбор и контроль

    Типовые модели финансирования

  • Fixed Price: фиксированная цена за фиксированный объем.
  • Time & Materials: оплата фактически затраченного времени.
  • Capacity-based: финансирование команды как мощности (например, “две команды на квартал”).

    • Delivery Manager чаще всего работает в hybrid-реальности: внутри продуктового финансирования может быть подрядчик с Fixed Price на часть работ, а релиз при этом общий.

    Из чего складывается бюджет

    Минимальный состав, который стоит держать видимым:

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

    • Базовые метрики контроля бюджета

  • Burn rate: сколько денег “сгорает” за неделю/спринт.
  • Cost to complete: сколько потребуется, чтобы завершить согласованный объем.
  • Отклонения: почему фактические траты расходятся с планом (люди, простои, переделки, дефекты, смена объема).

    • Delivery Manager помогает связать деньги с потоком: простои на средах и очереди согласований — это не “просто задержка”, это прямые затраты.

    Управление изменениями: как сохранять доверие

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

    Полезные правила change control

  • Любое изменение фиксируется как изменение объема, срока, бюджета или качества/рисков.
  • Есть понятный владелец решения (часто это продуктовая роль для объема и приоритетов, и спонсор/руководство для бюджета и дат).
  • Есть пороги эскалации (например, “если дата сдвигается более чем на 2 недели” или “если нужен +10% бюджета”).

    • Самый рабочий компромисс в Agile-доставке

    Во многих продуктовых контекстах фиксируют:

  • временной горизонт (например, релизное окно или конец квартала);
  • бюджет (команда на период);

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

    Статус и коммуникации: как сообщать сроки и деньги без “театра отчетности”

    Хороший статус — это инструмент принятия решений. Минимальный формат, который помогает стейкхолдерам:

    | Блок статуса | Суть | Пример вопроса, на который отвечает | |---|---|---| | Прогресс по вехам | Где мы на пути к релизу | “Интеграция завершена?” | | Прогноз даты | Диапазон и вероятность | “Когда будет готово с вероятностью 80%?” | | Риски и блокировки | Что угрожает сроку/бюджету | “Что может сдвинуть релиз?” | | Решения от стейкхолдеров | Что нужно решить и до когда | “Нужно согласовать компромисс по объему” | | Бюджетный статус | Burn rate и отклонения | “Мы укладываемся в лимит?” |

    Ключевое: Delivery Manager не “успокаивает”, а раньше подсвечивает — тогда у организации появляется пространство для маневра.

    Частые ошибки в планировании и оценке

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

    • Минимальный набор артефактов Delivery Manager для сроков и бюджета

  • Релизный план с вехами, владельцами и календарными ограничениями.
  • Карта зависимостей с датами закрытия и правилами эскалации.
  • RAID-лог для рисков, допущений, проблем и зависимостей.
  • Прогноз поставки на основе данных потока или обновляемых оценок.
  • Бюджетный трекер (burn rate, отклонения, резерв на риски).

    • Итоги

    Планирование, оценка и управление сроками и бюджетом — это “нервная система” delivery.

  • Delivery-модель задает стадии и контрольные точки, а Delivery Manager превращает их в управляемый релизный план.
  • Оценка полезна, если она честно отражает неопределенность и допущения.
  • Прогнозирование на данных потока повышает предсказуемость и качество разговоров со стейкхолдерами.
  • Управление изменениями и прозрачный статус сохраняют доверие даже тогда, когда сроки и бюджет приходится пересматривать.

    • 4. Управление командой и кросс-функциональным взаимодействием

    Управление командой и кросс-функциональным взаимодействием

    Delivery Manager отвечает за управляемую поставку от идеи до релиза: предсказуемость, зависимость-менеджмент, релизную готовность и прозрачные ожидания. В предыдущих темах мы разобрали роль, delivery-модель (SDLC, Agile, Lean) и практики планирования, оценки, сроков и бюджета. Теперь добавим то, без чего все это не работает в реальной организации: как выстраивать взаимодействие людей и команд так, чтобы поток задач проходил сквозь разработку, тестирование, безопасность, инфраструктуру, бизнес-приемку и операции.

    Ключевая идея: Delivery Manager редко “управляет командой” в смысле линейного руководства, но почти всегда управляет системой взаимодействия: правилами, ритмом, интерфейсами, эскалациями и прозрачностью.

    Что значит “управлять командой” в delivery-контексте

    В delivery контуре есть два слоя управления:

  • Внутри команды (обычно зона Engineering Manager/Team Lead, Scrum Master): качество инженерных практик, развитие людей, командный процесс.
  • Между командами и функциями (зона Delivery Manager): зависимости, интеграции, готовности, очереди, внешние согласования, релизный контур.

    • Поэтому управление командой для Delivery Manager чаще всего означает:

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

    • Если коротко: Delivery Manager не “ускоряет людей”, а ускоряет поток, убирая организационные и коммуникационные потери (Lean-логика из второй темы).

    Кросс-функциональная поставка: кто участвует и почему возникают конфликты

    Типовой контур поставки включает функции:

  • Product (Product Manager / Product Owner): ценность, приоритеты, критерии успеха.
  • Разработка: реализация и технические решения.
  • QA: стратегия тестирования, качество, регресс.
  • Безопасность и compliance: обязательные проверки, риски.
  • Архитектура: принципы, целостность, соответствие стандартам.
  • DevOps/платформа/инфраструктура: среды, CI/CD, релизные процедуры.
  • Operations/Support: мониторинг, инциденты, readiness, коммуникация пользователям.
  • Бизнес-стейкхолдеры: приемка, изменения процессов, обучение.

    • Конфликты в кросс-функциональной среде возникают не потому, что “люди плохие”, а потому что оптимизируют разные метрики:

  • Product оптимизирует ценность и скорость вывода.
  • Разработка оптимизирует устойчивость и технический риск.
  • QA оптимизирует качество и покрытие проверок.
  • Безопасность оптимизирует снижение вероятности и ущерба от инцидентов.
  • Операции оптимизируют стабильность и управляемость изменений.

    • Задача Delivery Manager — сделать эти оптимизации явными и переводить споры из режима “кто прав” в режим “какой компромисс выбираем и кто принимает решение”.

    !Карта ключевых функций и стыков, где обычно ломается поставка

    Основа управляемого взаимодействия: общие определения готовности и “стыки”

    Из темы про delivery-модель важны три определения, которые напрямую влияют на коммуникацию:

  • Definition of Ready: что должно быть уточнено, чтобы работа входила в разработку.
  • Definition of Done: что значит “сделано” для команды.
  • Release readiness: что значит “можно выпускать” для организации.

    • Если эти определения разные у разных функций, появляются типичные ситуации:

  • “Разработка закончила”, но QA не готова, потому что не согласован тест-план.
  • “Тесты прошли”, но релиз невозможен, потому что не закрыт security approval.
  • “Все готово”, но нет слота в релизном окне или не готова миграция.

    • Delivery Manager помогает договориться о стыках:

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

    • Роли и ответственность: как зафиксировать, чтобы не было “это не мы”

    Самый практичный инструмент — RACI-матрица:

  • R (Responsible): делает работу.
  • A (Accountable): принимает итог и несет ответственность за решение.
  • C (Consulted): дает экспертный вклад.
  • I (Informed): должен быть уведомлен.

    • Важно: RACI не должен быть “про все на свете”. Он особенно полезен на критичных процессах: релиз, инциденты, изменения объема, доступы и среды, security approvals.

    Пример RACI для релиза (упрощенно)

    | Активность | Product | Dev | QA | Security | DevOps/Platform | Operations | Delivery Manager | |---|---|---|---|---|---|---|---| | Решение “что в релизе” | A | C | C | C | C | C | R | | Подтверждение тестового статуса | I | C | A | C | I | I | R | | Подтверждение security approval | I | C | C | A | I | I | R | | Запуск деплоя/пайплайна | I | C | C | I | A | C | R | | Go/No-Go перед продом | A | C | C | C | C | C | R | | Коммуникация пользователям | A | I | I | I | I | R | R |

    Смысл: Delivery Manager не “назначает виноватых”, а делает путь решения ясным. Когда понятно, кто A, резко падает число конфликтов вида “мы думали, что это делает другая команда”.

    Ритм взаимодействий: какие встречи нужны, а какие создают шум

    Коммуникации должны поддерживать решения и поток, а не превращаться в “театр статусов”. Удобно строить ритм слоями.

    Ежедневный слой: управление потоком и блокировками

    Подходит формат короткой синхронизации по потоку:

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

    • Delivery Manager следит, чтобы обсуждали поток, а не пересказывали задачи.

    Еженедельный слой: зависимости, интеграции, релизная готовность

    Фокус:

  • Зависимости между командами.
  • Готовность сред и тестов.
  • Статус обязательных approvals.
  • Пересмотр прогноза (из темы про планирование): что изменилось и почему.

    • Слой “по событиям”: релиз, инцидент, критический риск

    Здесь важны заранее определенные форматы:

  • Go/No-Go встреча перед релизом.
  • Пост-релиз мониторинг и фиксация проблем.
  • Разбор инцидента и план корректирующих действий.

    • !Шаблон коммуникационного ритма, который поддерживает решения

    Единый источник правды: как сделать статус полезным

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

  • Один инструмент или пространство, где видны стадии, блокировки, владельцы и даты.
  • Одинаковые определения статусов для всех функций.
  • Явные “точки решений”: что нужно согласовать и к какому сроку.

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

  • Текущая стадия (например, анализ, разработка, тестирование, UAT, релизная подготовка, прод).
  • Блокировка: да/нет, причина, владелец снятия.
  • Ближайшая веха и дата.
  • Риски: коротко, с планом реакции.
  • Решения, ожидаемые от стейкхолдеров.

    • Управление зависимостями как ежедневная управленческая практика

    Зависимость — это внешний фактор, без которого задача не может перейти на следующую стадию. В enterprise и в многокомандной среде зависимости обычно важнее “скорости разработки”.

    Минимальный процесс работы с зависимостью

  • Идентифицировать зависимость как можно раньше.
  • Описать, что именно нужно (не “помогите”, а конкретный результат).
  • Назначить владельца со стороны поставки и владельца со стороны зависимой команды.
  • Зафиксировать дату, когда зависимость должна быть закрыта.
  • Договориться о сигнале риска: когда и как эскалируем.

    • Карта зависимостей

    Карта зависимостей — это не диаграмма “для красоты”, а инструмент управления очередями и рисками. Она помогает отвечать на вопрос из темы про сроки: что сегодня является самым ранним ограничением даты релиза?

    Фасилитация и конфликт-менеджмент: как принимать решения без разрушения отношений

    Delivery Manager часто выступает фасилитатором: помогает группе думать и договариваться, сохраняя фокус на цели.

    Типовые причины конфликтов

  • Разные цели и метрики (ценность vs стабильность).
  • Неясные роли (нет A в RACI).
  • Скрытые допущения (например, “тестовая среда всегда доступна”).
  • Разный язык (бизнес говорит “срочно”, инженеры говорят “высокий риск”).

    • Рабочий алгоритм фасилитации сложного решения

  • Сформулировать решение, которое нужно принять (одним предложением).
  • Ограничить варианты до 2–3 реальных опций.
  • Для каждой опции перечислить последствия по четырем измерениям из темы про планирование: объем, сроки, бюджет, качество/риски.
  • Назвать владельца решения (A) и срок принятия.
  • Зафиксировать решение и условия пересмотра.

    • Важно: компромиссы должны быть явными.

    “Перевод” между бизнесом и инженерией: как Delivery Manager снижает стоимость коммуникаций

    Delivery Manager часто действует как переводчик:

  • Бизнесу — объясняет ограничения через последствия (что переносим, какой риск принимаем, что нужно согласовать).
  • Инженерам — переводит “нужно срочно” в критерии (что именно нужно в релиз, какие проверки обязательны, какой критерий успеха).

    • Полезный формат “перевода” — краткий decision log:

  • Решение.
  • Причина.
  • Дата.
  • Кто принял.
  • Какие последствия и что мониторим.

    • Так снижается количество повторных споров и “переоткрытий” уже принятых договоренностей.

    Инженерные и организационные практики, которые усиливают кросс-функциональную поставку

    Delivery Manager не заменяет технических лидов, но может инициировать и поддержать практики, которые уменьшают риски на стыках:

  • Ранние интеграции и частые сборки, чтобы не копить “интеграционный ад”.
  • Уменьшение партий: небольшие изменения проще тестировать и выпускать.
  • Автоматизация проверок в CI/CD, чтобы quality gates были повторяемыми.
  • Совместное планирование тестирования и релизной стратегии.

    • Эти практики хорошо согласуются с DevOps-логикой и DORA-метриками, которые часто используют для оценки эффективности поставки: DORA.

    Также полезно помнить, что Scrum — это рамка для создания ценности, но сквозная поставка через много контуров требует дополнительной координации: The Scrum Guide.

    Анти-паттерны кросс-функционального взаимодействия

  • “Статус ради статуса”: много встреч, мало решений и владельцев.
  • “Перекидывание через стену”: функции работают последовательно без совместного планирования.
  • “Герои вместо системы”: все держится на одном человеке, знания не зафиксированы.
  • “Эскалация как единственный инструмент”: отсутствие рабочих правил приводит к постоянным конфликтам.
  • “Agile внутри, Waterfall между”: команды живут итерациями, но релизный контур остается очередью согласований.

    • Практический чек-лист: что настроить Delivery Manager, чтобы взаимодействие стало управляемым

  • Зафиксировать определения готовности: Definition of Ready, Definition of Done, Release readiness.
  • Собрать карту стейкхолдеров и договориться о ритме синхронизаций.
  • Ввести единый сквозной статус с блокировками, владельцами и датами.
  • Сделать RACI на релиз и на 1–2 критичных процесса (например, доступы/среды).
  • Вести зависимости как управляемые сущности: владельцы, сроки, эскалации.
  • Ввести decision log для ключевых компромиссов по объему, срокам, рискам.

    • Итоги

    Управление командой и кросс-функциональным взаимодействием для Delivery Manager — это про управление системой поставки через людей:

  • ясные роли и ответственность (RACI);
  • общие определения готовности (DoR/DoD/Release readiness);
  • ритм встреч, который производит решения;
  • прозрачное управление зависимостями и блокировками;
  • фасилитацию конфликтов через явные компромиссы по объему, срокам, бюджету и рискам.

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

    5. Качество, тестирование, релиз-менеджмент и DevOps-основы

    Качество, тестирование, релиз-менеджмент и DevOps-основы

    Delivery Manager отвечает за управляемую поставку от идеи до релиза: предсказуемость, прозрачные риски, управляемые зависимости и понятные ожидания. В прошлых темах мы построили основу:

  • роль и зона ответственности Delivery Manager
  • delivery-модель (SDLC, Agile, Lean) и выбор подхода
  • планирование, оценка, сроки и бюджет
  • кросс-функциональное взаимодействие (RACI, зависимости, ритм коммуникаций)

    • Теперь добавим слой, который превращает “сделали” в “можно безопасно выпустить и поддерживать”: качество, тестирование, релиз-менеджмент и DevOps-основы.

    Что такое качество в delivery и почему оно не равно тестированию

    Качество в поставке — это способность изменения:

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

    • Тестирование — лишь один из инструментов качества. Если качество “появляется” только на этапе тестов перед релизом, поставка почти всегда становится:

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

    • Для Delivery Manager качество — это не “проверить руками”, а построить систему, где:

  • критерии качества известны заранее
  • проверки встроены в поток
  • есть прозрачные quality gates
  • риски релиза управляемы и обсуждаемы

    • Критерии качества: от ожиданий к проверяемым условиям

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

    Базовые источники критериев

  • критерии приемки (acceptance criteria) для функциональности
  • нефункциональные требования: производительность, надежность, безопасность, совместимость
  • ограничения эксплуатации: мониторинг, алерты, процедуры отката, поддержка

    • Практика “качество по умолчанию”

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

  • что обязательно для “готово в команде” (Definition of Done)
  • что обязательно для “можно выпускать” (release readiness)

    • Эта логика напрямую продолжает определения готовности из темы про кросс-функциональное взаимодействие.

    Definition of Done и release readiness: ключевое различие

    Definition of Done обычно отвечает на вопрос: “готово ли изменение с точки зрения команды разработки?”.

    Release readiness отвечает на вопрос: “готова ли организация выпустить это изменение в продакшен безопасно?”.

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

    Пример: чем release readiness обычно шире DoD

  • релизные инструкции и runbook обновлены
  • мониторинг и алерты добавлены или проверены
  • безопасность: обязательные проверки пройдены
  • миграции данных готовы и проверены
  • есть план отката или безопасного roll-forward
  • поддержка и операции предупреждены, есть коммуникация

    • Delivery Manager помогает сделать эти условия явными и повторяемыми.

    Тестирование как система: уровни, виды, стратегия

    Тестирование в delivery-модели — это набор проверок, распределенных по стадиям SDLC и встроенных в CI/CD, а не “финальная фаза”.

    Уровни тестирования

  • модульное (unit): проверка логики на уровне функций/классов
  • интеграционное: проверка взаимодействия компонентов
  • контрактное: проверка совместимости сервисов по контракту API
  • end-to-end: проверка пользовательских сценариев через весь контур
  • приемочное (UAT): проверка бизнесом на соответствие ожиданиям

    • Виды проверок, которые часто влияют на сроки релиза

  • регресс (особенно если он ручной и большой)
  • тестирование производительности
  • тестирование безопасности
  • проверка миграций данных

    • Пирамида тестирования как принцип управления риском

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

  • больше быстрых автоматизированных проверок “ниже” (unit, часть интеграционных)
  • меньше тяжелых проверок “выше” (end-to-end)

    • Это не догма, а ориентир, который помогает не построить тестовую стратегию, где релиз “держится” на длинной ручной проверке.

    !Схема показывает, почему нельзя опираться только на E2E и почему выгодно инвестировать в unit и интеграционные тесты

    Shift-left и shift-right: как ускорять поставку, не теряя качество

    Shift-left

    Shift-left — сдвиг проверок ближе к началу:

  • требования уточняются через примеры и критерии приемки
  • архитектурные и security-риски выявляются до реализации
  • тесты (и автоматизация) создаются параллельно с разработкой

    • Эффект для Delivery Manager: меньше неожиданных блокировок “перед релизом”.

    Shift-right

    Shift-right — усиление контроля уже после выпуска:

  • наблюдаемость (логи, метрики, трассировки)
  • постепенные раскатки
  • быстрые откаты
  • feature flags

    • Эффект: релиз становится менее “одноразовым событием” и больше похож на управляемый процесс.

    Quality gates: как сделать контроль качества повторяемым

    Quality gate — заранее определенная обязательная проверка или условие, без выполнения которого работа не переходит дальше.

    Примеры quality gates (выбираются по контексту):

  • обязательный code review
  • прохождение набора автоматизированных тестов в CI
  • статический анализ и проверка зависимостей
  • security review для изменений определенного типа
  • обязательный performance smoke для высоконагруженных изменений

    • Delivery Manager важно удерживать баланс:

  • слишком мало gates — растет риск и аварийность
  • слишком много gates — поток превращается в очередь согласований

    • CI/CD в DevOps: что должен понимать Delivery Manager

    DevOps в контексте delivery — это практики, которые сокращают путь от изменения до пользователя, сохраняя надежность.

    CI/CD — ядро повторяемой поставки.

    CI (Continuous Integration)

    Смысл CI:

  • изменения интегрируются часто
  • сборка и базовые проверки запускаются автоматически
  • проблемы выявляются рано

    • CD (Continuous Delivery)

    Смысл CD:

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

    • !Сквозной пайплайн показывает, где встраиваются проверки и решения о релизе

    Что в CI/CD обычно “болит” и влияет на предсказуемость

  • нестабильные (flaky) тесты, из-за которых пайплайн “краснеет” случайно
  • долгие прогоны, из-за которых цикл обратной связи становится слишком длинным
  • ручные шаги без четких инструкций
  • зависимость от дефицитных сред и данных

    • Delivery Manager не обязан чинить пайплайн, но обязан сделать влияние этих проблем видимым: как риск сроков и качества.

    DORA-метрики как язык разговора о надежной скорости

    DORA-метрики помогают обсуждать delivery не через ощущения, а через измерения:

  • Deployment Frequency: как часто поставляем изменения
  • Lead Time for Changes: как быстро изменения доходят до продакшена
  • Change Failure Rate: как часто релиз приводит к деградации и требует исправлений
  • Time to Restore Service: как быстро восстанавливаем сервис после инцидента

    • Источник: DORA.

    Delivery Manager использует эти метрики как инструмент улучшения системы, а не как KPI для оценки людей.

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

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

    Две распространенные модели релизов

  • релиз “по готовности”: можно выпускать часто, если готовы и риск приемлем
  • релиз по календарю: релизные окна, release train, запреты на изменения (freeze)

    • Обе модели рабочие. Выбор зависит от контекста из delivery-модели: регуляторика, критичность, зрелость автоматизации, зависимость от внешних контуров.

    Минимальный релизный цикл

  • подготовка релиза: сбор изменений, проверка готовностей, релизные заметки
  • решение Go/No-Go: согласование риска и готовности
  • выполнение релиза: деплой, миграции, проверка smoke
  • пост-релиз: мониторинг, фиксация инцидентов, разбор проблем

    • Go/No-Go: что важно зафиксировать заранее

  • кто принимает решение (Accountable в терминах RACI)
  • какие критерии обязательны
  • какой риск допустим, а какой нет
  • что делаем при No-Go: перенос, урезание объема, отключение фичи, откат

    • Стратегии выкладки, которые снижают риск

    Delivery Manager полезно знать базовые стратегии, чтобы переводить “сделаем быстрее” в управляемые решения по риску.

  • blue-green deployment: переключение между двумя идентичными средами
  • canary release: постепенная выкладка на небольшую долю пользователей
  • feature flags: включение функциональности переключателем без повторного деплоя
  • progressive delivery: общий подход, где rollout управляется метриками и этапами

    • Важно: эти техники дают эффект только вместе с наблюдаемостью и дисциплиной отката.

    Версионирование и релизные заметки: как снизить стоимость изменений

    Семантическое версионирование

    Если продукт или API используются другими командами, полезно договориться о правилах версий. Часто применяют семантическое версионирование: Semantic Versioning.

    Ценность для delivery:

  • проще управлять ожиданиями интеграций
  • легче планировать совместимость и окна миграций

    • Release notes как инструмент управления ожиданиями

    Релизные заметки полезны не “для галочки”, а чтобы:

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

    • Безопасность в потоке: минимум, который должен быть встроен

    Безопасность часто становится узким местом не потому, что она “сложная”, а потому что ее подключают поздно.

    Базовые практики “security in delivery”:

  • классификация изменений по риску (что требует обязательного security review)
  • автоматизированные проверки зависимостей и уязвимостей
  • статический анализ кода (SAST) там, где это применимо
  • threat modeling для новых критичных потоков

    • Как ориентир для структуры требований безопасности можно использовать OWASP ASVS: OWASP ASVS.

    Delivery Manager помогает сделать security-проверки:

  • видимыми в плане и вехах
  • повторяемыми (по чек-листу и инструментам)
  • прогнозируемыми по срокам

    • Эксплуатационная готовность: качество после релиза

    Даже идеальные тесты не гарантируют отсутствие проблем. Поэтому релиз должен включать “готовность к эксплуатации”.

    Минимальные элементы эксплуатационной готовности:

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

    • Эта часть напрямую влияет на Time to Restore Service из DORA.

    Артефакты Delivery Manager для качества и релизов

    Ниже — набор артефактов, которые обычно реально помогают управлять поставкой. Их стоит держать максимально простыми.

  • стратегия тестирования: уровни тестов, ответственность, минимальные наборы проверок
  • релизный чек-лист: критерии release readiness
  • план релиза: даты/окна, состав, владельцы, коммуникации
  • план отката или безопасного roll-forward
  • decision log по компромиссам качества, объема и сроков
  • журнал инцидентов и пост-релизных проблем с действиями улучшения

    • Как Delivery Manager связывает качество, тестирование и релиз в одну систему

    Практический подход, который “склеивает” темы курса:

  • согласовать критерии готовности: DoR, DoD, release readiness
  • встроить проверки в delivery-модель как quality gates
  • сделать поток прозрачным: где стадия, где блокировка, кто владелец
  • согласовать релизный процесс и RACI на Go/No-Go
  • подключить DevOps-основы: повторяемые деплои, наблюдаемость, уменьшение партий
  • измерять систему: DORA + метрики потока (lead time, cycle time, доля блокировок)

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

    Типичные анти-паттерны

  • “тестирование в конце”: все проверки сдвинуты на последнюю неделю перед релизом
  • “ручной релиз как уникальное событие”: каждый релиз делается по памяти и героизму
  • “качество как ответственность QA”: команда не считает качество общей задачей
  • “approval без критериев”: согласования есть, но непонятно, что именно проверяют
  • “мы релизим редко, потому что страшно”: страх релиза заменяет работу с причинами риска

    • Практический чек-лист внедрения (минимум)

  • определить минимальный набор quality gates в CI
  • договориться о smoke-наборе проверок перед выкладкой
  • зафиксировать release readiness чек-лист и владельцев пунктов
  • внедрить шаблон Go/No-Go решения: критерии, риск, план действий при No-Go
  • договориться о стратегии выкладки для критичных изменений (canary или feature flags)
  • обеспечить пост-релизный мониторинг и процесс разбора проблем

    • Итоги

    Качество, тестирование, релиз-менеджмент и DevOps-основы — это фундамент предсказуемой поставки:

  • качество задается критериями и готовностями, а не только финальными тестами
  • тестирование — система уровней и видов проверок, встроенная в поток
  • релиз-менеджмент делает выпуск повторяемым: роли, критерии, Go/No-Go, коммуникации
  • DevOps и CI/CD сокращают lead time и снижают риск релизов через автоматизацию и наблюдаемость

    • Delivery Manager связывает это в единый контур: делает требования к качеству видимыми, встроенными в план и согласованными между функциями, чтобы релиз был не подвигом, а управляемой операцией.

    6. Риски, изменения, зависимости и управление ожиданиями стейкхолдеров

    Риски, изменения, зависимости и управление ожиданиями стейкхолдеров

    Delivery Manager отвечает за управляемую поставку от идеи до релиза. В предыдущих темах курса мы выстроили основу: роль Delivery Manager, delivery-модель (SDLC, Agile, Lean), планирование сроков и бюджета, а также кросс-функциональное взаимодействие (RACI, ритм коммуникаций, единый статус).

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

    Почему поставка “ломается” не в задачах, а в ожиданиях

    Большинство крупных срывов происходит не потому, что “плохо написали код”, а потому что:

  • Риск был известен, но не был проговорен и не имел плана реакции.
  • Зависимость “вдруг” не закрылась, хотя это можно было увидеть заранее.
  • Объем тихо вырос, а дата осталась прежней.
  • Стейкхолдеры слышали дату, но не слышали условия и сценарии.

    • Delivery Manager делает неопределенность видимой и управляемой: превращает ее в список тем, по которым можно принимать решения.

    Базовые понятия: риск, проблема, зависимость, изменение

    Риск

    Риск — это потенциальное событие, которое может повлиять на сроки, бюджет, объем или качество, но еще не произошло.

    Примеры:

  • “Проверка безопасности может занять до 2 недель из-за очереди”.
  • “Миграция данных может потребовать дополнительных прав и окна простоя”.

    • Проблема

    Проблема (issue) — это риск, который уже случился, или факт, который уже мешает поставке.

    Примеры:

  • “Security review не начат: нет назначенного ревьюера”.
  • “Тестовая среда недоступна до пятницы”.

    • Зависимость

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

    Примеры:

  • Доступы, среды, сертификаты.
  • Релиз внешней команды или изменение контракта API.
  • Решение архитектурного комитета.

    • Изменение

    Изменение — это корректировка согласованной поставки по одному или нескольким измерениям:

  • объем (что именно делаем)
  • сроки (когда будет)
  • бюджет (сколько стоит)
  • качество/риски (какие проверки обязательны, какие риски допустимы)

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

    RAID как минимальная система управления неопределенностью

    Практичный формат для Delivery Manager — вести единый список:

  • Risks: риски
  • Assumptions: допущения
  • Issues: проблемы
  • Dependencies: зависимости

    • RAID полезен не как “реестр ради реестра”, а как инструмент ежедневных решений:

  • что угрожает прогнозу
  • что нужно решить стейкхолдерам
  • что нужно эскалировать
  • где самый ранний ограничитель даты релиза

    • !Пример того, как RAID превращается в список действий и решений

    Оценка риска: как говорить о рисках без лишней математики

    Смысл оценки риска — не в точности, а в приоритизации.

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

    Иногда удобно использовать понятие экспозиции риска:

    Где:

  • — экспозиция риска, то есть “ожидаемая сила” влияния
  • — вероятность риска (например, 0.2, 0.5)
  • — величина влияния (например, +10 дней к сроку или +500k к бюджету)

    • Delivery Manager может не считать это “в цифру”, но обязан удерживать логику: высокая вероятность и высокий ущерб требуют реакции раньше, чем “редко и не страшно”.

    В качестве общей рамки управления рисками можно ориентироваться на стандарт ISO 31000.

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

    У риска должен быть план реакции. Типовые стратегии:

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

    • Практика, которая часто дает быстрый эффект: для каждого значимого риска фиксировать:

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

    • Управление зависимостями: сделать “ожидание” управляемой сущностью

    Зависимости особенно опасны тем, что выглядят как “не наша зона”, но именно они сдвигают сроки.

    Минимальный стандарт управления зависимостью

    Чтобы зависимость перестала быть разговором “они не сделали”, ей нужны атрибуты:

  • конкретный ожидаемый результат
  • владелец со стороны вашей поставки
  • владелец со стороны зависимой команды
  • дата, к которой результат нужен
  • сценарий, если зависимость не выполнена
  • правило эскалации

    • Карта зависимостей: зачем она нужна Delivery Manager

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

    Типовые эффекты карты зависимостей:

  • видно, какие зависимости критичны именно для ближайшего релиза
  • проще синхронизировать несколько команд
  • снижается вероятность “интеграционного сюрприза”

    • Управление изменениями: как сохранять контроль, не превращая процесс в бюрократию

    Изменения в delivery неизбежны по причинам:

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

    • Задача Delivery Manager — обеспечить управляемое изменение.

    Главный принцип: изменение должно быть “оплачено”

    Если что-то добавилось, это должно отразиться хотя бы в одном измерении:

  • сдвигаем дату
  • увеличиваем бюджет/мощность
  • уменьшаем объем в релизе
  • осознанно принимаем больший риск (например, переносим часть проверок, но это требует явного решения)

    • Эта логика продолжает тему “невозможно фиксировать все сразу” из статьи про сроки и бюджет.

    Практичный change control для продуктовой и проектной среды

    Вместо тяжелых комитетов можно использовать легкую дисциплину:

  • Любое изменение формулируется как выбор: что меняется из объема/сроков/бюджета/рисков.
  • Есть владелец решения: кто имеет право сказать “да”.
  • Есть пороги эскалации: при каком масштабе изменения нужна встреча уровня спонсора.
  • Есть журнал решений (decision log), чтобы не спорить повторно.

    • Если организация живет в ITSM-контуре, полезно понимать связь с управлением изменениями в эксплуатации. В ITIL это описывается как Change Enablement: ITIL 4.

    Управление ожиданиями стейкхолдеров: дата без условий — источник конфликтов

    Стейкхолдеры обычно хотят ясности:

  • когда будет
  • что именно будет
  • что может пойти не так
  • что от них требуется

    • Delivery Manager обеспечивает ясность через формат ожиданий, а не через “успокоительные статусы”.

    Практика сценариев: как говорить о сроках честно

    Вместо одной даты полезнее давать 2–3 сценария:

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

    • И обязательно:

  • какие триггеры переводят нас в другой сценарий
  • какое решение потребуется от стейкхолдеров, если сценарий ухудшится

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

    “Единый источник правды” и короткий статус

    Хороший статус отвечает на вопросы, а не пересказывает работу.

    Минимальный формат статуса поставки:

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

    • Чтобы этот статус работал, должны быть согласованы определения готовности (DoR/DoD/release readiness) из предыдущей темы про взаимодействие.

    Язык последствий: лучший способ снизить конфликтность

    Когда возникает спор, Delivery Manager возвращает обсуждение к последствиям по четырем измерениям:

  • объем
  • сроки
  • бюджет
  • качество/риски

    • Формула коммуникации, которая снижает напряжение:

  • “Если мы добавляем X, то при текущей мощности это означает Y по срокам”
  • “Если дату не двигаем, нужно выбрать: убрать A или принять риск B”

    • Это делает компромисс явным и помогает владельцу решения принять его осознанно.

    Эскалации: когда и как поднимать проблему “вверх”, не разрушая отношения

    Эскалация — это не “жалоба”, а управленческий инструмент, когда:

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

    • Признаки правильной эскалации

  • заранее определены пороги эскалации (например, “сдвиг даты более чем на 2 недели”)
  • есть четкая формулировка решения, которое нужно принять
  • предоставлены 2–3 варианта с последствиями
  • есть дедлайн на решение

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

    Связь с качеством и релизами: риск-ориентированная готовность

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

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

    • Иначе получится классический анти-паттерн: “все почти готово, но релиз стоит”.

    Типичные анти-паттерны

  • “Риски есть, но они без владельцев и без действий”.
  • “Зависимости вспоминают перед релизом”.
  • “Объем растет незаметно, дата остается прежней”.
  • “Статус информирует, но не приводит к решениям”.
  • “Эскалации происходят в последний момент, когда вариантов уже нет”.

    • Минимальный набор артефактов Delivery Manager

    Артефакты должны помогать принимать решения и снижать неопределенность:

  • RAID-лог
  • карта зависимостей
  • decision log
  • релизный план с вехами и quality gates
  • короткий статус поставки с блокировками и запросами решений

    • Итоги

    Риски, изменения, зависимости и ожидания стейкхолдеров — это одна система.

  • Риски дают раннее предупреждение и управляемые сценарии.
  • Зависимости делают видимыми “очереди” и внешние ограничения.
  • Управление изменениями удерживает контроль над объемом, сроками, бюджетом и качеством.
  • Управление ожиданиями превращает прогноз в совместные решения, а не в конфликт “вы обещали”.

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

    7. Метрики delivery, улучшения процесса и зрелость организации

    Метрики delivery, улучшения процесса и зрелость организации

    Delivery Manager отвечает за управляемую поставку от идеи до релиза. В предыдущих темах курса мы разобрали:

  • роль и ответственность Delivery Manager
  • delivery-модель (SDLC, Agile, Lean) и правила потока
  • планирование, оценку, сроки и бюджет
  • кросс-функциональное взаимодействие (RACI, зависимости, единый статус)
  • качество, тестирование, релизы и DevOps-основы
  • риски, изменения, зависимости и управление ожиданиями

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

    Ключевая мысль: метрики не заменяют управление, но делают управление честным. Они помогают ответить на вопросы:

  • Насколько предсказуемо мы поставляем?
  • Где реально теряется время?
  • Что улучшать в первую очередь?
  • Мы ускоряемся без роста аварийности?

    • Зачем Delivery Manager метрики

    Метрики в delivery нужны не для отчетности, а для решений:

  • подтвердить или опровергнуть ощущение "мы стали медленнее"
  • определить узкое место в потоке (ожидание среды, согласование безопасности, ручной регресс)
  • прогнозировать сроки на фактах (поддерживает тему планирования)
  • управлять рисками через ранние сигналы (поддерживает тему RAID)
  • балансировать скорость и надежность релизов (поддерживает тему качества и DORA)

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

    Принципы хороших метрик в delivery

    Метрики измеряют систему, а не людей

    Delivery — это поток через функции и контуры. Если метрики используются как KPI отдельных людей, чаще всего происходит:

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

    • Поэтому Delivery Manager держит фокус на сквозных метриках.

    Сначала определения, потом сбор

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

  • что считается "стартом" работы
  • что считается "готово"
  • что считается "релизом"

    • Это напрямую связано с договоренностями DoR, DoD и release readiness из предыдущих тем.

    Меньше метрик, но регулярнее ритм

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

    Основные классы метрик: что именно измеряем

    Практично разделять метрики на четыре группы.

    Метрики результата

    Они отвечают на вопрос: мы доставили ценность и эффект?

    Примеры:

  • конверсия, выручка, retention
  • снижение времени операции в бизнес-процессе
  • снижение числа обращений в поддержку по конкретной причине

    • Delivery Manager обычно не владеет этими метриками, но должен понимать, какая поставка имеет смысл, чтобы правильно расставлять приоритеты по улучшениям.

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

    Они отвечают на вопрос: как быстро и предсказуемо работа проходит путь до релиза?

    Ключевые:

  • lead time
  • cycle time
  • throughput
  • WIP
  • доля заблокированных задач и причины блокировок

    • Метрики надежности и качества

    Они отвечают на вопрос: не ускоряемся ли мы ценой аварийности?

    Здесь особенно полезны DORA-метрики (см. ниже) и операционные показатели:

  • инциденты после релиза
  • дефекты, найденные на поздних стадиях
  • время восстановления

    • Метрики здоровья процесса

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

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

    • Метрики потока: определения и практический смысл

    Lead time и cycle time

    Два термина, которые часто путают.

  • Lead time: время от запроса (или попадания в бэклог/очередь) до готовности в продакшене.
  • Cycle time: время, пока работа фактически находится в активной обработке (например, от "In Progress" до "Done" в команде или до "Ready for Release").

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

  • Lead time показывает, что видит бизнес: "почему так долго?"
  • Cycle time показывает, как работает команда и контур выполнения

    • Если lead time большой, а cycle time маленький, значит основная потеря — ожидание: очереди, среды, согласования, блокировки.

    Throughput

    Throughput — сколько элементов работы завершается за период (неделя, спринт, месяц).

    Практический смысл:

  • помогает прогнозировать объем поставки
  • помогает увидеть реальную пропускную способность системы

    • Важно: throughput корректно сравнивать только для сопоставимых единиц работы (например, одинаковый тип задач или одинаковый уровень декомпозиции).

    WIP и эффект многозадачности

    WIP (Work In Progress) — сколько элементов одновременно находится "в работе".

    Управленческая логика проста:

  • высокий WIP почти всегда увеличивает время прохождения из-за переключений контекста
  • снижение WIP часто повышает предсказуемость и ускоряет завершение

    • Это напрямую поддерживает Lean-подход из темы про delivery-модель и практики Kanban.

    Flow efficiency

    Flow efficiency помогает увидеть долю ожиданий в общем времени.

    Где:

  • — время, когда над задачей реально работали (разработка, тестирование, настройка)
  • — полное время от старта отсчета до готовности

    • Если flow efficiency низкая, это сигнал, что улучшения нужно искать не в "работайте быстрее", а в очередях и стыках: доступы, среды, approvals, интеграции.

    !Визуализация разницы между временем активной работы и временем ожидания в сквозном lead time

    DORA-метрики: язык разговора о скорости и надежности

    DORA-метрики стали стандартным набором для обсуждения delivery в DevOps-контексте:

  • Deployment Frequency
  • Lead Time for Changes
  • Change Failure Rate
  • Time to Restore Service

    • Источник и описание подхода: DORA. Также полезный первоисточник по исследованиям: Accelerate (Forsgren, Humble, Kim).

    Как интерпретировать DORA без ловушек

  • Deployment Frequency без контекста не означает зрелость
  • Снижение Lead Time for Changes ценой роста Change Failure Rate — это деградация, а не успех
  • Улучшение Time to Restore Service часто связано с наблюдаемостью, runbook и готовностью эксплуатации (из темы про релизы)
  • DORA-метрики полезны как баланс: скорость вместе с надежностью

    • Частые проблемы внедрения DORA

  • "мы считаем деплоем только большой релиз" и теряем смысл частоты
  • "lead time" считают от разных точек в разных командах
  • аварии после релиза не связывают с релизами, и Change Failure Rate занижен

    • Задача Delivery Manager — согласовать определения и обеспечить честность данных.

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

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

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

    • Типовые источники данных

  • трекер задач (Jira, YouTrack и аналоги): статусы, даты переходов
  • CI/CD: факты деплоев, время пайплайна
  • мониторинг и инцидент-менеджмент: время восстановления, частота деградаций
  • ITSM (если есть): изменения в продакшене и approvals

    • Delivery Managerу важно помнить: если система статусов в трекере не отражает реальный поток, метрики потока будут ложными. В таком случае сначала лечится процесс и определения, а не дашборд.

    Дашборд Delivery Manager: минимальный набор

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

    | Группа | Метрика | Зачем | Типичный управленческий вопрос | |---|---|---|---| | Поток | Lead time (перцентили) | Предсказуемость | "Когда будет готово с вероятностью 80%?" | | Поток | Cycle time | Эффективность исполнения | "Что мешает задачам быстро завершаться?" | | Поток | WIP | Контроль многозадачности | "Мы не раздули параллельную работу?" | | Надежность | Change Failure Rate | Баланс скорости и качества | "Релизы стали безопаснее или опаснее?" | | Восстановление | Time to Restore Service | Готовность к инцидентам | "Мы умеем быстро откатиться и восстановиться?" |

    Почему в таблице именно перцентили по lead time: среднее часто обманывает из-за редких, но очень долгих задач. В delivery полезнее смотреть, например, 50-й и 85-й перцентили: "в половине случаев" и "в большинстве случаев".

    Метрики как механизм улучшений: от наблюдения к экспериментам

    Если метрики просто публикуются, улучшений не будет. Нужен цикл.

    Ритм улучшений

    Один из рабочих вариантов для delivery-контура:

  • Еженедельно: обзор потока и блокировок, корректировка ближайшего плана и рисков
  • Раз в 2 недели или раз в спринт: разбор причин задержек и выбор 1–2 улучшений
  • Раз в месяц или квартал: обзор трендов (DORA, lead time) и инвестиции в системные улучшения (автоматизация, среды, архитектура)

    • Как выбирать улучшения по данным

    Практический подход:

  • Выбрать метрику-симптом (например, рост lead time)
  • Разложить ее на причины (например, ожидание безопасности, очередь на UAT, нестабильный регресс)
  • Выбрать улучшение с максимальным эффектом на узкое место
  • Сформулировать эксперимент и критерий успеха

    • Это соответствует Lean-логике: улучшать поток, убирая потери, а не добавляя "ускоряющие" активности.

    Пример формулировки эксперимента

  • Проблема: 85-й перцентиль lead time вырос из-за очереди на регресс
  • Гипотеза: автоматизация smoke и критичных регресс-сценариев снизит задержки
  • Действие: добавить обязательный smoke в CI и сократить ручной регресс до приемочного набора
  • Критерий: снижение 85-го перцентиля lead time на 20% за 6 недель без роста Change Failure Rate

    • Value Stream Mapping: где реально теряется время

    Когда организация спорит, "что тормозит", полезно построить карту потока ценности.

    Value Stream Mapping в IT — это визуализация стадий от запроса до продакшена с указанием:

  • времени выполнения
  • времени ожидания
  • точек согласований и очередей
  • ответственных ролей

    • !Пример Value Stream Map, показывающий, что основная задержка часто находится в ожидании на стыках

    Для Delivery Manager ценность VSM в том, что обсуждение становится предметным: видно, что ускорение разработки на 10% не поможет, если 60% времени уходит на ожидание среды или approvals.

    Зрелость delivery в организации: как оценивать и куда расти

    Зрелость — это не "у нас Agile" и не "у нас есть CI/CD". Это способность организации:

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

    • Ниже — практичная модель уровней зрелости, которую удобно использовать как диагностическую рамку.

    Уровень "стихийный"

    Признаки:

  • сроки держатся на героизме
  • релизы редкие и рискованные
  • метрик нет или они несопоставимы
  • блокировки и зависимости всплывают поздно

    • Что обычно дает быстрый эффект:

  • базовые определения DoR, DoD, release readiness
  • минимальный релизный чек-лист и RACI на Go/No-Go
  • единый статус по стадиям и блокировкам

    • Уровень "управляемый"

    Признаки:

  • есть релизный процесс и понятные роли
  • ведутся риски и зависимости (RAID)
  • есть несколько метрик потока и регулярный обзор
  • прогноз обновляется при изменениях

    • Куда расти:

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

    • Уровень "измеряемый"

    Признаки:

  • измерения привязаны к действиям и улучшениям
  • DORA и метрики потока используются совместно
  • есть регулярный improvement backlog
  • узкие места выявляются по данным, а не по конфликтам

    • Куда расти:

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

    • Уровень "оптимизируемый"

    Признаки:

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

    • Важно: зрелость может быть разной в разных контурах. Delivery Manager часто начинает с самого критичного потока или продукта.

    Роль Delivery Manager в росте зрелости

    Delivery Manager ускоряет зрелость не лозунгами, а управленческими механизмами:

  • согласует определения и границы (DoR, DoD, release readiness)
  • строит и поддерживает метрики потока и надежности
  • запускает ритм обзоров: метрики, RAID, решения
  • делает узкие места видимыми и приводит их к владельцам
  • превращает улучшения в план с приоритетами и эффектом

    • Это продолжает логику курса: delivery — это система, и ею нужно управлять как системой.

    Анти-паттерны: как метрики ломают delivery

  • "Метрики как KPI людей": стимулирует игру и скрывание проблем
  • "Слишком много метрик": теряется фокус, ритм улучшений умирает
  • "Сравнение несравнимого": разные типы задач и потоков в одной статистике
  • "Оптимизация одной метрики": ускорение релизов ценой роста аварийности
  • "Дашборд без действий": числа есть, изменений нет

    • Практический чек-лист: с чего начать измерения и улучшения

  • Выберите 1 поток поставки и зафиксируйте стадии
  • Определите start и end для lead time и cycle time
  • Запустите сбор WIP, throughput, доли блокировок
  • Добавьте 1–2 надежностные метрики (например, Change Failure Rate и Time to Restore Service)
  • Введите регулярный обзор: метрики -> причины -> 1–2 улучшения -> проверка эффекта

    • В качестве опоры по flow-подходу и управлению WIP полезно сверяться с базовыми принципами Kanban: Kanban Guides.

    Итоги

    Метрики delivery, улучшения процесса и зрелость организации — это единый контур управления:

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

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