Scrum Master (курс) : Лекция 7

Цели лекции

Понять роль Product Owner

Тезисы

Традиционно спорная роль.

Типичные ошибки:

• Product Owner - вообще не нужен, кросс-функциональная команда сама справиться с требованиями

• Product Owner - это такой аналитик которые должен написать правильные требования

Product Owner отвечает Product Backlog.

Это должна быть single point ответственность, если передать это команде — ответственность окажется размазанной. А если назначать кого-то в команде — то будет нарушено правило «в команде разделения по должностям, обязанностям и доменам». Это первая причина ввести PO.

Вторая причина ввести PO – это то, что для сбора и передачи команде требований, и наоборот для передачи информации от команды к стейкхолдерам требуется специфический набор умений и навыков, совершенно бесполезных для разработки. И наоборот, набор навыков нужных для разработки — совершенно бесполезен для общения со стейкхолдерами. Да, разработчикам нужен какой-то уровень soft skills для командной работы, НО как минимум они говорят на одном языке. А аналитик должен говорить с каждым на его языке.

Третья причина ввести PO – это то, что существует конфликт между обязанностью «максимизировать поставляемую ценность» и «обеспечить появление releasable increment» как минимум в тот момент, когда появляется понятие технического долга. Делегировать представлять обе стороны конфликта одним и тем же людям — это заставлять проявлять их противоестественное поведение, для человека естественнее отстаивать одну точку зрения и спорить с другими, а не с самим собой. .

Четвертая причина ввести PO – это то, что сам характер деятельности резко отличается. Команда занимается поиском решений для проблем — т. е. занимает проактивную позицию. Для сбора же требований в первую очередь требуется незамутненная личным мнением PO передача нужд и ожиданий стейкхолдеров. Настолько сильная смена требований расшатает любую здоровую психику.

Это аргументы против позиции PO вообще не нужен. Это можно перефразировать так — если вам не нужен PO – значит вы делаете слишком простые проекты. Возможно для настолько простых проектов не нужен и SCRUM (см. Stacey matrix).

Теперь о том, является ли PO «настоящим аналитиком» и единственным кто должен работать над product backlog.

Тоже нет. В полноценных системах типа RUP аналитик работал в паре с архитектором и дизайнером чтобы обеспечить полноту требований. В SCRUM соответствующих ролей нет. Поэтому, при том, что с PO в первую очередь работает со stakeholders, выясняет проблемы и потребности и передает их команде — есть огромный пласт технических требований за которые отвечает команда. Задача PO вовлекать команду в той части, в которой требуется их экспертиза.

Два приема которые можно рекомендовать PO:

a) Использовать модель FURPS (functionality, usablilty, reliabilty, performance, supportability), вовлекая команду в написание требований по URPS https://gehtsoftusa.com/blog/create-better-backlog-and-engage-the-development-team-with-furps/

б) Использовать модель 5 аттрибутов (бизнес-важность, бизнес-срочность, бизнес-ясность, техническая сложность и технический объем) привлекая команду к оценке технических аттрибутов. https://gehtsoftusa.com/blog/using-five-attribute-method-to-order-backlog/

Таким образом, «правильный» ПО как минимум:

a) Это человек у которого можно узнать ЗАЧЕМ мы делаем продукт

б) Это человек у которого можно узнать КАК ИМЕННО стейкхолдеры будут проверять подходит ли им продукт

в) Это человек который активно вовлекает команду в уточнение требований касающихся технической части требований

Замечание: на данном этапе PO это моя забота, я буду работать с ними отдельно. Я не ожидаю от SM что они смогут помочь PO или направить его. Обнаружить что PO не делает того, что надо и доложить куда следует — более чем достаточно на данном этапе.