Сколько времени занимает планирование
Что проверяют
Есть ли у вас процесс оценки или вы называете сроки наугад. Вопрос звучит про часы и дни, а слушают, различаете ли вы уровни планирования и понимаете ли, что оценка задачи это не обещание даты.
Как отвечать
Разделите планирование на уровни, у них разная цена:
- планирование итерации: командная встреча, обычно час или два. Если она тянется дольше, значит задачи пришли неразобранными;
- разбор задачи перед взятием: декомпозиция до кусков на день, уточнение требований, список затронутых мест. Для мелкой правки это минуты, для новой фичи половина дня;
- проектирование нетривиального куска: отдельная задача с результатом в виде схемы, контрактов и записанного решения. День или несколько, и это оправдано, когда цена ошибки высока.
Для .NET полезно назвать, что именно продумывается заранее: границы проектов в решении, публичные контракты и обратная совместимость API, схема базы и миграции, где нужна транзакция, что уходит в фоновые задачи.
Отдельно скажите, что оценку даёте диапазоном и рядом называете риски: незнакомый внешний сервис, код без тестов вокруг правки, чужая зона ответственности. И что после реализации сверяете факт с оценкой, иначе процесс не улучшается.
Где спотыкаются
Называют одно число на все случаи, вроде двух недель на планирование проекта. Без размера команды, состояния требований и цены ошибки это не оценка, а цифра из воздуха, и следующий вопрос про обоснование обычно валит.
Второе: заявляют, что планирование это потеря времени и надо сразу писать код. Собеседник слышит, что переделки в такой картине мира временем тоже не считаются, хотя именно они и съедают срок.
Третье: путают оценку и обязательство. Оценка это прогноз с погрешностью, а дата релиза берётся с запасом и включает ревью, тестирование и выкатку. Кандидат, который называет чистое время написания кода, регулярно срывает сроки.