Comments 16
product owner, хотя последнее — это всего лишь определенная роль в Scrum, которую может выполнять любой член команды.
вы путаете со scrum master'ом
Не соглашусь, хоть и понимаю, почему product manager и product owner путают. Product owner существует только в методологии Scrum. Эта роль отвечает только за конкретный бэклог определенного продукта. Задача product owner в коммуникации со scum командой: объяснение приоритетов, приоритезация бэклога, видение продукта. На Хабре есть статья Product Owner vs Product Manager или Product Owner/Product Manager / Хабр (habr.com)
Вопрос, вероятно, к формулировке "роль в Scrum, которую может выполнять любой член команды". Так как роль product owner выделенная и не может быть делегирована любому члены команды. Иначе, по классике, у вас уже не скрам, а совсем что-то другое :)
Да это просто классика - путать product manager и product owner. Особенно в смешанных командах работающих над комплексными продуктами.
Еще есть ощущение, что у Product Manager в текущей интерпретации нет фокуса на качественную проработку требований. Нарисовал cjm, согласовал дизайн, описал user story (в лучшем случае) и понеслась.
А как с этими артефактами потом разработчику работать, что конкретно надо делать, на сколько решение оптимально, как уменьшить ресурсы, как декомпозировать? Пусть тимлид придумает.
В общем случае продукт-менеджер должен максимально детально описывать функцию. Общее описание, роли, как работает в режиме конфигурации (если есть), как работает в режиме исполнения, альтернативный сценарий, и действия при обновлении. Я это упомянул, что от этого зависит как раз взаимоотношение в команде.
Но редко бывает, что и общего описания достаточно. При опытной, долго работающей инженерной команде возможно передавать общие описания.
если он детально описывает функцию, то получается, что он отнимает у команды возможность проектирования
нафига? лучшее, что он может сделать — это принести с рынка сегмент клиентов, описание и подтверждение их контекста и проблемы, расчеты, сколько компания может заработать, если решит проблему
команда из 3-5 голов с зачастую высшим образованием сама прекрасно спроектирует и функциональное и техническое решение, надо ей надо только помогать
иначе надо называть себя не менеджер продукта, а проектировщик продукта
Детальное описание, конечно делается с точки зрения сценария. Бывает так, что инженерная команда работает 10 лет и сама знает сценарии.
Прямой сценарий, альтернативный сценарий, что делать при отказе, что делать при обновлении.
Представим, что мы делаем инсталлятор для приложения Калькулятор. Ведь даже для него может быть ручная установка, автоматизированное развёртывание, сохранение настроек и истории операций при обновлении, развёртывание на одного пользователя, на всех пользователей машины, на всех пользователей терминального сервера.
Как руководитель product-функции (чтобы не спорить о названиях) согласен, что многое новое это хорошо забытое старое, при этом извращенно-упрощенное. Юнит-экономика - отличный тому пример. Но создается ощущение, что автор понадергал самых что ни на есть worst practices и выдает их за текущее состояние дел.
Есть вполне хорошие и зарекомендовавшие себя методы, а то, что их не все используют, а кто использует - частенько делает это криво, ну так в любой индустрии есть эта проблема - и что ж?
Вы спросИте CEO про функцию дизайна, например - как он ее видит стратегически? Если его ответ упрется в графику и отдельно выделенный отдел для этого - хреновый CEO и продакт-функция будет именно такая как вы описывали - тоже лажовая. А если для него дизайн это процесс, сквозняком проходящий через все остальные функции, формирующий конкурентные преимущества и затрагивающий все точки CJM (т.е. это UX - в широком смысле, а не графика), то годный CEO, не зря хлеб ест.
Качество формируется запросом. Нет второго - не будет и первого.
В статье я постарался сделать упор на то, что не нужно строить новые теории и конструкции, а главное не преподносить это как особую культуру производства. Все зарекомендовавшие методы, действительно существуют давно. Тот же lean берет начало где-то в 50-х годах. А то, что написано это в стиле "скандалы, интриги, расследования", ну кто бы читал статью из одного предложения.
Я рад, что тема вызывает и возражения. Что не вызывает у меня сомнения, это то, что подавляющее большинство продукт-менеджеров как раз делают ежедневную рутинную работу эффективно. Без ярких теорий.
Понимаю.
К сожалению, большинство (99%) продакт-менеджеров на постсоветском пространстве это "менеджеры по запилу фич". Я понимаю, что этот посыл идёт от руководства, имеющего технический бэкграунд (условный основатель/CEO, который всю жизнь был разработчиком), но это *в корне* неправильно. Продакт - это маркетинговая функция, а не техническая.
Из этой же ошибки следует подход "тестирования гипотез". Это вообще лютый ад как с точки зрения логики, так и операционного устройства бизнеса (= затрат).
Можно ещё добавить про касдев, который по сути во многом — маркетинговое исследование.
Про ярмарку тщеславия — интересно, что если посмотреть на западные конференции, там среди докладчиков сплошь высшее руководство компаний, в то время как у нас — рядовые продакты, хоть может и сеньоры.
В продукт-менеджменте много шумихи, теории ради теории и иногда ярмарок тщеславия