Delivery Manager — новая роль в мире Agile

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

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

Поехали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Programme Manager и Delivery Manager

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

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

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

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

THE END

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

Автор: MaxRokatansky

Источник ^[9]