Очередная выстраданная истина

согласен :(

Как определить реальный срок проекта?
Узнать у программиста за сколько дней он сделает (X)
Функция будет такой
R=X*X+X

Блин и не поспоришь… Хотя опредлённая доля лени всё же присутствует, особенно если уж совсем не уметь правильно оценивать свои силы: даже оценив как-то то, что делаешь, вроде бы учтя риски, думаешь, вот де это пока можно отложить, а потом я поднажму… ага… щаз… Очередная неправильная оценка сроков внутри уже неправильно оцененных сроков :))

А я всегда даю на порядок завышенные сроки, на случай всякого рода форс-мажора. Хотя, почти всегда говорю заказчику, что скорее всего успею раньше, чем их потом очень радую, сдав работу на неделю раньше чем договаривались.

Ага, действительно, это относится к программистам, которые еще не научились оценивать объем работы и выдавать истинные сроки.

Вообще-то всё очень зависит от задачи. Если это создание сайта-визитки, который делался многократно этим программистом на протяжении долгого времени, то он с большой долей вероятности сможет назвать вам реальные сроки. Но если это сложный программный продукт, который содержит в себе функционал, с которым данная компания/команда не сталкивалась, то реальных сроков назвать нельзя. Есть так называемые риски, которые могут присутствовать в проекте. Это именно те задачи и подводные камни, которые не видны на первый взгляд. Поэтому программист и может назвать оптимистичный прогноз. Но реальность такова, что не смотря на появление всех этих новомодных (хотя уже так долго они существуют, что можно назвать и старомодных) тенденций в управлении проектами, IT-проекты по статистике где-то в 60% случаев — не сдаются в срок. Но самое интересное то, что те оставшиеся 40% нельзя назвать успешными. Так как завершение в срок большей их части было сделано ценой превышения первоначально запланированного бюджета в разы. Сегодня программирование пока ещё остаётся чем-то творческим и исследовательским. Поэтому есть ещё куда стремиться в развитии индустрии производства программного обеспечения. Всё-таки отрасль относительно молода и сейчас идёт период становления.

это одна из причин, почему рекомендуется использовать короткие рекомендации, но это подходит только для больших задач

Простая формула для личной оценки сроков(ёпт метод":)).
Прикинуть сколько дней это займет(t) и помножить получившееся значение на e(≈2.7).
Затем помножить итог на π(≈3.14:)) и сказать результат заказчику.
В итоге, если в процессе выполнения не одалеет понос или золотуха, то функция реального времени от прикинутого:

ƒ(t)=eπt

В управлении проектами часто необходимо пользоваться декомпозицией — разбиением и детализацией задач до такого уровня, когда ты сможешь уже оценить время (хотя бы примерно), необходимое для завершения конкретной задачи. К этому добавляются возможные риски, обычно не менее 5%, но в реальности гораздо больше.

Практика управления рисками показывает, что для сложных задач первоначально оцененное время для разработки необходимо умножить на 3. Это и будет более или менее адекватное время разработки.