Product Backlog: упорядочивание по ценности
Узнайте, как Product Owner упорядочивает Product Backlog по ценности в Scrum. Балансируйте коммерческую выгоду, снижение рисков и стоимость задержки, чтобы достичь Product Goal.
Большинство продуктовых команд полагает, что упорядочивание Product Backlog по ценности означает простое перемещение наверх тех функций, которые сулят наибольшую выручку. Такой наивный взгляд часто приводит к провалу. Ценность в разработке программного обеспечения редко выражается одной цифрой в таблице. Она складывается из пользы для пользователей, снижения рисков, получения новых знаний и соответствия стратегии. Если ориентироваться только на сиюминутную финансовую отдачу, вы упустите базовую работу и циклы обратной связи, необходимые для создания жизнеспособного продукта.
Заблуждение о приоритете исключительно выручки
Когда заинтересованные лица продвигают желаемые функции, они почти всегда обосновывают их предполагаемыми суммами выручки. Эти цифры чаще всего являются догадками. Если Product Owner упорядочивает Backlog исключительно на основе таких оценок, команда тратит силы на создание масштабных гипотетических функций, основанных на непроверенных предположениях. К моменту релиза через шесть месяцев рынок уже уходит вперед, либо пользователям эти функции оказываются не нужны.
Реальная ценность возникает только тогда, когда программный продукт попадает к пользователям и вызывает измеримые изменения в их поведении. Пока Increment не находится в промышленной эксплуатации, любые расчеты ценности остаются лишь гипотезами. Восприятие Backlog только как инструмента для извлечения выручки мешает командам осознать истинную цену нерешенных архитектурных и рыночных рисков.
Четыре измерения ценности Backlog
Руководство по Scrum 2020 года определяет, что Product Owner отвечает за максимизацию ценности продукта, создаваемого Scrum Team. В нем намеренно нет жестких формул, поскольку ценность меняется в зависимости от контекста. Чтобы эффективно упорядочивать Backlog, оценивайте четыре ключевых измерения:
- Коммерческая ценность, которая включает прямое получение прибыли, привлечение клиентов и экономию операционных расходов.
- Информационная ценность, которая включает прототипы и эксперименты, позволяющие быстро проверить сомнительные рыночные гипотезы.
- Снижение рисков, что позволяет вовремя устранить архитектурные уязвимости, регуляторные угрозы и проблемы с производительностью.
- Ценность эффективности, которая устраняет технические сложности и позволяет Scrum Team более безопасно поставлять последующие результаты.
Зависимости и стоимость задержки
Ценность невозможно оценивать изолированно. Элемент высокой важности может полностью обесцениться, если выпустить его слишком поздно. В этом заключается суть понятия стоимости задержки, или Cost of Delay. Например, запуск функционала налоговой отчетности после установленного законом срока дает нулевую ценность, каким бы качественным ни был код. С другой стороны, выпуск простого прототипа всего на две недели раньше конкурента способен сохранить долю рынка.
Технические и логические зависимости также меняют порядок элементов. Предположим, функция Б обещает высокий доход, но требует базовых доработок аутентификации в функции А. В этом случае функция А наследует срочность функции Б. Product Owner сотрудничает с Developers, чтобы учесть подобные ограничения. Developers объясняют технические реалии, а Product Owner следит за тем, чтобы последовательность работ по-прежнему отвечала стратегии продукта.
Связь порядка элементов с Product Goal
Product Goal служит обязательством для Product Backlog в Scrum. Она задает команде четкий ориентир вместо хаотичного набора разрозненных запросов. Если элемент не приближает команду к текущей Product Goal, его место обычно ближе к концу списка, независимо от того, насколько настойчиво руководство требует его реализации.
По мере перемещения к началу Backlog элементы должны становиться меньше, конкретнее и быть полностью готовыми к выбору на Sprint Planning. Элементы высокой ценности, если они слишком объемны или не детализированы, невозможно завершить за один Sprint. Декомпозиция ценных элементов на небольшие проверяемые части дает Scrum Team возможность непрерывно инспектировать, адаптировать и поставлять реальную ценность.