Риски программных проектов

Сергей Трофимов 22.02.2003

Риски программных проектов можно разделить на четыре основные категории:

Риски связанные с требованиями
Технологические риски
Риски связанные с квалификацией персонала
Политические риски

Это только основные категории, однако, в каждом конкретном случае могут быть добавлены другие типы, не рассмотренные здесь.

Риски связанные с требованиями

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

Еще одна группа рисков, связанная с требованиями - это реализация второстепенных требований и откладывание требований, которые могут принести основной результат пользователям.

Основной способ справится с этой группой рисков - контролировать процесс управления требованиями, создавать UML модели вариантов использования и привлекать заказчиков для обсуждения полученных моделей. Заказчик должен понять, даже если он этого не понимал в начале, что он получит на каждом этапе разработки и как этим можно будет пользоваться. Использование инструментальных средств для управления требованиями, таких как RequisitePro и ClearQuest и такого инструмента для создания моделей, как, например, Rational Rose

Технологические риски

Эта группа рисков объединяет риски связанные с используемыми технологиями. Какие технологии вы планируете применить. Использовались в вашей компании выбранные средства, насколько эти технологии отработаны или это "только что испеченные пирожки".

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

Наилучший вариант оценить технологические риски - это создать прототип для проверки новых технологий.

Риски связанные с квалификацией персонала

Хотя этой группе рисков обычно уделяют мало внимания, когда как она не менее важна, чем две предыдущие. Насколько сотрудники, которые участвуют в проекте опытны применяемых технологиях? Есть ли опыт ведения аналогичных проектов, достаточен ли опыт менеджера проекта?

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

Политические риски

Это очень опасная группа рисков, которая с высокой вероятностью может привести к краху проекта даже если все другие "подводные камни" будут обойдены.

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

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

На одном из проектов я столкнулся с тихим противодействием руководителя подразделения, подчиненные которых были так загружены текущей работой, то на работы по проекту у них не оставалось времени, за чем ревностно следил сам руководитель подразделения.

В другом - было открытое противостояние внедрению новой программной системы со стороны главного бухгалтера, что привело к многим неприятным последствиям.

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