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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26 Вопросы?

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