Сегодня хочу поговорить о такой важной роли, как Service Delivery Manager.

Не смотря на то, что про нее уже написаны статьи (примеры: раз и два), я все же хочу разобраться в том, за что она отвечает и чем может быть полезна в бизнесе.

Изначально термин Service Delivery Manager пошел из книжки Канбан. Краткое руководство. В ней коротко говорилось о том, что это за роль, когда она возникает и за что отвечает. 

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

Именно поэтому данная роль применима к таким позициям, как проджект менеджер, продакт менеджер и линейный руководитель. Если с первой и третьей позицией всё более менее ясно, то вторая может вызывать вопросы. Как продакт менеджер может быть ответственным за поставку сервиса? Ведь он же отвечает за дискавери сервиса! 

На практике добиться этого очень легко. Заберите у продакта проджекта или тимлида и вы получите продакта, который отвечает и за дискавери и за деливери процессы. Делает он это просто потому, что больше некому отвечать за деливери в продуктовой команде, а у него за это “душа болит”. 

Хорошо ли это? Моё личное мнение, что это очень плохо, потому что продакту приходится отвечать сразу за две довольно большие зоны ответственности. Поэтому когда я вижу описание вакансии продакта “у нас нет проджектов” или “наши продакты сами управляют командой разработки”, мне становится не по себе. Эффективность таких продактов в продуктовых задачах редко превышает 50%. А если у него бэкграунд проджекта или тимлида, то она снижается еще больше и достигает 20-30%. То есть всё остальное время такой продакт тратит на деливери продуктовой команды.

Однако вернемся к роли Service Delivery Manager. Как я уже сказал, она возникающая и появляется в тот момент, когда нам нужен ответственный за сервис. Зона ответственности этой роли – организовать деливери процесс, следить за ним и улучшать по мере необходимости. Это могут быть как инженерные решения (внедрение код ревью, например), так и процессные (устранение узких горлышек).

Например, мой список обязанностей как проджект менеджера или деливери менеджера:

• Управление деливери
• Организация процесса разработки.
• Мониторинг метрик поставки.
• Разделение бэклога на версии продукта.
• Канбан-доска.
• Фокус на результате.
• Карта пользовательских историй.
• Дорожная карта в виде диаграммы Гантта.
• Фасилитация всех встреч.

Опыт работы в этой роли я описал подробно в этой статье.

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

Трудно переоценить важность этой роли. За всю свою восьмилетнюю карьеру в Канбан-методе я наблюдал множество раз, что происходит с сервисом, когда в нём нет этой роли. В лучшем случае кто-то из команды берет на себя эту ответственность. В худшем – никто не отвечает за деливери и тогда совсем становится не понятно, как эта команда деливерит и какие вообще у нее сроки поставки? И вообще про что она?

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

Желаю вам найти своего Service Delivery Manager. И тогда у вас будет классный, надежный сервис, который будет стабильно и предсказуемо поставлять для бизнеса результат.