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

Как действовать если не успеваешь в срок

Этот вопрос проверяет soft skills и умение работать в команде. Это реальная ситуация, которая случается постоянно. Ключ - честность и проактивность.

Шаг 1: Осознание проблемы (как можно раньше)

Я не жду последней секунды. Как только понимаю что что-то идет не по плану:

Примерно сегодня:
Задача: 3 дня
Прошло: 1.5 дня
Прогресс: 30%
Предполагаемое окончание: 5 дней
Дедлайн: 3 дня

-> КРАСНЫЙ ФЛАГ! Нужно действовать

Шаг 2: Анализ причин

Нужно понять ЧТО пошло не так:

Технические причины:

• Неожиданная баг в зависимости
• Слишком сложная реализация
• Неправильно оценил сложность
• Нужны данные от других команд

Внешние причины:

• Больничный, срочные встречи
• Другие приоритетные задачи вскочили
• Неправильно понял требования

Способ анализа:

1. Что уже сделано?
2. Что осталось?
3. Какие блокеры?
4. Могу ли я это распараллелить?

Шаг 3: Как можно раньше сообщить в команду

Это САМОЕ ВАЖНОЕ. Я сообщаю:

Сообщение тим-лиду/менеджеру:

"Привет! Хочу рассказать про задачу [TASK_ID].

Текущая ситуация:
- Я сделал часть 1 (фильтрация, поиск)
- Осталось: интеграция с API, юнит-тесты
- Найденная проблема: API возвращает другой формат, чем описано
  (по документации должно быть { items: [...] }, а приходит { data: {...} })

Мой прогноз:
- При текущем темпе: готово будет за 2 дня (вторник)
- Дедлайн: сегодня (понедельник)

Что я предлагаю:
1. Перенести дедлайн на вторник (+1 день)
2. Я уменьшу scope: убрать unit-тесты для первого релиза, добавлю позже
3. Попросить help от [Коллега] в интеграции API (параллельно работать)

Пожалуйста, скажи какой вариант выбираешь."

Шаг 4: Предложи варианты решения

Менеджер хочет слышать варианты, не проблемы:

Вариант 1: Перенести дедлайн

Плюсы: Полная функциональность, quality не страдает
Минусы: Задержка релиза на 1 день

Вариант 2: Уменьшить scope

1-я очередь:
- Фильтрация
- Поиск
- Базовая интеграция API

2-я очередь (после релиза):
- Unit-тесты
- Пагинация
- Сортировка

Плюсы: Отправляем вовремя
Минусы: Нужна 2-я задача на доделку

Вариант 3: Привлечь помощь

Тебе нужна помощь от backend разработчика?
Может быть [Коллега] поработает на документацией API
while я делаю фронтенд?

Тогда сможем:
- Работать параллельно
- Ускорить на 30%

Шаг 5: Взять ответственность

Я не кидаю ответственность на других:

Плохо:
"Задача сложнее чем ожидал"
"Документация была неправильная"
"Backend долго делает"

Хорошо:
"Я неправильно оценил сложность"
"Я должен был раньше проверить с backend"
"Я учту это в следующих оценках"

Шаг 6: Интенсивная работа

Когда план одобрен, я:

1. Исключаю отвлечения:

   - Отключаю уведомления Slack
   - Ставлю DND (Do Not Disturb)
   - Планирую встречи на минимум
   - Один-два блока deep work 3-4 часа
   

2. Переоценю задачу:

   - Какой абсолютный минимум?
   - Могу ли я убрать еще scope?
   - Каких bugs можно избежать?
   

3. Паррелизую:

   - Пока компилируется - читаю доки
   - Пока ждёшь ревью - пишу тесты
   - Пока проходят тесты - коммитится следующий PR
   

Шаг 7: Частые обновления статуса

Эмиттим коротких обновлений:

10:30 - начал интеграцию с API
12:00 - обнаружена баг, исправляю
14:30 - готова часть 1, push in progress
16:00 - code review, нужны правки
17:00 - все готово, тестирую
17:30 - готово, мерджу в main

Шаг 8: Постмортем/ретроспектива

После завершения анализирую:

Что пошло не так:
1. Я переоценил свою скорость (+50% to estimate)
2. Не учел синхронизацию с backend
3. Не запросил help раньше

Что буду делать в следующий раз:
1. На оценку буду добавлять буфер 20-30%
2. Перед стартом синхронизирусь с зависимыми
3. Буду просить help после 1-го дня, не после 2-го
4. Буду регулярно обновлять статус (not в конце)

Это говорю на ретро или 1-1 с ментором.

Что НЕ надо делать

❌ Молчать и надеяться что "как-то получится"
❌ Сообщать за день до дедлайна
❌ Обвинять других (backend, дизайн, требования)
❌ Просить help в последнюю секунду
❌ Коммитить untested код
❌ Писать плохую документацию для тех кто будет дорабатывать
❌ Игнорировать feedback на code review

Мысленный фрейм

Лучше сказать "не успеем во вторник" в понедельник 10:00, чем в понедельник 17:00.

Менеджер может:

• Перенести дедлайн
• Убрать features
• Привлечь помощь
• Поменять приоритеты

Но это нужно ВРЕМЯ. Если сказать в последнюю минуту - нечего делать.

Реальный пример

Текущее время: понедельник 11:00
Дедлайн: вторник 18:00 (31 час)
Прогресс: 40% от задачи

Что я делаю:
1. 11:30 - Пишу сообщение менеджеру
2. 12:00 - Встреча на 15 минут, обсуждаем варианты
3. 12:15 - Решили: убрать unit-тесты, добавить в 2-ю очередь
4. 12:30 - Обновляю PR, удаляю test files
5. 14:00 - Первый PR ready to merge
6. 16:00 - Все готово, мержу в main
7. 17:00 - Вторник 9:00 - QA тестирует
8. 17:30 - Вторник 9:30 - Feature live

Вывод

Ключевые actions:

1. Рано понимай что не успеешь
2. Честно скажи в команду
3. Предложи варианты (не жди решения)
4. Возьми ответственность
5. Действуй интенсивно
6. Обновляй статус регулярно
7. Учись на ошибках

Джуниоры думают что это "стыдно" просить help. Синиоры знают что это профессионально и правильно.