Джейсон Фрид недавно круто написал, что приоритеты у задач — плохо. Идея простая: у задач не бывает среднего или низкого приоритета — задачу или надо делать прямо сейчас, или когда-нибудь потом.

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

Любое несделаное дело стоит ресурсов. Во-первых оно давит: я чувствую себя меньшим молодцом, и каждый день когда я его переношу, испытываю поганое ощущение «Федя не заботится о здоровье». Во-вторых оно занимает место в задачнике (я не планирую больше 12 дел в день). В-третьих, в течение дня, когда оно висит в задачнике я трачу на него энергию: «вот сейчас пообедаю, и запишусь», «вот тут надо бы письмо написать, а потом можно и записаться», или «вот сейчас потуплю ютуб и запишусь».

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

Кажется, что с любой входящей задачей надо чётко решать: «делаем» или «не делаем». «Делаем с низким приоритетом» — в топку. Ну а в помощь, чтобы решить да или нет, есть классная мантра:

Стали бы мы делать эту задачу, если бы компании оставалось жить две недели?
А месяц?
Кажется этот вопрос стоит задавать про каждую задачу на планировании каждого спринта. И если ответ оба раза отрицательный, то такую задачу стоит выкинуть даже из беклога.

Здорово очищает голову.

Идея Фрида и пост Борщёва заставили задуматься, что не всё так чёрно-бело. Приоритизация "делаем сейчас или в топку" работает для приоритизации на высоком уровне и для маленьких проектов.

Однако, если у тебя проект с легаси системами, который длится 3 года, над которым работают десятки человек и который выкатывается по частям, количество задач переходит в сотни. Из них десятки - это Р0 (must have, launch blocker), сотни P1 (should have, can be done later) и сотни Р2 (nice to have).

Р2 можно бросить в топку, а вот приоритизация и stack ranking (сортировка по важности) P0 и P1 даёт команде, её зависимостям и стейкхолдерам ясность.