Re[5]: А ты прав. Метод не работает.
От: PepperLover  
Дата: 14.11.07 09:42
Оценка:
G>Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!

http://blogs.technet.com/eldar/archive/2007/11/13/2427453.aspx
Re[6]: А ты прав. Метод не работает.
От: Gaperton http://gaperton.livejournal.com
Дата: 14.11.07 10:43
Оценка:
Здравствуйте, PepperLover, Вы писали:

G>>Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!


PL>http://blogs.technet.com/eldar/archive/2007/11/13/2427453.aspx


Автор — идиот. Я вообще человек либеральных взглядов — но таким как он надо запрещать писать. Это не он про биохимию недавно писал?

обе задачи выполнились за запланированное время, которое, я напомню, оценивалось с вероятностью 80 процентов. Теперь пора вытащить школьный учебник по математике и сосчитать какова вероятность всего проекта уложиться во время, сосчитанное в Project или еще как путем сложения:

P( T1 & T2 ) = P(T1)*P(T2) = 0.8*0.8 = 0.64

То есть, если вы разбили проект всего на две части, оценили каждую с 80 процентами вероятности, то сумма имеет «надежность» всего лишь в 64 процента! Попробуйте в качестве домашнего задания, что получится если проект разбить на десять шагов? Попробовали? Ага. Чуть больше десяти процентов. Даже если вы стрясете с инженеров оценку каждого шага в 90 процентов, шансы вашего проекта из десяти шагов будут всего 35 процентов.


А теперь отрываем ВУЗ-овский учебник теории вероятностей (или википедию, за неимением учебника), и видим следующее.
1) Матожидание суммы случайных величин = сумма матожиданий. m = sum( m[i] )
2) Стандатное отклонение суммы независимых случайных величин s_dev = sqrt( sum( s_dev[i]^2 ) ).
3) Распределение суммы случайных величин с нормальным распределением — имеет также нормальное распределение.
4) Имеем: стандартное отклонение суммы независимых нормально распределенных случайных величин, выраженное в процентах к матожиданию суммы (относительное стандартное отклонение)
s_dev / m = sqrt( sum( s_dev[i]^2 ) ) / sum( m[i] )

будет стремиться к нулю при росте количества случайных величин, для положительных случайных величин которыми являются сроки задач. Доказываем:
a) Имеем, очевидно, sdev < m для всех задач в случае их нормального распределения. Иначе у нас будет нефиговая вероятность, что задача займет отрицательное время, чего быть не может. Замечаем, что формула также больше ноля.
б) Возводим формулу в квадрат.
sum( s_dev[i]^2 ) ) / ( sum( m[i] ) )^2
в) Оцениваем ее сверху, пользуясь неравенством в (а)
sum( m[i]^2 ) ) / ( sum( m[i] ) )^2
г) Уже сейчас по формуле видно, что на бесконечности это уйдет в ноль. Причина в том, что остаточный член после ракрытия скобок в знаменателе будет неограничено рости. Вот, смотрим:
sum( m[i]^2 ) ) / ( sum( m[i] ) )^2 = sum( m[i]^2 ) ) / ( sum( m[i]^2 ) + some_fuckin_growing_shit ).

Откуда следует, что относительная погрешность планирования на сумме независимых задач будет уходить в ноль при росте количества независимых задач в плане.

Если задачи зависимы, то что измениться? Формула для стандатного отклонения суммы случайных величин.
s_dev = sum( s_dev[i] ).
Только и всего. То есть, она не будет уходить в ноль, но и возрастать тоже не будет. В реальном плане всегда имеется смесь зависимых и независимых прогнозов, это надо учитывать.

Школьный учебник он открыл. Учебник, блин. Мысли он в голове удержать не может. Идиот клинический, прости господи.
Re[6]: А ты прав. Метод не работает.
От: Gaperton http://gaperton.livejournal.com
Дата: 14.11.07 18:27
Оценка:
Здравствуйте, PepperLover, Вы писали:

G>>Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!


PL>http://blogs.technet.com/eldar/archive/2007/11/13/2427453.aspx


Да, я искренне надеюсь, что автор не ты. В глаза называть автора идиотом — это было бы слишком с моей стороны. Но, блин, должен же он меру знать, в конце концов! Сначала эта биохимия, которой объясняется менеджент, потом — эти школьные учебники, которыми опровергается базовый принцип планирования!
Re[7]: А ты прав. Метод не работает.
От: Изя Рнет Беларусь  
Дата: 14.11.07 18:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>>>Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!


PL>>http://blogs.technet.com/eldar/archive/2007/11/13/2427453.aspx


G>Да, я искренне надеюсь, что автор не ты. В глаза называть автора идиотом — это было бы слишком с моей стороны. Но, блин, должен же он меру знать, в конце концов! Сначала эта биохимия, которой объясняется менеджент, потом — эти школьные учебники, которыми опровергается базовый принцип планирования!


Ну, справедливости ради, надо сказать, что оно по ходу своей статьи делает предположение, что никакая задача никогда не заканчивается раньше отведенного на нее срока, т.е. все отклонения только положительные. В этом есть некоторый смысл. Ты, кстати, сними метрики-то, и замерь распределение отклонения от предсказанного срока по каждой задаче. Это очень интересно. Впрочем, это конечно же не оправдывает откровенного ламерства автора в отношении базовой математики. Это уж извините, в глаза, не в глаза, как придется — объективный факт-с.
Re[8]: А ты прав. Метод не работает.
От: Gaperton http://gaperton.livejournal.com
Дата: 14.11.07 19:24
Оценка:
Здравствуйте, Изя Рнет, Вы писали:

ИР>Здравствуйте, Gaperton, Вы писали:


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


G>>>>Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!


PL>>>http://blogs.technet.com/eldar/archive/2007/11/13/2427453.aspx


G>>Да, я искренне надеюсь, что автор не ты. В глаза называть автора идиотом — это было бы слишком с моей стороны. Но, блин, должен же он меру знать, в конце концов! Сначала эта биохимия, которой объясняется менеджент, потом — эти школьные учебники, которыми опровергается базовый принцип планирования!


ИР>Ну, справедливости ради, надо сказать, что оно по ходу своей статьи делает предположение, что никакая задача никогда не заканчивается раньше отведенного на нее срока, т.е. все отклонения только положительные. В этом есть некоторый смысл.


А если я для задачи не срок назначаю, а оцениваю вероятностный коридор для ее завершения — как в PERT, что тогда? А если я применяю любую другую методику планирования, которая компенсирует тенденцию конкретных людей к систематической переоценке — что тогда? Скажем — PROBE Extimation, джоеловский тул, или тупо применяю поправочные коэффициенты, взятые из исторических данных? Тогда тоже перекос будет? Чушь это собачья, Билли. У таракана оторвали ноги — хлопнули в ладоши — он не убежал. Вывод — таракан слышит ушами.

При вменяемых тим-лидах и нормальной постановке задачи, аккуратном планировании с четким scope-ом проблемы, целями и критериями завершения, — бывают и в меньшую сторону. У меня, к примеру, был проект, который я закрыл в три раза быстрее, чем на него было выделено времени. И это — для проекта класса НИОКР — где надо было кроме прочего по ходу проекта понять проблемы, исследовать пути решения, составить план и выполнить его. Вторая группа заданий, которая принципиально нельзя точно запланировать — это исправления дефектов на maintenance. Так вот, эти дефекты постоянно исправляются то быстрее ожиданий, то дольше — без выраженного перекоса в ту или иную сторону. Это по сути своей тоже НИОКР.

ИР> Ты, кстати, сними метрики-то, и замерь распределение отклонения от предсказанного срока по каждой задаче. Это очень интересно.


Обязателно сниму — у меня скоро закрывается этап по одному из проектов — вот и посмотрим, что фактически получилось. Вообще — по хорошему я должен это каждую неделю контроллировать, чтобы в первые недели херовый план отсечь. Но пока, каюсь, руки не дошли как следует оперативкой заняться, форму недельного отчета тим-лида обновить и всех как следует вздрючить — расслабон у меня осенний, годовой отчет, изменение стратегии направления (думать надо много о вечном — а у меня от этого херовое настроение), и периодическое ощущение что меня все зае****. И все одновременно.

Кстати, на реальных планах матожидание с весами 1-2-1 почти не отличается от 1-4-1, потому, что средняя оценка обычно центрирована. А вот сигма — реально отличается, и имеет "физический смысл". Сейчас делаем так — прогнозируемое время завершения задач ставим на матожидание, выводим общую сигму по каждому этапу в процентах, и используем ее для коррекции общего бюджета и сроков этапа. Типа — это процент "риска". Для заказухи с жесткими датами заверения набрасываем две сигмы при планировании (98% — срок будет меньше суммы сигм при наличии независимых задач), чтоб в минус не залезть и сроки не сорвать, и одну сигму (85%), в качестве допустимого колебания и резерва, чтобы не расслабляться и не дергаться при небольших задержках.

ИР>Впрочем, это конечно же не оправдывает откровенного ламерства автора в отношении базовой математики. Это уж извините, в глаза, не в глаза, как придется — объективный факт-с.


Да ладно математики. В чем ламерства нет — ты скажи?
Re[7]: А ты прав. Метод не работает.
От: PepperLover  
Дата: 15.11.07 03:46
Оценка:
G>Да, я искренне надеюсь, что автор не ты.

Нет-с, увольте-с, просто почитываю его блог.
Этот мужик работает в Microsoft, видимо потому и умный.
Re[8]: А ты прав. Метод не работает.
От: Gaperton http://gaperton.livejournal.com
Дата: 15.11.07 10:42
Оценка:
Здравствуйте, PepperLover, Вы писали:

G>>Да, я искренне надеюсь, что автор не ты.


PL>Нет-с, увольте-с, просто почитываю его блог.

PL>Этот мужик работает в Microsoft, видимо потому и умный.

Конечно, ведь работа в Майкрософт автоматически делает людей в пять раз умнее, чем они есть, это все знают.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.