Почему задача на два часа иногда занимает два дня

Есть популярная иллюзия: если код можно написать за два часа, то и задача занимает два часа.

Но код - это только верхушка айсберга.

Под водой обычно остаётся всё, что не видно в первом описании:

- требования, которые можно понять по-разному; - неописанные сценарии и исключения; - зависимость от API, дизайна или решений другой команды; - поиск похожей логики в legacy; - проверка, что исправление не сломало соседний сценарий; - QA, ревью и уточнения перед релизом.

И это не обязательно означает, что кто-то «медленно пишет код». Часто разработка замедляется потому, что команда постепенно убирает неопределённость.

Чем раньше появились ответы на вопросы «что именно делаем?», «как проверяем?» и «от кого зависим?», тем точнее оценка и спокойнее релиз.

Полезная привычка перед стартом задачи:

1. Сформулировать ожидаемый результат. 2. Проверить зависимости: API, дизайн, доступы, смежные команды. 3. Зафиксировать критерии готовности. 4. Отдельно назвать неизвестные - не прятать их внутри оптимистичной оценки.

Оценка - это не обещание угадать срок до минуты. Это способ честно показать объём работы и риски.

А у вас что чаще всего превращает «быструю задачу» в длинную: требования, интеграции, legacy, согласования или проверка?

Почему задача на два часа иногда занимает два дня | Сетка — социальная сеть от hh.ru