В этом есть некий псевдонаучный момент, который нельзя обойти вниманием. Мы проигнорировали дополнительные причины прекращения проекта и создали свой симулятор «RISKOLOGY» таким образом, что он вынуждает вас столкнуться с возможностью прекращения проекта, пока не пройдено контрольное событие, обозначающее окончание угрозы, после чего предполагается нулевой риск прекращения проекта. Это – весьма грубый подход к деликатному предмету прекращения проектов, оправданный лишь тем, что очень высока доля проектов, в конце концов прекращенных, для которых оказалось невозможным достичь соглашения, необходимого для наступления данного контрольного события.
В литературе есть множество свидетельств наличия существенных различий в производительности между группами разработчиков. Различия между командами проектов в целом несколько сглажены и всегда меньше, чем индивидуальные различия. Более того, некоторые различия индивидуальной производительности возникают из-за того или иного из четырех главных рисков, о которых уже шла речь. После устранения воздействия других рисков и распространения индивидуальных различий на команды мы видим следующий результат вариации командной производительности (см. рисунок ниже).
Этот фактор, как правило, сбалансирован: по сути, одинакова вероятность как позитивных, так и негативных изменений производительности.
Опасно использовать наши данные для очень малых команд, поскольку индивидуальные различия там могут не сгладиться. Например, команда из одного человека подвержена куда большему воздействию низкой или высокой производительности.
Сбалансированный риск, вроде низкой или высокой производительности, просто вносит шум в процесс. Он расширяет диапазон неопределенности без сдвига среднего ожидаемого показателя, в каком бы то ни было направлении.
Моделирование требует нескольких параметров проекта и дает возможность заменить любой (или все) из главных рисков вашими собственными данными, а затем просчитывает варианты проекта, чтобы определить, какую продолжительность проекта следует ожидать. Данный профиль является результатом 500 отдельных прогонов, даты завершения которых сгруппированы в дискретные диапазоны. Для проекта (названного здесь Amalfi), где N – примерно 26 месяцев, без замещений, результаты моделирования с помощью «RISKOLOGY» похожи на цифры, с которыми вы сталкивались в конце главы 12:
Покажем здесь, как вы могли бы интерпретировать и объяснить результат, если бы таким был ваш проект существует некоторая ненулевая вероятность завершения проекта в период между 26-м месяцем и 27-м месяцем. Значительно вероятнее, однако, что вы будете готовы между 32-м и 34-м месяцами. С 75%-ной достоверностью можно назначить сроком сдачи 38-й месяц. Около 15% прогонов заканчивается прекращением проекта. Это – честная оценка риска прекращения проекта, с точки зрения взгляда на проект с начальной его даты, но за шесть месяцев действия проекта должно стать возможным оценить риск прекращения точнее и, быть может, снять его.
Главные риски можно также использовать для оценки того, был ли процесс управления рисками осуществлен разумно. Например, если вы представили пять главных рисков, но использовали данные, отличные от наших, вы можете быть достаточно уверены, что осуществили управление рисками, причем осуществили его разумно. Но мы с большим недоверием относимся к проектам, претендующим на управление рисками, когда они не принимали во внимание эти пять главных рисков.
Глава 14
Уточненный процесс обнаружения рисков
Вам следует беспокоиться не только о главных рисках. Может быть немало рисков, свойственных именно вашему проекту, которые нужно учесть в вашем уравнении риска. Например, может быть ключевой исполнитель, чей уход станет роковым для проекта, важный пользователь, который может решить идти своим путем или поставщик, чья необязательность может иметь ужасные последствия.
Как только вы обнаружили и количественно оценили эти риски, ими можно управлять, как и любыми другими. Но выявить их может быть нелегко. Культура наших организаций иногда не позволяет говорить о самых тревожащих рисках. Мы ведем себя, как самые дикие племена, которые пытаются не подпустить к себе дьявола тем, что отказываются произносить его имя. Хранить молчание о риске – это не способ избавиться от него. Например, при подготовке проекта запуска Ariane 5[24]
, никто не говорил, что есть риск ошибок, связанных с тем, что компилятор не делает проверку граничных значений, и это поставит под угрозу запускаемый спутник. Но это, тем не менее, случилось и привело к полному провалу запуска.