Что делаешь, если не успеваешь доделать задачу в срокЧто делаешь, если не успеваешь доделать задачу в срок?

Управление сроками и приоритизация в разработке

Это вопрос о профессионализме и коммуникации. В 10+ годах опыта я встречал эту ситуацию множество раз.

Мой подход: ранняя коммуникация

Ключевое правило: не жди последнего дня, чтобы сообщить о проблеме.

Шаг 1: Оцени реалистично на день 1

Текущая дата: понедельник, Срок: пятница (5 дней)

Задача требует:

• Дизайн: 1 день
• Разработка: 3 дня
• Тестирование: 1 день Итого: 6 дней

Вывод: 5 дней недостаточно. Действие: Сообщить менеджеру ВО ВТОРНИК.

Лучше честно сказать на день 1, чем извиняться на день 5.

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

Не приходи к менеджеру только с проблемой. Приди с решениями:

Проблема: Реалистичный срок 6 дней, а сроки 5 дней

Вариант 1: Продлить срок на 1 день

• Плюсы: Качественный код, полное тестирование
• Минусы: Задержка на день

Вариант 2: Урезать скоп

• Плюсы: Укладываемся в срок
• Минусы: Некоторый функционал отложится

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

• Плюсы: Распределить нагрузку
• Минусы: Нужно время на onboarding

Практический пример из реальной работы

Неправильно: Понедельник: Начал делать, не посчитал сложность Вторник-четверг: Работаю, но становится ясно что не успею Пятница 16:00: Бегу к менеджеру с незавершённой работой

Правильно: Понедельник утро: Разбираю задачу, планирую Понедельник 14:00: Вижу что реалистичный срок дольше Вторник утро: Встреча с менеджером с предложениями Вторник 15:00: Получена обратная связь, переоцениваем Понедельник-пятница: Работаю с уменьшенным скопом Пятница: Сдаю качественный код в срок

Стратегия MVP (Minimum Viable Product)

Когда сроки критичны, я делю задачу на:

v1 (обязательно, в срок):

• Основной функционал
• Тестирование критичных путей
• Минимальная документация

v2 (в следующий спринт):

• Оптимизация
• Расширенные фильтры
• Улучшенный UX

Ночные смены: когда да, когда нет

НЕ рекомендую:

• Работать ночью постоянно (burnout)
• Жертвовать качеством из-за спешки
• Игнорировать здоровье

Основной факт: одна ночь без сна = потеря недели работоспособности.

Использую только если:

• Экстренная ситуация (критичный баг в production)
• Редко (не система, а исключение)
• С согласованием руководства

Профилактика проблем

1. Правильная оценка Оценка = разработка + тестирование + буфер Ошибка новичков: оценка только кодирование Верно: оценка * 1.5 (буфер 50%)

2. Отслеживание прогресса День 1: 10% готово День 2: 25% готово День 3: 50% готово (половина) День 4: 75% готово День 5: 95% готово

Если на день 3 только 25%, уже пора сигнализировать.

1. Регулярные обновления статуса Ежедневный стендап: Вчера: Сделал авторизацию Сегодня: Буду делать фильтры Блокеры: Ждём API от бэка Сразу видны проблемы.

Качество vs Срок

Мой подход: Качество > Срок

Лучше сдать хороший код с задержкой, чем плохой код в срок.

Почему:

• Плохой код = технический долг = замедление будущей разработки
• Баги в production = потеря доверия
• Хороший код = легче поддерживать

Но это не значит игнорировать сроки. Ищу баланс через:

• Честную оценку на старте
• Раннюю коммуникацию о проблемах
• Приоритизацию (MVP)
• Переговоры о реалистичных сроках

Ответ на собеседовании

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

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

Основной принцип: лучше сдать 80% функционала в срок, чем 100% с опозданием и багами.

В опыте честная коммуникация + приоритизация решают 95% проблем со сроками.

Не геройствую и не работаю ночами часто. Ночные смены для экстренных ситуаций, не для обычной работы.