Дедлайн — вчера (часть 2) - сделаю за один час через два дня
Еще не забыли, о чем был прошлый пост? 🙂 Мы говорили, как оценивать трудоемкость задачи. А что слышно по срокам?
Предположим, вы оценили, что сделаете работу за 16 часов. Но это вовсе не значит, что через два дня клиент получит то, чего так ждет.
Почему нет?
– Спец, который будет работать над задачей, сейчас может быть занят другим проектом. А приступить к новому получится только через несколько дней.
– Спец может взять новую задачу параллельно с другими, тогда у него получится уделять ей только пару часов в день.
– Возможно, часть работы будет выполнять стажер, у которого пока уходит больше времени, чем у его старшего коллеги. К тому же его решение должен будет проверить опытный спец. А он не всегда свободен, не приступит к проверке мгновенно.
– Есть вероятность, что во время работы над новой задачей появятся другие, более приоритетные, на которые придется срочно переключиться. Например, это может быть устранение косяков по каким-то уже сданным работам, которые клиент активно тестирует.
– Имейте в виду: программировать 8 часов в день нереально. По крайней мере я не видел таких монстров, которые могли бы эффективно разрабатывать весь рабочий день. Чаще всего слышал (и мой опыт это подтверждает), что у программиста максимум 4-5 эффективных часов в день.
– В процессе работы над задачей иногда возникают вопросы, требующие уточнения у клиента. Если тот не может оперативно ответить, это тоже увеличивает срок выполнения работ.
При оценке сроков задаемся вопросами:
- Когда каждый участник проекта сможет приступить к работе?
- Сколько часов в день они смогут уделять проекту?
- Из-за чего могут возникнуть задержки?
Я как-то писал, что лучше озвучить дедлайн с запасом и сделать чуть раньше, чем проштрафиться. Если срок в 2-3 раза превышает трудоемкость, обычно у заказчика вопросов не возникает.
Ставьте 🔥, если узнали что-то новое для себя. Ну или 🤓, если давно все это применяете.
#кейсы