Бэклог и приоритеты
Product backlog · RICE · ICE
Помогает выбрать изменения, которые сейчас важнее остальных.
Когда пригодится
Очередь пожеланий растёт быстрее команды, срочным объявляется всё.
Как использовать
- Согласуйте цель и показатель, на который хотите повлиять.
- Для каждой идеи запишите проблему, подтверждение и ожидаемый эффект.
- Оцените охват, влияние, уверенность и трудозатраты, если используете RICE; для ICE явно договоритесь о шкалах.
- Отдельно учтите обязательные работы, зависимости и риски.
- Выберите посильный набор и вернитесь к оценкам после результата.
Что учесть
Баллы помогают обсуждать выбор, но не превращают догадки в факты. Не сравнивайте 7,4 и 7,6 как точное измерение пользы. При слабых основаниях полезнее сначала проверить идею.
От цели к выбору работы
Сначала определите результат бизнеса и показатель, затем найдите помеху по данным. Только после этого сравнивайте варианты. Дерево метрик связывает показатели, Продуктовая аналитика помогает проверить исходные данные.
Заполненный учебный пример
| Вариант | Основание | Решение |
|---|---|---|
| Новый отчёт | Просьба одного клиента, влияние на текущую цель не установлено. | Оставить в очереди; уточнить контекст и охват. |
| Подсказка при импорте | Наблюдения показывают, что часть команд не загружает данные. | Возможное решение, но причина ещё требует проверки. |
| Наблюдение первого запуска | Непонятно, мешает формат файла, права доступа или объяснение. | Сначала проверить сценарий: это может изменить выбор доработки. |
Вывод. Цель — больше компаний с первым рабочим отчётом. Выбрали наблюдение импорта, потому что не выяснена причина потери. Высокий придуманный балл функции не добавит уверенности.
После проверки. Если мешает формат файла, доработать импорт или инструкцию. Если права доступа — исправить доступ. Результат оценивается по получению отчёта и нагрузке поддержки, а не по закрытию задачи.
RICE и ICE помогают обсуждать приоритеты при явно заданных шкалах. При недостатке оснований сначала получите данные; обязательные работы и зависимости учитывайте отдельно.
Как сократить roadmap при ограниченной команде
Зафиксируйте цель периода, доступную ёмкость, обязательные работы и зависимости. После этого выбирайте набор работ, а не отдельную задачу с максимальным баллом.
| Инициатива | Основание и ограничение | Решение |
|---|---|---|
| Исправление ошибки оплаты | Подтверждённая потеря заказов; блокирует дальнейшие изменения оформления. | Берём первой, задаём проверку восстановления сценария. |
| Продление текущих клиентов | В одной группе подтверждена помеха, исправление укладывается в оставшуюся ёмкость. | Берём после устранения зависимости. |
| Выход в новый сегмент | Требует нескольких команд; спрос и стоимость обслуживания ещё не проверены. | Полный запуск в этом периоде не берём. Ограничиваем работу проверкой ключевого допущения. |
| Запрошенная функция | Польза одному клиенту известна, влияние на цель периода не подтверждено. | Переносим и объясняем основание заявителю. |
На выходе — что делаем, чего не делаем, почему, какие зависимости и при каких новых данных пересмотрим решение. Если обязательная работа занимает всю ёмкость, не обещайте параллельно полный план развития.
Каждая функция связана с метрикой
Я подбираю способ приоритизации вместе с командой: ICE, RICE, WSJF или другой подходящий метод. Но выбор формулы не отменяет главного требования: для каждой функции нужно понимать, на какую низкоуровневую продуктовую метрику она должна повлиять и как через дерево метрик это связано с верхнеуровневым бизнес-показателем.
Ожидаемое влияние функции остаётся гипотезой, пока не проверено. Расчётная связь показателей в дереве и предположение, что функция изменит поведение, — разные части обоснования. Здесь я описываю принцип связи функций с метриками; подробное построение дерева — отдельная тема.
Ожидания клиентов — отдельный вход в бэклог
В CRM нужен отдельный этап для готовых ждать конкретной доработки клиентов. Запишите, чего не хватает, и регулярно сопоставляйте ожидания с продуктовым бэклогом. Отдельно учитывайте желаемый X-сегмент, для которого пока нет подходящего продукта. Это основания для обсуждения, а не автоматическое обещание сделать любую запрошенную функцию.
На карточке инициативы полезно сохранять связь с клиентами, ожидаемое изменение метрики и основание для приоритета. Так продуктовая и коммерческая команда обсуждают одну цепочку от запроса к бизнес-результату.
Ограниченный первый шаг в сложной B2B-продаже
B2B-трипвайр — небольшой вход в большой продукт с возможностью допродажи. В примере из моей практики команда выделила простой пилот после уточнения реальной ценности для покупателя. Бесплатный пилот не является трипвайром. В моём подходе B2B-трипвайр — недорогой платный первый продукт с возможностью дальнейшей допродажи. Точный состав и условия этого проекта я пока не описывал.
Ожидающая доработки сделка может оставаться A/B. Состояние «Ждёт доработки» передаёт запрос в бэклог для обсуждения, но не определяет ABCDX-сегмент и не является автоматическим обещанием разработки.
Почему оценка RICE не заменяет выбор задачи
В бэклоге смешиваются обязательства, исправления, развитие продукта и исследовательские вопросы. Их нельзя безоговорочно ранжировать одной формулой. Сначала отделите то, что необходимо сделать по обязательствам и для работоспособности продукта. Для остальных инициатив укажите проблему, затронутую группу, ожидаемое изменение поведения и основание прогноза. RICE и ICE помогают обсуждать допущения, но точный балл не делает слабое допущение достоверным.
Когда нужна проверка вместо разработки
Если команда уверена в размере решения, но не знает, существует ли сама проблема, первой задачей становится исследование. Оно должно снять конкретную неопределённость, а не просто отложить решение.
Когда достаточно обоснования через риск
Не каждой работе нужно приписывать прямой прирост выручки. Для безопасности, инфраструктуры или других необходимых изменений иногда достаточно обоснования через снижение риска: что может произойти, чем это грозит бизнесу и как работа уменьшает этот риск.
Такое обоснование не требует придуманного точного эффекта на выручку. Важно объяснить, зачем нужна работа и почему её стоит сделать сейчас. Для продуктовых функций сохраняется связь с метриками и проверка ожидаемого влияния.
Почитать о методе
Коротко о понятии
Очередь идей и работ с понятными основаниями и приоритетами. Обсуждение очереди нужно, чтобы выбрать работу под текущую цель.