Недооценивают задачи обычно джуны или опытные разработчики

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

Ошибочно считать, что недооценивают задачи только джуны. И те, и другие делают это регулярно, но причины, масштаб ошибок и их последствия — кардинально разные.

## Недооценка джуниор-разработчиками

Главная причина — недостаток опыта и знаний. Джуниор оценивает только видимую часть айсберга.

### Ключевые причины:

• Незнание полного стека технологий. Джуниор может прекрасно написать компонент на React, но не учесть время на настройку сборки (Webpack/Vite), конфигурацию окружения, деплой, написание тестов (e2e, unit).
• Отсутствие "мышечной памяти" на похожие задачи. Опытный разработчик, десять раз наступавший на одни и те же грабли, сразу заложит время на их обход. Джуниор же каждый раз открывает для себя эти грабли заново.
• Оптимизм "чистого листа". "Да, это же просто форма с двумя полями!" — думает джуниор, не представляя себе валидацию, обработку состояний загрузки и ошибок, интеграцию с бэкендом, accessibility, кросс-браузерность.
• Непонимание процессов. Джуниор может не учесть время на code review (и несколько итераций правок), согласование дизайна, обсуждение с аналитиком, написание документации.

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

// Его мысленная модель: "Вот и вся работа"
const filteredData = data.filter(item => item.name.includes(filterValue));

В реальности же нужно:

1. Спроектировать UI для фильтра (поле ввода, кнопки сброса).
2. Обработать дебаунс (для производительности).
3. Связать состояние фильтра с URL (для сохранения состояния страницы).
4. Добавить сброс фильтра при смене других параметров.
5. Протестировать различные сценарии. Итог: задача легко растягивается на 1-2 дня.

## Недооценка опытными разработчиками

Здесь причины более глубокие и системные. Опытный разработчик обычно видит задачу целиком, но недооценивает "контекстные" и "нетехнические" факторы.

### Ключевые причины:

• Проклятие знаний (Curse of Knowledge). Специалист, для которого что-то элементарно, подсознательно предполагает, что это так же просто для всех. Он может не учесть время на объяснение сложного решения команде или на менторинг того самого джуниора, который будет работать с его кодом.
• Неучёт "долга" и "легаси". Задача "добавить новое поле в форму" в зелёфилд-проекте и в legacy-системе с 10-летней историей — это небо и земля. Опытный разработчик может машинально дать оценку для "чистого" случая, забыв про спагетти-код, отсутствие документации и риск сломать неочевидные зависимости.
• Недооценка координации. Старшие разработчики часто вовлечены в множество процессов: помощь коллегам, архитектурные обсуждения, собеседования. Их индивидуальная продуктивность ниже, чем "чистое" время за кодом, что нужно закладывать в оценку.
• Системная сложность и edge cases. Джуниор не видит подводных камней, а опытный — видит, но может сознательно или бессознательно отбросить их на этапе оценки как "маловероятные". Проблема в том, что в сложных системах эти кейсы почти всегда всплывают.

Пример: Опытный разработчик оценивает задачу "мигрировать библиотеку UI-компонентов с версии 4 на версию 5" в 3 дня, основываясь на официальном гайде.

# В гайде всё выглядит просто:
npm uninstall old-ui-library
npm install new-ui-library
npx update-ui-migration

Но в реальности оказывается:

1. Некоторые breaking changes затронули кастомные темы и глобальные стили, которые писались с прицелом на внутреннюю структуру v4.
2. В проекте есть свои кастомные компоненты, наследовавшиеся от классов библиотеки, API которых изменился.
3. Необходимо обновить и протестировать 150+ snapshot-тестов.
4. Нужно провести регрессионное тестирование ключевых пользовательских сценариев. Итог: задача превращается в 2-недельный эпик с рисками для релиза.

## Вывод: кто недооценивает "опаснее"?

• Джуниоры недооценивают объём технической работы. Их ошибки предсказуемы, их можно нивелировать через менторинг, дробление задач и обязательный ревью оценок сеньором.
• Опытные разработчики недооценивают контекст, сложность системы и организационные накладные расходы. Их ошибки часто носят системный характер и имеют больший вес, так как их оценки ложатся в основу планов спринта и дорожных карт. Недосмотр сеньора может поставить под удар сроки целого проекта.

Итоговый ответ: недооценивают задачи и джуны, и опытные разработчики. Разница — в качестве и природе ошибки. Поэтому ключевая практика — коллективная оценка (planning poker), где мнение джуна ("я не знаю, как это делать") и сеньора ("я знаю, какие здесь были проблемы раньше") пересекаются, и постоянный ретроспективный анализ оценок, чтобы учиться на ошибках всей команде.