Как приоритизируешь задачи в отсутствии Project Manager?

Приоритизация задач без Project Manager

Это критический навык для разработчика, особенно в стартапах и удалённых командах. Расскажу о framework'е, который использую 10+ лет для правильной приоритизации.

Матрица Eisenhower (2x2)

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

┌─────────────────────────┬──────────────────────────┐
│ ВАЖНО + СРОЧНО          │ ВАЖНО + НЕ СРОЧНО        │
│ (Кризисы, дедлайны)     │ (Стратегия, качество)    │
│ → ПЕРВООЧЕРЕДНО         │ → ПЛАНИРОВАТЬ             │
├─────────────────────────┼──────────────────────────┤
│ НЕ ВАЖНО + СРОЧНО       │ НЕ ВАЖНО + НЕ СРОЧНО     │
│ (Срочные просьбы)       │ (Отвлечения)             │
│ → ДЕЛЕГИРОВАТЬ          │ → ИСКЛЮЧИТЬ              │
└─────────────────────────┴──────────────────────────┘

Практическое применение

1. ВАЖНО + СРОЧНО (Do First)

• Production падает → исправляем сейчас
• Критический баг, которого ждёт клиент
• Дедлайн завтра, а фича не готова
• Безопасность под угрозой

Эти задачи требуют немедленного внимания.

2. ВАЖНО + НЕ СРОЧНО (Schedule)

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

Здесь закладываем основу для долгосрочного успеха. Это требует планирования.

// Пример: рефакторинг вместо новых фич
// Сейчас код работает, но:
// - сложно добавлять новые функции
// - сложно находить баги
// - новички теряются в коде
// Это ВАЖНО, но не СРОЧНО → планируем на спринт

3. НЕ ВАЖНО + СРОЧНО (Delegate)

• Клиент просит изменить цвет кнопки
• Администратор просит экспортировать отчёт
• Менеджер просит срочно сделать статистику

Это кажется срочным, но не влияет на ядро продукта. Лучше:

• Ответить: "Это займёт 2 часа, а у меня есть баг в платежах. Смогу завтра?"
• Или: "Сможешь ли ты написать в этом же Airtable значения? Я помогу завтра"
• Или делегировать менее опытному разработчику

4. НЕ ВАЖНО + НЕ СРОЧНО (Eliminate)

• "А давайте добавим фишку, которую никто не просил"
• Идеальное оформление кода, которое не даёт ценности
• Игра с новыми технологиями без причины

Прямо отклоняйте. Это waste времени.

Критерии оценки важности

Важно, если:

• Влияет на доход (платежи, конверсия)
• Влияет на безопасность или privacy
• Влияет на user experience (люди не могут работать)
• Влияет на скорость разработки (убирает blocker'ы)
• Требует другого разработчика (я единственный, кто может это сделать)

Не важно, если:

• Никто об этом не просил
• Может ждать неделю
• Мало пользователей затронуто
• Есть workaround

Критерии срочности

Срочно, если:

• Дедлайн завтра
• Клиент ждёт на звонке
• Production broken
• Блокирует работу других

Не срочно, если:

• Дедлайн через неделю
• Можно работать в фоне
• Есть workaround

Фреймворк принятия решений

Вот как я отвечаю на задачу без PM:

// 1. Быстро оцениваю Eisenhower
const task = {
  title: "Клиент просит добавить экспорт в CSV",
  important: false, // Это nice-to-have, не core functionality
  urgent: true,     // Клиент просил сегодня
};

// 2. Определяю квадрант
const quadrant = (important, urgent) => {
  if (important && urgent) return "DO FIRST";
  if (important && !urgent) return "SCHEDULE";
  if (!important && urgent) return "DELEGATE or DECLINE";
  return "ELIMINATE";
};

// 3. Действие
const action = quadrant(task.important, task.urgent);
// "DELEGATE or DECLINE"

// 4. Мой ответ клиенту:
// "Я могу сделать экспорт в CSV, это займёт 3 часа.
//  У меня сейчас есть критический баг в платежах, который я сейчас правлю.
//  Смогу сделать экспорт завтра утром или завтра днём — тебе всё равно?"

MoSCoW метод (для planification)

Когда есть список задач, использую MoSCoW:

• Must — критично, без этого product не работает
• Should — важно, но может подождать
• Could — nice-to-have, если будет время
• Won't — точно не делаем

const backlog = [
  { task: "Платежи работают", moscow: "MUST" },
  { task: "Отправка писем при регистрации", moscow: "SHOULD" },
  { task: "Тёмная тема интерфейса", moscow: "COULD" },
  { task: "Интеграция с Slack", moscow: "WON'T" },
];

// Сначала правлю MUST, потом SHOULD, потом COULD
// WON'T удаляю или откладываю на будущее

Практические советы

1. Спрашивай уточняющие вопросы:

• "Когда это нужно?"
• "Сколько пользователей это затрагивает?"
• "Есть ли workaround?"
• "Это блокирует других?"

2. Коммуницируй ожидания:

• "Я работаю над X, потом займусь Y. Это ок?"
• "Это займет 5 часов. У нас есть это время?"

3. Переоценивай приоритеты еженедельно:

• Вчера было не важно, но появился другой кризис → переоценивай
• Дедлайн сдвинулся → переоценивай

4. Защищай глубокую работу:

• Не отвлекайся на каждый Slack
• Блокируй время для ВАЖНО + НЕ СРОЧНО задач
• Эти задачи предотвращают кризисы завтра

Красный флаг

Если ВСЕ задачи кажутся СРОЧНЫМИ — это признак проблемы:

• Плохое планирование в компании
• Нет PM для приоритизации
• Слишком много задач на одного

В таком случае:

• Скажи честно: "Я не могу всё сделать быстро. Выбери максимум 3 приоритета"
• Или просто правь самые критичные первые

Итог

В отсутствие PM я:

1. Использую матрицу Eisenhower для быстрого анализа
2. Фокусируюсь на IMPORTANT задачах
3. Выбираю URGENT из них первыми
4. Защищаю время для IMPORTANT + NOT URGENT (они предотвращают кризисы)
5. Честно коммуницирую с командой о capacity

Это простой, но очень эффективный подход, который работает 10+ лет.