Подход Scrum: как распределить роли в проекте, чтобы не получилось «так себе»
Как, используя подход Scrum, распределить роли между специалистами, работающими на проекте. Какие трудности при этом могут возникнуть. Об этом на примере кейса проекта внедрения ПО для автоматизации учета в 5 европейских филиалах транспортно-экспедиторской компании, рассказывает наш эксперт Максим Якубович.
Автор статьи
Максим Якубович – эксперт Академии управления WINbd, соучредитель и директор по проектам компании «ДрайвИТ», Agile-коуч, консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас», преподаватель курса «Управление проектами» в РАНХиГС.
О чем статья
Гибкие подходы к управлению проектами набирают свою популярность. Настало время написать подробнее о самом популярном из них – Scrum, а именно о ролях в Scrum, используемых в документах и процессах. Документ, который описывает, как работает Scrum (в дальнейшем я буду писать «скрам») называется Scrum Guide. В Scrum Guide описаны три важные роли – владелец продукта (Product Owner), скрам-мастер (Scrum master), команда разработчиков продукта (Development team).
Рассмотрим подробнее эти роли на примере одного из проектов, в котором мы использовали Scrum. Целью проекта стало внедрение двух программных продуктов для автоматизации оперативного и управленческого учета в группе компаний, занимающейся транспортно-экспедиторской деятельностью, и имевшей на тот момент филиалы в пяти странах Европы.
Рассмотрим подробнее эти роли на примере одного из проектов, в котором мы использовали Scrum. Целью проекта стало внедрение двух программных продуктов для автоматизации оперативного и управленческого учета в группе компаний, занимающейся транспортно-экспедиторской деятельностью, и имевшей на тот момент филиалы в пяти странах Европы.
Как мы распределяли роли владельца проекта и скрам-мастера
Роли в Scrum
Одна из важнейших ролей в проекте по Scrum – владелец продукта. Вот, за что он отвечает
Его главная цель – создать максимально ценный для заказчика продукт за ограниченный бюджет проекта. Сначала не нашелся представитель от бизнеса, который смог бы выполнять роль владельца продукта. Внедряемые программные продукты использовались сотрудниками почти всех подразделений компании. Чтобы получить хорошего владельца продукта от бизнеса, пришлось бы пройти длинный путь от разъяснения бизнесу сути подхода Scrum до выбора самого заинтересованного в успехе проекта топ-менеджера. Мы решили назначить владельцем продукта бизнес-аналитика.
Бизнес-аналитик назначал высокий приоритет тем пожеланиям, которые ему было интересно анализировать. Но это могли быть не самые ценные в данный момент пожелания для бизнеса. После нескольких месяцев эксперимента я решил взять роль владельца продукта на себя. В это время я уже выполнял роль скрам-мастера (это вторая важная роль в Scrum). Сочетание двух ролей мне показалось не очень продуктивным. Каждый раз, принимая решение, я думал о том, кто я сейчас – скрам-мастер или владелец продукта? Как владельцу продукта мне хотелось, чтобы команда реализовала за одну итерацию как можно больше пожеланий. А как скрам-мастер я обязан был защищать команду от попыток владельца продукта убедить их взять работы больше, чем они могли реализовать. Кроме того, ко мне постоянно обращались топ-менеджеры компании с просьбами, чтобы их пожеланиям был поставлен приоритет повыше.
В итоге я предложил директору одного из офисов, с которого началось внедрение, стать владельцем продукта. Правда, я не стал объяснять ему все функции владельца продукта, а попросил выполнять хотя бы одну – приоритезацию требований. Таким образом, за наличие приоритетов по требованиям, ответственность нес один человек. Но понимая, что он один не сможет расставлять приоритеты по всем требованиям, ведь они касались разных функциональных областей, предложил ему создать комитет из топ-менеджеров, который собирался раз в месяц и обсуждал приоритеты по требованиям.
Наконец-то бизнес стал вовлекаться в проект: топ-менеджеры узнавали о том, какие пожелания генерируют сотрудники других подразделений, обсуждали и договаривались о приоритетах.
- Отбор пожеланий пользователей к продукту
- Приоритезацию этих требований
- Контроль расходования бюджета проекта
Его главная цель – создать максимально ценный для заказчика продукт за ограниченный бюджет проекта. Сначала не нашелся представитель от бизнеса, который смог бы выполнять роль владельца продукта. Внедряемые программные продукты использовались сотрудниками почти всех подразделений компании. Чтобы получить хорошего владельца продукта от бизнеса, пришлось бы пройти длинный путь от разъяснения бизнесу сути подхода Scrum до выбора самого заинтересованного в успехе проекта топ-менеджера. Мы решили назначить владельцем продукта бизнес-аналитика.
Бизнес-аналитик назначал высокий приоритет тем пожеланиям, которые ему было интересно анализировать. Но это могли быть не самые ценные в данный момент пожелания для бизнеса. После нескольких месяцев эксперимента я решил взять роль владельца продукта на себя. В это время я уже выполнял роль скрам-мастера (это вторая важная роль в Scrum). Сочетание двух ролей мне показалось не очень продуктивным. Каждый раз, принимая решение, я думал о том, кто я сейчас – скрам-мастер или владелец продукта? Как владельцу продукта мне хотелось, чтобы команда реализовала за одну итерацию как можно больше пожеланий. А как скрам-мастер я обязан был защищать команду от попыток владельца продукта убедить их взять работы больше, чем они могли реализовать. Кроме того, ко мне постоянно обращались топ-менеджеры компании с просьбами, чтобы их пожеланиям был поставлен приоритет повыше.
В итоге я предложил директору одного из офисов, с которого началось внедрение, стать владельцем продукта. Правда, я не стал объяснять ему все функции владельца продукта, а попросил выполнять хотя бы одну – приоритезацию требований. Таким образом, за наличие приоритетов по требованиям, ответственность нес один человек. Но понимая, что он один не сможет расставлять приоритеты по всем требованиям, ведь они касались разных функциональных областей, предложил ему создать комитет из топ-менеджеров, который собирался раз в месяц и обсуждал приоритеты по требованиям.
Наконец-то бизнес стал вовлекаться в проект: топ-менеджеры узнавали о том, какие пожелания генерируют сотрудники других подразделений, обсуждали и договаривались о приоритетах.
Организация взаимодействия
Чтобы команда понимала, что делать в первую очередь, мы вели журнал продукта, в который скрам-мастер собирал все требования к внедряемому программному продукту. Мы с командой даже расставляли предварительные приоритеты, которые владелец продукта с его комитетом вполне мог изменить.
Но главной задачей меня как скрам-мастера был не сбор пожеланий в журнал, а внедрение самого подхода скрам, в него входили
Кроме того, одной из задач было повышение производительности команды – всеми возможными способами. Для того, чтобы понять, растет ли производительность, было предложено измерять ее при помощи одной из метрик – Focus Factor. Кстати, к фактическому значению этой метрики были привязаны премиальные команды.
Но главной задачей меня как скрам-мастера был не сбор пожеланий в журнал, а внедрение самого подхода скрам, в него входили
- Организация и проведение совещаний по планированию спринтов (в Scrum так называются итерации, на который разбит весь проект)
- Фасилитация ежедневных скрам-митингов
- Фасилитация ретроспектив спринтов
- Организация демонстрации сделанного командой объема работ за спринт
- Освоение методов оценки объемов работ
Кроме того, одной из задач было повышение производительности команды – всеми возможными способами. Для того, чтобы понять, растет ли производительность, было предложено измерять ее при помощи одной из метрик – Focus Factor. Кстати, к фактическому значению этой метрики были привязаны премиальные команды.
Как работала команда проекта
Третью роль в скрам отводят команде. Команда нашего проекта состояла из программистов, администратора баз данных, специалистов поддержки (они же тестировщики) и бизнес-аналитика. Максимальный размер команды составлял девять человек.
Команда отвечала за выполнение запланированных на спринт задач и соответствие этих задач требованиям к ним. Для команды мы старались поддерживать кроссфункциональность, то есть в ней были представлены все специализации, которые нужны были для внедрения программных продуктов. Кроме того, мы поощряли выполнение сотрудниками задач по смежной для них специальности. Например, специалисты по поддержке иногда программировали простые задачи, а программисты изредка встречались с пользователями для уточнения требований.
У программистов не было жесткой специализации, и ребята разбирались во всех участках внедряемого программного продукта. Через несколько месяцев совместной работы, при планировании спринта, мы начали использовать практику самостоятельного выбора каждым участником тех задач, над которыми он будет работать в спринте. Это сильно повысило ответственность и мотивированность участников команды.
Команда отвечала за выполнение запланированных на спринт задач и соответствие этих задач требованиям к ним. Для команды мы старались поддерживать кроссфункциональность, то есть в ней были представлены все специализации, которые нужны были для внедрения программных продуктов. Кроме того, мы поощряли выполнение сотрудниками задач по смежной для них специальности. Например, специалисты по поддержке иногда программировали простые задачи, а программисты изредка встречались с пользователями для уточнения требований.
У программистов не было жесткой специализации, и ребята разбирались во всех участках внедряемого программного продукта. Через несколько месяцев совместной работы, при планировании спринта, мы начали использовать практику самостоятельного выбора каждым участником тех задач, над которыми он будет работать в спринте. Это сильно повысило ответственность и мотивированность участников команды.
Результаты
В итоге проект внедрения двух модулей информационной системы для автоматизации оперативного и управленческого учета в 5 филиалах разных стран Европы был завершен в срок и признан заказчиком проекта успешным. На реализацию проекта понадобилось 7 месяцев и 9 спринтов по три недели каждый. За это время мы реализовали около 150 требований пользователей.
Если вам откликается философия Scrum
Проведем обучение и подготовим вашу команду к более эффективной реализации проектов!
Как понять, что обучение будет полезно
Оставьте свои данные, и мы свяжемся с вами, чтобы обсудить подробности.
Как понять, что обучение будет полезно
- Непонятно, как оценивать успех проекта и соответствие поставленным целям
- Совещания и регулярные встречи не приносят должной пользы
- Сложно контролировать бюджет, ресурсы, сроки и качество работы
- Вы говорите на «разных языках» с коллегами, нет системного взгляда на проектное управление
Оставьте свои данные, и мы свяжемся с вами, чтобы обсудить подробности.
Вам может быть интересно