Программная инженерия. Управление рисками

Я немного присматриваю за тем, как в одном из вузов готовят программных инженеров (специальность 231000), и буду иногда писать в блог свои впечатления. Так получилось, что сразу после вводной лекции к курсу студентов ознакомили с управлением рисками ИТ-проекта. Наверное, такая последовательность изложения материалов не очень верна, но почему-то вот так сложилось. Поэтому сегодня пару слов об управлении рисками. Про риски сказано много. Сказано. что их надо выявлять, оценивать, мониторить, митигировать и т.д. Все это я повторять не стану, а выскажу своё понимание рисков.

Проектные риски появляются в ходе планирования и целеполагания. Как только мы говорим, что в некоторый момент времени хотим получить что-то, так сразу и появляется риск этого не получить, либо получить что-то другое, либо получить это не вовремя. Без наличия целей (конкретных, измеряемых, релевантных, детерминированных во времени и т.д.) никаких рисков не существует. Как только появляется цель, пусть цель промежуточная, так появляется и риск. Можно ли планировать без рисков? Конечно, нет. Причина этого не в том, что требования меняются или плохо сформулированы, технологии недостаточно отлажены или же сроки нереалистичны. Причина в том, что мы, в отличии от экстрасенсов, не умеем достоверно предсказывать будущее. А почему мы не умеем предсказывать будущее – вопрос философский. Мы же не станем философствовать, а лучше для себя запомним, что риски возникают в ходе планирования из-за нашей принципиальной неспособности создать абсолютно точный план.

Небольшое отступление. То, что план проекта и расписание проекта – это не одно и то же, знают многие. Не многие помнят, что английское слово plan может являться не только существительным, но и глаголом. Хороший проектный менеджер считает, что план – это именно глагол, а не существительное.

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

Другой вопрос в том, что практика планирования в управлении проектами подразумевает наличие единственного верного пути, приводящего нас к цели. Я ни разу не видел диаграмму Ганта, имеющую ветвления, условные переходы, альтернативные последовательности работ. Не знаю, почему так сложилось, но в проектном плане, в отличии, например, от модели бизнес-процесса, принято рисовать только один вариант действий. Это вам не use cases в стиле Алистера Коберна, описывающий основной сценарий, исключения и последовательности действий для обработки исключений. Ничего подобного в проектном менеджменте нет. Отчасти из-за этого и возникает необходимость в формулировании рисков (исключений, говоря языком use case-ов) и планировании последовательности действий, реализуемой при их возникновении.