Как приоритизировать функции, когда всё кажется срочным

Командой FabricLoop  ·  Май 2026  ·  6 мин чтения

В большинстве продуктовых команд бэклог — место, где срочность умирает. Всё, что туда попадает, было срочным на момент добавления: жалоба клиента, запрос отдела продаж, функция конкурента, внутренняя идея. Полгода спустя всё это по-прежнему лежит там, по-прежнему кажется срочным, и никто толком не знает, за что браться дальше.

Дело не в нехватке инструментов. Фреймворков приоритизации десятки: RICE, MoSCoW, Kano, ICE, взвешенная оценка. Проблема в том, что большинство из них требуют ложной точности — присваивать числа неизвестным, — из-за чего выглядят строгими, а на деле просто прогоняют интуицию через электронную таблицу.

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

Всего два измерения, которые действительно важны

Приоритизация сводится к двум вопросам. Первый: насколько это улучшит результат, который нам важен? (Влияние.) Второй: во сколько нам обойдётся реализация? (Трудозатраты.) Всё остальное — либо уточнение этих двух, либо отвлечение от них.

Иногда в качестве третьего измерения добавляют уверенность — «насколько мы уверены в оценке влияния?» — и об этом стоит помнить. Но на практике большинство команд и так понимают, когда гадают. Важно честно пометить догадку как догадку, а не оценивать её по шкале от 1 до 5 и подставлять в формулу.

Трудность не в понимании сетки, а в честности при её заполнении. В каждой команде есть функции, которые хочется сделать и которые на самом деле относятся к «пожирателям времени», но их раз за разом переквалифицируют в «крупные ставки». Фреймворк работает, только если команда честно оценивает влияние.

Как оценить влияние без ложной точности

Влияние — измерение, которое командам сложнее всего оценить, потому что для этого часто нужно предсказывать будущее. Соблазн — выставить числовую оценку и почувствовать себя учёными. Лучше подойти качественно, но структурированно.

Задайте три вопроса по каждой рассматриваемой функции:

• Какую конкретную проблему пользователя это решает? Если вы не можете назвать конкретную повторяющуюся проблему, аргументы в пользу влияния слабы.
• Сколько пользователей сталкиваются с этой проблемой и как часто? Влияние — это частота, умноженная на остроту. Лёгкое неудобство для всех — не то же, что серьёзное препятствие для немногих.
• Что произойдёт, если мы это не сделаем? Если ответ «ничего особенного», пересмотрите приоритет. Если ответ «пользователи уйдут» или «мы потеряем сделки», влияние реально.

Как оценивать трудозатраты, не занижая их

Команды систематически занижают трудозатраты. Это хорошо изучено — связано с ошибкой планирования (planning fallacy) и излишним оптимизмом — и особенно заметно для функций, которые затрагивают множество систем, требуют согласования между командами или опираются на возможности, которых команда раньше не создавала.

Помогают две практики. Во-первых, сначала спрашивайте разработчиков, а потом выставляйте оценку трудозатрат — не наоборот. Продакт-менеджеры, оценивающие трудозатраты в одиночку, почти всегда их занижают. Во-вторых, явно закладывайте множитель на «неизвестные неизвестные». Любая функция, которая затрагивает новый участок кодовой базы, сторонний API или пользовательский сценарий, давно не проверявшийся, заслуживает оценки трудозатрат в 1,5 раза выше, чем подсказывает очевидная часть работы.

Иллюзия срочности

Большая часть срочности в продуктовом бэклоге — не настоящая срочность, а свежесть. Клиент пожаловался на прошлой неделе, поэтому его запрос кажется неотложным. Конкурент выпустил что-то в прошлом месяце, поэтому кажется, что нужно срочно сделать так же. Но свежее не значит важное, и реакция на свежесть — один из самых верных способов упустить действительно важную работу.

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

Когда сетка даёт ничью

Сетка не всегда даёт чёткий ответ. Два пункта попадают в один квадрант с похожими оценками, а выбрать всё равно нужно один. В таких случаях пригодятся два критерия для разрешения ничьей: стратегическое соответствие (что приблизит вас к тому, где вы хотите быть через 18 месяцев?) и обратимость (что сложнее откатить, если решение окажется неверным?). Предпочитайте пункт, который лучше соответствует стратегии и легче обратим.