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