Comments 26
На словах всё так красиво: Везде светит радуга и скачут пони.
По факту: это источник постоянных конфликтов т.к. PO/PM стремятся к разному, клиенты выдвигают очень неадекватные требования большинство из которых не представляют ценности для развития продукта да и с приоритетами, их определением и выделением ресурса разработки всё не так просто.
А кто преследует интересы команды и защищает её от выгорания перед двумя локомотивами продукта и функционала?
Как договорились. РО и РМ должны заранее обговорить, кто лидирует эту активность. Но второй человек не устраняется полностью. Каждый должен держать руку на пульсе, просто один за это еще и отвечает.
Тогда появляется конфликт интересов. ПО хочет почти идеальный продукт в кратчайшие сроки, а команда хочет скинуть темп после предыдущих проектов, получается, что ПО будет сам себе противоречить. ПМ с теми же проблемами сталкивается. И уж самый ужасный вариант, когда ПМ с ПО объединяют в одном человеке, а потом удивляются, что команда прокрастинирует и тихонько тает на глазах. Но это конечно не претензия к вам, скорее мысли вслух.
В моей практике эта роль отводилась scrum-мастеру, не могу с уверенностью сказать что защита команды - каноническая задача для этой роли, но в наших реалиях это работало. Правда у нас не было позиции PM, только PO который по сути выполнял часть обязанностей, которые в статье приписываются PM.
В целом, на мой взгляд, защита интересов команды - задача менеджера команды, как бы он в конкретной ситуации не назывался scrum-мастер, тимлид или как-то иначе.
Включая режим душнилы хочется сказать, что Product Owner - это исключительно роль фреймворка Scrum. И если у вас не Scrum, то выходит, что у вас должен быть какой то другой менеджер - видимо Product Manager.
Поддержу ваш режим душнилы и спрошу: почему роль РО исключительно в Scrum?)
Я тут говорю в контексте различия Product Owner и Product Manager. Product Owner (владелец продукта) – это чисто скрамовская роль, предполагающая очень конкретный круг задач в рамках этого фреймворка, и не более того. А вот Product Manager (менеджер продукта) – это уже про управление продуктом как таковым без привязки к способу/методу разработки. На нем и работа с рынком и с пользователями, продвижение продукта в различных каналах и прочее
С вашего позволения подключусь к вашему душному разговору )))
Роль РО была описана в Scrum (ну или по крайней мере вошла в широкое употребление, потому что является частью Скрама), и имеет истойчивую ассоциацию с ним. Возникает вопрос: зачем называть роль Скрамовским термином, если вы не используете Скрам? Ув. @neonox логично заметил, что есть общее понятие Product Manager – почему не использовать его? Зачем размывать устойчивый термин?
Поясню. Описывая конфликт приоритетов, вы пишите: “PO сосредотачивается на максимизации ценности продукта для пользователей и заказчиков, тогда как PM ставит акцент на соблюдение сроков и бюджета. Это может привести к конфликту между тем, что должно быть реализовано в первую очередь, и тем, что можно уложить в заданные рамки”. То есть выходит, что в вашем определении РО максимизация ценности входит в его обязанности, а сроки и бюджет – нет. Но в Скраме это не так: РО отвечает за все эти пункты! Например, цитата из курсов Скрам-мастера Джеффа Сазерленда (один из авторов Скрама, если что): “Product Owner Deliverables: 1) Increasing Value/Point, 2) Profitability of the Product”. Очевидно, что вы не можете говорить о прибыльности продукта, забывая про сроки и бюджет. Ну или можно обратиться к публичному Руководству по Scrum: “Product Owner… разрабатывает и точно коммуницирует Product Goal”. Опять же, логично ожидать, что если есть какие-то сроки и бюджеты, то они просто обязаны попасть в Product Goal, достижение которой – главная задача Product Owner`а. Поэтому получается, что ваше определение РО не соответствует общепринятому.
Почему это плохо? Потому что есть существенный риск того, что неопытный человек, прочитав вашу статью, сделает вывод, что сроки и бюджеты – это не есть забота РО. Причем из-за уже упомянутой тесной ассоциации роли РО со Скрамом, он, вероятно, решит, что и в Скраме это норма! А потом вдруг появляются люди, которые говорят, что “Скрам не работает”...
При этом, я отнюдь не хочу сказать, что ваша концепция двух таких ролей не имеет право на существование! Я лишь против использования устоявшихся терминов не по прямому назначению.
Почему вы тоже уперлись, что РО - это роль именно в Скраме. Сейчас роль/должность РО можно встретить в каждой второй команде. И не важно, что у них там за фреймворк внедрен. При это в Скрам командах, где есть РО от Скрама зачастую лишь какие-то элементы.
Что же касается конфликтов РО и РМ - где есть РМ, там нет Скрама, так что и обязанности РО в такой конструкции не должны подчиняться Скрам-гайду (и тем более каким-то курсам) :)
Непосредственно про Скрам уже вроде аргументы написаны, и повторяться не буду. Но даже если отвлечься от Скрам, то использование Owner/Владелец в роли не соответсвует и общей менеджерской практике. Так, например, существуют еще такие понятия как Project Owner и Process Owner – и в том и в другом случае речь идет о людях, которые Заинтересованы в Результе Вцелом, а не каких-то точечных показателях. В вашей же интерпритации Product Owner (ввиду отсутствия ответственности за сроки и бюджеты) больше похож на тех продажников, которые обещают заказчику какую-то дичь да еще и в неизвестно откуда взятые сроки – главное продать, а потом хоть потоп, – а инженеры должны все это разгребать. В Скраме же Владелец Продукта – это именно Владелец классическом (устоявшемся) понимании. В итоге, когда человек, который ничего не знает про Скрам и Agile, но знаком с теорией процессов или проектов, впервые услышит термин Product Owner, у него скорее всего возникнут ассоциации куда ближе к Скрамовсому определению, чем к вашему. Это, в свою очередь, помогает людям быстрее находить общий язык, что и является целю профессиональной терминологии. Когда же понятия используются произвольно, в угоду моде, это затрудняет общение, потому что приходится переспрашивать: “а что конкретно вы имеете в виду?”, ну или пытаться угадать из контекста… Так и что в этом хорошего?
Хотя я конечно должен признать, что хайп как правило все-таки побеждает прозрачность понятий (((
Когда-то у меня был такой вариант: РО и РМ в одном лице, причем со стороны заказчика. Исполнитель подчинялся РМ заказчика через своего руководителя, которй "утрясал" выполнимость :) сплошной agile.
Мне кажется, что в статье не указан самый главный и определяющий аспект этих двух ролей, а именно ответственность перед спонсором. А он как раз и определяет все, что написано в статье, плюс указывает на неточности
Итак, есть спонсор с мешочком денег, за которые он хочет получить некий пподукт, который позволит заработать больше денег
PO - человек отвечающий за бизнес эффект от внедрения продукта. Т.е если продукт прошел тест на качество и вышел в мир - за финансовый результат спонсор спросит с PO. Так как ответственность конвертируется в права,то мы приходим к списку того, что написано в статье.
PM отвечает за разработку и внедрение. После того, как PO "расписался в том, что продукт ОК" - PM может открывать бутылку и праздновать успешное завершение проекта :) Потому что если он не взлетит как бизнес сущность - уже не важно :)
Теперь вооружившись этим "главным" знанием, смотрим на конфликты
Приоритет - чисто право PO. В силу его ответственности в бизнес результате. Мнение PM имеет смысл в части технической реализуемости и рекомендаций, которые на этом основаны.
Изменения. Тут это должно закрываться процедурой change request, которую драйвит PM. Это в его интересах, фиксировать все, чтобы потом выкатить.
Ресурсы и сроки - это просто данность, либо смотри предыдущий пунки.
Скоуп прерогатива PM, как и приоритет. Но PM имеет полное право все новые фичи, которых раньше не было, либо бантики, которые стоят дорого коммуницировать PO, а если тот уперся - просто фиксировать и делать
Коммуникация - PO и есть заказчик. И оба репортят спонсору за свою часть
-------
В реале статья очень механическая. Надо базово понимать, кто какую ответственность имеет и уметь слушать других. Плюс спокойно и аргументировано доносить свою точку зрения.
К примеру, PO хочет красную точку, которая стоит 13 стори поинтов. Команда дала объяснение, почему так много (иногда так бывает), но PO без нее не может жить. Ок, вопрос, что тогда выбрасывается из backlog. Чуда ж нет, и PO должен решить, чего выкинуть в обмен на чудо красную точку, или смириться, что ее не будет. Иди плюс один спринт, но тогда пошли к спонсору за деньгам :)
Либо грамотно эскалируем на спонсора. Вот "красная точка", вот ее цена и обоснование, вот варианты
Но вот этого в статье как то нет,точнее очень в общем. Ребята, PO отвечает за продукт и часто он ближе к спонсору. Ему надо помогать. Говорить что мы тоже все хотим сделать классную штуку (что правда), но пытаться донести до него, что давпй без красной точки, иди вот с ней, но тогда чуток по другому. Она будет "зеленой", но стоит 2 вместо 13. Просто PO часто человек идейный и не технический. Иногда любит уйти в детали, так как это же его детище и он его любит и хочет именно таким.
Часто помогает найти тех, у кого в команде возникла химия с ним, аналитик/лид/архитектор. Пусть они с ним больше сидят и на ранних этапах продвигают "хорошие" продуктовые решения
Дизайнера можно брать в союзники, так как он сразу может рисовать так, как будет недорого
Короче, это все не про механику, типа вот 5 пунктов. А про отношения команды в одной лодке
А если Product Owner называется Product Manager - то тут уже PM VS PM получается )))
Шах и Мат!
Можно ли это интерпретировать как Project Manager Vs Product Manager? А вот это уже интересный баттл, где первый смотрит за выполнением процессов, а второй за развитием продукта.
Да, конечно
Возможно эта моя ошибка, надо было в статье написать Product Owner/Product Manager, тогда у mgvoronin не было бы вопросов :)
PO - очередная новомодная хрень. Как там прописано в манифестах - это одно. В реальности, поддавшись рекламе и желая быть "в тренде", менеджмент просто вместо PM ставит PO. Был опыт работы с двумя PO в одной очень крупной компании. Мальчик и девочка. Опыта либо нет, либо непонятно какой, много гонору, езда по ушам, абсолютные нули в анализе, абсолютные нули в управлении, но зато умеют красиво рисовать в разных онлайн-рисовалках диаграммы и воронки вовлеченности на основе сводных таблиц.
100500-я статья о том, в чем разница между РО и РМ