[Перевод] Delivery Manager — новая роль в мире Agile
Всем добрый день!
До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.
Поехали.
Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.
О роли Delivery Manager мы говорим не часто. Конечно, это не часть «семьи» Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком «Разработчик». Вот, пожалуй, и все.
Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.
Зачем нужен 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
Как всегда ждём ваши вопросы и комментарии, которые можно оставить тут или написать их напрямую Марине на открытом уроке.
