Product Owner: владелец продукта

Одна из самых недопонятых ролей в IT: человек, который решает не «как», а «что» — и, главное, чего команда делать НЕ будет.

Product Owner (PO, владелец продукта) — один конкретный человек, отвечающий за то, чтобы работа команды приносила максимум ценности. Его главный инструмент — порядок задач в бэклоге.

Зачем вообще нужна такая роль

Представьте интернет-магазин. В команде пять разработчиков, спринт — две недели. За спринт они успевают примерно восемь задач среднего размера. А в бэклоге лежит сорок. И у каждой есть заказчик, который искренне считает свою задачу срочной: маркетинг ждёт баннеры на главной, поддержка — фильтр по статусу заказа, финансы — выгрузку в 1С, юристы — баннер про cookie.

Если решения принимают все сразу, побеждает тот, кто громче. Разработчики оказываются в положении, когда их дёргают в четыре стороны, а спринт превращается в лоскутное одеяло. Scrum закрывает эту дыру грубо и эффективно: есть один человек, чьё слово о порядке работ окончательно. Не комитет, не «продуктовый совет», не начальник отдела. Один.

В этом и смысл слова «владелец». Владеть — значит нести последствия. Если через полгода выяснится, что команда полгода пилила не то, спрашивать будут с PO, а не с разработчиков.

Ответственность №1: ценность, а не объём

Плохой показатель работы PO — «команда закрыла 34 задачи за спринт». Хороший — «конверсия в оформленный заказ выросла с 2,1% до 2,6%». Задачи — это расход, ценность — доход.

Отсюда следует неприятная для многих вещь: лучшее решение PO часто состоит в том, чтобы задачу не делать вовсе. Фильтр по статусу заказа просили три клиента из двух тысяч, а разработка займёт неделю. Возможно, дешевле написать этим троим письмо вручную. Такое решение никогда не примет разработчик — у него нет данных. Его принимает PO.

Ответственность №2: порядок бэклога

Бэклог — это не список дел, это очередь. Ключевое слово: у задач нет «одинакового приоритета». Есть первая, вторая, третья. Если PO говорит «вот эти пять — самые важные», он ещё не сделал свою работу.

Как это выглядит на практике:

PRODUCT BACKLOG — Магазин, состояние на 14.07

#  Задача                                   Оценка  Почему здесь
1  Оплата картой падает при сумме > 100k    3       теряем 40k выручки/нед.
2  Ускорить страницу товара (LCP 4.2s)      8       33% уходят, не дождавшись
3  Фильтр «в наличии» в каталоге            5       топ-1 запрос в поддержку
4  Выгрузка заказов в 1С                    13      финансы делают руками 2ч/день
5  Промокоды на первый заказ                8       гипотеза: +0.3% к конверсии
---------- граница спринта (ёмкость ~21) ----------
6  Тёмная тема                              8       просили 12 человек
7  Баннеры на главной                       5       маркетинг «очень надо»
8  Редизайн подвала                         3       никто не просил

Обратите внимание на две вещи. Первое: у каждой строки есть колонка «почему» — и там не «важно», а факт или гипотеза. Второе: «Баннеры на главной», которых так добивался маркетинг, стоят седьмыми. Именно этот разговор — «нет, не в этом спринте, и вот почему» — и есть настоящая работа PO. Всё остальное может сделать секретарь.

Как выглядит хорошая задача от PO

PO приносит команде проблему и критерий успеха, а не техническое задание. Классическая форма — user story:

История: Фильтр «только в наличии»

Как покупатель,
я хочу скрыть товары, которых нет на складе,
чтобы не тратить время на карточки, где всё равно нельзя купить.

Критерии приёмки:
- В каталоге есть переключатель «Только в наличии», по умолчанию выключен
- При включении в выдаче остаются товары с остатком > 0
- Выбор сохраняется при переходе на следующую страницу
- Счётчик показывает, сколько товаров скрыто

НЕ входит: фильтр по срокам доставки, резерв товара

Чего здесь нет? Ни слова про то, делать фильтрацию на бэкенде или на клиенте, добавлять ли индекс в базу, писать ли новый эндпоинт. Это решает команда — потому что это она будет с этим кодом жить. Строка «НЕ входит» не менее важна, чем критерии: она отсекает разрастание задачи.

Чем PO отличается от аналитика и от менеджера

Роли путают постоянно, и путаница дорого обходится. Разница — в одном вопросе: кто принимает решение и несёт за него ответственность.

Аналитик может быть у PO помощником — и часто им становится, когда бэклог большой. PO имеет право делегировать что угодно: писать истории, проводить исследования, вести таблицы. Но ответственность не делегируется. Если критерии приёмки написал аналитик и они оказались неверными, отвечает PO.

С менеджером сложнее: во многих компаниях PO назначают человека, который привык управлять людьми. И он начинает управлять людьми — распределять задачи, спрашивать статус, торопить. Это уже не PO, это менеджер с новой визиткой.

Как это работает изнутри

Неделя PO примерно такая: половина времени — снаружи команды (клиенты, поддержка, аналитика, метрики, переговоры с заинтересованными сторонами), половина — внутри (ответы на вопросы разработчиков, приёмка, груминг бэклога).

Хороший ориентир по состоянию бэклога — четыре свойства, известные как DEEP:

• Detailed appropriately — верхние задачи проработаны детально, нижние — одной строкой. Прорабатывать всё одинаково — выброшенное время, до половины из этого никогда не сделают.
• Estimated — у ближайших задач есть оценка от команды.
• Emergent — бэклог живой: задачи добавляются, дробятся и удаляются каждую неделю.
• Prioritized — упорядочен сверху вниз, без «одинаково важных».

И одна практика, которая экономит недели: PO обязан быть доступен для команды в течение спринта. Разработчик, застрявший на вопросе «а что показывать, если товар кончился прямо во время оформления?», либо получает ответ за десять минут, либо придумывает его сам — и с вероятностью 50% придумывает не то. Отвечать на такие вопросы — часть работы, а не отвлечение от неё.

Частые ошибки

Признаки плохого PO

• Появляется только на демо. Всю неделю недоступен, а на обзоре спринта заявляет: «я имел в виду не это». Стоимость такой фразы — две недели работы пяти человек.
• «Всё важно». Бэклог, где первый приоритет стоит у двадцати задач, — это бэклог без приоритетов. Работа PO начинается ровно там, где нужно сказать «нет» тому, кто громче кричит.
• Прокси-PO без полномочий. Человек сидит на встречах, но каждое решение уносит «наверх» и возвращается через три дня. Команда простаивает, а виновата, конечно, команда.
• Диктует решения, а не задачи. «Сделайте выпадающий список на React Select» вместо «покупателю нужно быстро выбрать город из тысячи». Команду лишают того единственного, в чём она сильнее PO.
• Бэклог-свалка. Четыреста тикетов, половина протухла год назад. Никто туда не смотрит, потому что там невозможно ничего найти. Удалять задачи — нормально и обязательно.
• PO по совместительству. Директор, у которого продукт — пятая обязанность после трёх совещаний в день. Роль требует времени; на четверть ставки она не работает.

Итоги

• Product Owner — один человек, а не комитет. Его решение о порядке работ окончательное.
• Отвечает за ценность, а не за объём сделанного. Отказ от задачи — тоже результат.
• Главный артефакт — упорядоченный бэклог: есть первая задача, вторая, третья, а не «пять одинаково важных».
• PO приносит проблему и критерии приёмки. Техническое решение остаётся за командой.
• Может делегировать работу (аналитику, написание историй), но не ответственность.
• Плохой PO узнаётся по недоступности, отсутствию приоритетов и отсутствию полномочий.