Как выбрать приоритет выполнения задач?

Как выбрать приоритет выполнения задач?

Приоритизация задач — критичный навык для разработчика, влияющий на продуктивность и качество результата. Рассмотрим системный подход.

Матрица Эйзенхауэра

Популярный метод делит задачи на четыре категории:

┌─────────────────────────────────────────┐
│                                         │
│  ВАЖНО + СРОЧНО           ВАЖНО + НЕ СРОЧНО
│  (Делать немедленно)      (Планировать)
│  • Критические баги       • Рефакторинг
│  • Блокирующие задачи     • Архитектура
│  • Срок сегодня           • Обучение
│                                         │
│  НЕ ВАЖНО + СРОЧНО        НЕ ВАЖНО + НЕ СРОЧНО
│  (Делегировать)           (Отклонить/Отложить)
│  • Быстрые уточнения      • Тулинг
│  • Встречи (часто)        • "Прикольные" идеи
│                                         │
└─────────────────────────────────────────┘

Стратегия: Большую часть времени посвящайте квадранту 2 (важно, но не срочно).

MoSCoW метод

Используется в agile для оценки требований:

• MUST — обязательно (1.0, MVP, критичные баги)
• SHOULD — должно быть (важные фичи, стабильность)
• COULD — было бы хорошо (улучшения, nice-to-have)
• WONT — не будет (откладывается, низкий приоритет)

// Пример распределения в спринте:
// MUST (40% времени): критичные исправления, MVP
// SHOULD (40%): основные фичи
// COULD (20%): улучшения

Технические критерии приоритизации

1. Влияние на пользователя

• Сколько пользователей затронуто?
• Насколько серьёзна проблема?
• Финансовое воздействие?

2. Блокирующие зависимости

• Блокирует ли эта задача другие работы?
• Зависит ли от чего-то незавершённого?

// Пример: тесты блокируют развёртывание
// Приоритет: ВЫСОКИЙ (блокирует 10 человек)

3. Технический долг

• Будет ли хуже, если отложить?
• Требует ли срочного рефакторинга?

4. Усилия vs Выгода

• Простые задачи (1-2 часа) часто имеют высокий приоритет
• Комплексные с маленькой выгодой — низкий приоритет

Практический пример

Начало дня, 5 задач в бэклоге:

1. Баг: страница падает при загрузке (severity HIGH, 50 пользователей) → MUST, СРОЧНО
2. Фича: новый фильтр в поиске (требует 2 дня) → SHOULD, ПЛАНИРОВАТЬ
3. Рефакторинг: переписать AuthService (требует 1 неделю) → COULD, ОТЛОЖИТЬ
4. Тесты: покрыть OrderController (требует 4 часа) → SHOULD, СЕГОДНЯ
5. Улучшение: добавить логирование в API (требует 2 часа) → COULD, НА НЕДЕЛЕ

Оптимальный порядок:

1. Утро: Исправить баг (MUST)
2. День: Написать тесты, добавить логирование (SHOULD)
3. На неделе: Спланировать фичу поиска
4. На месяц: Рефакторинг AuthService

Приёмы для самоорганизации

1. Timeboxing

9:00-10:00   Критичные баги (MUST)
10:00-12:00  Основная задача дня (SHOULD)
12:00-13:00  Встречи, общение
14:00-16:00  Длинные задачи или обучение
16:00-17:00  Code review, планирование завтра

2. 2-минутное правило

Если задача решается за 2 минуты — делай сразу, не откладывай.

3. Скорость обратной связи

Тасочки с быстрой фидбеком (review, QA) имеют приоритет — они разблокируют других.

Красные флаги

❌ Всегда высокий приоритет = нет приоритизации ❌ Никогда не говоришь "нет" = перегруженность ❌ Все сроки — "срочно" = эмоциональное решение ❌ Не обсуждаешь приоритеты с командой = конфликты

Системный подход к приоритизации экономит время, снижает стресс и улучшает качество кода.