Перейти к основному содержимому

О разделе "Продуктовые роли"

Product Owner (PO) и Product Manager (PM) стоят на стыке бизнеса и разработки: они решают, что строить, в каком порядке и когда результат можно считать принятым. В Scrum PO описан формально; в продуктовых компаниях PM часто шире по зоне (рынок, roadmap, метрики). Путаница PO, PM, бизнес-аналитика (BA) и тимлида — одна из частых причин неверных приоритетов, scope creep и конфликтов на приёмке.

Раздел написан для новичка в IT-проекте: после прочтения вы сможете назвать владельца backlog, понять разницу ролей в продукте, аутсорсе и госсекторе и знать, куда эскалировать запрос вне процесса.

Для кого

Разработчику и тестировщику — кто принимает фичу и откуда брать приоритет.

BA и SA — граница с PO/PM, RACI на требования.

Руководителю и PM — модели в продукте, аутсорсе, аутстаффе и госпроектах.


Что вы узнаете

ТемаРезультат
PO в ScrumВладение backlog, приёмка, один accountable
PMRoadmap, рынок, метрики — и связь с PO
BAТребования и AC без подмены приоритета
Тимлид и архитекторПоставка и техника — не вместо PO
Модели организацииПродукт, аутсорс, госсектор, внутренний IT
RACIКто A на приоритет и приёмку
КонфликтыDeputy PO, CR, обход PO через чат

Как читать раздел

ШагМатериалСодержание
1PO и PM — роли и границыScrum, PM, BA, тимлид, RACI, примеры
2ИтогиРезюме и FAQ по ролям
3Чек-листСамопроверка владельца приоритетов

Перед шагом 1 полезно бегло пройти роли Scrum. Если вы в заказной разработке — параллельно договор глазами разработчика.


Соседние разделы

ВопросКуда идти
Как оформить изменение scopeУправление изменениями
Кто пишет ТЗ и BPMNАналитика
Спринт, review, цель спринтаScrum
Очередь заявок от бизнесаITSM
Метрики и воронкиПродуктовая аналитика
Старт проекта и RACIНачало работы на проекте

Три контекста — три картины PO

Продуктовая компания. PO/PM смотрит на retention, выручку, конкурентов. Backlog меняется по данным, не только по письму от директора.

Аутсорс / заказная разработка. PO со стороны заказчика принимает результат; PM исполнителя следит за договором и change request. Приёмка без PO заказчика — риск спора после оплаты.

Госсектор и регламент. Приоритет может идти через комиссию и ТЗ; PO-куратор всё равно нужен как именованная точка для команды, иначе правки экспертизы размножаются бесконечно.


Типичные симптомы путаницы ролей

  • В спринт попадает то, что громче попросили, а не то, что в backlog сверху.
  • BA спорит с разработчиком о приоритете — хотя это зона PO.
  • Тимлид отменяет фичи без согласования с бизнесом.
  • На демо присутствует PM исполнителя, а заказчик видит результат впервые в prod.
  • Каждый стейкхолдер считает себя PO.

Если узнали проект — начните с главы 1 и чек-листа.


Термины раздела

ТерминКратко
POВладелец backlog и приёмки в Scrum
PMRoadmap, рынок, метрики продукта
BAТребования, процессы, AC
Deputy POЗаместитель с делегированием
RACIКто утверждает приоритет (один A)
StakeholderЗаинтересованная сторона, не PO

Вопросы, на которые ответит раздел

  1. Кто может сказать "эту фичу не делаем"?
  2. Кто принимает работу на Sprint Review?
  3. Чем PO заказчика отличается от PM исполнителя в аутсорсе?
  4. Может ли тимлид отменить фичу из backlog?
  5. Куда девать срочную просьбу из чата?
  6. Нужен ли PO в Kanban без Scrum?
  7. Как BA участвует, не подменяя приоритет?

Ответы — в главе 1; проверка — 999.