Оценка задач в разработке: как называть сроки и не подставляться

Вопрос «сколько это займёт» звучит невинно, а потом превращается в двухнедельную просрочку и неприятный разговор. Причём чаще всего виноват не разработчик: он честно назвал число, просто оценил не то, что в итоге пришлось делать.

Разберём, откуда берётся расхождение и как называть сроки, о которых потом не жалеешь.

Почему оценки систематически занижены

Дело не в оптимизме, а в структуре работы.

Оценивается счастливый путь. В голове разработчик видит основную ветку: написать функцию, подключить к API, вернуть результат. За кадром остаются обработка ошибок, тесты, ревью, правки после ревью, миграция, выкатка, разбор того, что сломалось.

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

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

Забывается контекст-свитчинг. Три параллельные задачи занимают заметно больше, чем те же три подряд.

Отсюда практический вывод: оценивать надо не «сколько я буду писать код», а «через сколько это окажется в проде».

Декомпозиция как единственный рабочий приём

Оценка задачи целиком почти всегда ошибочна. Оценка кусков по отдельности врёт меньше, потому что мелкие шаги проще представить.

Правило простое: если кусок оценивается больше чем в день, он ещё не разложен. Разбивайте, пока не получите шаги по несколько часов.

Побочный эффект полезнее самой оценки: при декомпозиции всплывают вопросы, о которых никто не подумал. «А что делаем со старыми записями?», «а миграция под нагрузкой не заблокирует таблицу?». Каждый такой вопрос дешевле задать сейчас, чем обнаружить в пятницу вечером.

Диапазон вместо точного числа

«Три дня» звучит уверенно и почти всегда неверно. «Три-пять дней, зависит от того, придётся ли трогать старый модуль» звучит менее эффектно, зато честно и защищает обе стороны.

Ширина диапазона сама по себе информация. Оценка «две недели, а может и два дня» громко говорит, что задача непонятна и её надо сначала исследовать.

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

Отдельно про исследовательские задачи

Есть класс задач, которые в принципе не оцениваются: «разберись, почему база иногда тормозит», «выясни, можно ли перейти на другую библиотеку».

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

Буфер: сколько и как объяснять

Классический совет «умножь на два» работает лучше, чем кажется, но выглядит непрофессионально, если так и сказать.

Правильная формулировка: назвать оценку вместе с тем, что в неё входит. «Пять дней: три на разработку, день на тесты и ревью, день на выкатку и наблюдение». Тогда буфер перестаёт быть надбавкой из воздуха и становится частью работы, которую видно.

Отдельно проговорите риски: «если окажется, что старый импорт тоже надо переписывать, добавится ещё три дня». Названный заранее риск воспринимается как компетентность, а тот же риск, всплывший в конце, как срыв.

Что делать, когда не укладываешься

Правило одно: сказать сразу, как только стало понятно. Не за день до дедлайна.

Плохо: молчать до конца срока и объявить о просрочке в последний момент.

Хорошо: «на второй день выяснилось, что данные приходят в трёх разных форматах, это добавляет два дня. Варианты: сделать полное решение к четвергу или к вторнику выкатить обработку только основного формата».

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

Как отвечать про сроки на собеседовании

Вопрос «как вы оцениваете задачи» задают и на технических, и на встречах с руководителем. За ним проверяют не методику, а зрелость.

Слабый ответ: «стараюсь оценивать точно и укладываться».

Сильный ответ описывает механику: разбиваю на части, оцениваю диапазоном, отдельно называю риски и неизвестные, при отклонении сообщаю сразу с вариантами.

Часто следом спрашивают про случай, когда вы сорвали срок. Отвечать честно: назвать реальный пример, объяснить, что не учли, и что изменили в подходе после. Вариант «я всегда укладываюсь» не верит никто.

Простой чек-лист перед тем, как назвать число

Разбита ли задача на шаги по несколько часов.

Учтено ли ревью, тесты, выкатка и наблюдение после.

Известны ли все места, которые придётся трогать, или есть неисследованные.

Есть ли зависимости от других людей и команд.

Что будет, если предположения окажутся неверными.

Пять вопросов, две минуты, и оценка становится в разы точнее.

И к слову о собеседованиях

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

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