Представьте ситуацию: у вашего продукта 50+ стейкхолдеров (30 бизнес-заказчиков, 5 архитекторов и еще 20 связанных систем) и все одновременно чего-то хотят.
Есть «очевидное» решение: нанимать больше людей. Но это порочная практика. Сколько бы людей вы ни наняли, если нет фильтра на входе, задач всегда будет больше, чем ресурсов.
Меня зовут Денис Тучин, я отвечаю за процессы разработки мобильного приложения ВкусВилл в IT-компании ТехВилл. А также веду канал про менеджмент в целом и управление продуктом в частности (https://t.me/tealorg). В этой статье я расскажу, как мы прошли путь: квоты → RICE → ROI, с какими проблемами столкнулись на каждом этапе и какие выводы сделали.
Контекст
Масштаб продукта:
~200 участников (бизнес, аналитики, дизайн, разработка, QA, DevOps);
12 продуктовых команд;
ежеквартальное PI-планирование для распределения задач.
На таком масштабе приоритизация перестаёт быть методологическим вопросом, она становится организационной и экономической задачей.
Вызов №1. 50+ стейкхолдеров на один продукт
На 2022 год у нас было:
Более 30 бизнес-заказчиков,
5 архитекторов,
И 20 связанных приложений и подсистем.
Все они приходили с задачами. У всех «срочно» и «очень важно». Понятно, что у каждой из продуктовых команд не более 10 стейкхолдеров, но и это всё равно очень много. На этом этапе ключевая проблема была не в выборе лучшей задачи, а в том, что:
команды физически не могли взять всё;
давление на команды росло.
Решение №1. Квоты
Первым шагом стали квоты по capacity
часть — под внешние запросы,
часть — под платформу и техдолг,
небольшой буфер под неопределённость, т.к. нельзя запланировать все неожиданности, особенно на квартал.
Самым сложным на данном этапе стало соблюдение уже выбранных квот.
Что это дало:
стало прозрачно, сколько команда реально может взять;
снизилось давление со стороны стейкхолдеров;
исчезла гонка «кто первый занял весь capacity».
Важно: квоты не решают проблему приоритизации, но отлично снимают первый слой хаоса.
Вызов №2. Приоритизация на основе харизмы
В 2023 году всплыла новая проблема. Допустим, к одной команде приходят 5 архитекторов. Один топит за микросервисы, второй за дизайн-систему, третий за PCI DSS. Квота на платформу ограничена, а все задачи «важные».
Что происходило на практике? Берут задачу того, кто лучше аргументировал, увереннее говорил или дольше объяснял последствия. Я назвал это «приоритизация на основе харизмы».
Решение №2: RICE
Мы внедрили RICE, чтобы жаркие споры превратились в структурированное обсуждение:
Reach — охват пользователей.
Impact — влияние на метрики (мы начали выбирать конкретную метрику квартала и бить в неё).
Confidence — наша уверенность (10 — данные исследований, 1 — просто гипотеза).
Effort — оценка в часах.
Самым сложным тут было договориться стейкхолдерам команды об одинаковом понимании показателей R, I и C.
Что изменилось?
Формула простая, но эффект оказался ощутимым:
жаркие споры стейкхолдеров превратились в структурированное обсуждение;
решения по приоритетам стали более объективными и проверяемыми;
стресс команд ещё больше снизился;
Вперед стали брать не просто самые важные задачи, но стали учитывать ещё и трудозатраты на них.
Например, на скриншоте ниже видно, что важность больше у 4 фичи, но она слишком трудозатратная, поэтому её опережают три более легковесные, пусть и чуть менее важные.
Вызов №3. «Бантики» против ценности
В 2024 году мы увидели «локальную оптимизацию». Одна команда могла быть завалена сверхценными фичами, а другая в это же время делала «бантики» — не очень ценные плюшки для своей части продукта, просто потому что там всё важное уже сделано.
Решение №3: Сквозная приоритизация по ROI
Нужен был объективный показатель, позволяющий сравнить задачи разных команд между собой. И этот показатель — деньги. Именно так мы выбрали показатель ROI.
ROI = (Эффект − Инвестиции) / Инвестиции × 100%
Где:
Эффект — рост дохода или снижение расходов;
Инвестиции — затраты на реализацию.
Самым сложным здесь было научиться считать потенциальный эффект, т.к. некоторые фичи дают непрямое или отложенное влияние на деньги.
Это позволило:
сравнивать задачи между командами;
передавать самые ценные инициативы в команды, где в беклоге менее ценные задачи;
отсекать убыточные задачи ещё до реализации;
приоритезация ROI более точный и объективный показатель, чем RICE.
Выводы
За 3 года мы поняли:
Квоты — хороший временный инструмент, но они не заменяют экономическую модель.
Визуализация (дашборды с приоритетами) резко снижает градус дискуссий и стресс команды.
ROI — самый точный инструмент, но он требует ресурсов. Для растущих продуктов часто достаточно RICE, но на масштабе без денег не обойтись.
Если вы чувствуете, что приоритеты в продукте всё чаще определяются «громкостью голоса», а не ценностью, то скорее всего, вы просто доросли до следующего уровня зрелости. 😉
