Понедельник, планирование. В бэклоге сорок задач, у половины пометка «срочно», у трети в комментарии написано «попросил руководитель». За две недели команда успеет пять-шесть из них. Какие брать?

Самый простой путь — отсортировать по тому, кто попросил и насколько громко. Он же самый дорогой. Команда постоянно переключается, разработка бросает задачи на середине, а продакт постепенно превращается в диспетчера входящих просьб.

Руководители ставят задачи, это нормальная часть их работы. Проблема начинается, когда источник запроса автоматически становится его приоритетом.

Источник запроса ещё не приоритет

Срочность и важность — разные вещи. Срочность говорит, как быстро нужно заняться задачей. Приоритет объясняет, почему её стоит делать раньше остальных. Упавшая оплата срочна и важна одновременно. Требование регулятора с конкретной датой — тоже. А фича, которую руководитель увидел у конкурента, может быть хорошей идеей, но срочной её делает только тон, которым о ней сказали.

Второе, что я разделяю, — запрос и задачу. Когда руководитель говорит «нам нужна такая-то функция», это входные данные. Переносить фразу в Jira как есть не обязательно. Сначала стоит понять, какую проблему он хочет решить. Например, за «нужна функция» стоит «пользователи уходят», а за этим — «они не могут сделать X». Тогда уже можно спросить, решит ли предложенная функция эту проблему и нет ли способа дешевле.

Это не спор с руководителем. После такого разговора его идея становится гипотезой, которую можно проверить.

Цена бездействия

Самый полезный вопрос в приоритизации, на мой взгляд: что произойдёт, если мы этого не сделаем? И сразу за ним: для кого это станет проблемой и насколько большой?

Если пройтись этим вопросом по бэклогу, картина быстро меняется:

  • ошибка в оплате: теряем транзакции каждый день;
  • обязательное требование: юридические или операционные последствия с понятной датой;
  • слабый онбординг: теряем часть новых пользователей, и это можно посчитать;
  • функция по просьбе руководства: пока непонятно;
  • редизайн ради красоты: скорее всего, ничего заметного.

Задачи с ответом «пока непонятно» не обязательно плохие. Но в разработку им рано, сначала нужно выяснить, что за ними стоит.

Сначала обязательное, потом сравнение

Не всё стоит сравнивать одной формулой. Законодательство, безопасность, критические ошибки, обязательства перед клиентами и партнёрами — это must do. Я выношу такие задачи отдельно и не взвешиваю их вместе с продуктовыми инициативами.

Всё остальное — выбор. Приоритета в вакууме не существует: мало сказать «эта задача очень важная», нужно ответить, важнее чего. Если команда успевает три задачи, четвёртая «очень важная» всё равно не поместится.

Для сравнения мне хватает четырёх параметров: эффект, срочность, стоимость и уверенность в своих предположениях. Большая инициатива на три месяца может проиграть задаче на два дня с меньшим, но понятным эффектом. Сложная модель со взвешенными баллами не нужна, оценки «высоко, средне, низко» уже показывают разницу.

Когда тянут несколько руководителей

Самая тяжёлая ситуация — когда два-три человека одновременно приходят каждый со своей срочной задачей. Продакту не нужно брать на себя роль того, кто говорит «ваша задача не в приоритете». Лучше сделать выбор прозрачным и показать, чем он оплачивается. Например, так:

Сейчас у нас в работе три инициативы. Если берём вашу первой, откладываем X и Y. По текущим данным ваша даст такой эффект, X — такой. Какую бизнес-цель мы сейчас считаем главной?

После такого разговора решение принимается там, где за него отвечают. Продакт приносит контекст, последствия и варианты, но не обязан в одиночку разруливать конфликт бизнес-приоритетов.

«Не сейчас» — нормальный ответ

По сути приоритизация — это про отказ. Каждое «берём» означает несколько «не сейчас», и честнее говорить это вслух, чем держать тридцать задач со статусом «срочно».

«Не сейчас» не значит «никогда». Это значит, что сегодня есть задачи с большей ценностью, большим риском или более жёстким дедлайном. Когда поменяются данные, цели или ресурсы, порядок можно пересмотреть. Чтобы пересмотр не превратился в хаос, я задаю себе один вопрос: что изменилось с момента, когда мы приняли решение? Если ничего, менять приоритет незачем.

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

Что сделать завтра утром

Открыть бэклог и пройтись по каждой крупной задаче с шестью вопросами:

  • Какую проблему решаем?
  • Для кого она важна?
  • Что будет, если не сделаем?
  • Какой эффект ожидаем?
  • Что откладываем, если берём её сейчас?
  • Почему именно сейчас?

Если ответов нет, перед вами пока входящий запрос. С ним можно работать дальше, но в спринт ему рано.

Больше разборов про продуктовое мышление и реальные кейсы — в моём телеграм-канале.