Вы рискуете проанализировать свои проекты?
Используете ли вы методы анализа рисков при запуске новых проектов?
Мне нравится, когда в компании начинают работать новые люди, у них так много теории, которую они изучают и хотят реализовать, когда начинают работать. Анализ рисков, управление проектами, стандарты кодирования, стандарты документации и так далее. (Тогда реальность поражает их, большинство клиентов не будут платить за все это);) Но, тем не менее, я действительно люблю свежий ветер и новые знания, которые они несут с собой!
Автомобильная индустрия, и я предполагаю, что ОЧЕНЬ много других отраслей используют ежедневный анализ рисков при внедрении новой функции или чего бы то ни было.
По моему опыту, "анализ рисков", который я проводил в прошлом, заключался в том, что "эта часть сложная, я не знаю, сработает она или нет" и "Если это не сработает, мы можем попробовать путь".
Сегодня я использовал протокол анализа рисков, относящийся к автомобильной промышленности, и был впечатлен тем, что после встречи он выделил одну вещь в проекте, которая была наиболее уязвимой. И дал ряд того, сколько внимания мы должны уделить этой функции в программе против всех других.
Конечно, мы делали это раньше в проектах, но тогда это просто называлось "Что может пойти не так в этом проекте" или "Каковы препятствия в проекте?" не является частью протоколла, который можно измерить между проектами и проанализировать с помощью нуберов.
Итак... Я хочу знать все, что вы знаете об анализе рисков. Просвети меня!
4 ответа
Я делаю анализ рисков все время - как формально, так и неформально (например, при оценке, если ошибка должна быть исправлена).
Это отличный инструмент, позволяющий уделять надлежащее внимание соответствующим вопросам, избегать паранойи по поводу некоторых аспектов проекта (иногда мы теряем перспективу и беспокоиться о неправильных вещах) и принимать трудные решения, когда у вас ограниченные ресурсы.
Это не должно быть чрезвычайно формальным или трудоемким. Когда вы приступите к этому, наш метод просто спросить:
- "Какова вероятность этого?"
- "Каково влияние, если это произойдет?"
- "Насколько хорошо мы сможем справиться с проблемой?"
Вы выставляете баллы от 1 до 10 по всем критериям, умножаете их и принимаете меры по профилактике рисков в порядке убывания (у нас также есть пороговое значение, выше которого риск считается неприемлемым и должен быть уменьшен).
Вы также можете добавить четвертый вопрос о том, сколько стоит снижение риска у источника (в медицинской отрасли мы этого не делаем: риск, который считается неприемлемым для здоровья пациента, должен быть снижен независимо от стоимости, или эта функция должна быть отброшена)
Я никогда не был вовлечен в проект, который сделал много формального анализа рисков. Тем не мение; мы все время проводим чуть менее формальный анализ рисков - мы постоянно составляем списки вещей, которые могут взорваться на наших лицах, что мы планируем сделать, чтобы предотвратить взрыв, и что мы будем делать, если у нас не получится предотвращая это, и это происходит.
Я был очень впечатлен материалом в Waltzing With Bears: Управление рисками с программными проектами. Они предлагают очень формальный процесс анализа рисков, но их анализ и понимание важны и для гораздо менее формального анализа рисков.
Существует несколько типов рисков, которые следует учитывать при приближении к проекту:
- Риск невыполнения - риск, связанный с неудачей проекта или его завершением.
- Риск пропущенных требований - риск того, что требования будут пропущены
- Организационный риск - риск, создаваемый любыми организационными изменениями, вызванными этими изменениями.
Кроме того, существуют особые риски:
- Риск интеграции - риск того, что интеграция функции приведет к тому, что система перестанет функционировать должным образом
- Риск регрессии - риск того, что функция вызовет неработоспособность других функций
- Риск безопасности - риск того, что функция не обеспечит адекватную защиту системы (использовать уязвимость)
С точки зрения анализа важно качественно определить риски проекта, чтобы команда знала об этом. Они в первую очередь смягчены коммуникационными планами. Для характеристики конкретных рисков важно определить конкретные риски количественно. Как правило, архитектор должен документировать риски интеграции и безопасности, а команда QA должна нести ответственность за риск регрессии. Я обнаружил, что на самом деле нет инструментов, которые могут это сделать, а также хорошая команда, которая хорошо общается.
Анализ риска - это причудливый способ сказать "прикрывать мою задницу, когда дела идут плохо", и, как таковой, это отличный способ уклониться от вины, когда дела идут не так, как планировалось (что в программной инженерии почти всегда),
Анализ рисков. Укажите все, что может пойти не так, напишите их в симпатичном PDF-файле и отправьте их своим остроконечным боссам.