Разница между Владельцем продукта и Scrum-мастером

Все больше и больше изучаю Scrum. Читаю книги, статьи, смотрю вебинары. До практики пока не дошло. Использую только некоторые элементы в своей работе.

Очень важная часть Scrum — его команда, которая состоит из владельца продукта (Product owner, PO), Scrum-мастера и команды разработчиков. Со Scrum-командой взаимодействуют Владелец бизнеса (Business owner, BO), Стейкхолдеры (заинтересованная сторона: заказчики, клиенты) и эксперты в предметных областях (Subject matter expert, SME).

Scrum

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

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

Photo by Chris Davis 

***

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

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

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

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

Всего за день хороший РО скорее всего справится с большинством задач (или даже со всеми задачами):
— составит техническое описание беклога
— проконтролирует качество работы команды разработчиков (проведет тестирование, для того чтобы убедиться, что команда делает то, что было задумано)
— организует встречу со стейкхолдерами для получения от них запросов и очередной порции потребностей
— подготовит ответы на вопросы и решения для разработчиков, предоставит сведения о деталях спринта, в котором команда сейчас работает
— примет участие во встречах с разработчиками для формирования общего понимания причин отставания от намеченного плана и подстегнет команду на набор темпа в спринте
— примет участие во встречах с руководством для получения информации о процессах происходящих в бизнесе и будущих событиях, которые могут повлиять на продукт
— разработает концепцию продукта для определения того, что именно должен делать продукт и почему
— постоянно будет поддерживать дорожную карту разработки продукта, для планирования работы на следующие 3 — 6 месяцев
— проведет переговоры со стейкхолдерами, о включении конкурентных элементов в продукт и обоснованное высказывание своих «да» или «нет» на запросы от них
— расскажет стейкхолдерам и пользователям о новых возможностях продукта и его функциях
— примет участие в scrum-мероприятиях.

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

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

Scrum-мастер (также известный как «Защитник» и «Слуга-Лидер») отвечает за ежедневную жизнь и долгосрочный успех Scrum-команды. Это активная роль, которая постоянно адаптируется к потребностям команды и бизнеса и может меняться изо дня в день под воздействием различных задач, которые стоят перед ним.

Это партнер, который гарантирует, что каждый играет свою роль на благо всей команды. Scrum-мастер держит в курсе остальную часть бизнеса о том, что и как делает команда. Он сдерживает любой конфликт, который возникает в жизни и вокруг команды. Вот типичный пример конфликта внутри команды:

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

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

Всего за один день хороший scrum-мастер способен с правится с большинством задач:
— сделает обзор беклога совместно с РО и разложить его на части и приоритизировать их
— проинформирует РО о любых препятствиях, с которыми сталкивается команда разработчиков (например, техническая проработка не позволяет реализовать функционал продукта или вышестоящее руководство, в обход РО, требует реализовать работу, отличную от запланированной в рамках текущего спринта) как можно скорее
— держит под контролем постоянные конфликты между командой разработчиков, которая стремится к качеству, и РО, который хочет внедрить больше возможностей и ценностей для клиента
— удалит любые препятствия на пути команды (например, команде нужна установка нового ПО для внедрения нового процесса, или кто-то выбыл и команде нужна замена, чтобы двигаться дальше. Препятствием может быть и низкий моральный дух команды)
— подбодрит команду, укрепляет её, создавая доверие и повышая моральный дух, любым способом, который наилучшим образом подходит для команды
— проведет встречи с руководством и РО, на которых получает обратную связь от них, удовлетворяет ли команда их требованиям
— ответит на вопросы от стейкхолдеров о потенциальных проблемах продукта и подключит команду разработчиков и РО, когда это необходимо (например, когда это происходит из-за ошибки ПО, а не из-за недостатков функционала)
— соберет информацию об успехах и неудачах команды на протяжении всего времени, отслеживая возможные проблемы и помогает каждому учиться на ошибках
— отчитается о прогрессе команды разработчиков перед руководство и стейкхолдерами, расскажет о том, как много работы они выполнили из той, что взяли в каждый их спринтов, какая у команды скорость
— расскажет стейкхолдерам о команде и о том почему она работает как работает
— будет держать контакт с командой разработчиков, связывая их в ежедневной работе
— поможет во всех scrum-мероприятиях.

Важные характеристики scrum-мастера:
— сглаживает конфликтные ситуации и является посредником в реальных действиях
— способен обучать и вдохновлять людей без авторитета и власти именно это и является определением «слуга-лидер»
— является любопытным, задает вопросы всегда обучается, особенно стремится получать новые знания о scrum и лидерском развитии
— легко зарабатывает доверие и уважение среди разных людей, поощряет сотрудничество и открытое взаимодействие (также важно, как и для РО)

***

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

(Visited 60 times, 60 visits today)

Тоже будет интересно:

Комментарии: