Когда вы требуете от своих подчиненных работать без остановок и выполнить проект вовремя любой ценой (даже если сроки абсурдны), вы должны понимать, что укомплектовываете ключевые должности гонщиками NASCAR. Они пойдут на любой риск, пренебрегая всевозможными срывами, ради того, чтобы сохранить (по крайней мере, как можно дольше удержать) любой малейший шанс на победу.
Назовите это, как хотите, но это не является управлением рисками.
Часть III
Как?
• Как мы решаем проблему управления рисками?
• Раз неизвестные нам неизвестны, как мы можем их количественно оценить?
• Какие существуют инструменты для этого?
• Откуда берутся данные для управления рисками?
• Что такое резервы на управление рисками, и как их используют?
• Что можно сделать в отношении риска, кроме отслеживания его?
• Что такое повторяющиеся риски проектов по разработке программного обеспечения, и что о них известно?
• Как мы вообще обнаруживаем риски?
Глава 8
Количественное определение неопределенности
Разработка программного обеспечения – рискованный бизнес, поскольку весь процесс окутан неопределенностями. Все, что нужно предсказать относительно проекта, будет в какой-то мере неопределенным. Но насколько именно?
Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 6-го числа, но немного сомневалась, будет ли это несколькими днями раньше или позже. Или, возможно, она совсем понятия не имела о сроке завершения. Ясно, что между этими двумя уровнями неопределенности колоссальная разница. Представьте это так: вы – руководитель проекта, и вы стремитесь завершить проект по графику к 30-му октября. У вас есть четкое ощущение, что 30-е октября – абсолютно нереально, но точнее вы ничего сказать не можете. Вы совершенно беспомощны. Ваши подчиненные также в полном неведении. Таким образом, примерно в середине лета, уже отставая от срока на четыре месяца, вы приглашаете консультанта. Выбранный вами консультант – лучший в данной области, способный правильно оценить проект даже во сне и определить его состояние. Через несколько дней погружения в технические условия и промежуточные результаты, а также встреч с исполнителями и акционерами, он заявляет напрямик:
«Слушай, шансов завершить до начала следующего года – никаких. Наиболее вероятная дата поставки приемлемого продукта – начало апреля в следующем году. Но и эта дата не абсолютно надежна. Возможно, лучше назначить срок сдачи не раньше чем на 1-е мая. По крайней мере, при дате 8 мая или позднее у вас шансы завершить проект выше, чем 50 на 50. Если нужно назначить дату, чтобы было практически невозможно не успеть к этому сроку, то стоит назначить конец декабря следующего года».
Вы пригласили консультанта, потому что были неуверенны относительно даты завершения проекта, но консультант и сам проявил некоторую неуверенность. Разница между вашей неопределенностью (полном отсутствием представления) и его (описанной в предыдущем абзаце) состоит в том, что его неопределенность заключена в четкие рамки.
Та же идея в графическом изображении
Возьмем оценку, данную консультантом, и отобразим ее на графике. Поскольку все, что он сказал, относится к вероятностным суждениям («нет шанса завершить работу до начала следующего года», шансы выше, чем 50 на 50» и т.д.), график будет показывать уверенность/неуверенность как вероятность поставки готового продукта на любую рассматриваемую дату. Мы продлим график в обе стороны, чтобы он охватывал весь диапазон: от совершенно нереальных до полностью гарантированных сроков. Итак, отложим на вертикальной оси вероятность, а по горизонтали разместим даты. Вот пустой график, на котором отмечены только четыре даты, прямо упомянутые консультантом:
Консультант сказал, что вероятность завершения проекта равна нулю для всех дат до 1 января, но счел почти невероятным предположение, что после 31 декабря следующего года потребуется дополнительное время (поскольку был практически уверен, что проект будет к этому сроку завершен); наиболее вероятной датой завершения проекта он назвал 1 апреля. Исходя из этого, можно заполнить эти два полуинтервала и обозначить пик кривой. Поскольку на вертикальной оси пока не задан масштаб, можно поместить пик произвольно, не заботясь о его точном значении. Это выглядит так:
Остается только заполнить середину, стараясь, чтобы площадь под кривой левее 1-го мая была примерно равна площади справа (подробнее об этом будет сказано дальше). Мягкая кривая, удовлетворяющая этим ограничениям, выглядит так:
Полученный результат представляет собой некий тип диаграммы неопределенности, называемый диаграммой риска. Диаграммы риска рассмотрены в главе 10, где вы узнаете больше об их свойствах и применении. Пока же вы, видимо, уже отметили основное:
• Площадь под кривой представляет собой общую вероятность завершения проекта к данной дате, поэтому, если треть площади лежит слева от 1 апреля, то это значит, что вероятность завершения к 1 апреля или раньше составляет примерно 33%.
• Площадь под всей кривой равна 1,0 в соответствии с оценкой консультанта, что работа будет завершена в период с 1 января до 31 декабря следующего года.
Что говорит нам диаграмма риска о распространенной сегодня практике
Диаграмма риска, изображенная выше, может показать гораздо больше неопределенности (больший разброс предполагаемого срока завершения), чем принято декларировать в вашей организации. Если вы верите, что она отображает реальность, то вас все же может беспокоить, кто с ней будет ознакомлен и как она будет представлена. Если даже предполагается, что никто, кроме вас, не увидит диаграмму, упражнение в количественной оценке неопределенности для вашего проекта с помощью такой диаграммы может дать вам огромные преимущества.
Например, диаграмма сразу же поможет понять многое из того, что происходило в отрасли, производящей программное обеспечение, в последние несколько десятилетий. Одна общая жалоба, которую разделяют с нами руководители проектов, состоит в том, что «самая ранняя из произнесенных дат автоматически превращается в крайний срок сдачи». Если обнародовать слова консультанта о том, что «нет шансов завершить работу до начала следующего года», то это тут же приведет к назначению вам жесткого срока сдачи на 1 января. Но на диаграмме риска площадь под кривой слева от 1 января равна нулю:
Это означает, что вероятность сдачи к этому сроку катастрофически мала. Патология установления срока сдачи по самой ранней из произнесенных дат, по сути, гарантирует, что график будет сорван.
Даже стратегия выбора «наиболее правдоподобной даты» не слишком надежна, поскольку площадь слева от пика едва составляет треть. Это означает, что с вероятностью 2/3 к этому сроку система не будет готова. Да, это наиболее правдоподобная дата из всех, но все же не очень правдоподобная.
Выбор даты прямо посередине (когда половина площади будет справа и половина – слева) дает всего лишь один шанс из двух возможных, что завершение проекта произойдет вовремя. Действительно, выбор любой точечной даты на диаграмме риска проблематичен, зато очень разумно рассматривать вместо этого всю диаграмму риска, как график работ. Нельзя не признать, что в нем есть неопределенности, но простой выбор даты и назначение ее сроком сдачи не устраняет этой неопределенности, а просто скрывает ее от людей, которым вы дали обязательство. Проверка «взрослости» организации состоит в том, что менеджеры всех уровней учатся жить с обязательствами, для которых в явном виде установлены границы неопределенности.
Дата с вероятностью нанопроцента[16]
Пересечение кривой с горизонтальной осью определяет первый день с ненулевой вероятностью. Но она, так скажем, не очень ненулевая. Это пересечение будем называть N, «дата с вероятностью нанопроцента» или просто «нанопроцентная дата», потому что вероятность поставки в этот срок составляет примерно один нанопроцент.
Совершенно бессмысленно брать обязательство на поставку в день N, но тем не менее это – важная дата. Она важна, поскольку является чем-то, к чему у нас есть врожденная привычка. Весь наш опыт оценок до сих пор учил нас тому, как оценить N, но затем ошибочно вел нас к тому, чтобы считать N датой сдачи. Этот второй шаг плох, но наш с трудом обретенный навык вычисления дат с вероятностью нанопроцента может и должен послужить нам во благо.