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

# Управление сроками и сообщение о рисках

Краткий ответ

Если я понимаю, что не успею сделать задачу в срок, я немедленно сообщаю об этом руководителю или техлиду, предлагаю варианты решения и совместно ищу оптимальный путь вперёд.

Пошаговый подход

1. Ранее обнаружение риска

Нужно определить проблему как можно раньше, а не на финальный день дедлайна. Я:

• Регулярно отслеживаю прогресс относительно плана задачи
• Выделяю риски уже на начальном этапе разработки
• Не ждусь до последнего момента для escalation

Примечание: опытный разработчик видит подводные камни раньше,
потому что знает, где обычно появляются неожиданные проблемы.

2. Честное общение

Когда понял, что не успеешь:

✓ ПРАВИЛЬНО:
  "Я вижу, что текущий прогресс — X%, при текущей скорости 
   я закончу только к дате Y. Начальный дедлайн был Z.
   Вот что я предлагаю..."

✗ НЕПРАВИЛЬНО:
  "Надеюсь, как-то успею..." (молчание до конца сроков)
  "Это чья-то ошибка..." (обвинения без решений)

3. Предложить варианты решения

Не просто сообщи проблему, а предложи конкретные опции:

Вариант 1: Переговорить дедлайн

• Аргументированный запрос на延期 (если позволяют условия)
• Указать, на сколько дней и почему
• Для микроменеджеров это означает, что ты отвественный и честный

Вариант 2: Снизить scope

• Выделить MVP (минимально жизнеспособный продукт)
• Отложить некритичные фичи на следующий спринт
• Остальные задачи можно рефакторить позже

// Пример для sprint planning
Все задачи: A, B, C, D, E (5 дней работы)
Доступно: 3 дня

MVP (критичные): A, B (2.5 дня) ← готовим сейчас
V2 (nice-to-have): C, D, E ← следующий спринт

Вариант 3: Добавить ресурсы

• Просить помощь у другого разработчика для parallelization
• Не стесняться озвучить, в каких частях нужна помощь
• Подготовить задачи так, чтобы их можно было распределить

Вариант 4: Оптимизировать процесс

• Убрать лишние meetings
• Сфокусироваться только на критичном функционале
• Скрипт для автоматизации тестирования

4. Взять ответственность

Что делать:
- "Я визуально ошибся в оценке сложности. 
   Вот что я сделаю, чтобы компенсировать..."
- Предложить работать extra часы если нужно
- Взять задачу переделать после дедлайна

Чего НЕ делать:
- Обвинять других в delay
- Скрывать проблему и делать вид
- Обещать чудо ("я ночью сделаю")

Пример из практики

Сценарий: Разработка REST API endpoint, которая заняла вместо 1.5 дней 3 дня из-за сложности интеграции с legacy системой.

День 2 (когда стало ясно):

Разработчик менеджеру:
"Я встретил неожиданность с интеграцией базы данных legacy системы.
 Теперь я вижу, что нужно ещё минимум 1.5 дня для полного completion.

Вот мои предложения:

1. Перенести дедлайн на [дату] — я справлюсь полностью
2. Выделить только core функционал к текущему дедлайну,
   остальное — в следующую итерацию
3. Если критично — я могу работать вечером/на выходных

Что вы считаете лучше?"

Профессиональные преимущества такого подхода

1. Доверие — менеджер видит, что ты честный и предусмотрительный
2. Нет паники — проблема решается спокойно, а не в кризис
3. Карьера — люди рассчитывают на тебя, потому что ты надёжен
4. Stress management — ты не напрягаешься в панике

Что НЕ делать (антипаттерны)

// Антипаттерн 1: Молчаливая надежда
private void failSilently() {
    // молчу и надеюсь, что как-то получится
    // Результат: срыв дедлайна, потеря доверия
}

// Антипаттерн 2: Обещание невозможного
private void promiseImpossible() {
    "я доделаю все за ночь, не волнуйтесь";
    // Результат: усталость, баги, срыв
}

// Антипаттерн 3: Обвинение других
private void blameOthers() {
    "это не мой косяк, я просил XYZ раньше";
    // Результат: потеря кредита доверия
}

Заключение

Профессиональный разработчик — это не тот, кто никогда не срывает сроки, а тот, кто:

• Рано обнаруживает проблемы
• Честно сообщает о рисках
• Предлагает решения вместо жалоб
• Берёт ответственность и работает над решением

Это показывает зрелость, профессионализм и надёжность.