Ответ
Приоритизация строится на оценке бизнес-ценности, срочности и технического влияния. Основной инструмент — матрица Эйзенхауэра (важное/срочное).
Практический подход:
- Критические инциденты — баги, нарушающие работу продакшена для значительной части пользователей.
- Функциональность с высоким ROI — задачи с дедлайнами или прямым влиянием на бизнес-метрики.
- Технический долг — оценивается по его влиянию на стабильность, производительность или скорость разработки.
- Улучшения и рефакторинг — не срочные работы, повышающие качество кода в долгосрочной перспективе.
Инструменты и практики:
- Использование систем вроде Jira с приоритетами (Blocker, Critical, Major, Minor).
- Регулярный пересмотр бэклога и приоритетов на планировании спринта, так как контекст может меняться.
- Четкое согласование критериев срочности и важности с продукт-менеджером и командой.
Ответ 18+ 🔞
Слушай, ну вот смотри, вся эта история с приоритетами — она ж, блядь, как в аптеке: если не разложить по полочкам, получится пиздец и бардак. Все кричат «срочно!», а на деле половина — это так, мартышлюшка какая-то.
Вот смотри, как у нас, у нормальных людей, это работает, без этих ваших заумных словечек.
Первое и главное — это пиздец в продакшене. Ну, вот реальный пиздец. Упала главная страница, пользователи орут, деньги текут в унитаз. Это, ёпта, даже не обсуждается. Все бросаются, как угорелые, и чинят. Это и есть «Blocker» в твоей Jira. Всё остальное — похуй.
Второе — это когда бабло прямо на кону. Пришёл продакт, глаза горят, говорит: «Ребята, вот эта фича — она нам через две недели миллион принесёт, контракт сорвём, если не сделаем». Ну, тут понятно, волнение ебать. Это важное и срочное. В матрице Эйзенхауэра — верхний правый квадрат, «Делай немедленно». ROI, блядь, высокий.
А теперь, внимание, третий пункт — технический долг. Вот тут все начинают сосать лапу. «А давайте перепишем на новом фреймворке, а то тут говнокод». Стоп, сука! Не всё долг одинаково полезен. Оцениваем так: если этот долг прямо сейчас мешает работать — тормозит всё, падает каждые пять минут, новый разработчик смотрит на код и плачет — тогда это важно. Если же это просто «некрасиво» — отправляем в долгий ящик, в квадрат «Не срочно, но важно». Разгребаем потихоньку, когда нет первых двух пунктов.
Четвёртое — всякие улучшайзеры и рефакторинг «на будущее». Это, извини, «Не срочно и не важно», пока не доказано обратное. Хочешь причесать код в модуле, который никто не трогает три года? Ну, иди, подрочи, если время есть. Но обычно его нет, потому что первые три пункта жрут всё.
Как это в жизни выглядит? Сидим мы на планировании спринта, пересматриваем бэклог. Продакт тянет своё, тимлид — своё. И вот тут надо чётко договориться, что есть «срочно». А то получится: «Ой, у кнопки тень не того оттенка — это критично!». Нет, блядь, не критично. Критично — это когда всё горит. А тень — это «Minor», в конец очереди. Без этого чёткого согласования будет вечный трёп и ни хуя не сделано.
Короче, алгоритм простой:
- Туши пожар (продакшен упал).
- Делай то, за что платят (фичи с дедлайном и деньгами).
- Чини то, что вот-вот развалится и всем мешает (злой техдолг).
- Всё остальное — по остаточному принципу.
Вот и вся ваша приоритизация, ебать её в сраку. Главное — не давать себя разводить на ерунду. Держи фокус, и будет тебе счастье.