Вальсируя с медведями
Шрифт:
1. Использовать процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту.
2. Убедиться, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Провести всю указанную предварительную подготовку по каждому из рисков:
• Дать наименование риску и присвоить ему уникальный номер.
• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).
• Оценить влияние риска на стоимость
• Оценить вероятность наступления риска.
• Рассчитать подверженность риску по отношению к графику и бюджету.
• Определить заранее, какие меры придется принять, если и когда событие риска наступит.
• Определить, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включить действия по ослаблению риска в общий план проекта.
• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделать первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект.
6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.
7. Выразить, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом.
8. Отслеживать все риски на предмет наступления или исчезновения и осуществлять планы на случай непредвиденных обстоятельств всякий раз, когда риски наступают.
9. Поддерживать в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Эти шаги достаточно легко перечислить, но труднее осуществить. Уместно сделать несколько замечаний:
Посылка, на которой строится наш подход к календарному планированию на основе N, состоит в том, что природная склонность к оптимизму и имеющийся опыт (вместе с любыми имеющимися у вас инструментами для решения этой задачи) делают нас достаточно искусными в вычислении N, самой оптимистичной из всех возможных дат завершения проекта. Отличие нашего подхода от традиционного состоит в том, что мы предлагаем не брать обязательств сдать работу в срок N, а использовать N как входные данные в процессе определения более разумных обязательств, приемлемых с точки зрения ограниченной неопределенности, показанной на вашей диаграмме риска.
Разумеется, график, построенный на основе N, может быть нарушен. Например, кто-то, горя желанием заставить вас взять обязательство завершить проект через 12 месяцев, может пытаться убедить вас, что N составляет 4 месяца, поэтому ваша диаграмма риска должна основываться на 4. Но бремя доказательств в этом
Предположим, что диаграмма риска для вашего проекта показывает N в марте, а готовность с вероятностью 75% – в сентябре. На этой основе вы можете предпочесть убедить участников проекта получить продукт в сентябре. Сентябрь – разумный срок для обязательств, но совсем не идеальная цель для вдохновения членов команды проекта. Никто не хочет работать ради цели, имеющей 75%-ную вероятность, то есть с очень низкой эластичностью. Аналогично, N – также неудачная цель для проекта, поскольку никто не хочет работать ради цели, имеющей вероятность 0%, все мы слишком большую часть жизни тратим на бесплодные усилия. Наилучшим решением является установление в качестве цели эластичной даты сдачи проекта где-то между N и установленным сроком сдачи.
Это – новое и отличное от прежнего: проект с установленной датой сдачи, отличающейся от эластичной цели. Долгое время в большинстве компаний было принято:
График = Цель = N действительно дурацкое уравнение
N – не вдохновляющая цель, потому что она недостижимая. По той же причине она будет катастрофической как обязательство по завершению проекта. Вместо этого мы предлагаем:
График > Цель > N более разумно
Если мы убедили вас, что это разумно, не стоит автоматически считать, что все в вашей организации посмотрят на дело таким образом. Глубоко укоренилась дурная привычка брать N как обязательство по сдаче. Необходимо отделаться от нее, но следует ожидать, что избавление от нее, как и от любой другой дурной привычки, будет болезненным процессом.
ТРЛ: Мой отец – математик, профессор на пенсии. Однажды он разворчался на меня по поводу всех проектов по разработке программного обеспечения, которые выполнялись с тем или иным опозданием, что относится почти к 100% проектов. «Почему так?» – вопрошал он.
Я ответил: «Видишь ли, у проекта есть всего два возможных варианта: своевременное выполнение и запаздывание. Полагаю, что перевес в пользу запаздывания, за исключением нескольких весьма примечательных случаев».
«Вариантов не два, Тим, – ответил он. – Есть и третий – досрочная готовность».
Это заставило меня задуматься. Я все время бывал в компаниях, для которых опережение графика совершенно немыслимо. Менеджера, который завершил бы проект раньше срока, обвинили бы в недобросовестном манипулировании графиком и, возможно, изгнали бы с позором.
Делая третий вариант – досрочную готовность – по сути незаконным, мы сокращаем шансы на выполнение проекта в срок почти до нуля. Наши меры противодействия превратили манипулирование графиком скорее в правило, чем в исключение.