Практически в каждом проекте по разработке продукта возникает необходимость в распределении ответственности между участниками команды — если, конечно, над продуктом трудится больше одного человека. Как правило, ситуация обостряется с наступлением очередного дедлайна: то, что не успели сделать за спринт, оперативно доделывает самый исполнительный сотрудник. Но эту неприятную ситуацию можно сильно сгладить, если еще на стадии планирования продукта позаботиться о ролевой модели участников.
О каких ролях мы поговорим:
- Владелец продукта, Product Owner.
- Скрам-мастер.
- Менеджеры продуктов: junior, middle, аналитики.
- Разработчики (не буду детализировать все их роли).
- Дизайнеры.
- Менеджеры проектов.
- Служба поддержки.
- Маркетинг.
- Специалисты по продажам.
Сразу сделаю оговорку: детально рассматривать роли в рамках этой статьи мы не будем, по этим темам написаны целые книги.
Как определить ответственность во время создания продукта
В гибких методологиях часто все занимаются всем, роли четко не прописаны и не возбраняется брать на себя столько ответственности, сколько хочется. Но всё же разумно иметь определенные рамки. Начнем с определения ролей.
Product Owner — отвечает за то, в каком направлении будет развиваться продукт, определяет бэклог и приоритеты, договаривается со всеми заинтересованными сторонами. Одна из главных задач владельца продукта — формировать и постоянно актуализировать видение продукта после регулярных исследований и сбора обратной связи. Также в его зоне ответственности управление релизами, изменениями, общением с партнерами, пользователями, руководством и командами разработки.
Скрам-мастер — обеспечивает координацию в команде продуктовой разработки между всеми её ключевыми участниками: менеджерами продуктов, разработчиками, дизайнерами, менеджерами проектов (если продукты большие) и другими участниками. Регулярные церемонии, контроль заполнения спринтов, ведение таск-трекера и внедрение agile-культуры — главные задачи скрам-мастера. Задачи скрам-мастер получает от владельца продукта.
Менеджеры продуктов и аналитики — отвечают за разработку отдельных модулей, части продукта или элементы процесса. Например, за регулярную обратную связь, пользовательские интервью. Необходимость в них обычно появляется, когда продукт уже достаточно большой.
Участники команды, отвечающие за разработку — программисты, дизайнеры, верстальщики, DevOps-инженеры и многие другие. Их задачи — непосредственная реализация проекта, постоянная работа над бэклогом, документирование технических решений, работа с подрядчикам, настройка и мониторинг производительности, тюнинг и многое другое, без чего продукт просто не будет работать.
Маркетинг, продажи, служба поддержки — названия говорят сами за себя, хотя именно тут чаще всего возникает непонимание. Насколько маркетинг влияет на продукт? Как провести исследование и кто за что в нем будет отвечать? Брать ли с собой владельца продукта на сложные продажи? Должны ли DevOps-инженеры заниматься поддержкой на третьей линии? Эти и многие другие вопросы беспокоят умы владельцев продуктов.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Так как же зафиксировать обязанности перед запуском проекта?
Какие инструменты использовать для описания обязанностей
Существует несколько фреймворков для описания ролей и обязанностей. Давайте рассмотрим один из самых простых — матрица RACI. Подробно почитать о нем можно в литературе по проектному управлению (PMBoK и т.п.).
В строках матрицы отмечают операции или задачи, а в столбцах — людей или роли участников процесса. Отвественность каждого отмечают с помощью 4-х букв на пересечении столбцов и строк после согласования между участниками команды, то есть еще до запуска процесса:
- R — отвечает.
- A — утверждает.
- С — консультирует.
- I — информируется.
Так можно достаточно легко согласовать и заполнить ключевые роли участников и границы полномочий между ними. Часто такие матрицы дополняют необходимыми полями и столбцами в зависимости от сложности продукта и процесса разработки. Но остерегайтесь превращения этой матрицы в проектный план.
Какие ещё фреймворки можно использовать для распределения ответственности в проекте или разработке продуктов? Есть несколько методологий продаж, среди них — SPIN или Solution Selling. В каждой описывается портрет потенциального клиента и других лиц, которые участвуют в сделке.
Например, в методологии Solution Selling активно используется схема Pain-Power-Value-Vision-Control, которая среди прочего детально определяет роли всех участников сделки. Вы можете создать свой шаблон, четко зафиксировать роли на старте разработки, а потом регулярно пересматривать и актуализировать задачи по каждой из ролей.
Что можно отдать на аутсорсинг
С точки зрения управления ответственностью между участниками передача на аутсорсинг неосновных функций может значительно упростить контроль и сфокусировать команду на достижении цели. Например, разработку архитектуры можно доверить своим разработчикам, а тестирование отдать подрядчику. Или маркетинговую стратегию разрабатывает отдел маркетинга, а исследования проводит агентство по четкому техзаданию.
Плюсы аутсорсинга:
- Сохраняется фокус команды.
- Развивается ключевая компетенция, не развиваются побочные.
- Появляется гибкость и возможность сменить подрядчика по договору.
- Четко зафиксирован образ будущего результата.
Минусы аутсорсинга:
- Зависимость от сторонних подрядчиков.
- Возможна утечка информации и потеря ноу-хау, уникальной идеи, а иногда и целых частей продукта. Не все аутсорсеры белые и пушистые.
- Высокая стоимость — часто это основная проблема передачи процессов и частей проекта на аутсорсинг.
В любом случае, решать вам, но хочу напомнить: быстро развивать продукт и при этом оставаться финансово эффективными помогут только настоящие профессионалы. При правильном выборе внешнего исполнителя вы получите подрядчика с сильной экспертизой и должным уровнем ответственности.
Чего не нужно делать менеджеру продуктов и как быть, если кто-то перетягивает ответственность
Очень часто менеджеры продуктов, особенно начинающие, хотят всё сделать самостоятельно, показать всем, как проводить интервью, писать хороший код или создавать качественный дизайн интерфейсов. К сожалению, это путь в никуда. В разработке крупных и серьезных продуктов эффективность и масштабируемость появляются, только когда большой коллектив работает слаженно, а качество измеряется и постоянно улучшается.
В таком случае делать какую-то часть работ своими руками для менеджера продуктов губительно и опасно. Чтобы не попадаться на эту удочку, регулярно, например, 1 раз в квартал актуализируйте роли в матрице RACI. Потом на ближайшей ретроспективе обсуждайте, кто и чем занимался во время спринта, и совместно со скрам-мастером реализуйте необходимые изменения в составе задач по каждому участнику проекта. В этом смысле мелкие задачи на коротких итерациях позволят получить более четкое разграничение ответственности и полномочий.
Резюме
- Определите роли в проекте, пропишите список задач и зоны ответственности для каждой из ролей.
- Для проработки ролей проекта используйте специальные фреймворки — например, матрицу RICE, SPIN или Solution Selling.
- Отдавайте на аутсорсинг некритичные части работ: тестирование, проведение исследований.
- Не пытайтесь сделать все сами — это губительно и опасно.
