[Перевод] Delivery Manager — новая роль в мире Agile

Всем добрый день!

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Поехали.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть «семьи» Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком «Разработчик». Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

plgebuhq5qgwlll314p2xfykusu.png

Зачем нужен Delivery Manager

Марти Каган (Marty Cagan) заметил тенденцию в США от Менеджера Проекта (Project Manager, кратко — PM) к Delivery Manager. Марти нравится этот тренд и новая роль по трем причинам:

  • «бренд» проектного менеджера настолько поврежден, что может потребоваться ребрендинг».
  • «есть вопрос о цели — завершить продукт. Задача не в исследовании, не в обучении процессам; цель исключительно в выпуске.»
  • Delivery Manager несет ответственность за сортировку и приоритезацию проблем продукта, тем самым освобождая Владельца Продукта.


Пользователи Scrum конечно согласны, что роль менеджера проекта настолько запятнана, что требует ребрендинга. Именно поэтому, по мнению Майка Кона (Mike Cohn) — одного из светил Scrum, появилась роль скрам-мастера. Однако, я думаю, что и роль скрам-мастера уже запятнана. Поэтому скрам-мастеров я не нанимаю.

Тем не менее, я назвал Рича Delivery Manager, не потому что мне не нравится термин «менеджер проектов». Я не вижу особого конфликта между проектными менеджерами и Agile в целом/Agile-ролями. Также я не вижу особого смысла в ребрендинге менеджеров проектов. Я просто хочу показать людям в чем смысл Delivery Manager.

Чем занимается Delivery Manager

Если загуглить «Delivery Manager», не стоит надеяться на много результатов. (На момент написания этой статьи в 2015 году.) Одним из первых будет материал британского Government Digital Service (GDS). В нем много интересного. Например, Марк Стэнли (Mark Stanley) описывает День из жизни Delivery Manager в GDS. Он пишет:

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

В GDS также есть описание роли Delivery Manager. Основные обязанности в этой роли следующие:

  • Выпускать проекты и продукты, использовать подходящую agile-методологию, постоянно учиться и улучшать процессы.
  • Совместно с менеджером продукта разрабатывать дорожную карту и переводить ее в пользовательские истории.
  • Руководить коллективным, динамическим процессом планирования — основной акцент стоит на работе, которую необходимо выполнить, в условиях ограничения мощностей и возможностей команды.
  • Матричное управление мультидисциплинарной командой.
  • Убедиться в качестве продукта на всех стадиях (альфа/бета/продакшн).
  • Активно участвовать в сообществе Delivery Manager, делиться и находить области применения для навыков и знаний, внедрять передовые практики.


С GDS ролью все в порядке, и, на мой взгляд, она гораздо полезней роли скрам-мастера.

Programme Manager и Delivery Manager

У меня была определенная потребность, когда я пригласил Рича на роль Delivery Manager. Суть в следующем:

  • У меня было три команды разработки, которые работали в одной большой комнате — всего около 35 человек.
  • Мне был нужен один процесс и одна Kanban доска для всей команды.
  • Я присутствовал только четыре дня в неделю, один из них удаленно.


Фактически, Рич управлял Kanban-доской и всеми связанными процессами. Он установил прочные тактические связи с владельцем продукта, убедился, что карточки были созданы и синхронизированы с электронной системой тикетов. Он собирал метрики, рисовал Накопительную Диаграмму Потока, организовывал ретроспективы. Плюс, он присутствовал на работе каждый день, чтобы команда не теряла импульс в мое отсутствие.

Мои отношения с Ричем можно сравнить с отношениями Главного Исполнительного Директора (Chief Executive Officer, кратко — CEO) и Главного Операционного Директора (Chief Operating Officer, кратко — COO). Как CEO, я был внешним лицом команды. Во время удаленной работы я обсуждал с удаленными старшими стейкхолдерами стратегию, чтобы убедиться в досягаемости компенсаций, адекватности приоритетов. Как COO, работа Рича была направлена внутрь команды. Он помогал ей двигаться дальше. Я проверял корректность направления. Вместе мы делали владельцев продукта счастливыми.

THE END

Как всегда ждём ваши вопросы и комментарии, которые можно оставить тут или написать их напрямую Марине на открытом уроке.

© Habrahabr.ru