В работе программиста есть такая штука как сроки разработки, которые нужно определить заранее, и которые нужно выдерживать. Проблема планирования сроков есть у всех. У кого-то получается вложиться в срок, у кого-то нет. Часто планы меняются, но это не отменяет процесса планирования. И от программиста всегда хотят услышать заветные цифры, когда ж он сделает работу. Хотят все: заказчики, менеджеры, технические директора, в общем - начальство.

Выдать правдивые сроки, которые можно выдержать - самое сложное, потому что каждый проект - это что-то новое. Либо новые технологии, либо новая предметная область, либо алгоритмы, либо... Да мало ли этих "либо".

Для того, чтобы получить адекватную оценку работы я стал использовать разбиение на очень подробные задачи, вплоть до вызова функций.

Например, нужно написать редактор карт помещений на Flash для какой-нибудь системы наблюдения. Тогда я сажусь и пишу:

• Шаблон приложения. 2 часа.
• Загрузка картинок с сервера. 4 часа.
• Загрузка данных о наблюдаемых объектах. 3 часа.
• Создание картинок для наблюдаемых объектов. 2 часа на каждую разновидность. 5 разновидностей. Итого 10 часов.
• Интеграция с HTML. 4 часа.
• JavaScript-интерфейс для вызовы функция A, B и C. 6 часов, по два на каждый метод.
• Ну и так далее.
• ...
• Анимация объектов. НЕТ ОЦЕНКИ. Нужны исследования. 4 часа.

Преимущества такого подхода:

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

Я несколько раз делал следующую штуку. Берусь за новую задачу. Делаю оценку путём прикидывания и медитирования (как делают многие программисты), причём оценку пессимистичную, и пишу необходимое время на листок бумаги. Потом оцениваю всё, расписывая каждую микрозадачу или микроисследование (не всё же можно точно предсказать) и пишу этот срок на листок бумаги. Второй срок всегда больше, даже если вторые оценки оптимистичные. При этом, в первом подходе всегда есть соблазн сократить срок, поддавшись оптимизму, а во втором случае, сокращать некуда, так как всё подробно расписано.