Когда я был в начале пути, мне казалось

если хорошо разобраться в задаче - можно точно сказать, сколько она займёт

Спойлер - нельзя.

Даже сейчас я регулярно ошибаюсь в оценках. И почти всегда - в одну сторону.

Пару лет назад у меня была задача, которой я дал оценку в 1-3 стори поинта. Казалось, что там всё просто - немного поправить расчёты и пойти дальше.

Я был в этом уверен. Слишком уверен.

Проблемы начались, когда я полез в логику подсчёта прибыли и убытков. Причём не в саму формулу, а в зависимость от места вызова утилиты.

И вот тут я утонул. - пограничные случаи - разные сценарии - поведение, которое меняется в зависимости от контекста

Я всё ещё думал, что "сейчас быстро поправлю". Но когда начал сравнивать реализацию с формулами аналитика, выяснилось, что часть из них вообще не сходится.

В итоге: - аналитик экстренно менял требовани - я переписывал утилиты снова и снова - добавлял новые условия и проверки

И всё это на фоне горящих сроков.

Задачу нужно было срочно отдать в тестирование. Потом влить до фичафриза. Ответственность за релиз по факту была на мне.

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

С тех пор я сильно спокойнее отношусь к словам: - "быстро поправить" - "там немного" - "давай просто чуть-чуть"

И почти всегда закладываю неопределённость, особенно если: - есть сложная бизнес-логика - формулы пришли извне - требования могут поменяться на ходу

Раньше я оценивал задачу так: "Экран + форма + запрос - 4 часа".

Сейчас думаю иначе: - "Код - 4 часа. - Всё остальное - неизвестно".

И именно это "всё остальное" почти всегда и съедает время: - уточнения требований - правки дизайна - странное поведение API - обсуждения в команде - код-ревью - и вечное "давай чуть переделаем"

Я всё ещё иногда сомневаюсь перед тем, как влить МР. Кажется, что можно ещё отполировать, упростить, сделать "на будущее".

Но опыт показывает - бесконечная полировка почти никогда не спасает от реальных проблем.

Зато помогает другое: - вовремя задать вопросы - честно сказать, где вижу риски - и не пытаться выглядеть умнее, чем ты есть

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

А вы чаще переоцениваете задачи или недооцениваете? Было что-то похожее? 👇