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

Продуктовые роли — чек-лист самопроверки

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Отметьте пункты, которые выполняются устойчиво, а не "один раз на старте". Подробности — глава 1, итоги и FAQ.

Владелец backlog и приоритет​

  • Есть именованный владелец backlog с правом отказывать от фич.
  • На каждое действие по приоритету в RACI ровно один A (Accountable).
  • Backlog упорядочен — сверху то, что делаем следующим, а не "всё P1".
  • Запросы стейкхолдеров попадают в один трекер, не только в чаты.
  • При отсутствии PO назначен Deputy PO с письменным делегированием.
  • Refinement проходит с участием PO или deputy — не "BA рассказал, PO не был".

Границы PO, PM и BA​

  • BA/SA не подменяют PO в приоритетах без явного делегирования.
  • PM (продуктовый) не путается с project manager без согласования RACI.
  • ТЗ и AC готовит BA; приоритет эпиков утверждает PO/PM.
  • SA подключается к NFR и интеграциям; не решает бизнес-приоритет alone.
  • Roadmap (квартал) и backlog (спринт/недели) — разные артефакты, оба актуальны.

Тимлид и команда​

  • Тимлид не единолично решает "что в спринте" без PO/PM.
  • Технический долг и инциденты имеют согласованную политику с PO (квота, Expedite).
  • Оценка feasibility идёт до commitment; PO знает trade-off по сроку.
  • Найм и процесс — зона тимлида; приоритет фич — зона PO.

Приёмка и Sprint Review​

  • Приёмка инкремента — решение PO (или заказчика в аутсорсе), не только QA.
  • На Review показывают работающий инкремент, не план на следующий спринт.
  • Отклонённый инкремент возвращается в backlog с ясными критериями доработки.
  • В аутсорсе в договоре указан представитель заказчика для приёмки.

Аутсорс, аутстафф, госсектор​

  • В аутсорсе зафиксировано, кто заказчик приёмки (договор).
  • Изменения scope оформляются как change request, не устно.
  • При аутстаффе известен PO клиента и его канал связи.
  • В госпроекте есть куратор, решающий очередность этапов при множестве правок ТЗ.

Изменения и scope creep​

  • Нет практики "обход PO через чат к разработчику".
  • Новая фича в середине спринта — пересмотр цели спринта с PO, не тихое дописывание.
  • PM/PO явно фиксирует trade-off: что снимаем, если добавляем scope.
  • Стейкхолдеры знают, когда пересматривается приоритет (ритм refinement).

Вопросы для самопроверки (устно)​

  1. Назовите ФИО или роль PO/PM на вашем продукте.
  2. Кто A в RACI на порядок backlog?
  3. Чем отличается приёмка QA от приёмки PO?
  4. Куда вы оформите срочную просьбу стейкхолдера?
  5. Кто принимает результат в вашей модели (продукт / аутсорс / гос)?
  6. Что произойдёт, если PO недоступен две недели?
  7. Как BA участвует в приоритете — и где граница?
  8. Когда нужен change request вместо "просто задачи в Jira"?
  9. Как тимлид влияет на backlog — консультант или решатель?
  10. Какая метрика продукта связана с верхней задачей backlog?

Если на половину вопросов нет уверенного ответа — перечитайте главу 1 и обсудите с тимлидом или PM.

Красные флаги​

  • "У нас PO — вся команда" или "PO — заказчик, но он не ходит на встречи".
  • Backlog обновляется только перед отчётом руководству.
  • Разработчики не знают, кто принял фичу на прошлом демо.
  • BA и PO спорят о приоритете на каждом refinement без эскалации.
  • В аутсорсе сдали этап, заказчик узнал из production.

При трёх и более отмеченных флагах — аудит ролей с руководителем проекта.

Последнее обновление
Содержание