https://vc.ru/hr/46048-glavnaya-oshibka-agile-transformatorov-pochemu-product-manager-i-product-owner-eto-ne-odin-chelovek

Зашло прямо

Класс

Ну типа директора разные отделов и прочего вообще ничего не делают

Зашло прямо

Есть полезные идеи), только с менеджерами получается перебор 😉

Есть полезные идеи), только с менеджерами получается перебор 😉

Ну с учетом того что продакта от проджекта отличают не все...

То норм :)

Есть полезные идеи), только с менеджерами получается перебор 😉

Как и в истории с книгой вчерашней - прочитать стоит, применить только то, что считаешь нужным и подходящим в твоей ситуации. Не все, что написано полезно и это не мануал :) Кстати, кто-то встречал понятие Команда PO (research/descovery team)?

Выделена 100% на конкретный продукт, все Scrum-команды, поставляет информацию PO, чтобы тот принимал решения лучше

Ну с учетом того что продакта от проджекта отличают не все...

продукт должен быть задумчивым

по мне он единственный должен похож быть на художника

если разработчики похожи на художников - то это ничего хорошего не принесет

https://vc.ru/hr/46048-glavnaya-oshibka-agile-transformatorov-pochemu-product-manager-i-product-owner-eto-ne-odin-chelovek

Забавная статья. Менеджер Продукта - это человек, который им управляет. Продукт управляется через Бэклог Продукта. Бэклог Продукта принадлежит Владельцу Продукта. Как это сочетать?

Как-то не очень похоже на Скрам. А вопрос с "шашечки или ехать" тут вообще странно выглядит, потому что на Скраме точно можно ехать, а на приведенной в статье модели - не факт.

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

ну в этой статье причинно-следственные связи не прослеживаются.

если разработчики похожи на художников - то это ничего хорошего не принесет

Почему?

https://vc.ru/hr/46048-glavnaya-oshibka-agile-transformatorov-pochemu-product-manager-i-product-owner-eto-ne-odin-chelovek

прочитал до конца :D это прям днище агиль трансформации и не понимания роли PO.

прям вижу такую тарнсформацию - PO консультируется с кучей PM про то как оформить беклог :D получается PO это просто менеджер беклога. Хотя беклог это просто средство визуализации приоритетов :D

нигде а агиле не написано, что РО не может ни с кем консультироваться.

Менеджер по клинингу бэклога

Я бы даже сказал, что он должен это делать

нигде а агиле не написано, что РО не может ни с кем консультироваться.

когда он консультируется с другими менеджерами появляется коммитет по решению приоритетов так или иначе :D

а когда он консультируется со стейкхолдерами?

а когда он консультируется со стейкхолдерами?

он должен иметь возможность послать стейкхолдеров нахрен

а если он имеет возможность послать нахер менеджеров? Никто ж не забирал у него такое право

а если он имеет возможность послать нахер менеджеров? Никто ж не забирал у него такое право

чоооо, никто не может послать менеджеров :D так как они делают свою работу.

а стейкхолдеры в носу ковыряют...

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

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

эта статья вообще не про это :D там черным по белому говорится что есть Product Managers они работают с клиентами и выясняют потребности, а есть PO который пишет стори и оформляет беклог и работает с командой.

И это как раз таки подразумевает что PO нихрена тут не главный :D

мы видимо читали разные статьи )

Почему?

имхо - команде нужно поставить довольно близкие и понятные цели что бы достичь те цели которые видит PM там нет времени художничать это работа PM выяснить что сейчас важно упор сделать например на быстродействие что бы продукт зашел а команад должна понять что PM провел работу и это дейтсвительно важно

ну если PM не уверен - можно попробвать несколько прототипов но это все должно быть конечно прозрачно

после этого все должны идти в одном направлении

а не думать и сомневаться

И это как раз таки подразумевает что PO нихрена тут не главный :D

@DasBotrek Я тоже это именно так прочитал. "Вывод следующий: необходима прослойка. Это место и может занять Product Owner." "Ему может быть делегировано «представительство продукта» перед разработчиками и многими стейкхолдерами, а также все активности, описанные в руководстве по Скраму, в то время как продакт-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта."

конечно не главный

чего ему быть главным

прапорщик же

имхо - команде нужно поставить довольно близкие и понятные цели что бы достичь те цели которые видит PM там нет времени художничать это работа PM выяснить что сейчас важно упор сделать например на быстродействие что бы продукт зашел а команад должна понять что PM провел работу и это дейтсвительно важно

А ничего, что это люди умственного труда?

Да везде думать надо, не только в разработке по

Дачи строить думать что не надо?

И я не говорю про микро менеджмент

Нужны близкие и чёткие цели, что бы все осознали куда надо идти

Например не сделать продукт лучше, а сделать мобильную версию, или удобную форму заказа, или переписать на такие то технологии

прочитал до конца :D это прям днище агиль трансформации и не понимания роли PO.

Насколько я понял автора, он как раз и хотел сказать про непонимание кто такой PO и зачем :)

Насколько я понял автора, он как раз и хотел сказать про непонимание кто такой PO и зачем :)

так афтор и сам не понимает :D

PO должен и с клиентами общатся и с командой. Его основная задача повысить ценность того что DT создает. Значит приоритетно для него общение с заказчиком т.е выполнение задач которы в этой статье делают PM :D

https://medium.com/the-liberators/sources-of-agile-inspiration-spotify-lego-and-kramp-958cdfbca9a6

Burndown Bingo - это пять! 👍

о, нормальный пятничный спам пошел

https://bosfera.ru/bo/filosofiya-safe-vmesto-klassicheskoy-waterfall?fbclid=IwAR3-Y1jTurcG3R9U5Hv2fUUEjQBttfjv-VtXa7-z5YraLLv3-2t84r6bbDQ

🤦‍♂️

кто такой DT ?

кто такой DT ?

Development Team, не?

Development Team, не?

development

development

Спасибо, исправил =)

PO должен и с клиентами общатся и с командой. Его основная задача повысить ценность того что DT создает. Значит приоритетно для него общение с заказчиком т.е выполнение задач которы в этой статье делают PM :D

я может читать не умею - но там именно это и написано

но не про общение конечно

так PO это обобщенная роль лол

приходится заниматся всем :D

и с клиентами и с командой

так статья как раз и говорится что это не очень вариант

один более на частные проблемы - другой более на общие

это вариант в ином случае - PO является коммитетом :D

я немного пугаюсь когда в меня терминами кидаются

комитетом по чему ?

по этике ?

потому что PM становятся коммитетом по выявлению хотелок клиента и создают ложное видение.

которое с реальностью не факт что соотносится :D каждый человек все через призму своего восприятия проводит. в scrum эта призма только PO

ну если это внутренняя разработка - то возможно хотелки клиента это важно в заказной это не так важно так как все клиенты хотят разное

в любой разработке хотелки клиента это важно :D

и неплохобы иметь человека котором пофиг на клиентов - но есть понимаание куда двигать продукт

совсем нет

надо просто уметь продавать

если писать код ради написания кода - то всё в мире не важно

а если писать код для программ которые кому-то нужны и их кто-то может купить - то где-то появляется смысл и важность

все клиент всегда буду хотеть разное - не обязательно это делать

SAP например настрать на хотелки клиентов

это тебе так кажется (про SAP)