Вы рискуете проанализировать свои проекты? - PullRequest
5 голосов
/ 22 января 2009

Используете ли вы методы анализа рисков при запуске новых проектов?

Мне нравится, когда в компании начинают работать молодые люди, у них так много теории, которую они изучают и хотят реализовать, когда начинают работать. Анализ рисков, управление проектами, стандарты кодирования, стандарты документации и так далее. (Тогда реальность поражает их, большинство клиентов не будут платить за все это);) Но, тем не менее, я действительно люблю свежий ветер и новые знания, которые они несут с собой!

Автомобильная индустрия, и я предполагаю, что ОЧЕНЬ много других отраслей используют анализ рисков ежедневно при внедрении новой функции или чего бы то ни было.

По моему опыту, «анализ рисков», который я проводил в прошлом, заключался в том, что «эта часть сложная, я не знаю, сработает она или нет» и «Если это не сработает, мы могу попробовать так ".

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

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

Итак ... Я хочу знать все, что вы знаете об анализе рисков. Просвети меня!

Ответы [ 4 ]

2 голосов
/ 22 января 2009

Я делаю анализ рисков все время - как формально, так и неформально (например, при оценке, если ошибка должна быть исправлена).

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

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

  • «Какова вероятность этого?»
  • "Каково влияние, если это произойдет?"
  • «Насколько хорошо мы сможем справиться с проблемой?»

Вы присваиваете баллы от 1 до 10 всем критериям, умножаете их и принимаете меры по профилактике рисков в порядке убывания (у нас также есть порог, выше которого риск считается неприемлемым и должен быть уменьшен).

Вы также можете добавить четвертый вопрос о том, сколько стоит снижение риска у источника (в медицинской отрасли мы этого не делаем: риск, который считается неприемлемым для здоровья пациента, должен быть снижен независимо от стоимость или эта функция должна быть отброшена)

2 голосов
/ 22 января 2009

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

Я был очень впечатлен материалом в Waltzing With Bears: Управление рисками с программными проектами . Они предлагают очень формальный процесс анализа рисков, но их анализ и понимание важны и для гораздо менее формального анализа рисков.

1 голос
/ 22 января 2009

Существует несколько типов риска, которые следует учитывать при приближении к проекту:

  • Риск невыполнения - риск, возникающий в случае сбоя проекта или в случае его завершения
  • Риск пропущенных требований - риск того, что требования будут пропущены
  • Организационный риск - риск, создаваемый любыми организационными изменениями, вызванными изменением

Кроме того, существуют особые риски:

  • Риск интеграции - риск того, что интеграция функции приведет к тому, что система перестанет функционировать должным образом
  • Риск регрессии - риск того, что функция приведет к неработоспособности других функций
  • Риск безопасности - риск того, что функция не обеспечит адекватную защиту системы (внедрить эксплойт)

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

0 голосов
/ 22 января 2009

Анализ рисков - это причудливый способ сказать «прикрывать мою задницу, когда дела идут плохо», и, как таковой, это отличный способ уклониться от вины, когда дела идут не так, как планировалось (что в разработке программного обеспечения довольно много всегда).

Анализ рисков: укажите все, что может пойти не так, запишите их в симпатичном .pdf и отправьте их своим остроконечным боссам.

...