Здравствуйте, __kot2, Вы писали:

S>>А вот мне кажется, ровно наоборот -- на большом временном интервале может произойти многое, тут сроки как раз будут не надежными.
S>>А вот на коротких интервалах более-менее сроки будут биться. Проще оценить сроки небольших задач. И это хрень, если с такими задачами
S>>человек впервые сталкивается, а не после нескольких лет работы. Если ТС видит кодовую базу впервые и не знаком с предметной областью,
S>>это, безусловно, хрень. Иначе это -- норма.(с)
__>если посмотреть на математическую модель, то вот у нас есть план работ типа этапы abcdef и каждый из них занимает два дня плюс-минус день по статистике, тогда матожидание будет 6*2 = 12 дней и чем больше этапов, тем меньше будет колебание вокруг этого общего значения дней. проблема возникает когда возникают новые этапы, либо оценка для каждого этапа не средняя, а излишне оптимистичная была взята. то есть были такие случаи когда вместо двух дней успевали каждый этап сделать за день и какой-то горе-менеджер ставит 1 день норматив и 6 дней ожидания в сумме. а получает 12. оттуда и торчат уши разных поправочных коэффициентов, типа берем план и умножаем на два. это все недоработка планирования.

Поэтому оценки и спускают непосредственно исполнителям, чтобы получить более адекватную оценку.