В большинстве команд продукта бэклог — это место, где срочность идёт умирать. Всё, что в него попадает, было срочным, когда было добавлено — жалоба клиента, запрос от продаж, функция конкурента, внутренняя идея. Шесть месяцев спустя, всё ещё там, и всё ещё кажется срочным, и никто точно не знает, что делать дальше.
Проблема не в отсутствии инструментов. Есть десятки фреймворков приоритизации: RICE, MoSCoW, Kano, ICE, взвешенное оценивание. Проблема в том, что большинство фреймворков требуют вид ложной точности — присвоение чисел неизвестным — что делает их кажущимися строгими при том, что они просто пропускают интуицию через электронную таблицу.
То, что реально работает, проще: два измерения, честно оценённые, и дисциплина действовать на результат.
Приоритизация сводится к двум вопросам. Во-первых: насколько это улучшает результат, которого мы добиваемся? (Влияние.) Во-вторых: сколько это нам будет стоить, чтобы доставить это? (Усилие.) Всё остальное — либо уточнение этих двух, либо отвлечение от них.
Иногда в качестве третьего измерения добавляют уверенность — "насколько мы уверены в влиянии?" — и это стоит иметь в виду. Но на практике большинство команд знают, когда они угадывают. Дисциплина — честно обозначить угадку, а не оценить её по шкале 1–5 и добавить в формулу.
Сложная часть — не понимание сетки — это честность при её заполнении. Каждая команда имеет функции, которые она хочет строить, что принадлежит "Пожирателям Времени" но продолжают быть переклассифицированы как "Большие Ставки." Фреймворк работает только если команда может быть честна о влиянии.
Влияние — это измерение, которое команды находят наиболее сложным для оценки, потому что оно часто требует предсказания будущего. Искушение — оценить это численно и чувствовать себя научным по этому поводу. Лучший подход — качественный но структурированный.
Задайте три вопроса для каждой функции на рассмотрении:
Команды систематически недооценивают усилие. Это хорошо задокументировано — это связано с предвзятостью планирования и оптимизмом — и это особенно выражено для функций, которые затрагивают множество систем, требуют координации между командами, или связаны с возможностями, которые команда не строила раньше.
Две практики помогают. Во-первых, всегда спрашивайте инженерию перед оценкой усилия, а не после. ПМы которые оценивают усилие в одностороннем порядке почти всегда недооценивают. Во-вторых, используйте концепцию "неизвестных неизвестных" как явный множитель усилия. Любая функция, которая затрагивает новую область кодовой базы, третий API, или пользовательский поток, который не был недавно протестирован, заслуживает оценку усилия в 1.5 раза выше, чем очевидная работа предполагает.
Большинство срочности в бэклоге продукта — это не реальная срочность — это недавность. Клиент пожаловался на неделю назад, поэтому его запрос кажется неотложным. Конкурент запустил что-то в прошлом месяце, поэтому его матч кажется критическим. Но недавность — это не то же самое что важность, и реагирование на недавность — это один из наиболее надёжных способов позволить действительно важной работе проскользнуть.
Практический тест: спросите себя, считали бы вы это всё ещё срочным, если бы услышали об этом шесть месяцев назад вместо на прошлой неделе. Если ответ нет, это предвзятость недавности в действии, не стратегический приоритет. Зафиксируйте это, оцените спокойно против сетки, и сопротивляйтесь искушению ускорить его просто потому что это свежее.
Сетка не всегда производит чистый ответ. Два элемента приземляются в том же квадранте с подобными оценками, и вы всё ещё должны выбрать один. В этих случаях два тай-брейкера полезны: стратегическое выравнивание (какой из них перемещает вас ближе к тому, где вы хотите быть через 18 месяцев?) и обратимость (какой из них сложнее отменить если это неправильно?). Предпочитайте элемент, который более стратегически выравнен и более обратим.