Введение
Думаю, многие из вас слышали выражение «9 женщин не могут родить ребёнка за 1 месяц!». Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.
Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.
Уверен, что многим из вас приходилось принимать какие-то решения, от которых впоследствии зависело очень многое. Как вы их принимали? Чем руководствовались? Знали ли вы наверняка, как именно будут развиваться события в зависимости от того, какой выбор был сделан? А ведь чем выше должность в иерархии управления, тем дальновидней должны быть решения и тем дороже обходятся ошибки от неверно принятых решений.
В большинстве случаев решения принимаются интуитивно, на основе жизненного и профессионального опыта. Принимая решения, на подсознательном уровне мы учитываем множество факторов, учитываем те знания, которые получили ранее. Только вот что, если вам нужно кому-то объяснить, почему вы так уверены в своём решении? Тут, конечно, можно применить все свои навыки убеждения, просто «продавить» свою позицию и успокоиться. Например, можно безапелляционно заявить: «Да я просто в этом уверен!», и проигнорировать все остальные доводы. Но это не всегда работает, особенно, если вы ниже рангом, чем те, кому вы доказываете свою позицию.
Было бы неплохо иметь возможность перевести свои «интуитивные ощущения» в какую-то более осязаемую форму. В такую форму, которая бы позволила:
- Осознать свои собственные ощущения
- Проверить различные догадки
- Наглядно и доходчиво объяснить остальным, почему то или иное решение будет более эффективным
Системы поддержки принятия решений
Для решения поставленных задач на помощь приходят системы поддержки принятия решений.Такие системы «позволяют принимать решения в сложных условиях для полного и объективного анализа предметной деятельности». Как раз то, что нам нужно при управлении проектами. Для поддержки принятия решений используют различные способы. Нас же интересует такой способ, который будет наиболее наглядным, чтобы решить задачи, указанные выше.
Имитационное моделирование
Наиболее полно этим задачам соответствует метод имитационного моделирования. Этот метод позволяет строить модели, описывающие процессы так, как они проходили бы в действительности. Такую модель можно «проиграть» во времени как для одного испытания, так и заданного их множества. Стоит, однако, помнить, что модель всегда остаётся моделью. Она никогда не сможет учесть всех факторов, но с определённой степенью достоверности позволяет делать обоснованные заключения.Инструменты для моделирования
Существует множество разных инструментов для моделирования. Среди них AnyLogic, GPSS и другие. Каждая из них обладает своими преимуществами и своими недостатками. У каждой из них есть свои приоритетные области применения. Не буду пытаться сравнивать эти системы, так как это выходит за рамки данного топика.
В этой статье в качестве примера я буду рассматривать систему iThink компании isee systems, inc. Эту систему я выбрал, во-первых, потому что именно про неё я услышал впервые, прочитав книгу Deadline Тома ДеМарко, а во-вторых потому, что она мне субъективно показалась наиболее простой для проведения моделирования специфических для управления проектами задач.Пример
Постановка задачи
Для простоты понимания возьму за основу пример из той самой книги, о которой я говорил выше — Deadline. В ней главный герой, мистер Томпкинс, и доктор Джамид моделируют изменение производительности команды в зависимости от разных условий. У нас «ситуация с женщинами» очень похожая, поэтому пример вполне подходит. Справедливости ради надо отметить, что, на самом деле, оригинальным источником этого примера является книга «Introduction to Systems: Thinking and ithink». (Hanowr, N H High Performance Systems, Inc, 1994).
Для построения модели создам новый файл в iThink и на вкладке «Model» начну добавлять её элементы.
Но прежде нужно выделить факторы и численные величины для моделирования.
Факторы
Для того, чтобы сократить пространные рассуждения в романическом стиле, коротко выделю те факторы, которые могут влиять на модель:
- Набор персонала в проект
- Стоимость интеграции новых членов в команду
- Отрицательный эффект масштаба
- Эффект слияния от совместной работы
Числа
Далее нам необходимо выделить величины, которые могут быть каким-либо образом измерены. В данном случае без этого моделирование будет невозможно.
Итак, наши численные величины — это:
- Количество сотрудников
- Объём реализуемого функционала в условных единицах (функциональные единицы)
Построение модели в iThink
Для того, чтобы проще было воспринимать модель, начну её построения с конца.
Возьмём два контейнера. Один — полный, будет символизировать собой работу, которую необходимо сделать. Второй — пустой, будет символизировать собой работу, которую команда уже выполнила. Соединим их через вентиль, который будет определять, как быстро работа из первого контейнера будет перемещаться во второй. Таким образом, этот вентиль будет характеризовать производительность команды по выполнению необходимой работы. К сожалению, iThink не очень хорошо дружит с русскоязычными подписями, поэтому все подписи буду делать на английском.
На следующем шаге нам необходимо представить процесс приёма нового персонала (напр., разработчиков) в команду. Стоит также помнить, что эффективно персонал начинает работать не сразу. Для начала новых сотрудников необходимо «ввести» в проект. Даже если это очень опытные и квалифицированные люди, им всё равно необходимо вникнуть в проект: разобраться в принятых подходах, уяснить нюансы и пр.
На диаграмме ниже показаны:
- облачко — ресурс-пул, откуда берутся новые сотрудники (для упрощения считаем бесконечным)
- вентиль Income Staff — показывает, с какой скоростью люди поступают на обучение
- контейнер New Staff — отражает сотрудников, находящихся на обучении
- вентиль Integration Level — показывает то, с какой скоростью люди вливаются в команду после обучения
- контейнер Effective Team — содержит сотрудников, представляющих из себя эффективно работающую команду
Далее нам необходимо связать между собой персонал (количество сотрудников) и изменение объёма реализованного/нереализованного функционала (в условных единицах). Для этого введём ещё один элемент в нашу модель — конвертер. Конвертер — это формула (правило), который преобразует одни числовые величины в другие. В данном случае конвертер будет отражать так называемый отрицательный эффект масштаба — diseconomies of scale, т.е. то, насколько менее эффективен будет каждый последующий добавленный член команды. Это поправку я заложил в виде умозрительного графика.
В iThink конвертеры могут задаваться как графически (набор значений, через которые проходит кривая), так и аналитически — в виде формулы.
Чтобы излишне не погружаться в детали модели и не создавать базу для споров, я не буду приводить здесь формулы. Уверен, что у каждого эти формулы будут свои.
На следующем этапе добавим ещё один конвертер — «стоимость интеграции» — Integration Cost. Этот конвертер будет показывать то, насколько снижается эффективность команды при внедрении новых сотрудников («старожилы» вынуждены отвлекаться от своей основной работы для того, чтобы помогать новичкам).
Известен ещё один интересный фактор в командной работе — «эффект слияния» — Join Effect. Иногда со временем люди в команде становятся не просто суммой отдельных индивидуумов. Люди становятся Командой! Поддерживая друг друга, они начинают не только работать эффективней, чем если бы они работали поодиночке, но и легче принимать к себе новых членов команды — в дружный коллектив легче влиться (к сожалению, бывает и наоборот). Для упрощения модели укажем, что этот фактор определённым образом влияет на фактор стоимости интеграции.
На последнем этапе добавим ещё одну стрелочку так, чтобы после окончания работы прекратить нанимать новых людей. На самом деле, прекращать приём надо ещё раньше, но пока не будем усложнять модель.
Совершенствование модели
Само собой, что представленная модель не идеальна. Естественно, в ней есть ошибки, есть пути уточнения и добавления новых факторов, влияющих на процесс.
Например:
- Можно добавить, что «эффект слияния» влияет на общую производительность работы и скорость интеграции (а не только на стоимость интеграции).
- Можно добавить, что персонал на обучении способен тоже выполнять какую-то полезную работу.
- Можно добавить фактор ухода персонала из проекта (например, по причине изменения корпоративной политики)
Принятие решения
Теперь, собственно, о принятии решения. Полученная модель помогает принять решение о том, до каких пор «вливание» новых членов в команду остаётся ещё достаточно эффективным.
Для того, чтобы понять, что будет происходить, запустим модель.
В результате получим следующие графики.
Первый график показывает, как быстро невыполненная работа будет преобразовываться в выполненную. Главное, что здесь видно, что процесс нелинейный.
А вот второй график более интересный. Он уже показывает, как именно меняется производительность команды по мере внедрения дополнительных членов команды. Из графика, например, видно, что в краткосрочном периоде производительность падает. Обратите внимание, как далеко это от прямых линий.
Чтобы понять, какое количество людей команда может относительно безболезненно принимать в свои ряды, нужно регулировать вентиль Income Staff, задавая различные значения, и повторно «прокручивать» модель.
Заключение
В этом топике я коротко рассказал вам, как можно замоделировать свои ощущения, проверить догадки и попробовать показать кому-либо причины и доводы того или иного принимаемого решения. К сожалению, это не гарантирует вам того, что вы сможете кого-либо убедить.
Как всегда, «серебряной пули» не существует. Имитационное моделирование не сможет за вас принимать решения и убеждать других. Никакое ПО (по крайней мере, на том уровне развития, что мы имеем сейчас) не достанет само из глубин вашего подсознания ваши предчувствия. Но, к счастью, мы имеем очень эффективные инструменты, которые помогают нам не только лучше осознать наши доводы самим, но и спрогнозировать ситуацию.
UPD: По просьбам трудящихся здесь доступна сама модель. Можно поэкспериментировать.
