Как распределить роли в проекте, чтобы не получилось «так себе» – кейс о подходе Scrum

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

– Гибкие подходы к управлению проектами набирают свою популярность в Беларуси. Настало время написать подробнее о самом популярном из них – Scrum.

В одной из статей я рассмотрел в общем, что такое Scrum и как он работает.

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

Документ, который описывает, как работает Scrum (в дальнейшем я буду писать «скрам») называется Scrum Guide и его можно получить бесплатно.

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

Хотя в Scrum Guide написано, что все три роли входят в состав команды.

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

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

Как мы распределяли роли владельца проекта и скрам-мастера

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

• Отбор пожеланий пользователей к продукту
• Приоритезацию этих требований
• Контроль расходования бюджета проекта 

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

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

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

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

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

После нескольких месяцев эксперимента я решил взять роль владельца продукта на себя. В это время я уже выполнял роль скрам-мастера (это вторая важная роль в Scrum). Сочетание двух ролей мне показалось не очень продуктивным. Каждый раз, принимая решение, я думал о том, кто я сейчас – скрам-мастер или владелец продукта? Как владельцу продукта мне хотелось, чтобы команда реализовала за одну итерацию как можно больше пожеланий. А как скрам-мастер я обязан был защищать команду от попыток владельца продукта убедить их взять работы больше, чем они могли реализовать. 

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

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

Таким образом, за наличие приоритетов по пожеланиям, ответственность нес один человек.

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

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

Как было организовано взаимодействие

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

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

• Организация планирования спринтов (в Scrum так называются итерации, на который разбит весь проект)
• Собрание ребят на ежедневные скрам-митинги
• Ретроспектива спринтов, организация демонстрации сделанного командой объема работ за спринт
• Освоение методов оценки объемов работ
• Помощь команде во время внедрения разных подходов к тестированию написанного кода.

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

Как работала команда проекта

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

• Программистов
• Администратора баз данных
• Специалистов поддержки (они же тестировщики) и бизнес-аналитика

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

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

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

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

Результаты

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

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

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

Я считаю, что это одна из задач скрам-мастера – помочь команде обрести владельца продукта.

Надеюсь, у вас появились вопросы по ролевой модели в Scrum? Я с удовольствием постараюсь на них ответить в комментариях к статье.

Хотите мгновенно получать уведомления о новых материалах и событиях «Про бизнес.»? Подписывайтесь на наш канал в Telegram!