Комментарии 3
В моей практике такая приоритизация нужна в поддержке, багфиксах - там, как вы написали, борьба идёт за их корректную маркировку, и обеспечение исполнения низших приоритетов.
А вот с разработкой как-то не складывается - каким образом работать с задачами одного приоритета - сортировать их по дедлайну? ИМХО сомнительная практика ждать пока важная задача превратится из несрочной в срочную. Обычно между задачами есть взаимосвязи, поэтому крайне желательно их реализовывать не когда захочет разработчик, а относительно синхронизировано (например, когда имплементация новой фичи затрагивает несколько модулей, и для её работы необходимо реализовать во всех - даже тех для которых она стоит с низким приоритетом).
Поэтому я ставлю приоритеты не на отдельные задачи, а на фичи, которые в свою очередь расставляю в порядке оптимальности технологического процесса разработки, и особого места этим градациям там нет, они группируются не по важности, а по логике этапов функциональности.
тут можно делать по-разному. Если приоритет везде равный, это, по умолчанию, означает, что порядок - на усмотрение производства. Если есть менеджер, то на его усмотрение (обычно он все таки есть).
Если менеджера нет и есть желание сделать полностью автоматический конвеер... ну я аккуратно скажу, что я такого не видел. Можно и правда идти от дедлайна по фиче, автоматически смотреть какие дедлайны и связи задач... но пока звучит как фантастика.
Я решаю это просто - есть РП или продакт, которы определяет, что пускаем в работу и все.
Да, если капасити команды меньше, чем объем задач, может получиться, что какие то задачи начнут "краснеть" и пойдут в работу с повышенным приоритетом. Ничего криминального не вижу - нормальная логика стека, когда входящий объем больше обрабатываемого.
Главное, следить надо за тем, чтобы общий входящий объем не превышал капасити команды продолжительное время - тогда начнутся задержки. Это уже не решить приоритетами, это решается планированием ресурсов команды.
Да, это то что я хотел услышать - что задачи таки распределяет специально обученный человек. Обычно когда пишут про управление приоритетами, создаётся впечатление что они как-то сами собой выстраиваются, а про то что задачи с одинаковым приоритетом надо тоже приоритизировать как-то умалчивают - кстати вероятно отсюда получается не 4, а 44 приоритета.
Разумеется, не каждую мелочёвку, может быть пул задач которые действительно всё равно когда делать - но это скорее из приоритета "неважные несрочные".
Кри-Кри или приоритизируй Это. Памятка по приоритизации для Руководителей