Как договариваться о ролях в новом проекте?

Как договариваться о ролях в новом проекте? Отвечает Михаил Войтко, Sr. Project Manager в Сбербанк

Практически в каждом проекте по разработке продукта возникает необходимость в распределении ответственности между участниками команды — если, конечно, над продуктом трудится больше одного человека. Как правило, ситуация обостряется с наступлением очередного дедлайна: то, что не успели сделать за спринт, оперативно доделывает самый исполнительный сотрудник. Но эту неприятную ситуацию можно сильно сгладить, если еще на стадии планирования продукта позаботиться о ролевой модели участников.

О каких ролях мы поговорим:

  1. Владелец продукта, Product Owner.
  2. Скрам-мастер.
  3. Менеджеры продуктов: junior, middle, аналитики.
  4. Разработчики (не буду детализировать все их роли).
  5. Дизайнеры.
  6. Менеджеры проектов.
  7. Служба поддержки.
  8. Маркетинг.
  9. Специалисты по продажам.

Сразу сделаю оговорку: детально рассматривать роли в рамках этой статьи мы не будем, по этим темам написаны целые книги.

Как определить ответственность во время создания продукта

В гибких методологиях часто все занимаются всем, роли четко не прописаны и не возбраняется брать на себя столько ответственности, сколько хочется. Но всё же разумно иметь определенные рамки. Начнем с определения ролей.

Product Owner — отвечает за то, в каком направлении будет развиваться продукт, определяет бэклог и приоритеты, договаривается со всеми заинтересованными сторонами. Одна из главных задач владельца продукта — формировать и постоянно актуализировать видение продукта после регулярных исследований и сбора обратной связи. Также в его зоне ответственности управление релизами, изменениями, общением с партнерами, пользователями, руководством и командами разработки.

Чем отличаются Product Manager и Product Owner: две точки зрения

Скрам-мастер — обеспечивает координацию в команде продуктовой разработки между всеми её ключевыми участниками: менеджерами продуктов, разработчиками, дизайнерами, менеджерами проектов (если продукты большие) и другими участниками. Регулярные церемонии, контроль заполнения спринтов, ведение таск-трекера и внедрение agile-культуры — главные задачи скрам-мастера. Задачи скрам-мастер получает от владельца продукта.

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

Участники команды, отвечающие за разработку — программисты, дизайнеры, верстальщики, DevOps-инженеры и многие другие. Их задачи — непосредственная реализация проекта, постоянная работа над бэклогом, документирование технических решений, работа с подрядчикам, настройка и мониторинг производительности, тюнинг и многое другое, без чего продукт просто не будет работать.

Маркетинг, продажи, служба поддержки — названия говорят сами за себя, хотя именно тут чаще всего возникает непонимание. Насколько маркетинг влияет на продукт? Как провести исследование и кто за что в нем будет отвечать? Брать ли с собой владельца продукта на сложные продажи? Должны ли DevOps-инженеры заниматься поддержкой на третьей линии? Эти и многие другие вопросы беспокоят умы владельцев продуктов. 

Подкаст make sense #39: о качествах сейлза, продажах и метриках в b2b с Антоном Гладковым

Так как же зафиксировать обязанности перед запуском проекта?

Какие инструменты использовать для описания обязанностей

Существует несколько фреймворков для описания ролей и обязанностей. Давайте рассмотрим один из самых простых — матрица RACI. Подробно почитать о нем можно в литературе по проектному управлению (PMBoK и т.п.).

В строках матрицы отмечают операции или задачи, а в столбцах — людей или роли участников процесса. Отвественность каждого отмечают с помощью 4-х букв на пересечении столбцов и строк после согласования между участниками команды, то есть еще до запуска процесса:

  1. R — отвечает.
  2. A — утверждает.
  3. С — консультирует.
  4. I — информируется. 

Так можно достаточно легко согласовать и заполнить ключевые роли участников и границы полномочий между ними. Часто такие матрицы дополняют необходимыми полями и столбцами в зависимости от сложности продукта и процесса разработки. Но остерегайтесь превращения этой матрицы в проектный план.

Матрица RACI

Пример матрицы

Какие ещё фреймворки можно использовать для распределения ответственности в проекте или разработке продуктов? Есть несколько методологий продаж, среди них — SPIN или Solution Selling. В каждой описывается портрет потенциального клиента и других лиц, которые участвуют в сделке. 

Пять принципов для построения процессов в компании на этапе роста

Например, в методологии Solution Selling активно используется схема Pain-Power-Value-Vision-Control, которая среди прочего детально определяет роли всех участников сделки. Вы можете создать свой шаблон, четко зафиксировать роли на старте разработки, а потом регулярно пересматривать и актуализировать задачи по каждой из ролей.

Что можно отдать на аутсорсинг

С точки зрения управления ответственностью между участниками передача на аутсорсинг неосновных функций может значительно упростить контроль и сфокусировать команду на достижении цели. Например, разработку архитектуры можно доверить своим разработчикам, а тестирование отдать подрядчику. Или маркетинговую стратегию разрабатывает отдел маркетинга, а исследования проводит агентство по четкому техзаданию. 

Плюсы аутсорсинга:

  • Сохраняется фокус команды.
  • Развивается ключевая компетенция, не развиваются побочные.
  • Появляется гибкость и возможность сменить подрядчика по договору.
  • Четко зафиксирован образ будущего результата.

Минусы аутсорсинга:

  • Зависимость от сторонних подрядчиков.
  • Возможна утечка информации и потеря ноу-хау, уникальной идеи, а иногда и целых частей продукта. Не все аутсорсеры белые и пушистые.
  • Высокая стоимость — часто это основная проблема передачи процессов и частей проекта на аутсорсинг.

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

Чего не нужно делать менеджеру продуктов и как быть, если кто-то перетягивает ответственность

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

Подкаст make sense #106: О теории и мифах менеджмента, и эволюции подходов в управлении проектами и людьми

В таком случае делать какую-то часть работ своими руками для менеджера продуктов губительно и опасно. Чтобы не попадаться на эту удочку, регулярно, например, 1 раз в квартал актуализируйте роли в матрице RACI. Потом на ближайшей ретроспективе обсуждайте, кто и чем занимался во время спринта, и совместно со скрам-мастером реализуйте необходимые изменения в составе задач по каждому участнику проекта. В этом смысле мелкие задачи на коротких итерациях позволят получить более четкое разграничение ответственности и полномочий.

Резюме

  1. Определите роли в проекте, пропишите список задач и зоны ответственности для каждой из ролей.
  2. Для проработки ролей проекта используйте специальные фреймворки — например, матрицу RICE, SPIN или Solution Selling.
  3. Отдавайте на аутсорсинг некритичные части работ: тестирование, проведение исследований.
  4. Не пытайтесь сделать все сами — это губительно и опасно.