Когда скоринг не ICE 😬
А вы используете скоринг для приоритизации своего бэклога? Если да, то у вас проблема и мы идём к вам.

Неужели фреймворки скоринга (ICE, RICE, WSJF и т. п.) — это плохие инструменты? Конечно, нет. С самими системами скоринга всё нормально. Они послушно выполняют работу по определению самых приоритетных задач на основе заданных вами данных.

Но как ни странно, использование этих инструментов в реальных командах и продуктах часто говорит о дисфункции в управлении продуктом.

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

Поэтому к продакту приходит гениальная мысль, как уменьшить боль от этого процесса. «А давайте придумаем алгоритм, который за меня будет отказывать стейкхолдерам и запускать в работу самое важное». Вот тут-то и появляется скоринг бэклога.

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

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