Как вы справляетесь с ситуацией, когда задач слишком много и дедлайны горят?

Управление перегрузом и горящими дедлайнами — практический подход

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

ШАГ 1: Остановись и оцени ситуацию (2-3 часа)

Первое, что я делаю — НЕ начинаю паниковать и НЕ сразу работаю. Нужно понять, что вообще происходит.

Вопросы, которые я задаю:

1. Все ли дедлайны действительно горят или это просто казалось?
2. Какие задачи критичны для бизнеса, а какие можно отложить?
3. Что произошло? Почему мы здесь? (scope creep? неправильная оценка? внешние факторы?)
4. Могу ли я что-то делегировать или попросить помощь?

Инструмент: Матрица приоритизации Eisenhower

           Срочно       Не срочно
Важно      ДЕЛАЙ СЕЙЧАС  ЗАПЛАНИРУЙ
Не важно   ДЕЛЕГИРУЙ     ОТЛОЖИ/ОТКЛОНИ

Пример из практики: На проекте внезапно появилось 5 критичных задач. Я остановился, провел тайм-бокс встречу с Product Owner на 30 минут и понял, что только 2 из 5 действительно критичны. Остальные можно отложить на следующий спринт. Это дало мне мысленную ясность.

ШАГ 2: Коммуникация со stakeholders (сразу же)

Честная коммуникация — ключ.

Я делаю следующее:

1. Информирую руководителя/PM о ситуации:

• "Вот текущий список задач и дедлайны"
• "Физически невозможно выполнить всё к этим срокам"
• "Вот три сценария и последствия каждого"

2. Предлагаю варианты решения:

Вариант 1: Переносим сроки

• Какие задачи можем отложить на неделю?
• Какое влияние на бизнес?

Вариант 2: Добавляем ресурсы

• Может ли кто-то помочь?
• Сколько времени на onboarding?

Вариант 3: Сокращаем scope

• Какая MVP версия может быть готова?
• Какие фичи выпускаем позже?

Вариант 4: Изменяем процесс

• Можем ли переходить на более частые маленькие релизы?
• Можем ли работать параллельно?

Пример разговора: "Привет Петр, у нас проблема. На этой неделе мне нужно:

1. Доделать анализ квартального плана (5 дней)
2. Провести UAT (3 дня)
3. Написать требования для новой фичи (4 дня)

Всего 12 дней, а у нас только 5 рабочих дней. Вот что я предлагаю: давай выберем 2 самых критичных, остальное отложим. Какие из этих трёх для бизнеса важнее?"

ШАГ 3: Приоритизация и re-planning

Я переделываю план на основе приоритетов:

День 1-2: Критичные задачи

• Фокусирую 100% внимания
• Минимум встреч и отвлечений
• Блокирую календарь

День 3-4: Важные, но не срочные

• Если есть время и энергия
• Если критичные задачи закончены

День 5+: Остаток или отложить

• Если не закончили — откладываем
• Переговариваемся со stakeholders о новых срокам

ШАГ 4: Оптимизация процесса (в течение дня)

Чтобы сэкономить время:

1. Async communication вместо синхронного

• Вместо встреч пишу письма и Slack сообщения
• Просю обратную связь в конкретное время
• Экономлю 2-3 часа в день

2. Batch processing

• Все встречи на одно время (10:00-12:00)
• Остальное время — focus time для работы
• Проверяю email только 3 раза в день

3. Делегирую рутину

• Можно ли PA или junior BA помочь с документированием?
• Можно ли junior взять на себя part of requirements?
• Я focus на критичные решения, они на execution

4. Используй шаблоны

• Вместо написания нового документа с нуля — беру шаблон
• Вместо создания новой диаграммы — адаптирую старую
• Экономлю часы

Пример: На одном проекте мне нужно было написать 5 User Stories к следующему дню. Я использовал шаблон, который создал раньше, и вместо 4 часов потратил 1.5 часа.

ШАГ 5: Здравый смысл и баланс

Важное правило: Не выгорай.

• Я не работаю по 14 часов в день регулярно
• Если дедлайн реально невозможен — скажу честно
• Не сдаю низкокачественную работу чтобы "поспешить"
• Горящие дедлайны — знак, что что-то неправильно с планированием

Долгосрочная стратегия:

• Я анализирую, почему мы в этой ситуации
• Это проблема оценки? Scope creep? Bad planning?
• Я предлагаю изменения процесса, чтобы это не повторялось

Пример из опыта: На четвёртый раз горящих дедлайнов я провел ретроспективу с командой:

• Проблема: Product Owner добавлял задачи в спринт середине спринта
• Решение: Заморозили спринт, новые задачи только в следующий
• Результат: Горящих дедлайнов стало намного меньше

ИНСТРУМЕНТЫ И МЕТОДЫ

1. Time blocking (Блокирование времени)

09:00-10:00 — Критичная задача 1 (focus time)
10:00-10:15 — Перерыв + кофе
10:15-12:00 — Критичная задача 2 (focus time)
12:00-13:00 — Meetings
13:00-14:30 — Доделываю задачи
14:30-15:00 — Email, Slack
15:00-16:00 — Planning на завтра

2. Must/Should/Nice to have

• MUST: Критично для бизнеса (делаю)
• SHOULD: Важно, но не критично (если остаётся время)
• NICE: Было бы хорошо (откладываю)

3. Риск-ориентированный подход

• Какая задача имеет самый высокий риск, если её не сделаю?
• Начинаю с того, что несёт самый высокий риск

РЕАЛЬНЫЕ ПРИМЕРЫ РЕШЕНИЙ

Пример 1: Много небольших задач

• Проблема: 20 small bugs из QA, все "важны"
• Решение: Попросил QA ранжировать по severity
• Действие: Fix критичные (P0), rest отложил
• Результат: Выпустили релиз вовремя, fixes пошли в следующий спринт

Пример 2: Конфликтующие требования

• Проблема: PM хочет фичу A, CEO хочет фичу B, клиент хочет фичу C
• Решение: Организовал 30-минутную встречу со всеми
• Действие: Все вместе выбрали приоритеты
• Результат: Прозрачность, все согласны, нет ресентимента

Пример 3: Неправильная оценка

• Проблема: Задача "3 дня" заняла 7 дней
• Решение: Рассказал PM правду день 3, предложил варианты
• Действие: Сокращили scope на MVP, rest на следующий спринт
• Результат: MVP вышел в срок, full version позже

ДОЛГОСРОЧНОЕ РЕШЕНИЕ ПРОБЛЕМЫ

Чтобы горящие дедлайны были редкостью:

1. Лучшее планирование — более точные оценки
2. Управление scope — меньше change requests в спринте
3. Буфер в плане — не планирую 100% capacity
4. Открытая коммуникация — раньше говорю о рисках
5. Регулярные ретро — учусь на ошибках

ФИНАЛЬНАЯ РЕКОМЕНДАЦИЯ

Когда дедлайны горят:

1. Сохраняй спокойствие (паника не помогает)
2. Честно оцени ситуацию (2 часа на это стоят)
3. Коммуницируй со stakeholders (они должны знать)
4. Приоритизируй ruthlessly (делай самое важное)
5. Работай эффективно (не качеством жертвуй)
6. Учись на ошибках (чтобы не повторялось)

В IT горящие дедлайны — норма. Важно как их юрить и как на них реагировать. Лучший BA — тот, кто их минимизирует и когда происходят — управляет ими профессионально.