Каков наилучший способ анализа рисков проекта?
Есть ли надежный способ избавиться от всех рисков, связанных с проектом? И отличается ли он в зависимости от типа проектов, над которыми вы работаете (например, веб-сайт, клиент / сервер...)?
8 ответов
"Различается ли [риск] в зависимости от типа проектов, над которыми вы работаете?"
Да, конечно. Существует несколько универсальных рисков для программных проектов (отсутствие управленческих обязательств, плохая коммуникация и т. Д.), Но "профили" риска различаются в зависимости от контекста. Скажем, риски проекта видеоигры сильно отличаются от рисков проекта управления цепочкой поставок предприятия.
Для корпоративного развития риски различаются в зависимости от управленческой поддержки и сложности, структуры команды, размера проекта, взаимодействия с клиентом по сравнению с внутренним, выбора платформы и уровня интеграции, и это лишь некоторые основные области.
Тот факт, что риски различаются, является одной из причин, по которой "недостаточный опыт в данной области" является универсальным риском.
Профили риска для различных контекстов являются популярными темами для научных работ (проведите опрос, отшлифуйте некоторые цифры, получите кредит на публикацию...). Как правило, они не увлекают чтением, но их стоит рассмотреть при разработке плана проекта.
Отличная короткая книга по управлению рисками - "Вальс с медведями" Демарко и Листера.
Определенно нет надежного способа. Целые книги были написаны на эту тему. И если говорить о книгах, я рекомендую этот:
Руководство по выживанию проекта программного обеспечения Стива Макконнелла (я знаю, дрянное изображение)
Нет надежного пути - самые опасные риски - это те, которые вы не предвидите.
К сожалению, это усугубляется тем, что разработчики склонны быть оптимистами. Если вы спросите программиста о "наиболее вероятной оценке", вы получите тот же ответ, что и при запросе "наилучшей оценки". По моему опыту, лучшее, что вы можете сделать, - это найти хороших людей и всегда предполагать, что их оценки низки, даже после того, как вы попросили их не быть оптимистичными, даже после того, как вы сказали им включить несколько непредвиденных обходных путей.
И прежде всего, никогда, никогда, НИКОГДА не говорите своему программисту, что оценка слишком высока, и ему нужно ее снизить. Если вы хотите вытащить оценку из своей шляпы, сделайте это, но будьте честны с тем фактом, что вы вытащили ее из своей шляпы. Притворяться, что "это оценка программиста", когда вы заставляете его понизить, это рискованно и нечестно.
Я очень рекомендую "Мифический человеко-месяц " Фреда Брукса для того, чтобы узнать о вреде процесса разработки программного обеспечения.
Не забудьте финал любой разработки:
Выпуск в производство
Можно утверждать, что любой риск, связанный с разработкой программного обеспечения, должен оцениваться с учетом этой цели (успешное внедрение в производство вашего программного обеспечения, иными словами "предоставление услуги клиенту").
Этого будет недостаточно, поскольку мониторинг и поддержка этого программного обеспечения сами по себе являются рискованными операциями, но это хорошее руководство.
Например, НАСА (для которого "выпуск" имеет первостепенное значение!) Имеет определение моделей качества программного обеспечения. У IBM есть большая серия статей на эту тему.
Все остальные ответы и рекомендации книги верны.
Я просто хотел поставить в центре любого ответа, что такое проект ("релиз"), чтобы лучше определить собственное определение "риска" для этого проекта.
Опыт. Практика разработки и выпуска программного обеспечения позволит вам предвидеть и снижать риски так, как это не может сделать структурированный анализ.
Управление рисками - огромная тема, и, вероятно, она не может быть признана справедливой в ответе здесь на stackru. Лучше всего пойти и получить хорошую книгу по управлению программными проектами (рекомендация для Руководства по выживанию программных проектов), и идти оттуда.
Пара основных рисков включает в себя: знают ли программисты, что нужно строить, и как это сделать, и могут ли они работать вместе? Некоторые методологии разработки, в том числе гибкие и экстремальные, атакуют эти риски в лоб, создавая что-то реально построенное как можно скорее, а затем развивая работающую систему, выполняя одну высокоприоритетную бизнес-задачу за раз.
Мне очень понравилась эта статья: Анализ рисков в разработке программного обеспечения(PDF), посмотрите на нее, дает хороший обзор анализа рисков, но я думаю, что нет надежного способа, он действительно зависит от вашей среды..,