Почему у айтишных проектов наступают дидлайны?

Этот пост меня подтолкнул написать один проект, который оказался в заложниках у программиста. Проработав продолжительное время с программистами и дизайнерами, часто приходилось сталкиваться с "провальными" сроками выполнения задач по разработке софта, заявленных исполнителями. При составлении плана разработок нам приходилось учитывать, что сроки занижены на порядок и мы корректировали их в сторону увеличения - так зачастую 1 день разработки превращался в 3-4 дня. Почему и зачем?

Каждый программист делает оценку планируемой свой работы отчасти правильно, но практически всегда забывает о накладных расходах (отладка, тесты и т.п.). Превышение сроков выполнения означает лишь только то, что задача слишком велика и её нужно разбивать на подзадачи. Если время задачи выполнения оценивается опытным разработчиком, то Вы должны услышать оценки срока по каждой задаче в диапазоне от 0.5 до 16 часов, а то, что не укладывается в 16 часов (два раб.дня) следует разбивать на части.

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

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

Для наглядности приведу некоторые задачи.