Всем успешной доставки! Наверное многим все еще не понятно кто такой Delivery Manager? Я этот канал завел только потому, что устал отвечать чем же я занимаюсь 😎 Давайте попробую еще раз раскрыть, что из себя представляет Delivery Manager (конечно только по моему мнению)
Если мы откроем hh и возьмем случайную вакансию которая будет называться Delivery Manager, мы увидим, что в каждой компании свои требования, вот вам пару примеров:
Вакансия 1 Требования: -планирование ресурсов совместно с PO и СТО для достижения целей в установленные сроки -поиск и устранение «узких мест» потока через анализ метрик (Cycle Time, Lead Time, Throughput и Flow Efficiency) -упрощение рабочих процессов: удаление лишних процедур и препятствий, которые замедляют команду -управление разногласиями по объёму работ и срокам: сведение позиций бизнеса и разработки к рабочему компромиссу, фиксация состава релиза и критериев готовности, управление изменения через формальный процесс согласований -организация управления инцидентами: настройка процесса реагирования (on-call/роли, runbooks, SLA/эскалации), проведение разборов (postmortem) с командой, формирование плана улучшений и контроль выполнения корректирующих действий. -управление поставкой: согласование релизного плана с PO и командой разработки, релизный календарь и синхронизация всех участников, организация поэтапной раскатки, подтверждение готовности к релизу.
Вакансия 2 Обязанности: -Полноценное управление жизненным циклом разработки: руководство кросс-функциональной командой (аналитики, разработчики, тестировщики); -Организация процесса доставки: полная ответственность за планирование, координацию и успешный выпуск релизов. -Внедрение и отладка процессов: активное внедрение и адаптация лучших практик Agile/Scrum, SAFe в команде. Регулярная отчетность о статусе разработки, прогрессе задач, пропускной способности команды и соблюдении сроков.
Вакансия 3 Задачи -Управлять портфелем изменений: приоритизация, масштабирование инициатив, перераспределение ресурсов между RUN и CHANGE -Вести программу экономии на SMS: тарифные стратегии с операторами, маршрутизация, каскады каналов, контроль стоимости доставки без потери качества -Оптимизировать бюджетирование и контроль затрат БЮ: драйверная модель, план–факт, меры экономии -Обеспечивать формирование стратегии бизнес-юнита: миссия и видение, дорожная карта и приоритеты -Выстроить активные коммуникации с другими бизнес-юнитами: SLA межблочных взаимодействий, регулярные синхронизации, единый журнал кросс-решений -Курировать взаимодействие с операторами сотовой связи и участвовать в переговорах: условия, бонусы/штрафы, альтернативные маршруты, SLA-ревью Вести метрики и отчётность: SLA, TTR, выполнение спринтов, NPS/CSAT партнёров, экономический эффект, вклад в EBITDA
И таких разных вакансий большое количество, есть совсем абсурдные требования. Иногда кажется, что вакансию называют Delivery Manager ради какого-то хайпа или моды, а обязанности остаются руководителя проекта или project managerа.
В моем понимании Delivery Manager - это data-driven менеджер изменений, который отвечает за сквозной процесс (т.е. за весь E2E) доставки итогового продукта до пользователя: сокращает время от идеи до выхода продукта на рынок и увеличивает прогнозируемость. Если нет запроса на сквозной процесс - отвечает за всю доступную цепочку. Если кратко то Delivery Manager это Produсt owner E2E процесса, для него продукт это процесс доставки ценности.
Зачем нужен: -Пересобирать и улучшать процессы растущего или изменяющегося бизнеса, чтобы компании не теряли гибкость и эффективность при масштабировании -Накапливать и делиться практиками и опытом с организацией, командами, сотрудниками, комьюнит -Ускорять поставку продуктов на рынок в условиях растущей сложности ИТ систем, процессов и самих продуктови Подробно все давно указано здесь
Надеюсь стало более понятней, если нет, то задавайте вопросы в комментариях.
· 23.02
Коллега, в целом согласна с мыслью про E2E и системность - это точно не просто «апгрейднутый PM» Но в финтехе я бы добавила важный нюанс: Delivery не может быть только data-driven управленцем процесса. В enterprise-среде E2E почти всегда проходит через CI/CD, инфраструктуру, сложные интеграцирешения на коленке, технически ограничения и регуляторику. Если Delivery не понимает техническую архитектуру поставки - он становится зависимым от чужих интерпретаций и управляет отчетами, а не системой. Речь не о том, чтобы самому настраивать пайплайны. Речь о том, чтобы понимать, где узкое место - в процессе или в архитектуре, и разговаривать с DevOps и архитекторами на одном языке, предлагать какие-то решения из видения улучшения и делегировать это Девопсам. Поэтому в финтехе, на мой взгляд, технический бэкграунд для Delivery - не опция, а необходимость. Иначе это превращается в апгрейднутого Проджекта и не более. Delivery должен быть больше из серии Technical Program Manager. Но не Проджект.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 14.03
Вот здесь Вы с языка сняли начало: из описания в современных реалиях, когда поставка идет через CI/CD, этот человек называется DevOps в широком смысле.
Есть 2 подхода к пониманию девопса - это либо инженер, либо настройщик процесса. Это зависит от того, что хотим получить и наличия материала под рукой.
В первом случае под капотом у этой роли не только сам пайплайн, но и договоренности. А в этом случае роли Delivery Manager-a рядом в описанном виде существовать не может.
Во втором мы смотрим на DevOps как инженера - и тогда да, нужны рядом отдельные специалисты, которые в часть выстраивания процессов идут.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён