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

    Введение


    Думаю, многие из вас слышали выражение «9 женщин не могут родить ребёнка за 1 месяц!». Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.
    image

    Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
    Но этот топик не об оценках трудоёмкости…
    Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
    Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

    Уверен, что многим из вас приходилось принимать какие-то решения, от которых впоследствии зависело очень многое. Как вы их принимали? Чем руководствовались? Знали ли вы наверняка, как именно будут развиваться события в зависимости от того, какой выбор был сделан? А ведь чем выше должность в иерархии управления, тем дальновидней должны быть решения и тем дороже обходятся ошибки от неверно принятых решений.
    image
    В большинстве случаев решения принимаются интуитивно, на основе жизненного и профессионального опыта. Принимая решения, на подсознательном уровне мы учитываем множество факторов, учитываем те знания, которые получили ранее. Только вот что, если вам нужно кому-то объяснить, почему вы так уверены в своём решении? Тут, конечно, можно применить все свои навыки убеждения, просто «продавить» свою позицию и успокоиться. Например, можно безапелляционно заявить: «Да я просто в этом уверен!», и проигнорировать все остальные доводы. Но это не всегда работает, особенно, если вы ниже рангом, чем те, кому вы доказываете свою позицию.

    Было бы неплохо иметь возможность перевести свои «интуитивные ощущения» в какую-то более осязаемую форму. В такую форму, которая бы позволила:
    • Осознать свои собственные ощущения
    • Проверить различные догадки
    • Наглядно и доходчиво объяснить остальным, почему то или иное решение будет более эффективным
    Понятно, что при неадекватном восприятии никакие модели не убедят человека в неправильности решения. Модель помогает не столько убедить кого-то, сколько разобраться самому в своих доводах.

    Системы поддержки принятия решений


    imageДля решения поставленных задач на помощь приходят системы поддержки принятия решений.
    Такие системы «позволяют принимать решения в сложных условиях для полного и объективного анализа предметной деятельности». Как раз то, что нам нужно при управлении проектами. Для поддержки принятия решений используют различные способы. Нас же интересует такой способ, который будет наиболее наглядным, чтобы решить задачи, указанные выше.

    Имитационное моделирование

    imageНаиболее полно этим задачам соответствует метод имитационного моделирования. Этот метод позволяет строить модели, описывающие процессы так, как они проходили бы в действительности. Такую модель можно «проиграть» во времени как для одного испытания, так и заданного их множества. Стоит, однако, помнить, что модель всегда остаётся моделью. Она никогда не сможет учесть всех факторов, но с определённой степенью достоверности позволяет делать обоснованные заключения.

    Инструменты для моделирования


    imageСуществует множество разных инструментов для моделирования. Среди них AnyLogic, GPSS и другие. Каждая из них обладает своими преимуществами и своими недостатками. У каждой из них есть свои приоритетные области применения. Не буду пытаться сравнивать эти системы, так как это выходит за рамки данного топика.

    imageВ этой статье в качестве примера я буду рассматривать систему iThink компании isee systems, inc. Эту систему я выбрал, во-первых, потому что именно про неё я услышал впервые, прочитав книгу Deadline Тома ДеМарко, а во-вторых потому, что она мне субъективно показалась наиболее простой для проведения моделирования специфических для управления проектами задач.

    Пример


    Постановка задачи

    Для простоты понимания возьму за основу пример из той самой книги, о которой я говорил выше — Deadline. В ней главный герой, мистер Томпкинс, и доктор Джамид моделируют изменение производительности команды в зависимости от разных условий. У нас «ситуация с женщинами» очень похожая, поэтому пример вполне подходит. Справедливости ради надо отметить, что, на самом деле, оригинальным источником этого примера является книга «Introduction to Systems: Thinking and ithink». (Hanowr, N H High Performance Systems, Inc, 1994).
    Для построения модели создам новый файл в iThink и на вкладке «Model» начну добавлять её элементы.
    Но прежде нужно выделить факторы и численные величины для моделирования.

    Факторы

    Для того, чтобы сократить пространные рассуждения в романическом стиле, коротко выделю те факторы, которые могут влиять на модель:
    1. Набор персонала в проект
    2. Стоимость интеграции новых членов в команду
    3. Отрицательный эффект масштаба
    4. Эффект слияния от совместной работы

    Числа

    Далее нам необходимо выделить величины, которые могут быть каким-либо образом измерены. В данном случае без этого моделирование будет невозможно.
    Итак, наши численные величины — это:
    1. Количество сотрудников
    2. Объём реализуемого функционала в условных единицах (функциональные единицы)

    Построение модели в iThink

    Для того, чтобы проще было воспринимать модель, начну её построения с конца.
    Возьмём два контейнера. Один — полный, будет символизировать собой работу, которую необходимо сделать. Второй — пустой, будет символизировать собой работу, которую команда уже выполнила. Соединим их через вентиль, который будет определять, как быстро работа из первого контейнера будет перемещаться во второй. Таким образом, этот вентиль будет характеризовать производительность команды по выполнению необходимой работы. К сожалению, iThink не очень хорошо дружит с русскоязычными подписями, поэтому все подписи буду делать на английском.
    image
    На следующем шаге нам необходимо представить процесс приёма нового персонала (напр., разработчиков) в команду. Стоит также помнить, что эффективно персонал начинает работать не сразу. Для начала новых сотрудников необходимо «ввести» в проект. Даже если это очень опытные и квалифицированные люди, им всё равно необходимо вникнуть в проект: разобраться в принятых подходах, уяснить нюансы и пр.
    На диаграмме ниже показаны:
    • облачко — ресурс-пул, откуда берутся новые сотрудники (для упрощения считаем бесконечным)
    • вентиль Income Staff — показывает, с какой скоростью люди поступают на обучение
    • контейнер New Staff — отражает сотрудников, находящихся на обучении
    • вентиль Integration Level — показывает то, с какой скоростью люди вливаются в команду после обучения
    • контейнер Effective Team — содержит сотрудников, представляющих из себя эффективно работающую команду

    image
    Далее нам необходимо связать между собой персонал (количество сотрудников) и изменение объёма реализованного/нереализованного функционала (в условных единицах). Для этого введём ещё один элемент в нашу модель — конвертер. Конвертер — это формула (правило), который преобразует одни числовые величины в другие. В данном случае конвертер будет отражать так называемый отрицательный эффект масштабаdiseconomies of scale, т.е. то, насколько менее эффективен будет каждый последующий добавленный член команды. Это поправку я заложил в виде умозрительного графика.
    image
    В iThink конвертеры могут задаваться как графически (набор значений, через которые проходит кривая), так и аналитически — в виде формулы.
    Чтобы излишне не погружаться в детали модели и не создавать базу для споров, я не буду приводить здесь формулы. Уверен, что у каждого эти формулы будут свои.
    image
    На следующем этапе добавим ещё один конвертер — «стоимость интеграции» — Integration Cost. Этот конвертер будет показывать то, насколько снижается эффективность команды при внедрении новых сотрудников («старожилы» вынуждены отвлекаться от своей основной работы для того, чтобы помогать новичкам).
    image
    Известен ещё один интересный фактор в командной работе — «эффект слияния» — Join Effect. Иногда со временем люди в команде становятся не просто суммой отдельных индивидуумов. Люди становятся Командой! Поддерживая друг друга, они начинают не только работать эффективней, чем если бы они работали поодиночке, но и легче принимать к себе новых членов команды — в дружный коллектив легче влиться (к сожалению, бывает и наоборот). Для упрощения модели укажем, что этот фактор определённым образом влияет на фактор стоимости интеграции.
    image
    На последнем этапе добавим ещё одну стрелочку так, чтобы после окончания работы прекратить нанимать новых людей. На самом деле, прекращать приём надо ещё раньше, но пока не будем усложнять модель.
    image
    Совершенствование модели

    Само собой, что представленная модель не идеальна. Естественно, в ней есть ошибки, есть пути уточнения и добавления новых факторов, влияющих на процесс.
    Например:
    • Можно добавить, что «эффект слияния» влияет на общую производительность работы и скорость интеграции (а не только на стоимость интеграции).
    • Можно добавить, что персонал на обучении способен тоже выполнять какую-то полезную работу.
    • Можно добавить фактор ухода персонала из проекта (например, по причине изменения корпоративной политики)
    В общем, простора для творчества достаточно. :)

    Принятие решения


    Теперь, собственно, о принятии решения. Полученная модель помогает принять решение о том, до каких пор «вливание» новых членов в команду остаётся ещё достаточно эффективным.
    Для того, чтобы понять, что будет происходить, запустим модель.

    В результате получим следующие графики.
    Первый график показывает, как быстро невыполненная работа будет преобразовываться в выполненную. Главное, что здесь видно, что процесс нелинейный.
    image
    А вот второй график более интересный. Он уже показывает, как именно меняется производительность команды по мере внедрения дополнительных членов команды. Из графика, например, видно, что в краткосрочном периоде производительность падает. Обратите внимание, как далеко это от прямых линий.
    image
    Чтобы понять, какое количество людей команда может относительно безболезненно принимать в свои ряды, нужно регулировать вентиль Income Staff, задавая различные значения, и повторно «прокручивать» модель.

    Заключение


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

    UPD: По просьбам трудящихся здесь доступна сама модель. Можно поэкспериментировать.
    Поделиться публикацией

    Комментарии 41

    • НЛО прилетело и опубликовало эту надпись здесь
        +22
        Не нравятся беременные женщины — можно про грибы:
        Мальчик за 1 час в среднем собираeт 3 кг грибов, а девочка — 2 кг грибов.
        Но это не значит, что они в лесу вместе за 1 час соберут 5 кг грибов.
        • НЛО прилетело и опубликовало эту надпись здесь
            +6
            Афоризму про «9 месяцев» сотни лет. И он отлично соответствует содержанию статьи!

            А про грибы лучше перефразировать, а то в коментах уже споры пошли:
            Если мы выпустим в лес молодого парня, то он соберет 3 кг ягод, если девушку-то 5 кг. Но это еще не значит, что, если мы выпустим их в лес вместе, то они соберут 8 кг ягод ;)))
              –1
              У вас девушка собирает больше парня :)
                +2
                Замечал, что парни больше в пузо ягоду кидают, чем в лукошко :)
                  +2
                  есть подозрения что эти двое вообще не будут ниче собирать, если пустить их в лес вдвоем;)
            0
            Пример с грибами, как мне кажется, не совсем корректен: зависимость сбора грибов от количества людей вполне может быть простой, а тема статьи подразумевает учет нелинейных эффектов, как необходимость времени на обучение, усложнение коммуникации в большей команде и прочие.
              +8
              Не совсем) неочевидно, возможно, но мальчик с девочкой в лесу могут не грибы собирать =)
                0
                Однако статья всё-таки о другом.
                  0
                  ах, я всё же не успел соригинальничать =)
                    0
                    С этим не поспоришь)
                    Подразумевалось, конечно, возможность экстенсивного увеличения результата работы.
                    0
                    Ну допустим, что в лесу находиться 4 кг грибов. В этом случае и мальчик, и девочка отдельно соберут по 3 и 2 кг соответственно.
                    А если их вдвоем отправить, то больше того, что есть, они не наберут )))
                    –1
                    s/ за 1 час соберут 5 кг грибов / будут собирать грибы /g
                      –1
                      Я, чего-то в примере не понял, наверное, но как раз вместе они соберут те 5 кг грибов.
                        0
                        Наверное имелось в виду что в лесу всего, например, 4 кг грибов находится :)
                          0
                          А может, они просто подумают, что нафиг им грибы? ;)
                          0
                          Зависит от того, где будут собирать. Если каждый на своей отдельной территории, то да 5 кг.
                          А если они будут рядом это делать, то плотность покрытия поверхности грибами упадёт — а она влияет на число собранных грибов за еденицу времени.
                            0
                            Т.е. над разными проектами работать?
                              0
                              Да, или над достаточно независимыми компонентами.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Автор топика — гуру аллегорий.
                            +3
                            Можно тогда сказать так: 1 программист напишет эту программу за год. Но это не значит, что 365 программистов напишут её за 1 день.
                            0
                            В общем классная статья, спасибо!.. В универе мой профиль как раз системы поддержки принятия решений. Направление классно и перспективное, но сложное :) Самом пробовал моделирование только в GPSS World. Надо попрбовать в остальных пакетах, приведенных в этой статье. Еще раз — спасибо!
                              +2
                              про это очень хорошо у Брукса написано.
                                0
                                Злободневно для меня. Спасибо.
                                  0
                                  Очень подробно тема раскрыта, спасибо.

                                  P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.
                                    0
                                    А потом еще и в тексте заметил туда же отсыл. Чтение по-диагонали до добра не доведет :(
                                    0
                                    отличный пост, очень интересно, спасибо.
                                      0
                                      Статья близка с темой моей научной работы, а потому хочу поинтересоваться полезными готовыми моделями, которые связанны с течением проектов (можно не только по разработке ПО).
                                      От себя могу добавить работы Форда (в частности его диссертацию) и книгу Software Process Dynamics by Raymond J. Madachy.
                                      И, хоть и отклоняясь от темы топика, было бы интересно посмотреть на данные по ходу реальных проектов, чтобы можно было позднее на них проверять предположения, заложенные в модели, если такие материалы где-то есть в открытом доступе и кто-нибудь поделится информацией.
                                        0
                                        Вот тут много моделей. Посмотрите. Может, найдёте что-нибудь по душе.
                                        Не гарантирую, что именно по процессу, но хоть что-то.
                                        По поводу данных… В открытом доступе такую информацию найти очень непросто. Это самое ценное, что может быть в оценке трудоёмкости — историческая калибровка. Имхо, тот, кто обладает такой информацией, не очень расположен ей делиться. Важно ещё помнить, что данные могут быть очень специфичны для данного места, типа работ и прочих условий. Проецировать их «один к одному» нужно очень осторожно.

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

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

                                        Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
                                          0
                                          Хорошая мысль. Я пока писал статью, тоже неоднократно думал об этом (а нужны ли «плюшечки»). Так вот, «плюшечки» всё-таки нужны. «Плюшечки» дают наглядность. В принципе, и без mind maps можно обойтись, оформив всё линейным списком. Но! Ради наглядности идут на усложнение представления. В картинках проще мыслить.
                                          Кроме того, в iThink есть закладка Equation, в которой все необходимые «системы уравнений» создаются самой программой (их можно редактировать) на основе графической модели.
                                          Метрика — это не модель. Я бы не стал смешивать эти понятия.
                                          Насчёт применимости моделей… все модели имеют какие-то ограничения. То, как она будет создана, и то, как будут интерпретироваться результаты целиком зависит от исследователя.
                                            –1
                                            Меня давно уже поражает в людях то, как компьютерные плюшки отучают людей от аналитических моделей в пользу имитационки. Скоро уже и уравнения типа 2х = х + 1 будут методом конечных разностей решать.
                                            0
                                            Интересный способ заранее определить развитие проекта… Как то даже не задумывался, что есть такое ПО, спасибо за обзор и примеры…
                                              0
                                              Отличная статья… читаю, а в голове всплывают несколько бывших начальников, произносящих фразу: «Нам нужно сократить сроки, что нужно докупить? Сколько и каких людей нанять? Все решают ресурсы!». А ведь новые люди должны еще «влиться» в коллектив, быстро «проникнуться» проектом.
                                                0
                                                не нужно воспринимать все буквально. если ваш начальник говорил про долгосрочную перспективу, то он прав (хоть Демарко и не согласился бы со мной, говоря, что догонять проект в конце плохая перспектива).
                                                +1
                                                Почитайте «Мифический человеко-месяц» Брукса, там это все очень подробно и просто объясняется.

                                                www.ozon.ru/context/detail/id/83760/
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    У одной женщины может быть несколько детей или ни одного.
                                                    0
                                                    Вообще-то в нецензурном варианте, как подконвойные ученые объясняли охране, почему нельзя все решить Давай — Даваем, фраза звучит так — Если бабу вдевятером дрючить она за месяц не родит.
                                                    (точнее она вообще не родит)

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.