Почему тимлид неверно установил сроки задач?

Проблема неправильных сроков: почему это происходит и как это решать

Это отличный вопрос о мягких навыках и управлении проектами. Неправильно установленные сроки — частая проблема в IT, и здесь важно показать, что вы понимаете корень проблемы и можете её решать конструктивно.

Основные причины неправильных сроков

1. Недостаточное понимание задач

Тимлид может установить сроки без полного анализа:

• Не рассмотрел все edge cases
• Не учел техдолг в коде
• Не проверил зависимости от других команд
• Не учел необходимость code review

Тимлид думает: "Добавить поле в базу — 2 часа"
Реальность: 
  - 2 часа написание
  + 1 час создание миграции
  + 1 час тестирование
  + 1 час code review и правки
  + 1 час deployment и монитиринг
  = 6 часов вместо 2

2. Оптимизм и game of telephone

• Бизнес просит: "Когда будет готово?"
• Тимлид (в спешке): "Примерно за неделю"
• Разработчик получает: "Срок неделя" (хотя нужны две)

Сроки сжимаются при передаче вверх по цепочке.

3. Отсутствие буфера (buffer) на неопределенность

Опытные менеджеры добавляют буфер 30-50%:

Если разработчик говорит: "3 дня"
Тимлид ставит: "5-6 дней" (оставляя буфер)

Новичок-тимлид часто забывает о буфере.

4. Незнание современных практик

• Не учитываются code review
• Не планируется написание тестов (TDD)
• Не учитываются неожиданные баги
• Не учитывается переключение контекста

Как правильно устанавливать сроки

Метод 1: Three-Point Estimation (3-точечная оценка)

Оптимистичный сценарий (best case): 2 дня
Вероятный сценарий (most likely): 5 дней
Пессимистичный сценарий (worst case): 10 дней

Ожидаемое время = (Best + 4*Most + Worst) / 6
               = (2 + 4*5 + 10) / 6
               = 32 / 6
               ≈ 5.3 дня

Этот метод даёт более реалистичную оценку.

Метод 2: Planning Poker (в Scrum команде)

• Каждый разработчик дает свою оценку (не зная оценок других)
• Оценки обсуждаются, находится консенсус
• Это выявляет неправильные предположения

Разработчик 1: "3 дня"
Разработчик 2: "8 дней"
Разработчик 3: "5 дней"
↓
Обсуждение: почему такой разброс?
Заключение: нужно глубже проанализировать задачу

Метод 3: Историческая аналогия

Если вы делали похожую задачу раньше:

"Прошлый раз маршруты настраивались 4 дня.
Эта задача на 20% сложнее.
Оценка: 4.8 дней → 5 дней"

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

❌ НЕПРАВИЛЬНЫЙ ПОДХОД:

"Ты неправильно установил срок! Мне нужна неделя!"

Это конфронтационный и непрофессиональный подход.

✅ ПРАВИЛЬНЫЙ ПОДХОД:

Шаг 1: Анализ задачи

// Детально разбить задачу на подзадачи
Таска: Реализовать API для получения статистики

Подзадачи:
1. Создать endpoint (1 день)
2. Реализовать бизнес-логику (2 дня)
3. Написать unit тесты (1 день)
4. Написать интеграционные тесты (1 день)
5. Code review и правки (1 день)
6. Тестирование в staging (0.5 дня)

Итого: 6.5 дней

Шаг 2: Конструктивный диалог

"Я разобрал задачу на подзадачи. Вот что получилось:
1. Endpoint - 1 день
2. Логика - 2 дня
3. Тесты - 2 дня
4. Code review - 1 день
5. Staging - 0.5 дня

Моя оценка: 6.5 дней. Я опасаюсь, что на срок "3 дня" 
мы не сможем сделать нормальное качество и code review.

Можем ли мы обсудить, какие пункты можно упростить?"

Шаг 3: Предложение компромисса

"Если сроки критичны, предлагаю:
- Пропустить интеграционные тесты (добавим позже)
- Временно упростить валидацию
- Одобрить быстрый code review

Тогда можем уложиться в 4 дня. Согласны?"

Почему важно не просто согласиться на неправильный срок

❌ Если вы согласитесь на 3 дня, но реально нужно 6:

• Вы начнете спешить и делать ошибки
• Спешка → баги → hotfixes → потерпевшие пользователи
• Техдолг накапливается
• Когда срок не выдержан, конфликт и репутация
• Следующему тимлиду еще сложнее планировать

✅ Если вы честно скажете 6 дней:

• Вы сделаете качественную работу
• Кода будет надежным
• Нет спешки → меньше багов
• Репутация профессионала
• Следующие сроки будут реалистичнее

Правило 20 процентов

Всегда добавляйте ~20% буфера к своей оценке:

Есть вы думаете: "Это займет 5 дней"
Говори тимлиду: "6 дней" (плюс 20%)

Большинство задач займут ровно столько, сколько вы оценили,
или больше. Редко быстрее.

Best Practice ответ на этот вопрос на собеседовании

"Когда тимлид установит неправильный срок, я:

1. Объективно анализирую задачу и разбиваю на подзадачи

2. Открыто обсуждаю с тимлидом, объясняя свою логику

3. Предлагаю компромиссы: упрощение, отложение фич, параллельную работу

4. Беру на себя ответственность: договариваюсь о реалистичном сроке

5. Предоставляю оценки статуса — не скрываю, если отстаю

Мне важно качество и реальность, а не видимость. Лучше честный "неделю" чем обещанные "три дня" и срыв.