Глава 2: Классификация рисков Козинов Евгений - лидер мини-проекта Лялин Сергей – главный разработчик Мини-проект выполнили:

Риски делятся на: Известные – те, которые определены, оценены, для которых возможно планирование. Неизвестные – те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть.

Можно выделить три основные группы: Риск проектирования. Технический риск. Бизнес-риск (деловой риск).

Коротко о рисках проектирования: Риски проектирования включают риски, связанные с неопределённостью в финансировании проекта, в квалификации персонала, непостоянствам требований заказчика, несвоевременными поставками технических и программных средств и так далее. Кроме того, факторами риска являются сложность и размер программного изделия.

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

Коротко о бизнес-рисках: Наиболее коварный – деловой риск. Например, создан прекрасный продукт, который ещё не соответствует требованиям рынка, либо созданный продукт не соответствует стратегической линии компании, либо прекращено бюджетное финансирование и тому подобные.

Категории рисков: Риски связанные с требованиями. Технологические риски. Риски связанные с квалификацией персонала. Политические риски. Это только основные категории, однако, в каждом конкретном случае могут быть добавлены другие типы, не рассмотренные здесь. К тому же эта категоризация не является подструктурой рассмотренной выше – её можно считать альтернативной.

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

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

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

Причины: Группа людей, которые заказывают программную системы и та группа людей, которая делает её, не совпадают друг с другом. Не совпадают их знания, методы, привычки, профессиональное чутьё. Для одних некоторая деталь системы является лишь мелкой технической проблемой, другие же считают её ключевой в проекте. Заказчик, из-за отсутствия у него опыта разработчиков, даже может не знать о некоторых свойствах системы, которые ему обязательно понадобятся.

Итог: Cоздаваемая система будет выполнять не то, что хотели пользователи. Особенно это касается сильно специализированных программных систем в редких приложениях или глубоко научных разработках. Чем дальше предмет системы от разработчиков, тем труднее будет правильно сформулировать исходные требования; то есть, сформулировать так, что бы они включали в себя все без исключения требования заказчика и были полностью и правильно поняты разработчиками.

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

Основная проблема: Эта группа рисков объединяет риски связанные с используемыми технологиями. Со времён зарождения отрасли производства программного обеспечения было создано великое множество технологий. Технологии создавались для того, что бы решать задачи по некоторому шаблону: не всегда «всё заново и как хочется», а с уже известными выделенными этапами и средствами. Для каких- то задач хороши одни технологии, но не применимы другие, а для других наоборот.

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

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

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

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

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

Проект не могут спасти гении-одиночки, если основная масса участников проекта – дилетанты. Если программисты не разбираются в UML диаграммах, а аналитики только их и создают, то проект можно даже не начинать. Итог:

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

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

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

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

Пример Открытое противостояние внедрению новой программной системы со стороны главного бухгалтера приводит ко многим неприятным последствиям.

Вопросы?

Использованные материалы: 1.Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е издание. М.: «Издательство Бином», СПб.: «Невский диалект», – 560 с., ил system.ru/pj_managment/article/pj_risk_pj.htmlhttp:// system.ru/pj_managment/article/pj_risk_pj.html