Теперь вернемся к реальному миру: ниже показана дифференциальная диаграмма риска для срока сдачи проекта и (непосредственно под ней) ее кумулятивный эквивалент:
Здесь снова оба графика показывают одни и те же данные, просто представленные слегка по-разному. Заметно, что шкалу по вертикали при кумулятивной форме несколько легче понять: она показывает непосредственно вероятность от 0 до 100%. Любая дата влево от 1 января безнадежна (0%-ная вероятность), но если мы захотим пройти весь путь до конца декабря следующего года, есть 100%-ная вероятность того, что к сроку все будет готово. Факт, что 1 мая следующего года дает вероятность 50 на 50, сразу виден на кумулятивной диаграмме, а на дифференциальной нужно оценить площади слева и справа отданной точки.
Обе формы полезны, и если у вас есть данные для одной из них, вы всегда можете использовать их для построения другой.
Глава 12
Глава 13
Здесь снова оба графика показывают одни и те же данные, просто представленные слегка по-разному. Заметно, что шкалу по вертикали при кумулятивной форме несколько легче понять: она показывает непосредственно вероятность от 0 до 100%. Любая дата влево от 1 января безнадежна (0%-ная вероятность), но если мы захотим пройти весь путь до конца декабря следующего года, есть 100%-ная вероятность того, что к сроку все будет готово. Факт, что 1 мая следующего года дает вероятность 50 на 50, сразу виден на кумулятивной диаграмме, а на дифференциальной нужно оценить площади слева и справа отданной точки.
Обе формы полезны, и если у вас есть данные для одной из них, вы всегда можете использовать их для построения другой.
Глава 12
Инструменты и процедуры
В этой главе у нас две задачи: (1) снабдить нас удобным инструментом для оценки рисков и (2) дать некоторые основные знания о пользовании им. Инструмент, названный RISKOLOGY, можно бесплатно скачать с нашего сайта в Интернете (http://www.systemsguild.com/riskology/)[21]. Это — модель риска в смысле, описанном в предыдущей главе. Инструмент предназначен для использования вместе с вашей собственной производственной моделью или механизмом параметрического оценивания. Наш инструмент не оценивает, сколько времени будет длиться ваш проект, он всего лишь говорит вам о том, сколько неопределенности следует приписать любой выдвигаемой оценке.
Модель представлена в виде электронной таблицы. Она исходит из логики, необходимой для работы с набором рисков в количественном выражении, включая исходную базу данных для четырех главных рисков разработки программного обеспечения. (Мы обсудим главные риски в главе 13).
Как можно водить машину без понимания всех тонкостей ее устройства, так можно использовать модель риска без глубокого понимания того, как она работает. В этой главе мы все же дадим вам возможность заглянуть внутрь модели. Это поможет слегка уменьшить суеверный страх и дать вам точку опоры, если вы решите самостоятельно подстроить электронные таблицы, чтобы они лучше соответствовали вашим задачам. Индивидуальная подгонка может быть важна, поскольку позволяет вам уничтожить, по крайней мере, некоторые из явных неопределенностей, относящихся к вашим проектам. Ваши собственные данные могут оказаться более оптимистичными и более применимыми, чем наша общеотраслевая информация.
Прежде, чем погрузиться в детали, обещаем не напрягать ваши мозги: мы не использовали «крутой» математики в этой главе. Если вы хоть немного знаете арифметику, эта глава будет вам посильна. Если вы собрались использовать электронную таблицу, например, для прогнозирования размера своей пенсии, у вас не должно быть проблем с тем, чтобы разобрать эту модель риска и собрать ее обратно, если решите заняться ее подгонкой.
К концу следующей главы будет показано, как это работает в проектах разработки программного обеспечения. А прямо сейчас мы намерены предложить для иллюстрации рассказ об очевидно надуманной проблеме, которую зато легче понять.
Предположим, что вы — бегун. Вы честно бегаете ежедневно, но время пробежки варьируется в зависимости от других ваших дел. Ваша ежедневная тренировка занимает от 15 минут до 1 часа. Вы ведете записи и обнаруживаете, что совершенно независимо от расстояния (в указанном временном диапазоне) скорость бега варьируется от 6,5 до 9 миль/час. Записи вы ведете так давно, что накоплена вполне приличная статистика:
Реальные данные, возможно, были в форме гистограммы, а то, что мы показываем здесь, является огибающей кривой, примерно повторяющей эту гистограмму. Это похоже на диаграмму неопределенности, ею она и является. На самом деле это можно представить в двух обычных формах, как показано ниже:
Это распределение прошлых результатов можно рассматривать как представление неопределенности в отношении того, как быстро вы побежите в следующий раз.
Предположим, что ваша скорость является не единственной неопределенностью, влияющей на следующий забег. Предположим, вы решили побежать по дорожке неизвестной длины: по периметру площадки для гольфа. Поскольку вы никогда раньше там не бегали, вы совсем не уверены, сколь длительным будет забег. У вас есть какие-то данные, полученные от Профессиональной ассоциации гольфа, о периметре площадки, из которых следует, что это расстояние может быть от двух до четырех миль, причем наиболее вероятна длина периметра примерно в 2,8 мили. Это тоже можно изобразить как распределение:
Эти данные более «зернистые» из-за недостаточного их количества.
Итак, сколько займет ваш следующий забег? Вы помните, что время — это расстояние, деленное на скорость (мили расстояния, поделенные на мили/час). Если расстояние и скорость были бы фиксированными величинами, то нам предстояло бы элементарное арифметическое действие, но в данном случае, оба параметра являются неопределенными, меняющимися в рамках определенного диапазона. Это обеспечивает наличие неопределенности также и в результате:
В целях выведения результирующей кривой, составленной из двух входных кривых, нам понадобилось бы использовать метод из области интегрального исчисления. Но такая «крутая» математика непозволительна в этой главе. Что же нам делать?
Вместо того чтобы строить кривую, мы намерены создать ее приближенный вариант путем моделирования ряда последовательных забегов. Для этого нам понадобится построить инструмент, который даст ряд выборочных данных из неопределенности любого вида и в то же время гарантирует соблюдение формы этой неопределенности по времени. Такой инструмент в применении к диаграмме скорости будет выглядеть так:
Если бы вы сами осуществляли механизм выборки в этом случае, как бы вы действовали дальше? Первую точку выбрать легко: смотрите на переход от минимума к максимуму и берете любую точку где-то посередине между ними. Кто оспорит ваше решение, на каком бы числе вы ни остановили свой выбор? Но если это нужно проделать больше одного раза, требование «соблюдать форму неопределенности во времени» заставляет задуматься. Как выбрать ряд данных с соблюдением такого же разброса вероятностей, как показан на исходной диаграмме неопределенности?
Как бы вы это ни сделали, фигура из выбранных точек должна, в конечном счете, повторять изначальную диаграмму неопределенности. Чтобы проверить себя, вы можете собрать свои результаты за некоторый период времени, рассортированные по удобным группам, и использовать их для построения гистограммы своих выбранных результатов. Если вы правильно рассчитали процесс выборки, последовательные гистограммы (для все большего и большего числа элементов выборки) могли бы выглядеть так:
В итоге, когда вы наберете пару сотен точек, огибающая вашей гистограммы будет очень похожа на диаграмму неопределенности, с которой вы начали:
Затем вы проводите вертикальную линию через точку, где ваша горизонталь пересекает кривую. Соответствующая величина на горизонтальной оси — это ваша первая точка выборки (см. нижний рисунок на следующей странице).
Второй рисунок говорит о том, что для первого выборочного забега вокруг площадки можно ожидать скорость 7,66 миль/час. Теперь повторим это, взяв больше случайных чисел, каждое из которых дает выборочное значение скорости. Если достаточно долго продолжать этот процесс и построить из результатов гистограмму, то огибающая гистограммы начнет аппроксимировать диаграмму неопределенности, с которой вы начали (ее дифференциальный вид).
Этот подход позволяет обходиться арифметическими действиями с выборками, вместо интегрального исчисления по кривым. В первый раз, когда вы запускаете этот процесс, он говорит вам, что вы пробежите, скажем, за 33 минуты. Этот результат не так уж и значим — это просто рассчитанное время для случайно выбранных величин из диапазона разброса скорости и расстояния. Но повторение этого процесса снова и снова даст распределение результатов, которые начинают аппроксимировать неопределенности ожидаемого времени забега.
Диаграмма, показанная выше, — это симулятор Монте-Карло для проблемы двойной неопределенности. Он позволяет вам моделировать n случаев проблемы и отображать результаты в форме результирующей диаграммы неопределенности. Вот результат для 100 образцов:
Метод, использованный здесь, не ограничен двумя неопределенностями. Его можно использовать для всего портфеля рисков, грозящих проекту по созданию программного обеспечения.
Скачайте копию симулятора «RISKOLOGY» с нашего сайта: http://www.pmo.ru/riskology
Там же можно найти некоторые шаблоны и инструкции по использованию и подгонке симулятора.
Для незнакомых с управлением рисками, или тех, кому очень сложно понять неопределенность, мы предлагаем воспринимать это как результат моделирования: «Мы прогнали этот проект 500 раз через симулятор, и получили результат, показанный на рисунке».
«Как вы видите, это показывает, что мы закончим работу до конца 30-го месяца проекта только в 15% случаев, — говорите вы. — Это не значит, что дата недостижима, она всего лишь имеет высокие риски. На нее можно рассчитывать лишь с 15%-ной уверенностью. Если вам нужна 75%-ная уверенность, вам лучше объявить датой сдачи 40-й месяц».
Модель представлена в виде электронной таблицы. Она исходит из логики, необходимой для работы с набором рисков в количественном выражении, включая исходную базу данных для четырех главных рисков разработки программного обеспечения. (Мы обсудим главные риски в главе 13).
Как можно водить машину без понимания всех тонкостей ее устройства, так можно использовать модель риска без глубокого понимания того, как она работает. В этой главе мы все же дадим вам возможность заглянуть внутрь модели. Это поможет слегка уменьшить суеверный страх и дать вам точку опоры, если вы решите самостоятельно подстроить электронные таблицы, чтобы они лучше соответствовали вашим задачам. Индивидуальная подгонка может быть важна, поскольку позволяет вам уничтожить, по крайней мере, некоторые из явных неопределенностей, относящихся к вашим проектам. Ваши собственные данные могут оказаться более оптимистичными и более применимыми, чем наша общеотраслевая информация.
Прежде, чем погрузиться в детали, обещаем не напрягать ваши мозги: мы не использовали «крутой» математики в этой главе. Если вы хоть немного знаете арифметику, эта глава будет вам посильна. Если вы собрались использовать электронную таблицу, например, для прогнозирования размера своей пенсии, у вас не должно быть проблем с тем, чтобы разобрать эту модель риска и собрать ее обратно, если решите заняться ее подгонкой.
Сложная смесь
В центре любой модели риска — метод определения объединенного воздействия двух и более неопределенностей:К концу следующей главы будет показано, как это работает в проектах разработки программного обеспечения. А прямо сейчас мы намерены предложить для иллюстрации рассказ об очевидно надуманной проблеме, которую зато легче понять.
Предположим, что вы — бегун. Вы честно бегаете ежедневно, но время пробежки варьируется в зависимости от других ваших дел. Ваша ежедневная тренировка занимает от 15 минут до 1 часа. Вы ведете записи и обнаруживаете, что совершенно независимо от расстояния (в указанном временном диапазоне) скорость бега варьируется от 6,5 до 9 миль/час. Записи вы ведете так давно, что накоплена вполне приличная статистика:
Реальные данные, возможно, были в форме гистограммы, а то, что мы показываем здесь, является огибающей кривой, примерно повторяющей эту гистограмму. Это похоже на диаграмму неопределенности, ею она и является. На самом деле это можно представить в двух обычных формах, как показано ниже:
Это распределение прошлых результатов можно рассматривать как представление неопределенности в отношении того, как быстро вы побежите в следующий раз.
Предположим, что ваша скорость является не единственной неопределенностью, влияющей на следующий забег. Предположим, вы решили побежать по дорожке неизвестной длины: по периметру площадки для гольфа. Поскольку вы никогда раньше там не бегали, вы совсем не уверены, сколь длительным будет забег. У вас есть какие-то данные, полученные от Профессиональной ассоциации гольфа, о периметре площадки, из которых следует, что это расстояние может быть от двух до четырех миль, причем наиболее вероятна длина периметра примерно в 2,8 мили. Это тоже можно изобразить как распределение:
Эти данные более «зернистые» из-за недостаточного их количества.
Итак, сколько займет ваш следующий забег? Вы помните, что время — это расстояние, деленное на скорость (мили расстояния, поделенные на мили/час). Если расстояние и скорость были бы фиксированными величинами, то нам предстояло бы элементарное арифметическое действие, но в данном случае, оба параметра являются неопределенными, меняющимися в рамках определенного диапазона. Это обеспечивает наличие неопределенности также и в результате:
В целях выведения результирующей кривой, составленной из двух входных кривых, нам понадобилось бы использовать метод из области интегрального исчисления. Но такая «крутая» математика непозволительна в этой главе. Что же нам делать?
Вместо того чтобы строить кривую, мы намерены создать ее приближенный вариант путем моделирования ряда последовательных забегов. Для этого нам понадобится построить инструмент, который даст ряд выборочных данных из неопределенности любого вида и в то же время гарантирует соблюдение формы этой неопределенности по времени. Такой инструмент в применении к диаграмме скорости будет выглядеть так:
Если бы вы сами осуществляли механизм выборки в этом случае, как бы вы действовали дальше? Первую точку выбрать легко: смотрите на переход от минимума к максимуму и берете любую точку где-то посередине между ними. Кто оспорит ваше решение, на каком бы числе вы ни остановили свой выбор? Но если это нужно проделать больше одного раза, требование «соблюдать форму неопределенности во времени» заставляет задуматься. Как выбрать ряд данных с соблюдением такого же разброса вероятностей, как показан на исходной диаграмме неопределенности?
Как бы вы это ни сделали, фигура из выбранных точек должна, в конечном счете, повторять изначальную диаграмму неопределенности. Чтобы проверить себя, вы можете собрать свои результаты за некоторый период времени, рассортированные по удобным группам, и использовать их для построения гистограммы своих выбранных результатов. Если вы правильно рассчитали процесс выборки, последовательные гистограммы (для все большего и большего числа элементов выборки) могли бы выглядеть так:
В итоге, когда вы наберете пару сотен точек, огибающая вашей гистограммы будет очень похожа на диаграмму неопределенности, с которой вы начали:
Эффект Монте-Карло
Выборка Монте-Карло — это подход, гарантирующий соблюдение формы наблюдаемой кривой во времени. Механизм выбора Монте-Карло использует данные прошлых наблюдений в форме кумулятивной диаграммы неопределенности вместе с простым генератором случайных чисел для отбора. Если выбрать достаточное количество данных, гистограмма этой выборки начнет аппроксимировать фигуру ваших наблюдаемых данных. Генератор настроен на выдачу случайных чисел между 0 и 1. Вся штука в том, чтобы использовать сгенерированное число для выбора значения на вертикальной оси диаграммы неопределенности и проведения через него горизонтальной линии. Если, например, первое сгенерированное число было 0,312, вы рисуете горизонтальную линию, проходящую через точку 0,312 на вертикальной оси (см. верхний рисунок на следующей странице).Затем вы проводите вертикальную линию через точку, где ваша горизонталь пересекает кривую. Соответствующая величина на горизонтальной оси — это ваша первая точка выборки (см. нижний рисунок на следующей странице).
Второй рисунок говорит о том, что для первого выборочного забега вокруг площадки можно ожидать скорость 7,66 миль/час. Теперь повторим это, взяв больше случайных чисел, каждое из которых дает выборочное значение скорости. Если достаточно долго продолжать этот процесс и построить из результатов гистограмму, то огибающая гистограммы начнет аппроксимировать диаграмму неопределенности, с которой вы начали (ее дифференциальный вид).
Моделирование забега с двумя неопределенностями
Механизм выборки, построенный на таком простом правиле, можно теперь применить к проблеме бега. Нам понадобится два таких механизма: один для получения данных с диаграммы скорости и другой для получения данных с диаграммы расстояния:Этот подход позволяет обходиться арифметическими действиями с выборками, вместо интегрального исчисления по кривым. В первый раз, когда вы запускаете этот процесс, он говорит вам, что вы пробежите, скажем, за 33 минуты. Этот результат не так уж и значим — это просто рассчитанное время для случайно выбранных величин из диапазона разброса скорости и расстояния. Но повторение этого процесса снова и снова даст распределение результатов, которые начинают аппроксимировать неопределенности ожидаемого времени забега.
Диаграмма, показанная выше, — это симулятор Монте-Карло для проблемы двойной неопределенности. Он позволяет вам моделировать n случаев проблемы и отображать результаты в форме результирующей диаграммы неопределенности. Вот результат для 100 образцов:
Метод, использованный здесь, не ограничен двумя неопределенностями. Его можно использовать для всего портфеля рисков, грозящих проекту по созданию программного обеспечения.
Модель риска для проектов программного обеспечения
«RISKOLOGY» — это симулятор Монте-Карло, созданный для менеджера, занимающегося рисками в проекте по разработке программного обеспечения. Это — прямое воплощение механизма выборки по методу Монте-Карло, выраженное в терминах логики электронных таблиц. Мы написали эту программу в Excel, поэтому вам понадобится лицензионная копия программы, чтобы использовать этот инструмент. «RISKOLOGY» идет в комплекте с нашими собственными данными о некоторых рисках, с которыми может столкнуться ваш проект. Вы можете использовать наши данные или заменить их собственными.Скачайте копию симулятора «RISKOLOGY» с нашего сайта: http://www.pmo.ru/riskology
Там же можно найти некоторые шаблоны и инструкции по использованию и подгонке симулятора.
Побочный эффект использования симуляции
Как только вы смоделировали достаточное количество примеров для своего проекта, симулятор обеспечит вам достаточно гладкую результирующую кривую. Эта кривая может показывать совокупные риски, связанные со сроком сдачи вашего проекта или с набором функциональных качеств, которые могут быть готовы к заданному сроку. В терминах управления рисками, результат представляется как диаграмма совокупного риска.Для незнакомых с управлением рисками, или тех, кому очень сложно понять неопределенность, мы предлагаем воспринимать это как результат моделирования: «Мы прогнали этот проект 500 раз через симулятор, и получили результат, показанный на рисунке».
«Как вы видите, это показывает, что мы закончим работу до конца 30-го месяца проекта только в 15% случаев, — говорите вы. — Это не значит, что дата недостижима, она всего лишь имеет высокие риски. На нее можно рассчитывать лишь с 15%-ной уверенностью. Если вам нужна 75%-ная уверенность, вам лучше объявить датой сдачи 40-й месяц».
Альтернативы «RISKOLOGY»
Наш симулятор «RISKOLOGY» не является единственным вариантом решения этой задачи. Существуют в продаже и другие подобные продукты. Вместо того, чтобы давать здесь прямые указания, мы будем поддерживать список на нашем сайте «RISKOLOGY» (см. URL выше). Там есть описания еще, по крайней мере, двух инструментов — наборов для построения своих собственных симуляторов риска. Эти продукты недороги, и их весьма легко освоить. Далее, как было обещано, мы перейдем к тому, что считаем самыми распространенными ключевыми рисками, с которыми сталкиваются руководители проектов по разработке программного обеспечения.
Глава 13
Основные риски проекта по разработке программного обеспечения
Если вы хоть сколько-то проработали в области создания программного обеспечения, то знаете, что есть некоторые общие проблемы, от которых страдают все проекты. Пропущенные сроки, установленные расписанием, и меняющиеся требования к проекту — это не то, что случается однажды и больше не повторяется. Они, скорее, неотъемлемая часть этой области бизнеса. Все мы это знаем. Странно только, что мы не планируем свои проекты с учетом этого знания. Вместо этого, мы планируем так, как будто эти проблемы надежно замурованы в прошлом и не грозят нам впредь. Конечно, вы знаете, что это неразумные ожидания. Эта глава поможет вам рассчитать, в каком объеме ваш план следующего проекта должен вмещать в себя проблемы, с которыми вы столкнулись в прошлом. Поскольку мы сами поступаем именно так, мы покажем использование симулятора «RISKOLOGY» в качестве инструмента для применения главных схем поведения, связанного с риском, к новым планам проектов.
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Только последний из них действительно связан с исполнением. Остальные четыре практически совсем не зависят от того, насколько усердно вы трудитесь и насколько вы компетентны и опытны в исполнении данной работы. Это стоит подчеркнуть, потому что многих руководителей смущает, не станет ли управление риском оправданием плохой работы исполнителей. Принятие разумных мер в отношении этих неконтролируемых событий — суть управления риском. Такие меры не освобождают вас от возможности неудачи, но создают резерв на случай, если некоторые из этих неконтролируемых событий обернутся против вас.
В следующих параграфах будет дано определение пяти рисков и показано, как принято количественно измерять их в нашей области.
Ошибки календарного планирования можно рассматривать как тенденцию неправильно судить о размерах продукта, который предстоит создать. Существует серьезная возможность недооценки, даже если вы прилагаете большие усилия по определению величины программного продукта, скажем, методом функциональных точек, по модели СОСОМО KLOC[22] или любым другим способом. Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.
Если вы не предпринимаете серьезных усилий по определению величины программного продукта, то ваши оценки календарного планирования основаны всего лишь на принятии желаемого за действительное: «Ого! Клиент хочет получить это в мае, до мая еще 7 месяцев, поэтому наугад можно поставить в график 7 месяцев». Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%. Когда семимесячный проект в конце концов занимает 12 месяцев, разъяренные топ-менеджеры редко винят график, вместо этого они ругают тех, кто должен был воплотить этот график (каким бы смехотворным он ни был) и жизнь. Но проблема в ошибочном календарном планировании, а не в плохом исполнении. В ретроспективе это выглядит так: размер продукта был недооценен по приказу; ограничение продолжительности проекта свело его размер к такому, какой мог быть создан за это время, но это ограничение оказалось нереалистичным.
Насколько большой проблемой являются ошибки календарного планирования в целом по отрасли разработки программного обеспечения? Чтобы ответить на этот вопрос, нам нужно было осмыслить данные по просрочкам, в том числе данные, собранные другими, а затем исключить воздействие остальных главных рисков. Это позволяло убедиться, что мы выделили воздействие именно ошибок календарного планирования. Такое выделение причинных факторов является нетривиальной задачей, и мы не претендуем на то, что достигли совершенства в своих результатах, но следующая диаграмма неопределенности — наша лучшая оценка отклонения от графика только из-за неверного календарного планирования:
Как показывает рисунок, если ничего больше не известно о вашем проекте или вашей организации, то можно с уверенностью утверждать, что первоначальная оценка размера продукта (как вычисленная непосредственно вами, так и декларативная) вынудит вас перерасходовать запланированное время, по крайней мере, на 30%. Например, горизонталь, проведенная на уровне 0,50 пересечет кривую в точке, показывающей увеличение времени в 1.3 или более.
Показанная здесь ситуация значительно хуже, чем ей следовало бы быть. Общеотраслевая тенденция скомпрометирована тем фактом, что так много компаний не выполняет предварительной работы по определению размера проекта, выбирая вместо этого календарное планирование от конца к началу или просто принимая желаемое за действительное. Хотя отрасль в целом управляется с этим не лучше, чем показано на рисунке выше, те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15% и менее. Сбор данных по нескольким проектам относительно масштабов недооценки размера научит вас закладывать необходимый резерв на это в ваших будущих проектах. В конечном счете, вы можете построить сбалансированную диаграмму риска, где точка 50 на 50 соответствует перерасходу на уровне 0%, а вероятность закончить проект досрочно (с учетом только этого главного риска) равна вероятности закончить с опозданием.
Наши данные смешены в сторону мелких проектов, не превышающих 3000 функциональных точек. Более крупные проекты, как кажется, несколько меньше страдают от этого явления. Может быть, меньше таких проектов пытаются миновать стадию оценки размера. Кроме того, более крупные (и более длительные) проекты предоставляют больше возможностей провести переоценку размера по ходу проекта.
Мы утверждали выше, что большинство главных рисков не относятся к низкой производительности команды. Это справедливо относительно риска ошибки календарного планирования, но только если игнорировать качество работы менеджмента. Руководители, предложившие или согласившиеся взять обязательства с серьезными ошибками календарного планирования, работают плохо. Ключевой момент здесь состоит в том, что когда проект не укладывается в график, то это происходит несмотря на работу разработчиков, а не благодаря ей. Команда, отдельно от руководителя, могла работать оптимально.
С точки зрения проекта, это изменение всегда является раздуванием. Даже удаление того, что уже создано — своего рода раздувание, поскольку требует дополнительной работы.
Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом. Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:
Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.
Но это не так. Поразить движущуюся цель — общая задача. Планировать поставить в будущем именно то, что заказчики хотят сегодня, все равно, что отсылать футбольный мяч туда, где раньше стоял игрок.
Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».
Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.
Опыт Минобороны США, может быть, трудно применить к вашему проекту. Поскольку типичные программные продукты для Минобороны велики, проекты часто выполняются с привлечением субподрядчиков (иногда нескольких уровней) и их продолжительность дольше, чем у большинства коммерческих проектов, более того, приближение, предложенное Минобороны США выражено, скорее, «терминах самого объема, чем в его влиянии на продолжительность по времени.
Из наших собственных наблюдений, где много одно— и двухгодичных проектов, осуществленных силами команд, состоящих из десятка, не более, исполнителей, сделан следующий вывод относительно ожидаемого воздействия изменяющихся требований на продолжительность во времени.
В вашей организации влияние этого риска может отличаться от того, которое мы показали. Конечно, вы захотите заменить наши данные собственными, если они у вас есть (см. в следующем разделе подсказки по такой замене). Если у вас нет данных, используйте для начала то, что мы предлагаем в симуляторе «RISKOLOGY». Это наверняка будет лучше, чем стандартный подход с ожиданием 0%-вых изменений.
Риски, общие для всех проектов разработки программного обеспечения
Возможно, вы могли бы составить список из 20 или 30 проблем, которые столь вездесущи, что разумно ждать их появления, по крайней мере, в некоторой степени, в каждом проекте. Мы выбрали для работы всего пять. Мы выбрали именно эту пятерку, поскольку именно из-за них происходит большинство расхождений между планом и реальностью, а также потому, что нам удалось собрать некоторые полезные данные по отрасли о размерах этих рисков. Вот наш список этих главных рисков:1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Только последний из них действительно связан с исполнением. Остальные четыре практически совсем не зависят от того, насколько усердно вы трудитесь и насколько вы компетентны и опытны в исполнении данной работы. Это стоит подчеркнуть, потому что многих руководителей смущает, не станет ли управление риском оправданием плохой работы исполнителей. Принятие разумных мер в отношении этих неконтролируемых событий — суть управления риском. Такие меры не освобождают вас от возможности неудачи, но создают резерв на случай, если некоторые из этих неконтролируемых событий обернутся против вас.
В следующих параграфах будет дано определение пяти рисков и показано, как принято количественно измерять их в нашей области.
Главный риск №1: Изъяны календарного планирования
Первый главный риск появляется из-за каких-то изъянов (или полной несостоятельности) процесса планирования бюджета времени и средств. Это можно рассматривать как ошибку собственно календарного планирования в противовес ошибкам осуществления проекта. (То, что сверхагрессивность может быть изъяном календарного планирования, удивит лишь тех руководителей, которым не приходилось встречаться с агрессивным календарным планированием, которое им не нравилось). Ошибка календарного планирования — не только реальный риск, но и самый крупный из пяти главных рисков по степени влияния на расхождение плана проекта и реального исполнения.Ошибки календарного планирования можно рассматривать как тенденцию неправильно судить о размерах продукта, который предстоит создать. Существует серьезная возможность недооценки, даже если вы прилагаете большие усилия по определению величины программного продукта, скажем, методом функциональных точек, по модели СОСОМО KLOC[22] или любым другим способом. Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.
Если вы не предпринимаете серьезных усилий по определению величины программного продукта, то ваши оценки календарного планирования основаны всего лишь на принятии желаемого за действительное: «Ого! Клиент хочет получить это в мае, до мая еще 7 месяцев, поэтому наугад можно поставить в график 7 месяцев». Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%. Когда семимесячный проект в конце концов занимает 12 месяцев, разъяренные топ-менеджеры редко винят график, вместо этого они ругают тех, кто должен был воплотить этот график (каким бы смехотворным он ни был) и жизнь. Но проблема в ошибочном календарном планировании, а не в плохом исполнении. В ретроспективе это выглядит так: размер продукта был недооценен по приказу; ограничение продолжительности проекта свело его размер к такому, какой мог быть создан за это время, но это ограничение оказалось нереалистичным.
Насколько большой проблемой являются ошибки календарного планирования в целом по отрасли разработки программного обеспечения? Чтобы ответить на этот вопрос, нам нужно было осмыслить данные по просрочкам, в том числе данные, собранные другими, а затем исключить воздействие остальных главных рисков. Это позволяло убедиться, что мы выделили воздействие именно ошибок календарного планирования. Такое выделение причинных факторов является нетривиальной задачей, и мы не претендуем на то, что достигли совершенства в своих результатах, но следующая диаграмма неопределенности — наша лучшая оценка отклонения от графика только из-за неверного календарного планирования:
Как показывает рисунок, если ничего больше не известно о вашем проекте или вашей организации, то можно с уверенностью утверждать, что первоначальная оценка размера продукта (как вычисленная непосредственно вами, так и декларативная) вынудит вас перерасходовать запланированное время, по крайней мере, на 30%. Например, горизонталь, проведенная на уровне 0,50 пересечет кривую в точке, показывающей увеличение времени в 1.3 или более.
Показанная здесь ситуация значительно хуже, чем ей следовало бы быть. Общеотраслевая тенденция скомпрометирована тем фактом, что так много компаний не выполняет предварительной работы по определению размера проекта, выбирая вместо этого календарное планирование от конца к началу или просто принимая желаемое за действительное. Хотя отрасль в целом управляется с этим не лучше, чем показано на рисунке выше, те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15% и менее. Сбор данных по нескольким проектам относительно масштабов недооценки размера научит вас закладывать необходимый резерв на это в ваших будущих проектах. В конечном счете, вы можете построить сбалансированную диаграмму риска, где точка 50 на 50 соответствует перерасходу на уровне 0%, а вероятность закончить проект досрочно (с учетом только этого главного риска) равна вероятности закончить с опозданием.
Наши данные смешены в сторону мелких проектов, не превышающих 3000 функциональных точек. Более крупные проекты, как кажется, несколько меньше страдают от этого явления. Может быть, меньше таких проектов пытаются миновать стадию оценки размера. Кроме того, более крупные (и более длительные) проекты предоставляют больше возможностей провести переоценку размера по ходу проекта.
Мы утверждали выше, что большинство главных рисков не относятся к низкой производительности команды. Это справедливо относительно риска ошибки календарного планирования, но только если игнорировать качество работы менеджмента. Руководители, предложившие или согласившиеся взять обязательства с серьезными ошибками календарного планирования, работают плохо. Ключевой момент здесь состоит в том, что когда проект не укладывается в график, то это происходит несмотря на работу разработчиков, а не благодаря ей. Команда, отдельно от руководителя, могла работать оптимально.
Главный риск №2: Раздувание требований
Программное обеспечение, которое вы со своей командой разрабатываете, всегда предназначено для того, чтобы вписаться в область деятельности вашего клиента. В одном вы можете быть уверены — в том, что эта область не останется статичной за время создания программного обеспечения. Она будет изменяться со скоростью, диктуемой рынком и собственными темпами технологического развития. Если вы в январе обязались поставить продукт X через 10 месяцев, то к моменту истечения этих 10 месяцев ваши бизнес-партнеры уже хотят не X. На самом деле они уже хотят Х-штрих. Разница между тем, что они хотят в начале и в конце этого периода возникает из-за изменений, которые произошли в данной области бизнеса за это время.С точки зрения проекта, это изменение всегда является раздуванием. Даже удаление того, что уже создано — своего рода раздувание, поскольку требует дополнительной работы.
Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом. Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:
Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.
Но это не так. Поразить движущуюся цель — общая задача. Планировать поставить в будущем именно то, что заказчики хотят сегодня, все равно, что отсылать футбольный мяч туда, где раньше стоял игрок.
Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».
Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.
Опыт Минобороны США, может быть, трудно применить к вашему проекту. Поскольку типичные программные продукты для Минобороны велики, проекты часто выполняются с привлечением субподрядчиков (иногда нескольких уровней) и их продолжительность дольше, чем у большинства коммерческих проектов, более того, приближение, предложенное Минобороны США выражено, скорее, «терминах самого объема, чем в его влиянии на продолжительность по времени.
Из наших собственных наблюдений, где много одно— и двухгодичных проектов, осуществленных силами команд, состоящих из десятка, не более, исполнителей, сделан следующий вывод относительно ожидаемого воздействия изменяющихся требований на продолжительность во времени.
В вашей организации влияние этого риска может отличаться от того, которое мы показали. Конечно, вы захотите заменить наши данные собственными, если они у вас есть (см. в следующем разделе подсказки по такой замене). Если у вас нет данных, используйте для начала то, что мы предлагаем в симуляторе «RISKOLOGY». Это наверняка будет лучше, чем стандартный подход с ожиданием 0%-вых изменений.