1

Математическая статистика для менеджера проектов

Максим Дорофеев

Аннотация Среди менеджеров программных проектов встречается очень много выпускников технических

ВУЗов. Однако подавляющее их большинство твердо убеждены в неприменимости полученного

образования к управленческим задачам. Это совсем не так, мало того, элементарная

математическая грамотность крайне необходима менеджеру проекта, особенно если проект

затрагивает область разработки ПО, известную своей плохой предсказуемостью и высоким

процентом неудач. В статье будут даны намеки на то, как математическая статистика

помогает взглянуть с другой стороны на задачи планирования и оценки проекта.

Введение Самая главная мысль, с которой стоит начать, и которую я считаю аксиомой это то, что в начале

проекта узнать точную дату его завершения невозможно по фундаментальным причинам

(подробно эта тема рассматривалась в [1]). С той или иной вероятностью любая дата может быть

датой завершения, и основной задачей планирования является поиск функции плотности

распределения вероятности даты завершения проекта.

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

Несмотря на свою простоту, справедливость этой формулы не вызывает сомнений. Основная

проблема заключается в том, что ни одна величин, стоящих в правой части нам точно неизвестна.

На неопределенность объема работ влияют следующие фундаментальные факторы:

1. IKIWISI – этот термин хорошо известен в Agile-сообществах и является аббревиатурой I’ll

Know It When I See It1. Наличие многостраничного технического задания, подписанного

собственной рукой заказчика, вовсе не означает, что разработанный в точном

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

Если основной целью проекта является решение проблемы заказчика, а не дословное

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

просто неизвестна или не верна.

2. Естественная погрешность оценки отдельных задач. Обычно точность оценки

индивидуальных задач при правильном подходе составляет 10%-20%. Такая точность

является очень хорошей для программной инженерии, но все равно эту погрешность

необходимо принимать в расчет при планировании проекта в целом.

1 Я узнаю это, когда я это увижу

2

3. Неполнота WBS. В самом начале проекта с очень высокой вероятностью, в план будут не

включены те задачи, которые в итоге придется выполнить. Это может происходить по

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

наличия рисков: практически никогда в первой версии плана по разработке ПО не

встречаются задачи вида «Починить сломавшийся сервер» или «Исправить конфликт с

библиотекой стороннего производителя», хотя в реальности эти задачи приходится

выполнять достаточно часто.

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

1. Производительность даже хороших программистов может отличаться в разы,

2. Производительность одного и того же программиста так же может отличаться в разы в

зависимости от внешних условий (состав команды, предметная область проекта, личные

обстоятельства).

Таким образом, хоть формула и верна, но определить точные значения величин, стоящие в

правой части со сколь-нибудь приемлемой точностью оказывается практически невозможно.

Конечно, существуют более сложные методики оценки программных проектов, но они обладают

аналогичными недостатками, и так же оказываются неспособными дать удовлетворительную

оценку на ранних этапах.

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

неопределенности:

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

составить подробный план и следовать ему, стараясь подчинить реальность

составленному плану

2. Смириться с наличием неопределенности и быть готовым предсказывать ход проекта на

основе вероятностных характеристик, уточняя план по мере выявления нового знания о

проекте.

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

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

Подвижная мишень Многие даже опытные менеджеры считают итеративный подход не предсказуемым. «Как вы

можете предсказать дату окончания проекта, если в каждую итерацию вам добавляются новые

задачи?» - этот вопрос является номером 1 по популярности среди менеджеров, не имевших

опыта работы в хорошо настроенном итеративном процессе. Одной из причин этого вопроса

является слабая визуализация проекта. Диаграммы Гантта, считающиеся чуть ли не стандартным

способом визуализации, совершенно не подходят для итеративных проектов, в то время как

альтернативные инструменты пока еще не столь популярны. Ниже будет показан один из

альтернативных инструментов контроля итеративного проекта, известный как Enhanced Burn Down

Chart.

Детали итеративных и инкрементальных методологий достаточно хорошо изложены в литературе

(например [4]) и поэтому я позволю себе не останавливаться на этом. В общем случае в каждую

итерацию происходит одно и то же:

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 также присутствуют черные прямые – они являются линиями тренда, их углы наклона

показывают средние скорости выполнения задач (верхняя прямая) и добавления новых задач

(нижняя прямая). Очевидно, что спустя несколько итераций эти линии тренда должны

пересекаться, и точка их пересечения показывает ориентировочный номер последней итерации

проекта.

4

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

Во введении было сказано, что любая дата в будущем с той или иной вероятностью может

оказаться датой завершения проекта. Это утверждение справедливо и к номеру итерации. Ниже

будет дана схема оценки вероятности завершения проекта в ту или иную итерацию.

Таблица 1 содержит данные, полученные в ходе выполнения проекта, что позволяет судить о

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

являются случайными величинами, распределенному по определенному закону. Для

простоты будем считать закон распределения нормальным. В общем случае это не верно, но в

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

это утверждение не далеко от истины. Как известно, нормальное распределение полностью

описывается двумя параметрами: средним значением и среднеквадратичным отклонением. Имея

реальные данные проекта по нескольким итерациям, мы можем вычислить эти значения:

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

, среднеквадратичные отклонения этих величин.

Предполагая параметры распределения постоянными, легко получить функцию плотности

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

распределена по нормальному закону со средним значением:

5

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

Имея параметры распределения, и используя способ, подробно описанный в [1], можно

вычислить вероятность каждой будущей итерации стать последней. Получив эти вероятности их

можно нанести на график с Enhanced Burn-Down Chart (см. Рис. 2). На этом графике столбиками

слева показаны вероятности закончить проект в определенную итерацию, а сплошной линией

показана кумулятивная функция распределения или вероятность завершить проект до указанной

итерации включительно.

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

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

следующим образом:

1. В самом начале проекта мы делаем наши лучшие предположения относительно

параметров производительности и притока новых задач,

2. После завершения каждой итерации на основе реальных данных вычисляются новые

значения параметров, и корректируется общая картина

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

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

мы минимизируем неопределенность в производительности команды. В случае работы на одного

и того же заказчика над проектами примерно из той же самой области, исторические данные по

притоку новых задач также могут быть использованы, и тем самым мы учитываем IKIWISI-эффект.

Использование относительных оценок для трудозатрат позволяет нам минимизировать влияние

естественной погрешности и частично негативный эффект неполноты WBS.

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%,

что совсем не мало.

7

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

Учет подобных флуктуаций особенно важен на относительно коротких проектах. Предположим,

что предполагаемая длительность нашего проекта составляет всего 5 итераций, с какой

вероятностью минимум в 3 итерации нам придет 4 и более задач по поддержке? Помочь ответить

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

успехов при испытаниях при вероятности успеха равной . Здесь под успехом мы понимаем

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

как это видно из Рис. 3 равна 35%. При помощи обычных офисных приложений можно вычислить,

что с вероятностью 24% не менее, чем в 3 из 5 итераций придет не менее 4-х задач по поддержке.

Другими словами, с такой вероятностью больше половины времени выполнения проекта,

команда получит число задач по поддержке, превышающее среднее значение.

Аналогичным образом можно вычислить вероятность того, что минимум в 3 из 5 итераций

команда будет получать по 2 и менее внешних задач. Вероятность такого исхода равна примерно

35%. То есть с ненулевой вероятностью команда может оказаться загруженной задачами по

поддержке меньше среднего. Опять естественным образом возникает неопределенность: с

немалой вероятностью задачи по поддержке не будут тревожить команду, и с чуть меньшей

вероятностью команда наоборот может оказаться перегруженной внешними задачами.

Выше рассматривалось просто число внешних задач, в то время как для планирования проекта

нужно уметь оценивать трудозатраты. Очевидно, что невозможно дать точную оценку задаче,

которая еще не возникла, но вполне возможно оценить вероятностные характеристики. Если

сделаны хоть сколько-нибудь адекватные предположения относительно вида плотности

распределения трудозатрат одной задачи, можно рассчитать и плотность распределения общих

трудозатрат на внешние задачи в течение проекта. Однако с практической точки зрения будет

более целесообразным измерять сразу статистические параметры трудозатраты на поддержку и

учитывать их, делая поправки параметров и в модели, описанной в предыдущем разделе.

8

Проекты с фиксированной стоимостью Вопросом под номером 2 по популярности является вопрос о стратегии оценки проектов с

фиксированной стоимостью. В случае проекта с фиксированной стоимостью нам не нужно знать

точную дату завершения, будет достаточно оценить дату, до наступления которой проект может

быть завершен с хорошей вероятностью, то есть дать оценку сверху. Естественно, если

неоправданно завысить стоимость проекта, то есть риск потерять заказчика, а если стоимость

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

озвучить дату или стоимость еще до начала проекта, можно воспользоваться следующим

подходом:

1. На основании исторических данных, экспертных оценок и интуиции (источники

перечислены в порядке убывания степени доверия), вычисляется кумулятивная функция

распределения для длительности или стоимости проекта,

2. На основе текущей стратегии компании определяется уровень толерантности к риску, то

есть тот риск, на который компания готова идти,

3. Используя функцию плотности распределения, находится значение

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

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

На Рис. 4 показан пример кумулятивной функции распределения номера завершающей итерации.

В этом примере уровень толерантности к риску равен 80%. Если использовать хорошую

статистическую модель оценки проектов, и следовать описанному выше подходу, то в

долгосрочной перспективе это позволит получить точную оценку сверху для 80% проектов. Что

естественно, в 20% случаев оценки окажутся ниже и для удачного завершения проекта придется

прибегать к методам компенсации заниженной оценки. К сожалению, способ, дающий 100%

точность при оценке проектов до их начала, в индустрии разработки программного обеспечения

пока не известен.

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