Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

8.17. Разработка калиброванной модели для оценивания времени выполнения проектов. Часть Вторая.

Некоторые нюансы такой модели
Применение описанной выше модели к каждому новому проекту - это скорее искусство, чем строгая наука, особенно когда речь идет о подсчете "суммы сложностей" проекта. Например, какие-то характеристики продукта считаются более сложными, чем другие. Менее сложные характеристики учитываются в общей сумме с коэффициентом 0,5, тогда как более сложные - с коэффициентами 1,5 или даже 2. На практике средний весовой коэффициент сложности равняется 1, особенно в очень сложных проектах, поэтому весовые коэффициенты сложностей не играют большой роли. Некоторые проекты, например проекты, связанные с выполнением технического обслуживания или модернизацией уже существующей системы, предполагают использование при выполнении этих проектов многого из того, что было разработано ранее, что позволяет в таких случаях говорить не об усложнении, а об упрощении. В этих случаях сложность выражается отрицательной величиной (например, -1). Еще одной ситуацией, когда можно говорить об упрощении, будет выполнение проекта специалистом особо высокой квалификации.
Несмотря на эти тонкости, анализ сложностей проекта и вычисление расчетного времени выполнения проекта - весьма ценный инструмент, который позволяет удовлетворить ожидания клиента. Если описанная выше модель указывает на то, что выполнение проекта затянется настолько, что он не впишется в "рыночное окно", проведение переговоров с заказчиком относительно возможности некоторого упрощения проекта иногда позволяет своевременно завершить этот проект.
Создание модели для нескольких разработчиков
Со временем все большее количество проектов Adobe Systems, связанных с разработкой принтеров, становились настолько сложными, что выполнение таких проектов единственным разработчиком оказывалось совершенно нереальным. Связь между сложностью проекта и временем его выполнения, выражающаяся моделью для одного разработчика, подтвердилась на практике, поэтому представлялось целесообразным проанализировать, как изменяется сложность проекта в целом в случае его выполнения несколькими разработчиками. Увеличение численности разработчиков, участвующих в выполнении проекта, помогает уменьшить сложность, связанную с выполнением задач проекта, хотя бы потому, что в таком случае на каждого разработчика приходится меньшее количество задач; однако увеличение численности разработчиков само по себе означает повышение сложности.
Например, на рис. 8.9 показано влияние увеличения количества разработчиков на сложность проекта, "сумма сложностей" которого равняется 9. При использовании одного разработчика выполнение такого проекта займет примерно два года. Это объясняется главным образом тем, что над каждой из задач такого проекта одному разработчику придется работать последовательно. Подключение к этому проекту второго разработчика позволяет существенно сократить время его выполнения (примерно до 13 месяцев). Во многом это объясняется тем, что два разработчика смогут поделить между собой задачи. Иными словами, сложность, связанная с выполнением задач проекта, уменьшится примерно в два раза, в то время как сложность, обусловленная увеличением количества разработчиков, повысится лишь незначительно. Подключение к этому проекту третьего разработчика не приведет к столь существенному сокращению времени выполнения проекта, как подключение второго разработчика, поскольку третий разработчик сможет принять на себя выполнение меньшего количества задач. Кроме того, при подключении третьего разработчика повысится сложность, обусловленная увеличением количества разработчиков. Из графика, показанного на рис. 8.8, видно, что при использовании слишком большой численности разработчиков время выполнения проекта даже увеличивается.
Использование меньшей численности разработчиков по сравнению с оптимальным их количеством может быть оправданно с точки зрения экономии затрат. Руководитель проекта должен оценить целесообразность такой экономии, сравнив возможную потерю прибыли, обусловленную запоздалым завершением проекта, со стоимостью использования дополнительных разработчиков, которых, кстати говоря, можно было бы задействовать в других проектах, имеющих более высокий приоритет. В данном случае третьего разработчика, возможно, следовало бы задействовать в каком-то другом проекте, подключение к которому еще одного разработчика позволило бы существенно сократить время выполнения этого проекта. 
МОДЕЛЬ ОЦЕНКИ ВРЕМЕНИ ВЫПОЛНЕНИЯ ДЛЯ НЕСКОЛЬКИХ РАЗРАБОТЧИКОВ


Модель оценки времени выполнения T (в месяцах) проекта, "сумма сложностей" которого равняется C, в случае использования нескольких разработчиков (D) имеет следующий вид:
T = 5 месяцев х 1,2C/D+0,5 х (D - 1).
Выражение C/D означает, что сложность C, связанная с выполнением задач проекта, делится между количеством разработчиков D, а выражение 0,5 х (D - 1) добавляет половину сложности при подключении каждого дополнительного разработчика. Обратите внимание на то, что при D = 1 эта модель превращается в модель оценки времени для одного разработчика.
Разработка калиброванной модели для оценивания времени выполнения проектов


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
8.16. Разработка калиброванной модели для оценивания времени выполнения проектов 8.18. Разработка калиброванной модели для оценивания времени выполнения проектов. Часть Третья.





Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта