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

Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 6-го числа, но немного сомневалась, будет ли это несколькими днями раньше или позже. Или, возможно, она совсем понятия не имела о сроке завершения. Ясно, что между этими двумя уровнями неопределенности колоссальная разница. Представьте это так: вы – руководитель проекта, и вы стремитесь завершить проект по графику к 30-му октября. У вас есть четкое ощущение, что 30-е октября – абсолютно нереально, но точнее вы ничего сказать не можете. Вы совершенно беспомощны. Ваши подчиненные также в полном неведении. Таким образом, примерно в середине лета, уже отставая от срока на четыре месяца, вы приглашаете консультанта. Выбранный вами консультант – лучший в данной области, способный правильно оценить проект даже во сне и определить его состояние. Через несколько дней погружения в технические условия и промежуточные результаты, а также встреч с исполнителями и акционерами, он заявляет напрямик:

Вы пригласили консультанта, потому что были неуверенны относительно даты завершения проекта, но консультант и сам проявил некоторую неуверенность. Разница между вашей неопределенностью (полном отсутствием представления) и его (описанной в предыдущем абзаце) состоит в том, что его неопределенность заключена в четкие рамки.

Возьмем оценку, данную консультантом, и отобразим ее на графике. Поскольку все, что он сказал, относится к вероятностным суждениям («нет шанса завершить работу до начала следующего года», шансы выше, чем 50 на 50» и т.д.), график будет показывать уверенность/неуверенность как вероятность поставки готового продукта на любую рассматриваемую дату. Мы продлим график в обе стороны, чтобы он охватывал весь диапазон: от совершенно нереальных до полностью гарантированных сроков. Итак, отложим на вертикальной оси вероятность, а по горизонтали разместим даты. Вот пустой график, на котором отмечены только четыре даты, прямо упомянутые консультантом:

Консультант сказал, что вероятность завершения проекта равна нулю для всех дат до 1 января, но счел почти невероятным предположение, что после 31 декабря следующего года потребуется дополнительное время (поскольку был практически уверен, что проект будет к этому сроку завершен); наиболее вероятной датой завершения проекта он назвал 1 апреля. Исходя из этого, можно заполнить эти два полуинтервала и обозначить пик кривой. Поскольку на вертикальной оси пока не задан масштаб, можно поместить пик произвольно, не заботясь о его точном значении. Это выглядит так:

Остается только заполнить середину, стараясь, чтобы площадь под кривой левее 1-го мая была примерно равна площади справа (подробнее об этом будет сказано дальше). Мягкая кривая, удовлетворяющая этим ограничениям, выглядит так:

Полученный результат представляет собой некий тип диаграммы неопределенности, называемый диаграммой риска. Диаграммы риска рассмотрены в главе 10, где вы узнаете больше об их свойствах и применении. Пока же вы, видимо, уже отметили основное:

• Площадь под кривой представляет собой общую вероятность завершения проекта к данной дате, поэтому, если треть площади лежит слева от 1 апреля, то это значит, что вероятность завершения к 1 апреля или раньше составляет примерно 33%.

• Площадь под всей кривой равна 1,0 в соответствии с оценкой консультанта, что работа будет завершена в период с 1 января до 31 декабря следующего года.

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

Например, диаграмма сразу же поможет понять многое из того, что происходило в отрасли, производящей программное обеспечение, в последние несколько десятилетий. Одна общая жалоба, которую разделяют с нами руководители проектов, состоит в том, что «самая ранняя из произнесенных дат автоматически превращается в крайний срок сдачи». Если обнародовать слова консультанта о том, что «нет шансов завершить работу до начала следующего года», то это тут же приведет к назначению вам жесткого срока сдачи на 1 января. Но на диаграмме риска площадь под кривой слева от 1 января равна нулю:

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

Даже стратегия выбора «наиболее правдоподобной даты» не слишком надежна, поскольку площадь слева от пика едва составляет треть. Это означает, что с вероятностью 2/3 к этому сроку система не будет готова. Да, это наиболее правдоподобная дата из всех, но все же не очень правдоподобная.

Выбор даты прямо посередине (когда половина площади будет справа и половина – слева) дает всего лишь один шанс из двух возможных, что завершение проекта произойдет вовремя. Действительно, выбор любой точечной даты на диаграмме риска проблематичен, зато очень разумно рассматривать вместо этого всю диаграмму риска, как график работ. Нельзя не признать, что в нем есть неопределенности, но простой выбор даты и назначение ее сроком сдачи не устраняет этой неопределенности, а просто скрывает ее от людей, которым вы дали обязательство. Проверка «взрослости» организации состоит в том, что менеджеры всех уровней учатся жить с обязательствами, для которых в явном виде установлены границы неопределенности.

Пересечение кривой с горизонтальной осью определяет первый день с ненулевой вероятностью. Но она, так скажем, не очень ненулевая. Это пересечение будем называть N, «дата с вероятностью нанопроцента» или просто «нанопроцентная дата», потому что вероятность поставки в этот срок составляет примерно один нанопроцент.

Совершенно бессмысленно брать обязательство на поставку в день N, но тем не менее это – важная дата. Она важна, поскольку является чем-то, к чему у нас есть врожденная привычка. Весь наш опыт оценок до сих пор учил нас тому, как оценить N, но затем ошибочно вел нас к тому, чтобы считать N датой сдачи. Этот второй шаг плох, но наш с трудом обретенный навык вычисления дат с вероятностью нанопроцента может и должен послужить нам во благо.

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

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

Итак, все это легко бы сошло, если бы допуск неопределенности можно было удержать в небольших пределах. Но можно ли это сделать? Конечно, можно быть ярым сторонником диаграмм риска, если диаграмма для вашего проекта выглядит так:

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

Но предположим вместо этого, что ваша диаграмма риска выглядит так:

Совсем несимпатично в этой картинке то, что неопределенность слишком велика по сравнению с интервалом от начала проекта до N.

Если вы такой же, как и остальные из нас, руководителей проектов по созданию программного обеспечения, то вам комфортно при допуске порядка 10-15% времени от интервала с начала проекта до N и тревожно при любых больших значениях, то есть тревога возрастает по мере роста диапазона допуска свыше 15%.

Неудачи прежних проектов и их политики приучили нас к мысли, что подходящим диапазоном допуска является 10-15% от интервала с начала проекта до N. То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления.

Однако всё это не имеет никакого значения. Размер вашего допуска неопределенности является производным от того, сколь велик шум (отклонения) в процессах разработки, принятых в вашей организации, и не имеет никакого отношения к тому, что кому-то кажется подходящим.

Шум – источник отклонений от одного проекта к другому, объяснение того, почему некоторые проекты занимают больше времени, несмотря на все ваши усилия. До некоторой степени шум является количественной оценкой последствий прошлых рисков, величина шума может быть эмпирически определена для любой организации, которая ведет хотя бы элементарные записи деятельности. Эта цифра устанавливает, сколько неопределенности должно быть в вашем следующем проекте. Другими словами, ваша прежняя деятельность определяет размер диапазона допуска.

В целом для отрасли, производящей программное обеспечение, диапазон допуска составляет порядка 150-200% от интервала с начала проекта до N. Таким образом, у проекта с N, приходящимся на 25-е число какого-то месяца, дальний конец диапазона кривой неопределенности придется на 75-е число. От вас не требуется испытывать восторг по этому поводу. Просто так устроен мир. Бесполезно притворяться, что дело обстоит иначе.