SlideShare a Scribd company logo
1 of 9
Download to read offline
Математическая статистика для
менеджера проектов
             Максим Дорофеев



                                          Аннотация
Среди менеджеров программных проектов встречается очень много выпускников технических
ВУЗов. Однако подавляющее их большинство твердо убеждены в неприменимости полученного
образования к управленческим задачам. Это совсем не так, мало того, элементарная
математическая грамотность крайне необходима менеджеру проекта, особенно если проект
затрагивает область разработки ПО, известную своей плохой предсказуемостью и высоким
процентом неудач. В статье будут даны намеки на то, как математическая статистика
помогает взглянуть с другой стороны на задачи планирования и оценки проекта.


Введение
Самая главная мысль, с которой стоит начать, и которую я считаю аксиомой это то, что в начале
проекта узнать точную дату его завершения невозможно по фундаментальным причинам
(подробно эта тема рассматривалась в [1]). С той или иной вероятностью любая дата может быть
датой завершения, и основной задачей планирования является поиск функции плотности
распределения вероятности даты завершения проекта.

В идеальном мире длительность проекта выражается простой формулой:




Несмотря на свою простоту, справедливость этой формулы не вызывает сомнений. Основная
проблема заключается в том, что ни одна величин, стоящих в правой части нам точно неизвестна.
На неопределенность объема работ влияют следующие фундаментальные факторы:

      1. IKIWISI – этот термин хорошо известен в Agile-сообществах и является аббревиатурой I’ll
         Know It When I See It1. Наличие многостраничного технического задания, подписанного
         собственной рукой заказчика, вовсе не означает, что разработанный в точном
         соответствии с этим документом продукт, окажется способным решить основную задачу.
         Если основной целью проекта является решение проблемы заказчика, а не дословное
         следование техническому заданию, то большая часть спецификаций в начале проекта
         просто неизвестна или не верна.
      2. Естественная погрешность оценки отдельных задач. Обычно точность оценки
         индивидуальных задач при правильном подходе составляет 10%-20%. Такая точность
         является очень хорошей для программной инженерии, но все равно эту погрешность
         необходимо принимать в расчет при планировании проекта в целом.



1
    Я узнаю это, когда я это увижу
                                                 1
3. Неполнота WBS. В самом начале проекта с очень высокой вероятностью, в план будут не
      включены те задачи, которые в итоге придется выполнить. Это может происходить по
      многим причинам. Например, из-за недостаточного четкого видения проекта либо из-за
      наличия рисков: практически никогда в первой версии плана по разработке ПО не
      встречаются задачи вида «Починить сломавшийся сервер» или «Исправить конфликт с
      библиотекой стороннего производителя», хотя в реальности эти задачи приходится
      выполнять достаточно часто.

Производительность команды нам так же не известна и опять по фундаментальным причинам [2]:

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

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

Существует два принципиально различных подхода к управлению проектом в условиях большой
неопределенности:

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

В этой статье будут рассматриваться элементы второго подхода и способы их применения к
управлению проектом, выполняемым по итеративной и инкрементальной методологии.


Подвижная мишень
Многие даже опытные менеджеры считают итеративный подход не предсказуемым. «Как вы
можете предсказать дату окончания проекта, если в каждую итерацию вам добавляются новые
задачи?» - этот вопрос является номером 1 по популярности среди менеджеров, не имевших
опыта работы в хорошо настроенном итеративном процессе. Одной из причин этого вопроса
является слабая визуализация проекта. Диаграммы Гантта, считающиеся чуть ли не стандартным
способом визуализации, совершенно не подходят для итеративных проектов, в то время как
альтернативные инструменты пока еще не столь популярны. Ниже будет показан один из
альтернативных инструментов контроля итеративного проекта, известный как Enhanced Burn Down
Chart.

Детали итеративных и инкрементальных методологий достаточно хорошо изложены в литературе
(например [4]) и поэтому я позволю себе не останавливаться на этом. В общем случае в каждую
итерацию происходит одно и то же:

                                             2
1. В процессе планирования итерации команда берет в работу определенное число задач из
      общего пула (пусть в начале проекта он имеет размер относительных единиц
      трудозатрат)
   2. На протяжении этой итерации команда полностью реализует определенное число задач,
      общей «стоимостью»         относительных единиц трудозатрат, где обозначает номер
      итерации.
   3. В конце итерации команда демонстрирует потенциально готовый к поставке продукт
      заказчику. Демонстрация дает возможность глубже понять потребности заказчика и в
      результате в общий пул задач добавляются задачи «стоимостью»     . Заметим, что на
       практике       может быть и отрицательным, например, в случаях, когда заказчик
       понимает бесполезность определенных, ранее заявленных требований.

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

                                Итерация     Out(n)     In(n)
                                    1          8          4
                                    2         12          5
                                    3         14          1
                                    4         14          2
                                    5         15          3
                                            Табл. 1

Enhanced Burn Down Chart для этого проекта изображен на Рис. 1. Правила его построения просты:

   1. В самом начале проекта рисуется столбик, по высоте равный общему объему задач
      (соответствует итерации 0)
   2. В конце первой итерации рядом рисуется такой же столбик, только сверху «отрезается»
      объем выполненных задач          , а снизу «приклеивается» объем добавленных задач
            .
   3. Для каждой последующей итерации аналогичным образом рисуется очередной столбик

Таким образом, высота столбика обозначает объем оставшейся работы по окончанию итерации.
Разница между верхней границей самого первого столбика, и верхней границей столбика для
текущей итерации показывает объем работ, выполненный командой. Аналогичным образом,
нижняя граница столбиков показывает суммарный объем добавленных задач.

На Рис. 1 также присутствуют черные прямые – они являются линиями тренда, их углы наклона
показывают средние скорости выполнения задач (верхняя прямая) и добавления новых задач
(нижняя прямая). Очевидно, что спустя несколько итераций эти линии тренда должны
пересекаться, и точка их пересечения показывает ориентировочный номер последней итерации
проекта.




                                              3
Рис. 1 Пример Enhanced Burn-Down Chart

Во введении было сказано, что любая дата в будущем с той или иной вероятностью может
оказаться датой завершения проекта. Это утверждение справедливо и к номеру итерации. Ниже
будет дана схема оценки вероятности завершения проекта в ту или иную итерацию.

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




Где        и    обозначают средние значения «стоимости» выполненных и добавленных задач, а
      ,     среднеквадратичные отклонения этих величин.

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




                                                   4
и среднеквадратичным отклонением:




Имея параметры распределения, и используя способ, подробно описанный в [1], можно
вычислить вероятность каждой будущей итерации стать последней. Получив эти вероятности их
можно нанести на график с Enhanced Burn-Down Chart (см. Рис. 2). На этом графике столбиками
слева показаны вероятности закончить проект в определенную итерацию, а сплошной линией
показана кумулятивная функция распределения или вероятность завершить проект до указанной
итерации включительно.




                      Рис. 2 Enhanced Burn Down Chart с функциями распределения

Таким образом, общая схема оценки и контроля итеративного проекта выглядит примерно
следующим образом:

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

В случае, когда состав команды не меняется от проекта к проекту, можно использовать
накопленные исторические данные, измеренные в прошлом, для оценки будущих проектов. Этим
мы минимизируем неопределенность в производительности команды. В случае работы на одного
и того же заказчика над проектами примерно из той же самой области, исторические данные по
притоку новых задач также могут быть использованы, и тем самым мы учитываем IKIWISI-эффект.
Использование относительных оценок для трудозатрат позволяет нам минимизировать влияние
естественной погрешности и частично негативный эффект неполноты WBS.
                                               5
Учет неучтенных задач
В ряде случаев команде проекта приходится заниматься задачами, не относящимися, например, к
поддержке других проектов. Такое часто встречается в заказной разработке, где преобладают
небольшие по трудозатратам проекты, или в отделах внутренней автоматизации, где команда,
едва закончив работу над одной системой, берется за разработку следующей, оставляя
завершенную систему без подготовленной линии поддержки.

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

Рассмотрим пример. Пусть у нас имеются данные по числу внешних задач, выполненных
командой в предыдущие 10 итераций (Табл. 2).

                                Номер      Число внешних
                               итерации        задач
                                   1              0
                                   2              2
                                   3              1
                                   4              7
                                   5              2
                                   6              5
                                   7              2
                                   8              4
                                   9              2
                                  10              5
                                           Табл. 2

В среднем за одну итерацию добавляется 3 задачи. Однако за предыдущие 10 итерации ни разу
не было добавлено ровно 3 задачи, и это должно насторожить. Данная выборка не достаточна,
что бы судить о точном виде распределения, поэтому мы не сильно ошибемся, если будем
считать, что число добавленных внешних задач подчиняется распределению Пуассона. Если
сделать такое предположение, то построить предполагаемые функции плотности для числа
внешних задач (см. Рис. 3). Кумулятивная функция распределения говорит о том, что вероятность
получить 3 и менее внешних задачи равна 65% (в нашем примере таких случаев 6 из 10).
Соответственно, вероятность получить 4 и более внешних задач в следующей итерации равна 35%,
что совсем не мало.




                                             6
Рис. 3 Функции распределения числа внешних задач

Учет подобных флуктуаций особенно важен на относительно коротких проектах. Предположим,
что предполагаемая длительность нашего проекта составляет всего 5 итераций, с какой
вероятностью минимум в 3 итерации нам придет 4 и более задач по поддержке? Помочь ответить
на этот вопрос поможет биномиальное распределение, возвращающее вероятность получить
успехов при   испытаниях при вероятности успеха равной . Здесь под успехом мы понимаем
итерацию, с числом задач по поддержке большим или равным 4. Вероятность подобного исхода,
как это видно из Рис. 3 равна 35%. При помощи обычных офисных приложений можно вычислить,
что с вероятностью 24% не менее, чем в 3 из 5 итераций придет не менее 4-х задач по поддержке.
Другими словами, с такой вероятностью больше половины времени выполнения проекта,
команда получит число задач по поддержке, превышающее среднее значение.

Аналогичным образом можно вычислить вероятность того, что минимум в 3 из 5 итераций
команда будет получать по 2 и менее внешних задач. Вероятность такого исхода равна примерно
35%. То есть с ненулевой вероятностью команда может оказаться загруженной задачами по
поддержке меньше среднего. Опять естественным образом возникает неопределенность: с
немалой вероятностью задачи по поддержке не будут тревожить команду, и с чуть меньшей
вероятностью команда наоборот может оказаться перегруженной внешними задачами.

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

   1. На основании исторических данных, экспертных оценок и интуиции (источники
      перечислены в порядке убывания степени доверия), вычисляется кумулятивная функция
      распределения для длительности или стоимости проекта,
   2. На основе текущей стратегии компании определяется уровень толерантности к риску, то
      есть тот риск, на который компания готова идти,
   3. Используя функцию плотности распределения, находится значение
      длительности/стоимости, соответствующее определенному уровню толерантности к риску.




   Рис. 4 Определение длительности проекта, соответствующей установленному уровню толерантности к риску

На Рис. 4 показан пример кумулятивной функции распределения номера завершающей итерации.
В этом примере уровень толерантности к риску равен 80%. Если использовать хорошую
статистическую модель оценки проектов, и следовать описанному выше подходу, то в
долгосрочной перспективе это позволит получить точную оценку сверху для 80% проектов. Что
естественно, в 20% случаев оценки окажутся ниже и для удачного завершения проекта придется
прибегать к методам компенсации заниженной оценки. К сожалению, способ, дающий 100%
точность при оценке проектов до их начала, в индустрии разработки программного обеспечения
пока не известен.



                                                    8
Литература
  [1] М. Дорофеев, «Ловушки статистического планирования», Управление Проектами, N4(17),
       2009
  [2] Э. Йордон, «Путь камикадзе», Лори, 2008
  [3] G. Stepanek, “Software Projects Secrets: Why Software Projects Fail”, Apress, 2005
  [4] C. Larman, “Agile and Iterative Development: Manager’s Guide”, Addison-Wesley, 2003




                                            9

More Related Content

What's hot

Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"
Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"
Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"Kanaidi ken
 
Pmbok Processes Flow, ALL!
Pmbok Processes Flow, ALL!Pmbok Processes Flow, ALL!
Pmbok Processes Flow, ALL!Sasan Hosseyni
 
PRINCE2 Foundation Training Manual by Frank Turley
PRINCE2 Foundation Training Manual by Frank TurleyPRINCE2 Foundation Training Manual by Frank Turley
PRINCE2 Foundation Training Manual by Frank TurleyFrank Turley
 
Rpl 4-proses perangkat lunak & metrik proyek
Rpl 4-proses perangkat lunak & metrik proyekRpl 4-proses perangkat lunak & metrik proyek
Rpl 4-proses perangkat lunak & metrik proyekf' yagami
 
Perbandingan pmbok dan prince2
Perbandingan pmbok dan prince2Perbandingan pmbok dan prince2
Perbandingan pmbok dan prince2Bagus Wahyu
 
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVN
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVNSharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVN
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVNBunga Steviane,S.H
 
Learn the PRINCE2 Principles ebook
Learn the PRINCE2 Principles ebookLearn the PRINCE2 Principles ebook
Learn the PRINCE2 Principles ebookKnowledge Train
 
Chunnel Project_Development Phase
Chunnel Project_Development PhaseChunnel Project_Development Phase
Chunnel Project_Development PhaseKhyati Tewari
 
Software Project Management - Proses Manajemen Proyek
Software Project Management - Proses Manajemen ProyekSoftware Project Management - Proses Manajemen Proyek
Software Project Management - Proses Manajemen ProyekDudy Ali
 
PC 2012 PMO plan
PC 2012 PMO planPC 2012 PMO plan
PC 2012 PMO plandrewboy07
 
Manajemen ruang-lingkup-proyek
Manajemen ruang-lingkup-proyekManajemen ruang-lingkup-proyek
Manajemen ruang-lingkup-proyekFajar Baskoro
 
Materi Training 'PROJECT MANAGEMENT"
Materi Training 'PROJECT MANAGEMENT"Materi Training 'PROJECT MANAGEMENT"
Materi Training 'PROJECT MANAGEMENT"Kanaidi ken
 
VERTEX Construction Delays and Forensic Schedule Analyses
VERTEX Construction Delays and Forensic Schedule AnalysesVERTEX Construction Delays and Forensic Schedule Analyses
VERTEX Construction Delays and Forensic Schedule AnalysesThe Vertex Companies, LLC
 
Project management final report
Project management final reportProject management final report
Project management final reportSANKET SENAPATI
 
Delay analysis ... wise after the event.
Delay analysis ... wise after the event.Delay analysis ... wise after the event.
Delay analysis ... wise after the event.Tim Lloyd
 

What's hot (20)

Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"
Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"
Tahap Eksekusi Proyek _Materi Training "PROJECT MANAGEMENT"
 
Pmbok Processes Flow, ALL!
Pmbok Processes Flow, ALL!Pmbok Processes Flow, ALL!
Pmbok Processes Flow, ALL!
 
PRINCE2 Foundation Training Manual by Frank Turley
PRINCE2 Foundation Training Manual by Frank TurleyPRINCE2 Foundation Training Manual by Frank Turley
PRINCE2 Foundation Training Manual by Frank Turley
 
Rpl 4-proses perangkat lunak & metrik proyek
Rpl 4-proses perangkat lunak & metrik proyekRpl 4-proses perangkat lunak & metrik proyek
Rpl 4-proses perangkat lunak & metrik proyek
 
Perbandingan pmbok dan prince2
Perbandingan pmbok dan prince2Perbandingan pmbok dan prince2
Perbandingan pmbok dan prince2
 
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVN
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVNSharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVN
Sharing Knowledge - Hukum Kontrak Konstruksi - KJF-TSJ.REV.IVN
 
materi induksi.pptx
materi induksi.pptxmateri induksi.pptx
materi induksi.pptx
 
Learn the PRINCE2 Principles ebook
Learn the PRINCE2 Principles ebookLearn the PRINCE2 Principles ebook
Learn the PRINCE2 Principles ebook
 
07 pmp cost management exam
07 pmp cost management exam07 pmp cost management exam
07 pmp cost management exam
 
Chunnel Project_Development Phase
Chunnel Project_Development PhaseChunnel Project_Development Phase
Chunnel Project_Development Phase
 
Software Project Management - Proses Manajemen Proyek
Software Project Management - Proses Manajemen ProyekSoftware Project Management - Proses Manajemen Proyek
Software Project Management - Proses Manajemen Proyek
 
Mppl 1
Mppl 1Mppl 1
Mppl 1
 
Claim Presentation Rev 03 FINAL
Claim Presentation Rev 03 FINALClaim Presentation Rev 03 FINAL
Claim Presentation Rev 03 FINAL
 
Rkk2
Rkk2Rkk2
Rkk2
 
PC 2012 PMO plan
PC 2012 PMO planPC 2012 PMO plan
PC 2012 PMO plan
 
Manajemen ruang-lingkup-proyek
Manajemen ruang-lingkup-proyekManajemen ruang-lingkup-proyek
Manajemen ruang-lingkup-proyek
 
Materi Training 'PROJECT MANAGEMENT"
Materi Training 'PROJECT MANAGEMENT"Materi Training 'PROJECT MANAGEMENT"
Materi Training 'PROJECT MANAGEMENT"
 
VERTEX Construction Delays and Forensic Schedule Analyses
VERTEX Construction Delays and Forensic Schedule AnalysesVERTEX Construction Delays and Forensic Schedule Analyses
VERTEX Construction Delays and Forensic Schedule Analyses
 
Project management final report
Project management final reportProject management final report
Project management final report
 
Delay analysis ... wise after the event.
Delay analysis ... wise after the event.Delay analysis ... wise after the event.
Delay analysis ... wise after the event.
 

Viewers also liked

эффект выпрямления сроков
эффект выпрямления сроковэффект выпрямления сроков
эффект выпрямления сроковMaxim Dorofeev
 
Spm conf 2012_maxim_dorofeev_part_i
Spm conf 2012_maxim_dorofeev_part_iSpm conf 2012_maxim_dorofeev_part_i
Spm conf 2012_maxim_dorofeev_part_iMaxim Dorofeev
 
Построение облачных процессов с помощью Mistral
Построение облачных процессов с помощью MistralПостроение облачных процессов с помощью Mistral
Построение облачных процессов с помощью MistralCodeFest
 
CodeFest 2013. Дорофеев М. — Клеим модель правильно
CodeFest 2013. Дорофеев М. — Клеим модель правильноCodeFest 2013. Дорофеев М. — Клеим модель правильно
CodeFest 2013. Дорофеев М. — Клеим модель правильноCodeFest
 
CodeFest-2013 Maxim Dorofeev (part 1#3)
CodeFest-2013 Maxim Dorofeev (part 1#3)CodeFest-2013 Maxim Dorofeev (part 1#3)
CodeFest-2013 Maxim Dorofeev (part 1#3)Maxim Dorofeev
 
Стратегическое планирование для чайников, Ольга Гужва
Стратегическое планирование для чайников, Ольга ГужваСтратегическое планирование для чайников, Ольга Гужва
Стратегическое планирование для чайников, Ольга ГужваUKRAINKY.BIZ
 
GTD Intro (DevGarage 2012)
GTD Intro (DevGarage 2012)GTD Intro (DevGarage 2012)
GTD Intro (DevGarage 2012)Maxim Dorofeev
 
Reliable Scrum: итеративная разработка и жесткие сроки
Reliable Scrum: итеративная разработка и жесткие срокиReliable Scrum: итеративная разработка и жесткие сроки
Reliable Scrum: итеративная разработка и жесткие срокиCEE-SEC(R)
 
Максим Дорофеев
Максим ДорофеевМаксим Дорофеев
Максим ДорофеевCodeFest
 
Диаграмма разрешения конфликтов
Диаграмма разрешения конфликтовДиаграмма разрешения конфликтов
Диаграмма разрешения конфликтовMaxim Dorofeev
 

Viewers also liked (12)

эффект выпрямления сроков
эффект выпрямления сроковэффект выпрямления сроков
эффект выпрямления сроков
 
SPM Conf 2012 Part II
SPM Conf 2012 Part IISPM Conf 2012 Part II
SPM Conf 2012 Part II
 
Spm conf 2012_maxim_dorofeev_part_i
Spm conf 2012_maxim_dorofeev_part_iSpm conf 2012_maxim_dorofeev_part_i
Spm conf 2012_maxim_dorofeev_part_i
 
Построение облачных процессов с помощью Mistral
Построение облачных процессов с помощью MistralПостроение облачных процессов с помощью Mistral
Построение облачных процессов с помощью Mistral
 
CodeFest 2013. Дорофеев М. — Клеим модель правильно
CodeFest 2013. Дорофеев М. — Клеим модель правильноCodeFest 2013. Дорофеев М. — Клеим модель правильно
CodeFest 2013. Дорофеев М. — Клеим модель правильно
 
CodeFest-2013 Maxim Dorofeev (part 1#3)
CodeFest-2013 Maxim Dorofeev (part 1#3)CodeFest-2013 Maxim Dorofeev (part 1#3)
CodeFest-2013 Maxim Dorofeev (part 1#3)
 
Стратегическое планирование для чайников, Ольга Гужва
Стратегическое планирование для чайников, Ольга ГужваСтратегическое планирование для чайников, Ольга Гужва
Стратегическое планирование для чайников, Ольга Гужва
 
GTD Intro (DevGarage 2012)
GTD Intro (DevGarage 2012)GTD Intro (DevGarage 2012)
GTD Intro (DevGarage 2012)
 
Reliable Scrum: итеративная разработка и жесткие сроки
Reliable Scrum: итеративная разработка и жесткие срокиReliable Scrum: итеративная разработка и жесткие сроки
Reliable Scrum: итеративная разработка и жесткие сроки
 
Максим Дорофеев
Максим ДорофеевМаксим Дорофеев
Максим Дорофеев
 
Диаграмма разрешения конфликтов
Диаграмма разрешения конфликтовДиаграмма разрешения конфликтов
Диаграмма разрешения конфликтов
 
Why testing take so long
Why testing take so longWhy testing take so long
Why testing take so long
 

Similar to PMMagazine Statistcis4PM

Метрики кода программного обеспечения
Метрики кода программного обеспеченияМетрики кода программного обеспечения
Метрики кода программного обеспеченияTatyanazaxarova
 
Расширенная диаграмма выгорания работ в энтерпрайзе
Расширенная диаграмма выгорания работ в энтерпрайзеРасширенная диаграмма выгорания работ в энтерпрайзе
Расширенная диаграмма выгорания работ в энтерпрайзеArtem Letyushev
 
Critical Chain Project Management
Critical Chain Project ManagementCritical Chain Project Management
Critical Chain Project ManagementValerii Kosenko
 
Управление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольУправление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольNatalia Zhelnova
 
оп.05 основы программирования
оп.05 основы программированияоп.05 основы программирования
оп.05 основы программированияStepan1234
 
Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...ph.d. Dmitry Stepanov
 
Управление проектами
Управление проектамиУправление проектами
Управление проектамиMikhail Kalinin
 
Планирование проектов
Планирование проектовПланирование проектов
Планирование проектовJana Pavlenkova
 
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)Ontico
 
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
 
Сетевое моделирование
Сетевое моделированиеСетевое моделирование
Сетевое моделированиеKaterinaMakarevich
 

Similar to PMMagazine Statistcis4PM (20)

лек11 7
лек11 7лек11 7
лек11 7
 
лек11 7
лек11 7лек11 7
лек11 7
 
Метрики кода программного обеспечения
Метрики кода программного обеспеченияМетрики кода программного обеспечения
Метрики кода программного обеспечения
 
лек11 8
лек11 8лек11 8
лек11 8
 
Расширенная диаграмма выгорания работ в энтерпрайзе
Расширенная диаграмма выгорания работ в энтерпрайзеРасширенная диаграмма выгорания работ в энтерпрайзе
Расширенная диаграмма выгорания работ в энтерпрайзе
 
Critical Chain Project Management
Critical Chain Project ManagementCritical Chain Project Management
Critical Chain Project Management
 
Управление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольУправление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контроль
 
CCPM DBR Vebinar 28 01 2010
CCPM DBR Vebinar 28 01 2010CCPM DBR Vebinar 28 01 2010
CCPM DBR Vebinar 28 01 2010
 
оп.05 основы программирования
оп.05 основы программированияоп.05 основы программирования
оп.05 основы программирования
 
Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...
 
лек12
лек12лек12
лек12
 
Lection 21-22
Lection 21-22Lection 21-22
Lection 21-22
 
Методы сетевого планирвоания
Методы сетевого планирвоанияМетоды сетевого планирвоания
Методы сетевого планирвоания
 
Управление проектами
Управление проектамиУправление проектами
Управление проектами
 
Планирование проектов
Планирование проектовПланирование проектов
Планирование проектов
 
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)
Риски, которые необходимо учесть при разработке сложного проекта (Олег Бунин)
 
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...
 
Сетевое моделирование
Сетевое моделированиеСетевое моделирование
Сетевое моделирование
 
206297
206297206297
206297
 
14 project-mistakes
14 project-mistakes14 project-mistakes
14 project-mistakes
 

More from Maxim Dorofeev

Цель, модель и все такое
Цель, модель и все такоеЦель, модель и все такое
Цель, модель и все такоеMaxim Dorofeev
 
CodeFest 2013 Maxim Dorofeev Part II
CodeFest 2013 Maxim Dorofeev Part IICodeFest 2013 Maxim Dorofeev Part II
CodeFest 2013 Maxim Dorofeev Part IIMaxim Dorofeev
 
GTD Part IV (DevGarage 2012)
GTD Part IV (DevGarage 2012)GTD Part IV (DevGarage 2012)
GTD Part IV (DevGarage 2012)Maxim Dorofeev
 
GTD Part III (DevGarage 2012)
GTD Part III (DevGarage 2012)GTD Part III (DevGarage 2012)
GTD Part III (DevGarage 2012)Maxim Dorofeev
 
GTD Part II (DevGarage 2012)
GTD Part II (DevGarage 2012)GTD Part II (DevGarage 2012)
GTD Part II (DevGarage 2012)Maxim Dorofeev
 
GTD Part I (DevGarage 2012)
GTD Part I (DevGarage 2012)GTD Part I (DevGarage 2012)
GTD Part I (DevGarage 2012)Maxim Dorofeev
 
Shewhart, 6-Sigma and snowflake-men
Shewhart, 6-Sigma and snowflake-menShewhart, 6-Sigma and snowflake-men
Shewhart, 6-Sigma and snowflake-menMaxim Dorofeev
 
Project burndown template
Project burndown templateProject burndown template
Project burndown templateMaxim Dorofeev
 
Planning basics dev_labs2010_thescaleofuncertainty
Planning basics dev_labs2010_thescaleofuncertaintyPlanning basics dev_labs2010_thescaleofuncertainty
Planning basics dev_labs2010_thescaleofuncertaintyMaxim Dorofeev
 
Gtd Dev Labs2010 Part I
Gtd Dev Labs2010 Part IGtd Dev Labs2010 Part I
Gtd Dev Labs2010 Part IMaxim Dorofeev
 
Gtd Dev Labs2010 Part Iii
Gtd Dev Labs2010 Part IiiGtd Dev Labs2010 Part Iii
Gtd Dev Labs2010 Part IiiMaxim Dorofeev
 
Gtd Dev Labs2010 Part Ii
Gtd Dev Labs2010 Part IiGtd Dev Labs2010 Part Ii
Gtd Dev Labs2010 Part IiMaxim Dorofeev
 

More from Maxim Dorofeev (20)

Цель, модель и все такое
Цель, модель и все такоеЦель, модель и все такое
Цель, модель и все такое
 
CodeFest 2013 Maxim Dorofeev Part II
CodeFest 2013 Maxim Dorofeev Part IICodeFest 2013 Maxim Dorofeev Part II
CodeFest 2013 Maxim Dorofeev Part II
 
GTD Part IV (DevGarage 2012)
GTD Part IV (DevGarage 2012)GTD Part IV (DevGarage 2012)
GTD Part IV (DevGarage 2012)
 
GTD Part III (DevGarage 2012)
GTD Part III (DevGarage 2012)GTD Part III (DevGarage 2012)
GTD Part III (DevGarage 2012)
 
GTD Part II (DevGarage 2012)
GTD Part II (DevGarage 2012)GTD Part II (DevGarage 2012)
GTD Part II (DevGarage 2012)
 
GTD Part I (DevGarage 2012)
GTD Part I (DevGarage 2012)GTD Part I (DevGarage 2012)
GTD Part I (DevGarage 2012)
 
SWP2012 part II
SWP2012 part IISWP2012 part II
SWP2012 part II
 
SWP2012 part I
SWP2012 part ISWP2012 part I
SWP2012 part I
 
Shewhart, 6-Sigma and snowflake-men
Shewhart, 6-Sigma and snowflake-menShewhart, 6-Sigma and snowflake-men
Shewhart, 6-Sigma and snowflake-men
 
Mc connelchecklist
Mc connelchecklistMc connelchecklist
Mc connelchecklist
 
softwarepeople11
softwarepeople11softwarepeople11
softwarepeople11
 
Project burndown template
Project burndown templateProject burndown template
Project burndown template
 
Fixed Price Strategy
Fixed Price StrategyFixed Price Strategy
Fixed Price Strategy
 
Planning basics dev_labs2010_thescaleofuncertainty
Planning basics dev_labs2010_thescaleofuncertaintyPlanning basics dev_labs2010_thescaleofuncertainty
Planning basics dev_labs2010_thescaleofuncertainty
 
Gtd Dev Labs2010 Part I
Gtd Dev Labs2010 Part IGtd Dev Labs2010 Part I
Gtd Dev Labs2010 Part I
 
Gtd Dev Labs2010 Part Iii
Gtd Dev Labs2010 Part IiiGtd Dev Labs2010 Part Iii
Gtd Dev Labs2010 Part Iii
 
Gtd Dev Labs2010 Part Ii
Gtd Dev Labs2010 Part IiGtd Dev Labs2010 Part Ii
Gtd Dev Labs2010 Part Ii
 
SWP2010 Part II
SWP2010 Part IISWP2010 Part II
SWP2010 Part II
 
SWP2010 Part I
SWP2010 Part ISWP2010 Part I
SWP2010 Part I
 
SWP2010 Part III
SWP2010 Part IIISWP2010 Part III
SWP2010 Part III
 

PMMagazine Statistcis4PM

  • 1. Математическая статистика для менеджера проектов Максим Дорофеев Аннотация Среди менеджеров программных проектов встречается очень много выпускников технических ВУЗов. Однако подавляющее их большинство твердо убеждены в неприменимости полученного образования к управленческим задачам. Это совсем не так, мало того, элементарная математическая грамотность крайне необходима менеджеру проекта, особенно если проект затрагивает область разработки ПО, известную своей плохой предсказуемостью и высоким процентом неудач. В статье будут даны намеки на то, как математическая статистика помогает взглянуть с другой стороны на задачи планирования и оценки проекта. Введение Самая главная мысль, с которой стоит начать, и которую я считаю аксиомой это то, что в начале проекта узнать точную дату его завершения невозможно по фундаментальным причинам (подробно эта тема рассматривалась в [1]). С той или иной вероятностью любая дата может быть датой завершения, и основной задачей планирования является поиск функции плотности распределения вероятности даты завершения проекта. В идеальном мире длительность проекта выражается простой формулой: Несмотря на свою простоту, справедливость этой формулы не вызывает сомнений. Основная проблема заключается в том, что ни одна величин, стоящих в правой части нам точно неизвестна. На неопределенность объема работ влияют следующие фундаментальные факторы: 1. IKIWISI – этот термин хорошо известен в Agile-сообществах и является аббревиатурой I’ll Know It When I See It1. Наличие многостраничного технического задания, подписанного собственной рукой заказчика, вовсе не означает, что разработанный в точном соответствии с этим документом продукт, окажется способным решить основную задачу. Если основной целью проекта является решение проблемы заказчика, а не дословное следование техническому заданию, то большая часть спецификаций в начале проекта просто неизвестна или не верна. 2. Естественная погрешность оценки отдельных задач. Обычно точность оценки индивидуальных задач при правильном подходе составляет 10%-20%. Такая точность является очень хорошей для программной инженерии, но все равно эту погрешность необходимо принимать в расчет при планировании проекта в целом. 1 Я узнаю это, когда я это увижу 1
  • 2. 3. Неполнота WBS. В самом начале проекта с очень высокой вероятностью, в план будут не включены те задачи, которые в итоге придется выполнить. Это может происходить по многим причинам. Например, из-за недостаточного четкого видения проекта либо из-за наличия рисков: практически никогда в первой версии плана по разработке ПО не встречаются задачи вида «Починить сломавшийся сервер» или «Исправить конфликт с библиотекой стороннего производителя», хотя в реальности эти задачи приходится выполнять достаточно часто. Производительность команды нам так же не известна и опять по фундаментальным причинам [2]: 1. Производительность даже хороших программистов может отличаться в разы, 2. Производительность одного и того же программиста так же может отличаться в разы в зависимости от внешних условий (состав команды, предметная область проекта, личные обстоятельства). Таким образом, хоть формула и верна, но определить точные значения величин, стоящие в правой части со сколь-нибудь приемлемой точностью оказывается практически невозможно. Конечно, существуют более сложные методики оценки программных проектов, но они обладают аналогичными недостатками, и так же оказываются неспособными дать удовлетворительную оценку на ранних этапах. Существует два принципиально различных подхода к управлению проектом в условиях большой неопределенности: 1. Приложить как можно больше усилий к выяснению всех деталей с самого начала, составить подробный план и следовать ему, стараясь подчинить реальность составленному плану 2. Смириться с наличием неопределенности и быть готовым предсказывать ход проекта на основе вероятностных характеристик, уточняя план по мере выявления нового знания о проекте. В этой статье будут рассматриваться элементы второго подхода и способы их применения к управлению проектом, выполняемым по итеративной и инкрементальной методологии. Подвижная мишень Многие даже опытные менеджеры считают итеративный подход не предсказуемым. «Как вы можете предсказать дату окончания проекта, если в каждую итерацию вам добавляются новые задачи?» - этот вопрос является номером 1 по популярности среди менеджеров, не имевших опыта работы в хорошо настроенном итеративном процессе. Одной из причин этого вопроса является слабая визуализация проекта. Диаграммы Гантта, считающиеся чуть ли не стандартным способом визуализации, совершенно не подходят для итеративных проектов, в то время как альтернативные инструменты пока еще не столь популярны. Ниже будет показан один из альтернативных инструментов контроля итеративного проекта, известный как Enhanced Burn Down Chart. Детали итеративных и инкрементальных методологий достаточно хорошо изложены в литературе (например [4]) и поэтому я позволю себе не останавливаться на этом. В общем случае в каждую итерацию происходит одно и то же: 2
  • 3. 1. В процессе планирования итерации команда берет в работу определенное число задач из общего пула (пусть в начале проекта он имеет размер относительных единиц трудозатрат) 2. На протяжении этой итерации команда полностью реализует определенное число задач, общей «стоимостью» относительных единиц трудозатрат, где обозначает номер итерации. 3. В конце итерации команда демонстрирует потенциально готовый к поставке продукт заказчику. Демонстрация дает возможность глубже понять потребности заказчика и в результате в общий пул задач добавляются задачи «стоимостью» . Заметим, что на практике может быть и отрицательным, например, в случаях, когда заказчик понимает бесполезность определенных, ранее заявленных требований. Предположим, у нас есть проект, имеющий в самом начале пул задач общим объемом относительных единиц. Пусть прошло 5 итераций со следующими параметрами: Итерация Out(n) In(n) 1 8 4 2 12 5 3 14 1 4 14 2 5 15 3 Табл. 1 Enhanced Burn Down Chart для этого проекта изображен на Рис. 1. Правила его построения просты: 1. В самом начале проекта рисуется столбик, по высоте равный общему объему задач (соответствует итерации 0) 2. В конце первой итерации рядом рисуется такой же столбик, только сверху «отрезается» объем выполненных задач , а снизу «приклеивается» объем добавленных задач . 3. Для каждой последующей итерации аналогичным образом рисуется очередной столбик Таким образом, высота столбика обозначает объем оставшейся работы по окончанию итерации. Разница между верхней границей самого первого столбика, и верхней границей столбика для текущей итерации показывает объем работ, выполненный командой. Аналогичным образом, нижняя граница столбиков показывает суммарный объем добавленных задач. На Рис. 1 также присутствуют черные прямые – они являются линиями тренда, их углы наклона показывают средние скорости выполнения задач (верхняя прямая) и добавления новых задач (нижняя прямая). Очевидно, что спустя несколько итераций эти линии тренда должны пересекаться, и точка их пересечения показывает ориентировочный номер последней итерации проекта. 3
  • 4. Рис. 1 Пример Enhanced Burn-Down Chart Во введении было сказано, что любая дата в будущем с той или иной вероятностью может оказаться датой завершения проекта. Это утверждение справедливо и к номеру итерации. Ниже будет дана схема оценки вероятности завершения проекта в ту или иную итерацию. Таблица 1 содержит данные, полученные в ходе выполнения проекта, что позволяет судить о производительности команды, основываясь на реальных цифрах. По большому счету и являются случайными величинами, распределенному по определенному закону. Для простоты будем считать закон распределения нормальным. В общем случае это не верно, но в случае хорошо слаженной команды, делающей не первый проект для одного и того же заказчика, это утверждение не далеко от истины. Как известно, нормальное распределение полностью описывается двумя параметрами: средним значением и среднеквадратичным отклонением. Имея реальные данные проекта по нескольким итерациям, мы можем вычислить эти значения: Где и обозначают средние значения «стоимости» выполненных и добавленных задач, а , среднеквадратичные отклонения этих величин. Предполагая параметры распределения постоянными, легко получить функцию плотности распределения объема работ, выполненных за N итераций. Эта функция будет так же распределена по нормальному закону со средним значением: 4
  • 5. и среднеквадратичным отклонением: Имея параметры распределения, и используя способ, подробно описанный в [1], можно вычислить вероятность каждой будущей итерации стать последней. Получив эти вероятности их можно нанести на график с Enhanced Burn-Down Chart (см. Рис. 2). На этом графике столбиками слева показаны вероятности закончить проект в определенную итерацию, а сплошной линией показана кумулятивная функция распределения или вероятность завершить проект до указанной итерации включительно. Рис. 2 Enhanced Burn Down Chart с функциями распределения Таким образом, общая схема оценки и контроля итеративного проекта выглядит примерно следующим образом: 1. В самом начале проекта мы делаем наши лучшие предположения относительно параметров производительности и притока новых задач, 2. После завершения каждой итерации на основе реальных данных вычисляются новые значения параметров, и корректируется общая картина В случае, когда состав команды не меняется от проекта к проекту, можно использовать накопленные исторические данные, измеренные в прошлом, для оценки будущих проектов. Этим мы минимизируем неопределенность в производительности команды. В случае работы на одного и того же заказчика над проектами примерно из той же самой области, исторические данные по притоку новых задач также могут быть использованы, и тем самым мы учитываем IKIWISI-эффект. Использование относительных оценок для трудозатрат позволяет нам минимизировать влияние естественной погрешности и частично негативный эффект неполноты WBS. 5
  • 6. Учет неучтенных задач В ряде случаев команде проекта приходится заниматься задачами, не относящимися, например, к поддержке других проектов. Такое часто встречается в заказной разработке, где преобладают небольшие по трудозатратам проекты, или в отделах внутренней автоматизации, где команда, едва закончив работу над одной системой, берется за разработку следующей, оставляя завершенную систему без подготовленной линии поддержки. Подобные задачи возникают случайным образом и, как правило, в самый не подходящий момент. Правильно учесть влияние внешних задач не сложно, но есть одна тонкость. Часто для вычисления поправки к плану менеджеры используют только средние величины, игнорируя их разброс. Это может привести к очень серьезным промахам. Рассмотрим пример. Пусть у нас имеются данные по числу внешних задач, выполненных командой в предыдущие 10 итераций (Табл. 2). Номер Число внешних итерации задач 1 0 2 2 3 1 4 7 5 2 6 5 7 2 8 4 9 2 10 5 Табл. 2 В среднем за одну итерацию добавляется 3 задачи. Однако за предыдущие 10 итерации ни разу не было добавлено ровно 3 задачи, и это должно насторожить. Данная выборка не достаточна, что бы судить о точном виде распределения, поэтому мы не сильно ошибемся, если будем считать, что число добавленных внешних задач подчиняется распределению Пуассона. Если сделать такое предположение, то построить предполагаемые функции плотности для числа внешних задач (см. Рис. 3). Кумулятивная функция распределения говорит о том, что вероятность получить 3 и менее внешних задачи равна 65% (в нашем примере таких случаев 6 из 10). Соответственно, вероятность получить 4 и более внешних задач в следующей итерации равна 35%, что совсем не мало. 6
  • 7. Рис. 3 Функции распределения числа внешних задач Учет подобных флуктуаций особенно важен на относительно коротких проектах. Предположим, что предполагаемая длительность нашего проекта составляет всего 5 итераций, с какой вероятностью минимум в 3 итерации нам придет 4 и более задач по поддержке? Помочь ответить на этот вопрос поможет биномиальное распределение, возвращающее вероятность получить успехов при испытаниях при вероятности успеха равной . Здесь под успехом мы понимаем итерацию, с числом задач по поддержке большим или равным 4. Вероятность подобного исхода, как это видно из Рис. 3 равна 35%. При помощи обычных офисных приложений можно вычислить, что с вероятностью 24% не менее, чем в 3 из 5 итераций придет не менее 4-х задач по поддержке. Другими словами, с такой вероятностью больше половины времени выполнения проекта, команда получит число задач по поддержке, превышающее среднее значение. Аналогичным образом можно вычислить вероятность того, что минимум в 3 из 5 итераций команда будет получать по 2 и менее внешних задач. Вероятность такого исхода равна примерно 35%. То есть с ненулевой вероятностью команда может оказаться загруженной задачами по поддержке меньше среднего. Опять естественным образом возникает неопределенность: с немалой вероятностью задачи по поддержке не будут тревожить команду, и с чуть меньшей вероятностью команда наоборот может оказаться перегруженной внешними задачами. Выше рассматривалось просто число внешних задач, в то время как для планирования проекта нужно уметь оценивать трудозатраты. Очевидно, что невозможно дать точную оценку задаче, которая еще не возникла, но вполне возможно оценить вероятностные характеристики. Если сделаны хоть сколько-нибудь адекватные предположения относительно вида плотности распределения трудозатрат одной задачи, можно рассчитать и плотность распределения общих трудозатрат на внешние задачи в течение проекта. Однако с практической точки зрения будет более целесообразным измерять сразу статистические параметры трудозатраты на поддержку и учитывать их, делая поправки параметров и в модели, описанной в предыдущем разделе. 7
  • 8. Проекты с фиксированной стоимостью Вопросом под номером 2 по популярности является вопрос о стратегии оценки проектов с фиксированной стоимостью. В случае проекта с фиксированной стоимостью нам не нужно знать точную дату завершения, будет достаточно оценить дату, до наступления которой проект может быть завершен с хорошей вероятностью, то есть дать оценку сверху. Естественно, если неоправданно завысить стоимость проекта, то есть риск потерять заказчика, а если стоимость окажется заниженной, то прибыль проекта может стать отрицательной. В случае, когда требуется озвучить дату или стоимость еще до начала проекта, можно воспользоваться следующим подходом: 1. На основании исторических данных, экспертных оценок и интуиции (источники перечислены в порядке убывания степени доверия), вычисляется кумулятивная функция распределения для длительности или стоимости проекта, 2. На основе текущей стратегии компании определяется уровень толерантности к риску, то есть тот риск, на который компания готова идти, 3. Используя функцию плотности распределения, находится значение длительности/стоимости, соответствующее определенному уровню толерантности к риску. Рис. 4 Определение длительности проекта, соответствующей установленному уровню толерантности к риску На Рис. 4 показан пример кумулятивной функции распределения номера завершающей итерации. В этом примере уровень толерантности к риску равен 80%. Если использовать хорошую статистическую модель оценки проектов, и следовать описанному выше подходу, то в долгосрочной перспективе это позволит получить точную оценку сверху для 80% проектов. Что естественно, в 20% случаев оценки окажутся ниже и для удачного завершения проекта придется прибегать к методам компенсации заниженной оценки. К сожалению, способ, дающий 100% точность при оценке проектов до их начала, в индустрии разработки программного обеспечения пока не известен. 8
  • 9. Литература [1] М. Дорофеев, «Ловушки статистического планирования», Управление Проектами, N4(17), 2009 [2] Э. Йордон, «Путь камикадзе», Лори, 2008 [3] G. Stepanek, “Software Projects Secrets: Why Software Projects Fail”, Apress, 2005 [4] C. Larman, “Agile and Iterative Development: Manager’s Guide”, Addison-Wesley, 2003 9