Как расставлять приоритеты у задач

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

Как это работает

Основные факторы, которые я учитываю при расстановке приоритетов:

• Бизнес-ценность — насколько задача влияет на ключевые метрики продукта или бизнес-цели. Задачи, которые приносят прямую выгоду пользователям или доход, получают более высокий приоритет.
• Сроки и зависимости — дедлайны, а также задачи, которые блокируют работу других команд или критичные для релиза. Если задача без срока, но от неё зависят другие, она становится приоритетной.
• Риски — потенциальные проблемы, если задача не будет выполнена вовремя. Например, технический долг, который может замедлить разработку в будущем, или уязвимости безопасности.
• Ресурсы — доступность команды, необходимые технологии и экспертиза. Задача, которую можно выполнить быстро с текущими ресурсами, может быть приоритетнее, чем долгая задача, требующая найма.

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

// Псевдокод для расчета приоритета
function calculatePriority(task) {
  const score = task.businessValue * 0.4 
               + task.urgency * 0.3
               + task.riskFactor * 0.2
               + (1 - task.resourceComplexity) * 0.1;
  return score;
}

Здесь businessValue — оценка от 1 до 10, urgency — срочность, riskFactor — уровень риска, resourceComplexity — сложность с точки зрения ресурсов (0 — просто, 1 — сложно). Чем выше итоговый балл, тем выше приоритет.

Пример приоритизации

Рассмотрим типичную ситуацию в Jira. У нас есть три задачи:

1. Исправить критический баг в платежном шлюзе — бизнес-ценность 9, срочность 10, риск 8, сложность 0.3.
2. Добавить новую страницу в документацию — бизнес-ценность 3, срочность 4, риск 2, сложность 0.1.
3. Рефакторинг модуля аутентификации — бизнес-ценность 6, срочность 5, риск 7, сложность 0.7.

Расчет:

• Задача 1: 90.4 + 100.3 + 8*0.2 + (1-0.3)*0.1 = 3.6 + 3 + 1.6 + 0.07 = 8.27
• Задача 2: 30.4 + 40.3 + 2*0.2 + (1-0.1)*0.1 = 1.2 + 1.2 + 0.4 + 0.09 = 2.89
• Задача 3: 60.4 + 50.3 + 7*0.2 + (1-0.7)*0.1 = 2.4 + 1.5 + 1.4 + 0.03 = 5.33

Очевидно, что задача 1 — самая приоритетная, затем задача 3, и только потом задача 2. Такой подход помогает принимать объективные решения, а не полагаться на интуицию.

Подводные камни

• Субъективность оценок — баллы могут быть произвольными. Чтобы снизить субъективность, стоит согласовывать оценки с командой и заинтересованными сторонами.
• Перекос в сторону срочного — если всегда гореть в пожарном режиме, можно забыть о стратегических задачах. Поэтому важно выделять время на технический долг и улучшения.
• Игнорирование технического долга — если постоянно откладывать рефакторинг, скорость разработки упадет. Рекомендую выделять около 20% времени на погашение технического долга.
• Изменение приоритетов — приоритеты могут меняться, поэтому нужно регулярно пересматривать бэклог и адаптироваться.

Когда использовать

Скоринговая модель полезна, когда задач много и нужно быстро сравнить их между собой. Она хорошо работает в командах, использующих Agile и Scrum, где бэклог постоянно обновляется. Однако для небольших команд или коротких спринтов можно обойтись простым списком приоритетов на основе бизнес-ценности и срочности.

Коротко

• Учитывайте бизнес-ценность, сроки, риски и ресурсы при приоритизации.
• Используйте скоринговую модель для объективного сравнения задач.
• Не забывайте про технический долг — выделяйте на него время.
• Регулярно пересматривайте приоритеты, так как они могут меняться.