Может быть, вам и не придется. Польза от частичных данных «выгоды/затраты» состоит в том, что они позволяют упорядочить компоненты для включения в версии. Получить точные оценки было бы отлично, но если их приобрести нельзя, то не устроит ли вас вместо этого упорядочение?
Сам факт, что вы собираетесь сдавать проект по частям, дает вам рычаг для получения инструкций по упорядочению даже от самых упрямых заказчиков. В конце концов, некоторые части системы обязательно придется внедрять после каких-то других. Одни части будут первыми, а другие – последними. Если вы отдадите это решение в руки своим заказчикам, они кинутся рассказывать вам о порядке осуществления. Все знают, что порой системы опаздывают и «первые» части могут оказаться готовыми к изначально определенному сроку, а вот «последние» еще не будут готовы. Редкий пользователь не сумеет воспользоваться преимуществами этого дополнительного уровня управления, несмотря на то, что использование этого является признанием неравномерной концентрации ценности в разных частях системы.
Глава 21
Выгоды возмещают риски
Насколько мы готовы рисковать в данном проекте? Какой бы ответ вы ни дали, он должен учитывать потенциальную выгоду, которую он мог бы принести. Ни одна рабочая теория риска не может игнорировать выгоду. Когда ставки высоки, стоит идти даже на серьезные риски. Когда игра не стоит свеч, практически никакой риск не является допустимым.
Если предыдущий абзац показался вам убедительным, вы относитесь к меньшинству. Кажется, что вся IT-отрасль поддерживает практически противоположный взгляд: Рискуйте много, когда выгода ничтожна. Как еще мы сумеем снизить затраты настолько, чтобы оправдать этот нестоящий проект?
Это мышление – порождение одного из самых распространенных, но постыдных стилей работы в нашей отрасли…
В этих случаях непоколебимая жертвенность непреложно требуется от всех до одного участников проекта. Проект требует забросить личную жизнь, бесконечно работать сверхурочно, проводя субботы и воскресенья в офисе, отдалиться от семьи и т.д. Неприемлемо ничто меньшее, чем полное посвящение себя проекту.
Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходимо, что требует предела возможного от персонала проекта. Но есть нечто загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги необходимые для его нормального осуществления?
По нашему опыту, единственной общей характеристикой таких проектов является низкая ожидаемая выгода. Это – проекты, нацеленные на выпуск продуктов монументальной незначительности. Единственным реальным обоснованием проектов на выживание является то, что выгода столь мала, что нормальное выполнение проекта явно привело бы к затратам, которые будут больше выгоды. Только героическими усилиями можно надеяться заставить свинью летать.
Второй характеристикой проекта на выживание является одурачивание людей, чтобы заставить их принести свою личную жизнь в жертву компании, убедив, что только это может привести к успеху, поскольку выгода столь крохотная, что осмысленными будут только самые низкие затраты.
Третья характеристика такого проекта состоит в том, что они почти всегда кончаются полным фиаско, не создав ничего или почти ничего (обычно при затратах выше среднего) и заставив всех чувствовать себя одураченными и озлобленными. Должен быть выход лучше.
Лучший выход состоит в том, чтобы руководствоваться ожидаемой выгодой при решении, на какое количество рисков отважиться. В ретроспективе, главной причиной того, что мы раньше этого не делали, была нехватка дисциплины, чтобы заставить количественно оценить выгоду. В особенности по не очень выгодным проектам, мы стойко отказывались количественно оценить выгоду, поскольку это было единственным способом сохранять сколько-нибудь приличный вид всей затеи. Без объявленных ожиданий стоимости можно было опираться только на сокращение расходов на разработку. Обоснование преимущественно было таким: «Мы так снизим затраты, что они наверняка будут меньше, чем любая полученная выгода».
Реальное обоснование проекта (вы всегда знали это в глубине сердца) требует сбалансированности риска и выгоды, как показано на рисунке:
Здесь есть техническая проблема: как решить, перевешивает ли выгода, показанная на левой стороне, риски, показанные справа. Поскольку и выгода, и риски являются до некоторой степени неопределенными, следует ожидать, что и баланс тоже будет в некоторой степени неопределенным. Если призвать на помощь сложную математику, то получим диаграмму неопределенности, показывающую одновременное воздействие неопределенной выгоды и неопределенного риска. Однако без вычислений наилучшим подспорьем является симуляция с помощью RISKOLOGY, показывающая чистую выгоду для ряда из 100 смоделированных проектов. Система дает гистограмму, которую можно аппроксимировать гладкой кривой, как показано на этом рисунке:
Глава 22
Уточнение правил управления рисками
Вернемся к правилам, впервые изложенным в главе 10, чтобы добавить некоторые уточнения. Начнем здесь с пересмотра первого раздела этой главы «Что понимают под управлением рисками».
Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект (пункты 6-12 включают больше всего изменений по сравнению со списком в главе 10, но мы, конечно, рассмотрим заново весь процесс):
1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.