Как приоритизируешь задачи

# Как приоритизируешь задачи?

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

1. Матрица Эйзенхауэра (Wichtig/Dringend)

Это один из самых эффективных способов приоритизации. Задачи разделяю по двум осям:

• Важность — влияние на бизнес и пользователей
• Срочность — насколько быстро нужно сделать

┌─────────────────┬──────────────────┐
│   Важно + Срочно │  Важно + Не срочно│
│  (Приоритет 1)  │  (Приоритет 2)   │
├─────────────────┼──────────────────┤
│Срочно + Не важно│ Не важно + Не срочно
│  (Приоритет 3)  │  (Приоритет 4)   │
└─────────────────┴──────────────────┘

Примеры для разработчика:

Приоритет 1 (Важное + Срочное):

• Production баг, мешающий пользователям
• Критическая уязвимость безопасности
• Блокирующее решение для выпуска версии
• Потеря данных пользователей

Приоритет 2 (Важное + Не срочное):

• Рефакторинг технического долга
• Оптимизация производительности (когда не критичная)
• Автоматизация процессов
• Документирование архитектуры
• Улучшение тестового покрытия

Приоритет 3 (Срочное + Не важное):

• Быстрая фиксация падающего теста
• Срочное собрание, которое могло подождать
• Уведомления, требующие немедленного ответа

Приоритет 4 (Не важное + Не срочное):

• Красивое форматирование кода
• Новые библиотеки для изучения
• Оптимизация, которая даст 0.1% улучшения

2. MoSCoW метод

Разделяю задачи на 4 категории:

Must Have (Должны)  — 50%
  └─ Критичные для выпуска, без них нет смысла
  └─ Production баги, обязательные требования
  └─ Задержки могут заблокировать команду

Should Have (Нужны) — 30%
  └─ Важны, но не критичны
  └─ Влияют на пользовательский опыт
  └─ Могут быть отложены

Could Have (Можно) — 15%
  └─ Хорошо было бы иметь
  └─ Не влияют на основной функционал
  └─ Первые кандидаты на откладывание

Won't Have (Не будут) — 5%
  └─ Не делаем в этом спринте
  └─ Планируем на будущее
  └─ Меньше уводит энергию

3. Практический алгоритм приоритизации

Когда получаю новую задачу, задаю себе вопросы:

Шаг 1: Критичность

1. Блокирует ли это других разработчиков или команду?
   → ДА = Приоритет MAX
   
2. Влияет ли на production или пользователей?
   → ДА = Приоритет HIGH
   
3. Это security issue?
   → ДА = Приоритет CRITICAL (выше всего)

Шаг 2: Влияние на бизнес

1. Сколько пользователей это касается?
   → Много = HIGH
   → Мало = LOW
   
2. Какой финансовый/репутационный урон?
   → Большой = HIGH
   → Маленький = LOW

Шаг 3: Затраты времени

1. Сколько времени это займёт?
   → < 2 часов = можно взять сейчас
   → > 2 дней = нужно планировать
   
2. Зависит ли это от других задач?
   → ДА = может быть отложено
   → НЕТ = можно начать сразу

4. Система приоритизации в коде

В реальных проектах обычно используем систему меток:

// CRITICAL - Security, data loss, production down
// HIGH - Feature blocking, major bugs
// MEDIUM - Nice to have, can be deferred
// LOW - Polish, optimization
// TECHNICAL_DEBT - Refactoring, cleanup

// GitHub Issues Example:
// @critical production-bug data-loss
// @high feature-blocker regression
// @medium improvement documentation
// @low polish performance
// @technical-debt refactor cleanup

5. Ежедневная тактика приоритизации

Начало дня (10 минут)

1. Посмотрю на слаки, уведомления
2. Проверю production monitoring
3. Быстро поглядю на критичные PR/issues
4. Обновлю свой список задач на день

Блокирующие задачи (делаю СРАЗУ)

1. Production баги
2. Все, что блокирует других
3. Security issues
4. Критичные PR reviews

Запланированные задачи (по спринту)

1. Важные разработки для спринта
2. Техдолг, который накопился
3. Code review и менторинг

Контекстные переключения (делаю осторожно)

❌ Не перепрыгиваю между задачами просто так
✅ Переключаюсь только если:
   - Это production issue
   - Это блокирует других
   - Это критичное PR review

6. Интеграция с фреймворками управления

С Scrum/Agile

Sprint Planning:
1. Разговор с PO о приоритетах
2. Разбор задач по Story Points
3. Согласование реалистичного объёма

Daily Standup:
- Что было вчера (приоритет 1-2)
- Что буду делать сегодня (приоритет 1-2)
- Что блокирует? (нужна помощь)

С Kanban

Active Column (только 3-5 задач одновременно):
1. Что из CRITICAL/HIGH делаю сейчас
2. Что ждёт code review

Backlog Prioritization (еженедельно):
1. Переоцениваю приоритеты
2. Вижу, что появилось нового
3. Перераспределяю ресурсы

7. Особенности для разработчика

Technical Debt

Когда приоритизирую tech debt:

Высокий приоритет если:
- Замедляет разработку новых фич
- Снижает надёжность системы
- Усложняет onboarding новичков
- Есть явная причина (старые lib, плохая архитектура)

Низкий приоритет если:
- Может остаться как есть
- Не мешает текущей разработке
- Исправление займёт много времени

Code Review

Приоритет code review:

1. CRITICAL
   - Security fix
   - Production bug fix
   - Dependency update
   → Review в течение 30 минут

2. HIGH
   - Новая фича для спринта
   - Важное улучшение
   → Review в течение 2 часов

3. MEDIUM
   - Документация, рефакторинг
   → Review в течение дня

4. LOW
   - Комментарии, cleanup
   → Review когда есть время

8. Работа с давлением и сроками

Когда давит время и много задач:

1. Переговариваюсь с лидом/PM
   - Что реально делать в первую очередь?
   - Что можно отложить?
   - Какие риски?

2. Честно оцениваю (не обещаю невозможное)
   - Список того, что реально сделаю
   - Список того, что отложу
   - Список risks

3. Фокусируюсь на done > perfect
   - Делаю достаточно хорошее решение
   - Документирую то, что быстро сделал
   - План на рефакторинг потом

9. Инструменты для приоритизации

- GitHub Issues/Discussions — labels, milestones
- Jira — priority field, roadmap
- Notion/Obsidian — личная система
- Linear — быстрая работа с приоритетами
- Slack reminders — для срочных задач

10. Практический пример дня разработчика

09:00 - Проверю Slack, Production monitoring
        Видим: "Баг на production с платежами"
        → CRITICAL - делаю это

09:15 - Начинаю фиксить production баг
        Одновременно:
        - Дал code review срочному PR (HIGH) - 15 минут

11:00 - Production баг зафиксен и завислен

11:15 - Возвращаюсь к запланированной задаче (MEDIUM)
        - Feature для спринта, которую начал вчера

13:00 - Обед

14:00 - Продолжаю фичу
        Попутно делаю:
        - Code review для коллег (2-3 часа в день это норма)
        - Помогаю новичку с вопросом (5 минут)

17:00 - Завершаю feature, запускаю тесты

17:30 - Работаю на tech debt
        - Документирую архитектуру (1 час)

18:00 - Планирую завтра

Вывод

Приоритизация задач — это не один раз выученный алгоритм, а постоянная практика. Ключи:

1. Критичность — production и security всегда на вершине
2. Влияние — какой эффект на пользователей и бизнес
3. Затраты — во времени и ресурсах
4. Зависимости — блокирует ли это других
5. Контекст — в одном проекте задачи разные

Основной совет: научись говорить "нет" или "позже" тому, что не критично. Это сохраняет фокус и качество работы.