Программистов постоянно спрашивают: «Сколько это займёт?». Зачастую этот вопрос сопровождают следующие факторы:

• Требования неясны. Никто не сделал глубокого анализа всех последствий;
• Новая фича может что-нибудь сломать в существующем коде, и вы сразу начинаете думать о том, сколько всего вам возможно придётся отрефакторить;
• У вас есть незаконченная работа с предыдущих проектов, и вам приходится учитывать её при расчёте;
• «Когда всё будет готово?» Что значит это размытое «готово»? «Готово» в смысле «когда закончу писать код» или «когда люди уже начнут использовать софт»?
• Иногда, вне зависимости от осознания всех этих вещей, «программерская гордость» заставляет нас указать или принять сроки короче тех, которые мы для себя рассчитали. Особенно часто такое бывает, когда чувствуешь давление из-за приближающегося дедлайна или завышенных ожиданий руководства.

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

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

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

Из книги «Программист-прагматик. Путь от подмастерья к мастеру»:

Что сказать, если вас просят оценить что-либоГоворите «Я отвечу позже».Почти всегда оценка сроков будет более точной, если не торопиться и потратить некоторое время, чтобы пройтись по всем стадиям, описанным в данном разделе.  К оценкам, сделанным на ходу (например, у офисной кофеварки) придётся возвращаться вновь и вновь (как, впрочем, и к кофе), теряя при этом покой.

В этом разделе авторы советуют выполнять следующую процедуру:

• Насколько точный должен быть ответ? Если вы скажете, что на проект вам потребуется 5–6 месяцев, то заказчик вряд ли обратит внимание на то, что вы сдали проект в начале седьмого месяца. Но если вы установили срок в 150 дней, то просрочка дедлайна до 180 или 210 дня будет восприниматься совсем иначе;
• Убедитесь, что понимаете, о чём вас просят. Определите объём работы;
• Постройте модель системы. Это может быть ментальная модель, диаграмма или существующие записи данных. Декомпозируйте эту модель и сделайте оценку на основе её компонентов. Каждому компоненту присвойте время на выполнение и  возможное отклонение;
• Сделайте оценку на основе вашей модели;
• Отслеживайте сроки выполнения и срывы этих сроков. Записывайте информацию о проблеме, которую вы оцениваете, и ваш прогноз по ней;
• В оценку можно включить ещё разработку и документирование требований или изменения в их спецификациях, создание и обновление проектных документов, а также проведение тестирования (модульного, интеграционного и приёмочного) и создание или обновление руководств пользователя. Если вы работаете с кем-то вместе, то много времени будет отнимать связь (телефонные звонки, электронные письма, совещания), а также слияние кода. Если вам хотят поручить объёмное задание, то при подсчёте сроков учитывайте другую работу, время на отдых (праздники, выходные, больничные), встречи и всё остальное, что может на них повлиять.

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