Product Owner и Product Manager
Кто решает, что делать дальше
В IT-проекте постоянно возникает вопрос: что строить в первую очередь, кто принимает результат и как согласовать бизнес с командой разработки. За это отвечают продуктовые роли — прежде всего Product Owner (PO) и Product Manager (PM). Их часто путают с бизнес-аналитиком (BA) и тимлидом; из-за путаницы приоритеты съезжают, сроки горят, а разработчик узнаёт о новой фиче из чата в пятницу вечером.
Эта глава — карта ролей для новичка: кто за что отвечает, как роли выглядят в продуктовой компании, в аутсорсе и в госсекторе, и что делать при типичных конфликтах. Смежные темы — Scrum, аналитика, управление изменениями.
PO — владелец приоритета и приёмки ценности. PM — видение, рынок и roadmap (часто шире PO). BA — ясность требований и процессов. Тимлид — как команда поставляет качественно и предсказуемо.
Product Owner в Scrum
Product Owner (PO) — формальная роль из Scrum Guide. PO владеет Product Backlog — упорядоченным списком всего, что может понадобиться продукту, и несёт ответственность за максимизацию ценности работы команды.
Обязанности PO
- приоритизирует backlog по ценности для бизнеса и пользователей, а не по громкости голоса стейкхолдера;
- уточняет требования вместе с командой — отвечает на вопросы на refinement, а не исчезает до демо;
- принимает инкремент на Sprint Review — решает, достигнута ли цель спринта;
- делегирует детализацию, но не снимает с себя ответственность за приоритет.
В Scrum PO — один человек на продукт, не комитет. Если решения принимает совет из пяти менеджеров, Scrum-формально PO нет — это источник хронических конфликтов. Подробнее о событиях и артефактах — роли Scrum, спринт.
Что PO не обязан делать сам
| Задача | Кто обычно помогает |
|---|---|
| BPMN, детальные use cases | BA |
| Оценка трудозатрат, техриски | SA, разработчики |
| Организация процесса Scrum | Scrum Master |
| Код-ревью, CI, найм | Тимлид |
PO отвечает за что и зачем для бизнеса; команда — за как реализовать в рамках DoD.
Deputy PO и недоступный владелец
На практике PO бывает в отпуске, на конференции или совмещает три продукта. Рабочие варианты:
- Deputy PO — человек с письменным делегированием на период;
- фиксированные слоты на вопросы (например, 30 минут ежедневно);
- заранее согласованные границы автономии (что deputy может менять в приоритете без эскалации).
Без этого команда либо стоит, либо угадывает приоритеты — оба сценария дорогие.
Product Manager в продуктовой компании
Product Manager (PM) в индустрии часто шире PO по зоне ответственности. В стартапе один человек может совмещать PM и PO. В корпорации PM координирует линейку продуктов или направление, а PO ведёт backlog конкретного продукта или сквода.
| Зона | Обычно у PM |
|---|---|
| Видение продукта и roadmap на квартал–год | да |
| Исследование рынка, конкурентов, сегментов | да |
| Метрики продукта (North Star, retention, LTV) | да |
| Приоритет backlog ближайших итераций | да (как у PO) |
| Детальные acceptance criteria, BPMN | частично, с BA |
| Технический дизайн и стек | нет — SA / техлид |
Пример — продуктовая fintech-компания
PM видит, что конверсия в первую оплату падает на мобильных. Он формулирует гипотезу, согласует с аналитикой воронку, ставит эпик в backlog. PO на ближайшие две недели вытаскивает конкретные user stories (упростить KYC, сократить шаги оплаты). BA описывает сценарии и AC. Тимлид следит, чтобы команда не взяла в спринт лишнего. Результат проверяют по метрике, а не по ощущению "стало удобнее".
Roadmap и backlog — разные уровни
- Roadmap — направления на месяцы (темы, эпики, бизнес-цели).
- Backlog — конкретные задачи на ближайшие спринты или поток Kanban.
PM чаще владеет roadmap; PO/PM вместе держат backlog в актуальном порядке. Разработчику важно понимать оба слоя: из roadmap прилетает "интеграция с госреестром", в backlog — "API-метод проверки ИНН с таймаутом 3 с".
Бизнес-аналитик (BA)
Бизнес-аналитик (BA) переводит язык бизнеса в ясные требования, процессы и критерии приёмки. BA не подменяет PO в приоритетах, если на это нет явного делегирования.
| PO / PM | BA (бизнес-аналитик) | |
|---|---|---|
| Фокус | Что максимально ценно сейчас | Как процесс и система должны работать |
| Артефакты | Roadmap, приоритет backlog | Use cases, BPMN, ТЗ, AC |
| Типичный конфликт | "Нужна фича X быстрее" | "Процесс требует согласования Y" |
| Приёмка | Утверждает ценность инкремента | Проверяет полноту и непротиворечивость требований |
Рабочая схема: PM/PO задаёт приоритет, BA обеспечивает ясность требований и приёмки (взаимодействие аналитика). Если BA пишет ТЗ на 200 страниц без ранжирования PO — получается backlog-свалка: всё "важно", ничего не делается.
В проектах для госзаказчика BA часто ведёт регламентную документацию (ТЗ по ГОСТ, протоколы согласований). PO со стороны заказчика может быть куратором из ведомства. Приоритет всё равно должен быть именован — иначе разработка тонет в бесконечных правках "по замечаниям экспертизы". См. техническое письмо.
Системный аналитик (SA) — граница с BA
SA отвечает за техническую проработку: интеграции, NFR, контракты API, схемы данных. PO спрашивает "нужна ли интеграция с ЕСИА в этом квартале"; SA отвечает "какие протоколы, лимиты, отказоустойчивость". Путаница BA/SA/PO — частая причина, что требования "готовы", а разработка не может начать.
Тимлид и архитектор
- Тимлид (team lead) — как команда поставляет (процесс, качество, люди, культура кода).
- PO / PM — что поставлять и в каком порядке.
- Архитектор — в рамках каких технических ограничений и NFR.
Если приоритет backlog de facto решает техлид ("мы не будем делать эту фичу, она технически неудобна"), а PO только подписывает — процесс нужно пересмотреть. Техлид консультирует по feasibility и рискам; отказывать от бизнес-целей без согласования с PO нельзя. Компромисс фиксируют в backlog, spike или ADR.
| Роль | Вопрос, на который отвечает |
|---|---|
| PO/PM | Стоит ли это делать сейчас? |
| BA | Что именно должно получиться? |
| Тимлид | Как команда это сделает качественно? |
| Архитектор | В каких рамках система останется жизнеспособной? |
Кто владеет приоритетом в разных моделях
| Модель организации | Кто играет роль PO | Особенности |
|---|---|---|
| Продуктовая компания | Внутренний PM/PO | Метрики продукта, A/B, быстрые итерации |
| Заказная разработка (аутсорс) | Заказчик + PM исполнителя | Договор, CR при изменении scope |
| Аутстафф | PO клиента | Вы выполняете задачи в его процессе |
| Госсектор / регламент | Куратор + комиссия | Формальные ТЗ, протоколы, длинные согласования |
| Внутренний IT департамент | Владелец услуги из бизнеса | Очередь через ITSM |
Разработчику важно знать, чьё согласие закрывает приёмку — иначе "сдали" фичу одному стейкхолдеру, а второй блокирует релиз.
Пример — аутсорс для ритейла
Заказчик (ритейл) хочет личный кабинет поставщика. PO заказчика — директор по закупкам: он ранжирует "отчёты" выше "чата". PM исполнителя следит за сроками по договору, оформляет change request, если заказчик просит CRM в том же релизе. BA исполнителя пишет AC и сценарии; приёмка на демо — с PO заказчика, не только с PM исполнителя.
Пример — внутренний продукт банка
PM владеет roadmap мобильного банка. PO сквода "платежи" ведёт backlog переводов. Тимлид ограничивает WIP. Любой релиз в prod проходит через CAB — это не отменяет приоритет PO, но накладывает окна и чек-листы.
RACI — приоритет фичи в backlog
RACI помогает не спорить "кто должен был сказать да". Для одного действия A (Accountable) — ровно один человек.
| Действие | R | A | C | I |
|---|---|---|---|---|
| Порядок backlog | PO/PM | PO/PM | BA, техлид | Команда |
| Детализация AC | BA | PO/PM | SA, dev | Команда |
| Оценка feasibility | SA, dev | Техлид | PO | PM |
| Реализация | Dev | Техлид | BA | PO |
| Приёмка инкремента | PO | PO | BA, QA | PM, стейкхолдеры |
| Change request на новый scope | BA/PM | PO/заказчик | SA, юрист | Команда |
R — исполняет, A — утверждает (один на действие), C — консультирует, I — информируется.
В колонке A стоят двое "на всякий случай". В момент конфликта оба отказываются быть плохими — решение не принимается. У PO/PM должен быть один accountable за приоритет.
Стейкхолдеры и единая точка приоритета
Стейкхолдер — любой, кого затрагивает продукт: продажи, поддержка, юристы, безопасность, госорган. У всех есть пожелания. PO собирает input, но не обязан выполнить всё сразу.
Признаки здорового процесса:
- запросы попадают в один backlog или трекер, а не в личные чаты;
- стейкхолдер знает, когда PO пересмотрит приоритет (refinement, review);
- жёсткие дедлайны (регулятор, договор) явно помечены и согласованы с capacity.
Если стейкхолдер обходит PO и давит на разработчика напрямую — это эскалация к спонсору проекта и пересмотр RACI. Разработчику уместно ответить: "Зафиксируйте в тикете, PO расставит приоритет на refinement".
Sprint Review и приёмка
На Sprint Review команда показывает инкремент — работающий результат, а не слайды. PO (или заказчик в аутсорсе) решает:
- инкремент принят — цель спринта достигнута;
- не принят — что доработать, остаётся ли цель спринта актуальной;
- изменён приоритет — новые находки уходят в backlog, не в "тихое дописывание" текущего спринта.
"Тестировщик сказал ок" не равно приёмка PO. QA проверяет соответствие AC и качество; PO проверяет ценность и готовность отдавать пользователям. Подробнее — тестирование и приёмка.
Типичные конфликты и что делать
| Ситуация | Почему больно | Решение |
|---|---|---|
| PO недоступен в спринте | Команда блокируется на вопросах | Deputy PO, слоты, письменное делегирование |
| PM меняет scope без оформления | Scope creep, срыв сроков | Change request, trade-off в backlog |
| BA пишет ТЗ без приоритета | Всё срочно, ничего не делается | PO ранжирует; ТЗ дробится на эпики |
| Stakeholder обходит PO | Два источника правды | Эскалация, единая точка приоритета |
| Тимлид = de facto PO | Техника диктует бизнес | RACI, эскалация к спонсору |
| Два PO на один продукт | Комитет, медленные решения | Один A, остальные C |
| Аутсорс: "PM исполнителя принял" | Заказчик не согласен | Приёмка по договору с заказчиком |
Продуктовая аналитика и гипотезы
Продуктовый аналитик смотрит на поведение в живом продукте — воронки, A/B-тесты, события (продуктовая аналитика). PM связывает метрики с гипотезами в backlog: не "больше кликов", а "рост конверсии в оплату на 2 п.п. за квартал".
Цикл зрелой продуктовой команды:
- Метрика просела или есть возможность.
- PM формулирует гипотезу и критерий успеха.
- PO ставит эксперимент в backlog с приоритетом.
- Команда поставляет измеримый инкремент.
- По данным — масштабируем, откатываем или pivot.
Без шага 5 backlog превращается в список "фич, которые когда-то просили".
Связь с изменениями scope
Любая просьба "сделайте ещё вот это" без пересмотра приоритета — кандидат в scope creep. PO обязан либо снять что-то из backlog, либо инициировать change request с влиянием на срок и бюджет. Молчаливое согласие разработчика ("ладно, быстренько") разрушает доверие к приоритетам.
В Agile изменения ожидаемы — но прозрачны. См. управление изменениями.
PO на событиях Scrum
| Событие | Участие PO |
|---|---|
| Sprint Planning | Уточняет цель спринта, согласует scope с capacity |
| Daily Scrum | Не обязателен; доступен для блокеров по ценности |
| Refinement | Приоритет уточнения, ответы "зачем бизнесу" |
| Sprint Review | Принимает инкремент, собирает feedback |
| Retrospective | Консультант по продуктовым болям, не единственный голос |
Если PO не ходит на Planning и Review — команда строит не то или не может сдать. Scrum Master помогает договориться о присутствии, не подменяет PO.
Discovery и delivery
Discovery — исследование проблемы (интервью, прототип, spike). Delivery — поставка в prod. PM/PO держат баланс: вечный discovery без релизов — теория; вечный delivery без discovery — фичи никому не нужны.
| Фаза | Артефакты | Роли |
|---|---|---|
| Discovery | Гипотеза, прототип, результаты интервью | PM, BA, дизайн |
| Refinement | User stories, AC | PO, BA, команда |
| Delivery | Инкремент, метрики | Команда, PO на Review |
В аутсорсе discovery часто оплачивается отдельно (фаза анализа в договоре). В госпроекте — отдельный этап ТЗ до разработки.
Карта стейкхолдеров
Полезный артефакт PM — таблица кто влияет / кто решает / кто информируется:
| Стейкхолдер | Интерес | Связь с PO |
|---|---|---|
| Спонсор | Бюджет, срок | Эскалация при конфликте приоритетов |
| Продажи | Срочные обещания клиентам | Input в backlog, не прямой приоритет |
| Юристы / ИБ | Compliance | Must-have с дедлайном регулятора |
| Поддержка | Боли пользователей | Источник багов и улучшений |
| Разработка | Feasibility | Консультант (C в RACI) |
PO фильтрует input: не всё попадает в топ backlog. Обещание продаж без PO — риск scope creep.
Пример — госпортал услуг
Куратор (PO со стороны ведомства) получает правки от экспертизы ТЗ. BA подрядчика оформляет дельту. PM подрядчика считает влияние на этап и оформляет CR к контракту. Тимлид не соглашается на "добавить модуль" без подписанного CR — иначе штрафы и срыв приёмки этапа. Разработчик работает по приоритету куратора после оформления, не по звонку из министерства в обход PM.
Пример — аутстафф в продуктовую команду
Вы разработчик на стороне аутстафф-вендора. PO — у клиента. Его backlog в Jira клиента; вы берёте задачи сверху. Ваш менеджер у вендора не PO: он решает кадры и контракт с клиентом, не приоритет фич. Вопросы "можно ли отложить" — к PO клиента. Приёмка — на демо клиента, не у вашего PM.
PM и PO в карьере
| Роль | Типичный путь входа | Навыки |
|---|---|---|
| BA → PO | Аналитика домена, затем приоритет | Фасилитация, отказ стейкхолдерам |
| Разработчик → PO | Глубокое знание продукта | Риск: подмена бизнес-ценности техникой |
| Маркетинг → PM | Рынок, позиционирование | Метрики, интервью пользователей |
| Project manager → PO | Нужно учить продуктовое мышление | Не путать срок проекта с ценностью |
Новичку достаточно различать роли на проекте, не выбирать карьеру сразу. См. карьера в IT.
Refinement — рабочая встреча PO и команды
Цель refinement — сделать верх backlog готовым к спринту (DoR):
- PO объясняет ценность и порядок.
- BA уточняет AC и граничные случаи.
- Команда оценивает и поднимает риски.
- PO решает, что достаточно ясно для Planning.
Без PO refinement превращается в технический семинар без приоритета.
Делегирование без потери accountability
PO может делегировать:
- написание user stories — BA;
- демо части инкремента — тимлид;
- приоритет внутри одного эпика — deputy PO.
PO не делегирует без письма:
- финальную приёмку релиза;
- отказ от обязательного регуляторного требования;
- подпись CR в fixed price (это заказчик).
Метрики здоровья продуктовых ролей
| Метрика | Здорово | Тревога |
|---|---|---|
| % спринтов с принятой целью | Стабильно высокий | Постоянный "почти" |
| Время ответа PO на блокер | Часы, не недели | Команда угадывает |
| Доля работ вне backlog | Низкая | Много "срочно из чата" |
| Конфликты приоритет BA/PO | Редкие, с эскалацией | Каждый спринт |
Методы приоритизации backlog
PO не обязан использовать сложную математику. Распространённые подходы:
| Метод | Суть | Когда уместен |
|---|---|---|
| Value vs Effort | Ценность делить на трудозатраты | Стартап, мало данных |
| WSJF | Weighted Shortest Job First (SAFe) | Портфель, много эпиков |
| MoSCoW | Must / Should / Could / Won't | Фиксированный релиз, госэтап |
| Cost of Delay | Цена задержки фичи | Очередь с зависимостями |
| Простой стек ранжирования | PO упорядочивает вручную с обоснованием | Малые команды |
Важно не название метода, а прозрачность: стейкхолдер понимает, почему его фича третья, а не первая. BA помогает оценить effort; решение о порядке — PO.
User Story Mapping и roadmap
User story mapping (карта историй) — визуализация пути пользователя слева направо, задачи сверху вниз по приоритету. PM/PO используют на discovery-сессиях с BA и дизайном. Результат — релизные срезы (MVP, v2), а не плоский backlog из 200 карточек.
Связь с roadmap:
- roadmap = темы по кварталам;
- story map = как пользователь проходит сценарий;
- backlog = готовые к разработке истории на ближайшие итерации.
Приёмка в fixed price по этапам
В заказной разработке приёмка часто по акту этапа, не по каждому спринту:
| Этап | Кто принимает | Артефакт |
|---|---|---|
| Анализ | Заказчик + PO | ТЗ, протокол согласования |
| Разработка модуля | PO заказчика | Демо, чек-лист AC |
| Ввод в эксплуатацию | Комиссия | Протокол, CR закрыты |
PM исполнителя готовит приёмку (демо, документы); подписывает заказчик. Разработчик на демо объясняет техническую часть; спор "входит ли в scope" — к CR и договору.
PO и технический spike
Когда команда не может оценить фичу, PO выделяет spike (исследование на 1–3 дня) с вопросом и критерием завершения. После spike PO решает: берём в backlog, режем scope или откладываем. Spike не превращается в бесконечный прототип без решения — иначе scope creep.
SA ведёт технический spike; BA — spike по процессу и правилам.
Внутренний IT — владелец услуги
В корпоративном IT владелец услуги (service owner) играет роль PO для внутреннего продукта (HR-портал, CRM отдела). Заявки идут через ITSM. Без именованного владельца очередь определяется громкостью департаментов — классический конфликт с разработкой.
Ошибки новичка при работе с PO
| Ошибка | Как правильно |
|---|---|
| Согласился в чате на "быструю доработку" | "Оформите в тикет, PO расставит приоритет" |
| Ждёт идеального ТЗ перед вопросом | Уточнять на refinement с BA и PO |
| Путает желание тимлида с приоритетом PO | Эскалация, RACI |
| На аутсорсе сдал PM исполнителя | Уточнить представителя заказчика в договоре |
| Спорит с BA о "важнее" | Направить к PO |
Словарь продуктовых ролей (кратко)
| Термин | Определение |
|---|---|
| Product Owner | Роль Scrum: владелец backlog, максимизация ценности, приёмка |
| Product Manager | Видение продукта, roadmap, рынок, метрики (часто шире PO) |
| Project manager | Сроки и бюджет проекта (не путать с product PM) |
| BA | Бизнес-аналитик: требования, процессы, AC |
| SA | Системный аналитик: интеграции, NFR, техпроработка |
| Спонсор | Источник бюджета, эскалация при тупике |
| Stakeholder | Заинтересованная сторона |
| Backlog | Упорядоченный список работ на продукт |
| Инкремент | Работающий результат итерации |
| Deputy PO | Заместитель PO с делегированием |
Сценарий дня — разработчик в продуктовой команде
09:00 Daily — блокер: неясно, нужна ли оплата в валюте в MVP. Тимлид направляет к PO на refinement в 11:00, не угадывать.
11:00 Refinement — PO: "валюта в v2, сейчас только рубли". BA обновляет AC. Задача остаётся в спринте.
15:00 Сообщение от продаж: "клиент X ждёт API завтра". Разработчик: "Создайте тикет, PO в приоритет". PO ставит Expedite, снимает менее срочную задачу — видно на доске.
17:00 Review — PO принимает инкремент по цели спринта; одна фича отложена — не баг QA, а изменение приоритета.
Сценарий дня — аутсорс
Утро — PM исполнителя: статус по CR-012 (ожидает подпись заказчика). Разработка не начинает CR без статуса "принято".
Демо — присутствует представитель заказчика; протокол приёмки в Confluence заказчика.
Вечер — сообщение в Telegram от менеджера заказчика "добавьте поле". Ответ: "Передайте куратору на CR или тикет в наш портал".
Чек-лист для разработчика в первый месяц
- Знаю имя PO/PM и как к нему попасть с вопросом по приоритету.
- Понимаю, кто принимает фичу на review (особенно в аутсорсе).
- Не начинаю работу по устной просьбе без тикета и приоритета.
- Различаю задачи BA (уточнить AC) и PO (можно ли отложить).
- Знаю, куда эскалировать CR, если scope растёт.
Итоги и чек-лист
Итоги раздела · Чек-лист самопроверки