Роли при использовании фреймворка Scrum

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

Всем привет!

Меня зовут Максим Якубович, я – партнер Product Lab и практикующий эксперт по управлению проектами и Agile. В этой статье расскажу про роли и ответственности Scrum-команды, а также поделюсь бесплатным мероприятием, которое вам может быть полезным.

Итак, начнем.

В Scrum Guide описаны три важные роли – владелец продукта (Product Owner), скрам-мастер (Scrum master), команда разработчиков продукта (Development team). Для простоты я буду писать «команда». Хотя в Scrum Guide написано, что все три роли входят в состав команды.

В Scrum Guide описаны три важные роли – владелец продукта (Product Owner), скрам-мастер (Scrum master), команда разработчиков продукта (Development team). Для простоты я буду писать «команда». Хотя в Scrum Guide написано, что все три роли входят в состав команды.

Рассмотрим подробнее эти роли на примере одного из проектов, в котором мы использовали Scrum.

Цель проекта о котором пойдет речь: внедрение двух программных продуктов для автоматизации оперативного и управленческого учета в группе компаний, занимающейся транспортно-экспедиторской деятельностью, имевшей на момент внедрения филиалы в пяти странах Европы.

Одна из важнейших ролей в проекте по Scrum – владелец продукта. Он отвечает за:

Его главная цель – за ограниченный бюджет проекта создать максимально ценный для заказчика проекта продукт.

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

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

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

После нескольких месяцев эксперимента я решил взять роль владельца продукта на себя.

В это время я уже выполнял роль скрам-мастера (это вторая важная роль в Scrum).

Сочетание этих двух ролей мне показалось не очень продуктивным.

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

Кроме того, ко мне постоянно обращались топ-менеджеры компании с просьбами, чтобы их пожеланиям был поставлен приоритет повыше.

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

Понимая, что в одиночку расставлять приоритеты по всем требованиям будет сложно (они касались разных функциональных областей – маркетинга, оказания услуг, продаж, учета и т.д.), я предложил создать новому владельцу продукта комитет из топ-менеджеров, который собирался раз в месяц и обсуждал приоритеты по требованиям.

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

Главная цель скрам-мастера — внедрение самого подхода Scrum:

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

Третья роль в скрам – команда разработки. Команда разработки нашего проекта состояла из:

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

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

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

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

Это, на мой взгляд, сильно повысило ответственность и мотивированность участников команды.

В итоге проект внедрения двух модулей информационной системы для автоматизации оперативного и управленческого учета в 5 филиалах разных стран Европы был завершен в срок и был признан заказчиком проекта успешным.

На проект понадобилось 7 месяцев и 9 спринтов по три недели каждый. За это время мы реализовали около 150 требований пользователей.

Самым сложным для нас оказался поиск заинтересованного в бизнес-результате владельца продукта, который смог организовать работу по приоритезации требований пользователей.

Если эта статья была для вас интересной и вы бы хотели больше погрузиться в тему, то приглашаю вас на мой бесплатный прямой эфир в Product Lab по теме «Как организовать работу Agile-команды»

Cкоро я буду проводить тренинг Agile Certified Professional, где вы можете погрузиться в Agile, Scrum и Kanban на практике и получить международный сертификат от ICAgile. Вы и ваша команда научитесь профессионально использовать Agile, Scrum и Kanban, выстраивать эффективную работу команды, гибко реагировать на изменения, визуализировать рабочие процессы и точно оценивать сроки выполнения задач.

В результате обучения вы: узнаете:

научитесь:

сможете:

получите:

Узнать подробнее

Присоединяйтесь к курсу: научитесь использовать два подхода за один тренинг, улучшите процессы своей команды и ускорьте разработку продуктов!