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

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

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

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

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

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

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

Организация взаимодействия

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

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

1. Организация и проведение совещаний по планированию спринтов (в Scrum так называются итерации, на который разбит весь проект)
2. Фасилитация ежедневных скрам-митингов
3. Фасилитация ретроспектив спринтов
4. Организация демонстрации сделанного командой объема работ за спринт
5. Освоение методов оценки объемов работ

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

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

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

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

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

Результаты

В итоге проект внедрения двух модулей информационной системы для автоматизации оперативного и управленческого учета в 5 филиалах разных стран Европы был завершен в срок и признан заказчиком проекта успешным. На реализацию проекта понадобилось 7 месяцев и 9 спринтов по три недели каждый. За это время мы реализовали около 150 требований пользователей.

Если вам откликается философия Scrum

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

Как понять, что обучение будет полезно

1. Непонятно, как оценивать успех проекта и соответствие поставленным целям
2. Совещания и регулярные встречи не приносят должной пользы
3. Сложно контролировать бюджет, ресурсы, сроки и качество работы
4. Вы говорите на «разных языках» с коллегами, нет системного взгляда на проектное управление