Кто такой Proxy Product Owner?

Автор: Dmitry Zdanovich

О жизни

Ура, новый проект! Заказчик говорит – «Ребята, я много слышал про Agile разработку. Я хочу Scrum на проекте». Все просто в восторге. Эйфория полная. Начинается разработка.

– Мы готовы к работе. Где можно найти product backlog?

– Guys, ну вы понимаете, я сейчас очень занят. Давайте попозже.

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

– Все, мы уже создали всю инфраструктуру. Мы не знаем, что делать дальше.

– У меня столько дел…

В конце концов кратко рассказывается, что заказчик хочет видеть. Естественно, ни о каких user stories речь не идет. Но хоть что-то, чтобы начать работать.

По самым оптимистичным оценкам работы как минимум на несколько человеко-лет.

– А какие приоритеты?

– Вся функциональность должна быть сделана. Причем, как можно быстрее!

Нда, начальная эйфория куда-то пропала…

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

Сделали. Sprint demo (как оказалось, в данном проекте feedback во время спринта – недостижимая роскошь).

– Мы завершили итерацию. Готовы показать то, что получилось.

– Ребята, ну вы понимаете, вы же умные люди… Я уверен, что вы все делаете правильно – я же вам все рассказал.

Упс. Команда начинает понимать, что какой-то уж очень странный Scrum получается. И даже совсем не Scrum. Но проект-то есть. И делать его надо.

Посовещались. Пришли к выводу – product owner проекту необходим. Если эту роль не может выполнять заказчик, значит, должен выполнять кто-то из команды (или из компании).

Выбрали. И начались нелегкие будни proxy product owner’a.

Первым делом, надо понять, как заказчик видит продукт в целом. Общение, общение и еще раз общение. Все, вроде в целом какое-то видение сформировалось. После того, как команда поняла, что это будет за проект, стало намного веселее.

Дальше. Product backlog. User stories. Proxy product owner разбил весь продукт на отдельные user stories. Отправил заказчику. Как ни странно, заказчик даже внес некоторые изменения. Значит, не все еще потеряно! Команда становится веселее и продуктивнее прямо на глазах!

Приоритеты. Proxy product owner интуитивно понимает, что сейчас начнется самое интересное. Что делать, если для заказчика все самое важное? Попробовать подойти с другой стороны.

– Представьте, что мы не успеваем сделать одну историю. Какую вы бы предпочли выкинуть?

– Вот эту.

– А если еще одну?

– Эту.

– А если еще?…

Ух ты, даже начальные приоритеты удалось получить. Все, жизнь налаживается.

Остался feedback. Как быть, если заказчик действительно очень занят? И тут команда предлагает гениальную идею – найти реальных пользователей. С большим трудом у заказчика выбиваются контакты реальных пользователей. Что удивительно, пользователи рады, что их к этому привлекают.

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

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

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

Команда тоже.

Happy end.

Proxy product owner – когда, зачем и что должен делать

Если есть человек, который успешно выполняет роль product owner’a, то вводить proxy product owner’a абсолютно нет смысла. По сути, proxy product owner – это локальный product owner. И если существующий product owner не предоставляет user stories, product backlog, priorities и feedback – нужно задуматься о введении такой роли.

Второй вариант, когда команда использует Scrum (и для этого проекта он подходит), но заказчик не хочет брать на себя обязанности product owner’a. В этом случае proxy product owner просто необходим.

Что должен делать proxy product owner? По сути, то же, что и product owner:

  1. Vision
  2. Product backlog с приоритетами
  3. Быть готовым ответить на вопросы по проекту
  4. Организовать получение feedback’a

Есть несколько вариантов того, кто должен стать proxy product owner’ом.

Один из самых хороших вариантов – когда эту роль берет на себя кто-то из компании, но не из команды:

  1. Это не нагружает команду
  2. Не вносит больших помех со стороны видения команды (оно часто слишком техническое)
  3. Позволяет ставить реальные бизнес-приоритеты
  4. А если человек является экспертом в домене проекта, так и вообще отлично.

Второй вариант – Scrum master становится proxy product owner’ом. Есть несколько минусов у этого решения:

  1. Scrum master может стать слишком перегруженным
  2. Scrum master может стать представителем заказчика в глазах команды,
  3. Так как Scrum master плотно взаимодействует с командой, то она может повлиять на него в плане приоритетов.

Третий вариант – proxy product owner’ом становится кто-то из команды. Также ряд минусов:

  1. Скорее всего, будет преобладать технический vision
  2. Приоритеты будут тоже больше техническими
  3. Это человек получит определенную власть, что может привести к расколу команды
  4. Он может быть слишком перегруженным
  5. Эта роль может вызывать раздражение (особенно у программистов).

Заключение

Вы знаете, что Scrum для этого проекта и вашей команды подходит просто идеально? Но не хватает такого же идеального product owner’a? Создайте его!

Автор: Dmitry Zdanovich

Tags: ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • Konstantin Razumovsky

    Интересная статья, но закрались сомнения, насколько корректно в ней используется термин “Proxy Product Owner”.

    Из статьи можно сделать вывод, что если не получилось найти PO на стороне клиента, и в качестве PO выступает человек из команды (компании), то это уже не PO, а Proxy PO. Насколько я понимаю, Product Owner совершенно не обязан принадлежать организации-клиенту, при этом он остается полноценным PO, а не каким-то прокси :). У Кена Швабера в “Agile SW Development with Scrum” читаем:
    “For commercial development the Product Owner may be the Product Manager”.

    При этом под Proxy PO понимают, кажется, несколько иную фигуру, например:
    http://softwaredevelopmenttoday.blogspot.com/2008/04/proxy-product-owner-pattern-in-scrum.html

    Буду только рад, если знатоки Scrum меня поправят 🙂

  • Dmitry Zdanovich

    Полноценный Product owner имеет право определять бюджет и несет ответственность за успех проекта. Для своих продуктов product manager как раз и будет product owner. Для разработки на заказ, как правило, product manager на стороне компании-исполнителя не может самостоятельно принимать решения о серьезном изменении функционала.

    Тот паттерн, что описан в этой статье, наиболее характерен для outsource проектов. И именно в таком значении этот термин объяснялся во время сертификационных тренингов для Scrum master’ов.

    Btw, у Асхата Уразбаева было какое-то свое разбиение для больших проектов, когда есть несколько Product owner’ов (сходу не вспомню, надо поискать).