Наш симулятор «RISKOLOGY» не является единственным вариантом решения этой задачи. Существуют в продаже и другие подобные продукты. Вместо того, чтобы давать здесь прямые указания, мы будем поддерживать список на нашем сайте «RISKOLOGY» (см. URL выше). Там есть описания еще, по крайней мере, двух инструментов — наборов для построения своих собственных симуляторов риска. Эти продукты недороги, и их весьма легко освоить. Далее, как было обещано, мы перейдем к тому, что считаем самыми распространенными ключевыми рисками, с которыми сталкиваются руководители проектов по разработке программного обеспечения.
Глава 13
Основные риски проекта по разработке программного обеспечения
Если вы хоть сколько-то проработали в области создания программного обеспечения, то знаете, что есть некоторые общие проблемы, от которых страдают все проекты. Пропущенные сроки, установленные расписанием, и меняющиеся требования к проекту — это не то, что случается однажды и больше не повторяется. Они, скорее, неотъемлемая часть этой области бизнеса. Все мы это знаем. Странно только, что мы не планируем свои проекты с учетом этого знания. Вместо этого, мы планируем так, как будто эти проблемы надежно замурованы в прошлом и не грозят нам впредь. Конечно, вы знаете, что это неразумные ожидания. Эта глава поможет вам рассчитать, в каком объеме ваш план следующего проекта должен вмещать в себя проблемы, с которыми вы столкнулись в прошлом. Поскольку мы сами поступаем именно так, мы покажем использование симулятора «RISKOLOGY» в качестве инструмента для применения главных схем поведения, связанного с риском, к новым планам проектов.
Возможно, вы могли бы составить список из 20 или 30 проблем, которые столь вездесущи, что разумно ждать их появления, по крайней мере, в некоторой степени, в каждом проекте. Мы выбрали для работы всего пять. Мы выбрали именно эту пятерку, поскольку именно из-за них происходит большинство расхождений между планом и реальностью, а также потому, что нам удалось собрать некоторые полезные данные по отрасли о размерах этих рисков. Вот наш список этих главных рисков:
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Только последний из них действительно связан с исполнением. Остальные четыре практически совсем не зависят от того, насколько усердно вы трудитесь и насколько вы компетентны и опытны в исполнении данной работы. Это стоит подчеркнуть, потому что многих руководителей смущает, не станет ли управление риском оправданием плохой работы исполнителей. Принятие разумных мер в отношении этих неконтролируемых событий — суть управления риском. Такие меры не освобождают вас от возможности неудачи, но создают резерв на случай, если некоторые из этих неконтролируемых событий обернутся против вас.
В следующих параграфах будет дано определение пяти рисков и показано, как принято количественно измерять их в нашей области.
Первый главный риск появляется из-за каких-то изъянов (или полной несостоятельности) процесса планирования бюджета времени и средств. Это можно рассматривать как ошибку собственно календарного планирования в противовес ошибкам осуществления проекта. (То, что сверхагрессивность может быть изъяном календарного планирования, удивит лишь тех руководителей, которым не приходилось встречаться с агрессивным календарным планированием, которое им не нравилось). Ошибка календарного планирования — не только реальный риск, но и самый крупный из пяти главных рисков по степени влияния на расхождение плана проекта и реального исполнения.
Ошибки календарного планирования можно рассматривать как тенденцию неправильно судить о размерах продукта, который предстоит создать. Существует серьезная возможность недооценки, даже если вы прилагаете большие усилия по определению величины программного продукта, скажем, методом функциональных точек, по модели СОСОМО KLOC[22] или любым другим способом. Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.
Если вы
Насколько большой проблемой являются ошибки календарного планирования в целом по отрасли разработки программного обеспечения? Чтобы ответить на этот вопрос, нам нужно было осмыслить данные по просрочкам, в том числе данные, собранные другими, а затем исключить воздействие остальных главных рисков. Это позволяло убедиться, что мы выделили воздействие именно ошибок календарного планирования. Такое выделение причинных факторов является нетривиальной задачей, и мы не претендуем на то, что достигли совершенства в своих результатах, но следующая диаграмма неопределенности — наша лучшая оценка отклонения от графика только из-за неверного календарного планирования:
Как показывает рисунок, если ничего больше не известно о вашем проекте или вашей организации, то можно с уверенностью утверждать, что первоначальная оценка размера продукта (как вычисленная непосредственно вами, так и декларативная) вынудит вас перерасходовать запланированное время, по крайней мере, на 30%. Например, горизонталь, проведенная на уровне 0,50 пересечет кривую в точке, показывающей увеличение времени в 1.3 или более.
Показанная здесь ситуация значительно хуже, чем ей следовало бы быть. Общеотраслевая тенденция скомпрометирована тем фактом, что так много компаний не выполняет предварительной работы по определению размера проекта, выбирая вместо этого календарное планирование от конца к началу или просто принимая желаемое за действительное. Хотя отрасль в целом управляется с этим не лучше, чем показано на рисунке выше, те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15% и менее. Сбор данных по нескольким проектам относительно масштабов недооценки размера научит вас закладывать необходимый резерв на это в ваших будущих проектах. В конечном счете, вы можете построить сбалансированную диаграмму риска, где точка 50 на 50 соответствует перерасходу на уровне 0%, а вероятность закончить проект досрочно (с учетом только этого главного риска) равна вероятности закончить с опозданием.
Наши данные смешены в сторону мелких проектов, не превышающих 3000 функциональных точек. Более крупные проекты, как кажется, несколько меньше страдают от этого явления. Может быть, меньше
