Всем привет, меня зовут Алина, я работала в роли Delivery Manager и прожила её изнутри, поэтому хорошо понимаю, почему в большинстве компаний роль есть, а эффекта от роли нет. Сейчас объясню.

Для меня Delivery Manager (DM) отвечает не за отдельную задачу или проект, а за устойчивость delivery в целом: условно, за конвейер, через который любой проект или фича проходят предсказуемо. В первую очередь это роль, которая работает на уровне системы:

• видит зависимости между командами и в команде,

• понимает технические ограничения,

• управляет рисками и загрузкой команд,

• влияет на решения, которые сказываются на сроке и качестве.

DM не пишет код, но влияет на условия, в которых работает вся система разработки. 

Но это в теории. А в реальности чаще всего есть некая «бумага», на которой прописано, что существует роль, отвечающая за delivery. При этом зона ответственности размыта, особенно там, где есть пересечение ролей Team Lead, SM, PO,PM, метрик нет, а влияние на результат ограничено.

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

Где ломается система

Мы видим явление, но причин приводящих к этой дисфункции несколько.

№1. Смещение ролей и зон ответственности

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

• Product Manager отвечает за то, что мы строим и зачем.

• Project Manager — за план, сроки, бюджет проекта. 

• Tech Lead — за технические решения. 

• Team Lead — за людей и их работу.

• Scrum Master — за процесс.

А Delivery Manager отвечает за то, чтобы стройка в целом не остановилась.

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

И задаёт вопрос: «Что может остановить стройку и как этого не допустить?»

На этом уровне всё выглядит логично, но в реальности всё иначе. Для того, чтобы увидеть, что есть смещение ролей и зон ответственности достаточно открыть hh и посмотреть тройку вакансий DM:

Основной вывод после анализа такой: «В разных компаниях роль трактуется по разному».

• где-то это Project Manager,

• где-то это Scrum Master,

• где-то это Product Owner, 

• где‑то это Tech Lead DEV/QA/SA/Team Lead,

• а где‑то человек, который «тушит пожары» и закрывает чужую неэффективность (на этот счёт очень откликается пост в канале тг #безвотэтоговотвсего «Тимлид как громоотвод для чужой неэффективности»)

Пока писала, в памяти всплыло одно из самых запоминающихся собеседований в моей жизни. Одна компания как‑то вышла на меня с запросом на прозрачность delivery и выравнивание процессов между командами. В ходе интервью мне несколько раз подчеркнули, что у них есть горизонтальные, вертикальные и еще какие‑то, уже не вспомнить, Team lead, и все они «умеют делать процессы». Я все никак не могла переварить в своей голове один вопрос: «Тогда зачем вам Я?»

Со временем я ответила себе на этот вопрос. Иногда DM — это не про рост зрелости компании, а про «организационный пластырь». 

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

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

№2. Размытая зона ответственности

Delivery Manager несёт ответственность за все. Но по сути управляет ничем: 

• сроки зависят от Команд,

• приоритеты от PO или Заказчика,

• ресурсами ограниченные и во владении у ITBP/IT Lead,

• техдолгом управляет Tech Lead/Team Lead/ITBP/IT Lead,

• за изменения в этапах SLDC (Software Development Life Cycle) ответственны Tech Lead/Team Lead.

В итоги ответственность есть, а инструментов влияния нет.

№3. Отсутствие метрик

Пока нет метрик — есть только ощущения, абсолютно невозможно управлять тем, что не измеряется.

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

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

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

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

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

• сроки предсказуемы,

• зависимости прозрачны,

• ритм стабильный,

• поток поставки ценности прозрачен.

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

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

Почему Agile не решает проблему?

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

Так появляются церемонии, борды, роли и ритуалы.

Но по какой‑то причине delivery остается таким же непредсказуемым. И возникает закономерный вопрос: «Почему Agile не работает?»

Хочу отметить, что Agile не лечит организационные противоречия. Он лишь делает их более заметными:

• ответственность размыта;

• нет владельца потока или же он есть, но только с ответственностью, без управления;

• процессы внедрены, но модель принятия решений не изменилась;

• управление остаётся реактивным;

• и т.д. и т.п.

Приведу пример. Однажды в одном из бизнес-юнитов внедрили Scrum: у команд появились все события и артефакты Scrum и все решили что процессы стали формально правильными. Но один ключевой момент не изменился — все важные решения остались вне зоне влияния команды:

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

• перераспределение ресурсов было невозможно,

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

При этом у команды была ответственность за delivery, но не было никакого влияния на решения, от которых delivery и зависит.

И здесь, как мне кажется, находится главная проблема. Agile не может помочь там, где у команды есть ответственность, но нет влияния на решения. Даже идеально выстроенные Scrum-процессы не сделает delivery предсказуемым, если ключевые решения остаются вне команды.

Процессы меняются, а модель управления delivery — нет.

Давайте рассмотрим, как системные ошибки начинают проявляться в работе delivery 

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

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

Кейс №1. Когда поток ценности блокирует прошлое

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

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

В результате:

• релизы зависели от старых договоренностей, которые были зафиксированы у кого‑то 2 года назад в почте;

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

• delivery был непредсказуемым, такие «выпадания из шкафа» были обычным делом.

Вместо того чтобы «пробить доступ» и идти дальше, как в принципе делается повсеместно, мы:

• договорились о временном компромиссе для текущего релиза (сроки не пострадали);

• зафиксировали проблему как системную;

• инициировали миграцию;

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

• собрали реестр тех долгов и закрыли успешно все легаси долги платформы за 3 квартала (их было не мало).

В итоге была устранена причина, а не симптом.

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

Кейс № 2  Когда перегруз это иллюзия

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

На первый взгляд — классический конфликт приоритетов.

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

• синхронизировали принципы оценки,

• сделали загрузку прозрачной,

• добились сопоставимости данных с помощью инструментов между командами.

Без этого любые попытки перераспределения задач приводили бы к конфликтам и потере доверия. Это был необходимый пререквизит.

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

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

Не обошлось, конечно, без сопротивлений — подход выходил за рамки локальной ответственности команд. Но именно это позволило:

• снизить перегруз в одной команде по соотношению к другой,

• повысить реалистичность планирования,

• сделать delivery более предсказуемым.

Что меняется, когда появляется система?

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

В нашем случае это привело к формированию доверия между командами развития, DevOps, SRE и бизнесом. Команды начали работать как единая система, а не как набор отдельных участников.

Доверие — это не «атмосфера», а следствие управляемой системы delivery.

А что делать?

Оба кейса выглядят по-разному: в одном системная проблема с тех долгами, а в другом в планировании.

Но в обоих одна причина: отсутствие управления delivery на уровне системы.

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

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

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

• Загрузку и capacity: когда видно не только «команда перегружена», а где именно возникает дисбаланс, и есть возможность перераспределять поток.

• Прозрачность delivery: когда появляется общая картина: где bottleneck, где риски, где неопределенность, а не только статус «в работе».

• Системные ограничения: когда можно поднимать вопросы архитектурных зависимостей, legacy, инфраструктурных ограничений, Tech Debt, SLDC, применение инженерных практик и не оставлять их вне зоны управления.

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

• Принятие решений: когда DM участвует не только в координации, но и влияет на приоритеты, на создания последовательностей/упорядочения действий, trade‑offs и управление рисками.

То есть когда DM получает возможность управлять есть всей системой delivery. В этот момент роль перестаёт быть декоративной «координатор с ответственностью».

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

И тогда первый вопрос, который стоит задать себе:

«На что я реально влияю внутри этой системы?»

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

Если статья откликнулась — в следующих частях можно разобрать:

• почему DM нельзя оценивать как технического специалиста,

• как оценивать DM: модель компетенции,

• уровни зрелости DM и их эффект на бизнес. 

Подписывайтесь на Телеграм-канал Alfa Digital — там рассказываем о работе в IT, делимся новостями, анонсами митапов и квартирников, рассказываем о технологиях, делимся советами наших экспертов, вакансиями и стажировками, иногда шутим.

Читайте также:

• Как я (внезапно) стал адвокатом вайб‑кодинга в корпорации

• AI делает видео за вас? Я попробовал — и расскажу, где нас обманывают

• История вайб‑кодера: «Я был скептиком, но до 4 утра спорил с GLM-5»