Всем привет!

Сегодня хочу поговорить о том, кто такой Service Request Manager (SRM). Об этой роли так же написаны статьи и записаны подкасты, но я бы хотел поделиться своим мнением и наблюдением за этой ролью.

Лучше всего ее иллюстрирует следующий слайд:

Видно, что роль занимает первую половину Канбан-доски и отвечает за зону Восходящего Канбана (Upstream Kanban). За ней идет точка принятия обязательств, где SRM передает ответственность за работу Service Delivery Manager (SDM). И уже после точки принятия обязательств идет зона ответственности SDM.

На практике роль SRM встречается довольно редко, потому что на ее месте обычно находится роль продакт менеджера или владельца продукта. Однако если у вас есть Восходящий Канбан или вы хотите упростить жизнь продакту или владельцу продукта, вы можете построить этот Восходящий Канбан и объяснить, чем занимается роль SRM.

Её основной фокус – это отсев опционов (или идей), чтобы до Нисходящего Канбана (Downstream Kanban)  доходила только проверенная и подтвержденная работа. По этой причине на картинке выше показаны такие этапы работы SRM, как Risk Analysis и Requirements Analysis.

SRM проверяет работу на риски (что будет, если мы это не сделаем) и анализирует требования (что именно нужно сделать). Если работа высокорисковая или требования туманны и непредсказуемы, работа может быть отменена или отложена до лучших времен..

Девид Дж. Андерсон в 2016 году у себя в блоге писал (перевод), что на практике редко встретишь сразу две роли в одной Канбан-системе. На текущий момент я бы сказал, что ситуация изменилась. В таких компаниях, как ТБанк, Авито и Юmoney эти роли есть, просто называются они по-другому. Service Request Manager – это менеджер продукта. Service Delivery Manager – это тимлид (или техлид, или проджект).

Таким образом на сегодняшний день у нас есть больше возможностей наблюдать эту роль в реальном мире. Я, например, работаю продакт менеджером и у меня нет выделенного тимлида, поэтому мне приходится совмещать в себе две роли: SRM и SDM. Сразу скажу, что на практике это не просто. Помимо основной деятельности в Discovery приходится постоянно следить за зоной Delivery, чтобы была поставка разработанных фичей. О своей работе продактом и обязанностях я писал более подробно в этом посте. 

Приведу короткий список:

• Управление дискавери.
• Управление стратегией развития продукта.
• Достижение KPI продукта
• Формирование видения продукта.
• Проведение глубинных интервью.
• Генерация и валидация гипотез.
• Сбор обратной связи от пользователей.
• Управление бэклогом продукта.
• Юнит-экономика продукта.
• Рост метрик продукта.

Самое важное, что мне хотелось бы подчеркнуть, нужно очень хорошо выстроить границы между двумя ролями: SRM и SDM. Нужно, чтобы каждый участник в Канбан-системе понимал, где границы его зоны ответственности. Если этого не сделать, роли будут заходить на территорию друг друга и это может вызывать конфликты и проблемы.

Подводя итог вышесказанному могу сказать, что сегодня роль Service Request Manager уже не экзотика, а вполне себе понятная и прозрачная роль в Канбан-методе. Поэтому если вы, как и я, адепты Канбан-метода, внедряйте ее и экспериментируйте.

Применение обеих ролей в Канбан-системе сделает ваш сервис не только предсказуемым и понятным, но еще и приносящим реальную пользу пользователям.