Чаще недооцениваешь или переоцениваешь время при планировании?

Мой опыт с оценкой времени при планировании

Начальный период: классическое недооценивание

В первые годы я был оптимистом. Я смотрел на задачу и думал:

• "Это просто SQL запрос, 15 минут"
• "Отчёт добавить легко, 30 минут"
• "Интеграция с системой? Часа два"

Реальность:

• SQL запрос → нужны тесты, граничные случаи, оптимизация → 3 часа
• Отчёт → нужны красивые шапки, группировки, форматирование → 4-5 часов
• Интеграция → обработка ошибок, синхронизация, тестирование → 2 дня

Коэффициент ошибки: 1 к 5-10x.

Я недооценивал постоянно. Мои оценки были смешны:

Оценка          │ Реальность       │ Коэффициент
────────────────┼──────────────────┼─────────────
30 мин          │ 3 часа           │ 6x
2 часа          │ 1 день           │ 4x
1 день          │ 3 дня            │ 3x
1 неделя        │ 2 недели         │ 2x

Что я не учитывал в первые годы

1. Обсуждение с клиентом — не входит в оценку, но отбирает 30% времени
2. Окружающие отвлечения — вопросы коллег, review кода, фиксы багов
3. Невидимая часть айсберга — граничные случаи, исключения, специальные условия
4. Тестирование — я недооценивал на 50%. Думал "буду тестировать по ходу", но это не работает
5. Совместимость и регрессия — новый код ломает старый код, нужно фиксить
6. Код-ревью и правки — первая версия редко подходит, нужны итерации
7. Документирование — забывал учитывать
8. Развёртывание и фиксы в боевой системе — всё работало на dev, сломалось на prod

Переломный момент: опыт крупного проекта

В 2016-2017 году я работал над интеграцией для холдинга. Исходная оценка:

• Разработка: 3 недели
• Тестирование: 1 неделя
• Развёртывание: 2 дня

Реальность:

• Разработка: 8 недель (архитектура оказалась неправильной, пришлось переделывать)
• Тестирование: 4 недели (много граничных случаев, особенно при перенесении старых данных)
• Развёртывание: 3 недели (нашли баги, которые проявились только с боевыми данными)

Итого: запланировано 6 недель, потрачено 15 недель.

Это было больно, но очень полезно. Я понял, что моя интуиция о времени неправильна.

Адаптация: что я стал делать

Техника 1: Planning Poker (с коллегами)

Вместо того чтобы оценивать сам, я обсуждаю с другими разработчиками:

Я: "Добавить отчёт по продажам"
Коллега1: "3 часа"
Коллега2: "8 часов"
Я: "4 часа"

Средняя: ~5 часов. Я всегда ошибаюсь в меньшую сторону,
на мою оценку добавляю коэффициент 1.5x → 6 часов.

Техника 2: Историческое сравнение

Я начал вести лог:

Тип задачи              │ Оценка │ Реальность │ Коэффициент
────────────────────────┼────────┼────────────┼─────────────
Простой отчёт СКД      │ 2ч     │ 4ч         │ 2x
Отчёт с логикой        │ 4ч     │ 8ч         │ 2x
Новая интеграция       │ 2д     │ 5д         │ 2.5x
Рефакторинг            │ 3д     │ 5д         │ 1.7x
Оптимизация БД         │ 4ч     │ 12ч        │ 3x
Тестирование (вдобавок)│ -      │ +30% к разработке │ -
Документация (вдобавок)│ -      │ +15% к разработке │ -

Теперь я знаю: берешь оценку → умножаешь на свой коэффициент ошибки.

Техника 3: Буфер (contingency buffer)

Оценка разработки:     10 часов
Оценка тестирования:   4 часа
Оценка code review:     2 часа
Оценка fix issues:      3 часа
━━━━━━━━━━━━━━━━━━━━━
Итого:                 19 часов

Буфер непредвиденных (20%): +4 часа
━━━━━━━━━━━━━━━━━━━━━
Финаль:                23 часа (~3 дня)

Оказалось, что 20% буфер — это мой "коэффициент реальности".

Текущая практика (2023-2024)

Опыт показал, что я немного переоцениваю, но в последние годы более точно.

Статистика последнего года:

• 60% задач: оценка совпадает с реальностью (±10%)
• 25% задач: переоценка на 20-30%
• 15% задач: недооценка на 20-50%

Ключевые факторы точности:

1. Знакомость с технологией — если я это делал раньше, ошибка ±10%
2. Ясность требований — если требования туманны, ошибка 2-3x
3. Риск неизвестного — раньше я их не учитывал, теперь добавляю 50%
4. Интеграция с другими системами — 2.5x ошибка гарантирована
5. Legacy код — ещё хуже, там +100% минимум

Мой совет при оценке

1. Разбей задачу на подзадачи — чем меньше кусочки, тем точнее оценка
2. Обсуди с коллегой — твоя оценка почти всегда ниже реальной
3. Добавь буфер — даже сейчас я добавляю 15-20%
4. Учти контекст-переключения — в реальном мире ты не работаешь 8 часов в день над одной задачей
5. Вели лог — через год ты увидишь свои паттерны ошибок
6. Будь честен — клиента лучше удивить рано завершением, чем обещать быстро и опоздать

Вывод

В начале я недооценивал на 5-10x (оптимист). Сейчас я немного переоцениваю на 10-20% (реалист).

Это идеальное состояние. Лучше сказать "неделя" и сделать за 4 дня, чем сказать "2 дня" и не сделать за неделю.

Главное правило: "Never commit to estimates, always commit to your process of estimating."