Как подойти к оценке задачи на новом проекте

Что проверяют

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

Как отвечать

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

Порядок действий:

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

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

Где спотыкаются

Называют цифру, не выяснив, есть ли тестовая среда и данные.

Оценивают только прогон проверок, забывая про разбор дефектов и повторные прогоны.

Молчат о рисках, а потом объясняют срыв срока обстоятельствами, которые были известны с самого начала.