В Ozon есть руководители направлений и подчиняющиеся им владельцы продуктов, которые управляют беклогом и разработкой в рамках своей вертикали (будь то логистика, взаимодействие с клиентом, ценообразование и проч.) и продакт-менеджеры, которые формируют пул требований и задач, необходимые реализовать для роста бизнеса, продуктовых метрик и NPS пользователя.
По сути, владельцы продуктов, у которых KPI - количество реализованных продуктов и фич, способствующих росту ключевых метрик, и продакт-менеджеры, у которых KPI - количество спроектированных и доведенных до реализации продуктов и фич, способствующих росту бизнеса и продуктовых метрики, стараются пересечься в интересах.
Первые - сделать меньше в рамках одной задачи, но больше в количестве. Вторые - сделать больше и лучше: полноценные сервисы, а не MVP, на которых можно растить выручку и маржу компании - ключевые метрики роста бизнеса.
Порядок формирования задач на разработку
+ формулировка бизнес-требований происходит в первую очередь. Бизнес-руководители определяют, на чем и как будут зарабатываться деньги
+ продакт-менеджеры определяют CJM&Job Stories в продукте, посредством которых могут быть достигнуты бизнес-задачи
+ совместно с системными аналитиками продукта и предполагаемых к взаимодействию систем
+ собирается большая общая встреча со всеми руководителями и системными аналитиками задействованных систем. Все стараются прикинуть свое участие, с приоритетом на закрытие продуктовой потребности и минимизации своих трудозатрат. Задачи декомпозируются горизонтально, в основном по бизнес-процессам, в том числе и по части, в каком месте правильнее было бы концептуально сделать ту или иную доработку.
+ после нескольких встреч/итераций/обсуждений формируются решения и пул интеграций между вертикалями, формируется топик и группа задач и тикетов, планирование задач в спринтах
+ все коммуникации по фиче - в общем чате и периодических встречах
Особенности распределения продукта между продактами
+ всегда есть продакт-лид фичи, который отвечает за концентуальную, техническую и организационную часть продукта
+ распределение происходит концептуальное: исходя из реального предназначения той или иной вертикали. Соответственно, доработка под фичу может быть разной по объему
+ задачи ранжируются от первостепенной (без чего не будет ничего работать) до самой некритичной (без которой на самом деле можно запустить фичу и уже заработать денег). Примерно в таком порядке и реализуются. Как правило, самые критичные берутся и делаются в первую очередь.
+ при откладывании в приоритете задач одной из вертикалей ищется решение по изменению пользовательского флоу, взаимодействия систем. Но чаще всего приходится ждать, когда задача доедет до реализации, сроки корректируются.
+ на интеграции закладываются отдельные спринты разработки и тестирования
