Почему 9 женщин не могут родить ребёнка за 1 месяц или О применении имитационного моделирования в управлении проектами

[@DeTerminator]

Не нравятся беременные женщины — можно про грибы:
Мальчик за 1 час в среднем собираeт 3 кг грибов, а девочка — 2 кг грибов.
Но это не значит, что они в лесу вместе за 1 час соберут 5 кг грибов.

[@general]

Афоризму про «9 месяцев» сотни лет. И он отлично соответствует содержанию статьи!

А про грибы лучше перефразировать, а то в коментах уже споры пошли:
Если мы выпустим в лес молодого парня, то он соберет 3 кг ягод, если девушку-то 5 кг. Но это еще не значит, что, если мы выпустим их в лес вместе, то они соберут 8 кг ягод ;)))

[@medalist]

У вас девушка собирает больше парня :)

[@note]

Замечал, что парни больше в пузо ягоду кидают, чем в лукошко :)

[@Londeren]

есть подозрения что эти двое вообще не будут ниче собирать, если пустить их в лес вдвоем;)

[@gnd]

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

[@WasD]

Не совсем) неочевидно, возможно, но мальчик с девочкой в лесу могут не грибы собирать =)

[@Jay_Di_Human]

Однако статья всё-таки о другом.

[@Untit1ed]

ах, я всё же не успел соригинальничать =)

[@gnd]

С этим не поспоришь)
Подразумевалось, конечно, возможность экстенсивного увеличения результата работы.

[@keltanas]

Ну допустим, что в лесу находиться 4 кг грибов. В этом случае и мальчик, и девочка отдельно соберут по 3 и 2 кг соответственно.
А если их вдвоем отправить, то больше того, что есть, они не наберут )))

[@Untit1ed]

s/ за 1 час соберут 5 кг грибов / будут собирать грибы /g

[@corpor]

Я, чего-то в примере не понял, наверное, но как раз вместе они соберут те 5 кг грибов.

[@promotechart]

Наверное имелось в виду что в лесу всего, например, 4 кг грибов находится :)

[@Yareactor]

А может, они просто подумают, что нафиг им грибы? ;)

[@Sauron]

Зависит от того, где будут собирать. Если каждый на своей отдельной территории, то да 5 кг.
А если они будут рядом это делать, то плотность покрытия поверхности грибами упадёт — а она влияет на число собранных грибов за еденицу времени.

[@twi]

Т.е. над разными проектами работать?

[@Sauron]

Да, или над достаточно независимыми компонентами.

[@Pasha_21]

Если мальчику и девочке каждому по 18 лет, то это не значит, что оказавшись в лесу каждый с лукошком, они займутся сбором грибов...Ведь есть другие более интересные и уврекательные занятия.

[@odiszapc]

Автор топика — гуру аллегорий.

[@Igor_Sib]

Можно тогда сказать так: 1 программист напишет эту программу за год. Но это не значит, что 365 программистов напишут её за 1 день.

[@klz]

В общем классная статья, спасибо!.. В универе мой профиль как раз системы поддержки принятия решений. Направление классно и перспективное, но сложное :) Самом пробовал моделирование только в GPSS World. Надо попрбовать в остальных пакетах, приведенных в этой статье. Еще раз — спасибо!

[@void]

про это очень хорошо у Брукса написано.

[@Shtorkin]

Злободневно для меня. Спасибо.

[@lovchy]

Очень подробно тема раскрыта, спасибо.

P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.

[@lovchy]

А потом еще и в тексте заметил туда же отсыл. Чтение по-диагонали до добра не доведет :(

[@rzoner]

отличный пост, очень интересно, спасибо.

[@gnd]

Статья близка с темой моей научной работы, а потому хочу поинтересоваться полезными готовыми моделями, которые связанны с течением проектов (можно не только по разработке ПО).
От себя могу добавить работы Форда (в частности его диссертацию) и книгу Software Process Dynamics by Raymond J. Madachy.
И, хоть и отклоняясь от темы топика, было бы интересно посмотреть на данные по ходу реальных проектов, чтобы можно было позднее на них проверять предположения, заложенные в модели, если такие материалы где-то есть в открытом доступе и кто-нибудь поделится информацией.

[@Jay_Di_Human]

Вот тут много моделей. Посмотрите. Может, найдёте что-нибудь по душе.
Не гарантирую, что именно по процессу, но хоть что-то.
По поводу данных… В открытом доступе такую информацию найти очень непросто. Это самое ценное, что может быть в оценке трудоёмкости — историческая калибровка. Имхо, тот, кто обладает такой информацией, не очень расположен ей делиться. Важно ещё помнить, что данные могут быть очень специфичны для данного места, типа работ и прочих условий. Проецировать их «один к одному» нужно очень осторожно.

Спасибо за ссылку на книгу!

[@nuald]

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

Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).

Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).

[@Jay_Di_Human]

Хорошая мысль. Я пока писал статью, тоже неоднократно думал об этом (а нужны ли «плюшечки»). Так вот, «плюшечки» всё-таки нужны. «Плюшечки» дают наглядность. В принципе, и без mind maps можно обойтись, оформив всё линейным списком. Но! Ради наглядности идут на усложнение представления. В картинках проще мыслить.
Кроме того, в iThink есть закладка Equation, в которой все необходимые «системы уравнений» создаются самой программой (их можно редактировать) на основе графической модели.
Метрика — это не модель. Я бы не стал смешивать эти понятия.
Насчёт применимости моделей… все модели имеют какие-то ограничения. То, как она будет создана, и то, как будут интерпретироваться результаты целиком зависит от исследователя.

[@dimag0g]

Меня давно уже поражает в людях то, как компьютерные плюшки отучают людей от аналитических моделей в пользу имитационки. Скоро уже и уравнения типа 2х = х + 1 будут методом конечных разностей решать.

[@Softovick]

Интересный способ заранее определить развитие проекта… Как то даже не задумывался, что есть такое ПО, спасибо за обзор и примеры…

[@lasto4kin]

Отличная статья… читаю, а в голове всплывают несколько бывших начальников, произносящих фразу: «Нам нужно сократить сроки, что нужно докупить? Сколько и каких людей нанять? Все решают ресурсы!». А ведь новые люди должны еще «влиться» в коллектив, быстро «проникнуться» проектом.

[@reydan]

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

[@mifa]

Почитайте «Мифический человеко-месяц» Брукса, там это все очень подробно и просто объясняется.

www.ozon.ru/context/detail/id/83760/

[@atomicxp]

У одной женщины может быть несколько детей или ни одного.

[@sclv]

Вообще-то в нецензурном варианте, как подконвойные ученые объясняли охране, почему нельзя все решить Давай — Даваем, фраза звучит так — Если бабу вдевятером дрючить она за месяц не родит.
(точнее она вообще не родит)