关于软件项目的风险识别，你应该知道的一切
关于软件项目的风险识别，你应该知道的一切
只需花几分钟来遵循本文中的步骤，您应该能够识别项目中 80%的风险。
所有项目都有风险。在你最需要的时候，主动解决这些风险会节省你的时间和精力。但首先，让我们定义术语“风险”,因为它让我们对我们以后的活动有更好的理解:
风险是一种不确定的事件或情况，如果发生，至少会对一个【项目】目标产生影响
这种说法可以用下面的方式来表达
风险=概率*影响
对于每一个风险，我们将需要理解它发生的概率或可能性，以及如果它发生，它将对项目产生的影响。
这是一个快速指南，所以让我们开始识别您的项目风险。
注意:常见风险领域
您的大多数项目风险可能产生于以下优先领域(根据 Tharwon Arnuphaptrairong 的一项研究):
- 对要求的误解
- 缺乏管理层的承诺和支持
- 缺乏足够的用户参与
- 未能获得用户承诺
- 未能管理最终用户期望
- 要求的变更
- 缺乏有效的项目管理方法
风险识别技术
调查表
使用此(简化)问卷(完整问卷)来识别风险，并根据 Boehm 十大软件风险中的建议的缓解策略进行工作:
1。 人员不足
问题:项目时间框架内所需数量的熟练技能是否可用？
缓解:配备顶尖人才、工作匹配、团队建设、关键人员协议、交叉培训
2。不切实际的时间表和预算
问题:所有的需求&任务都是由承担工作的团队评估的吗？
问题:任务之间的所有依赖关系都被识别和考虑了吗？
缓解:详细的里程碑成本和进度估计，成本设计，增量开发，软件重用，需求清理
3。开发错误的功能和属性
问题:对系统的需求是否清晰易懂且稳定？
问题:开发人员和定义产品需求的人员之间有误解或沟通不畅的历史吗？
缓解:组织分析、任务分析、运营概念制定、用户调查和用户参与、原型制作、早期用户手册
4。开发错误的用户界面
问题:用户界面是否已经原型化并在样本用户群中测试过？
问题:用户界面的目标被定义了吗？
缓解:原型、场景、任务分析、用户参与
5。镀金
问题:在项目开发过程中，是否有不需要的功能被添加的历史？
缓解:关注 MVP，需求清理，原型，成本收益分析，按成本设计
6。持续不断的需求变化
问题:过去的客户历史是否表明需求经常变化？
问题:团队是否很好的理解了客户/用户在系统中想要什么？
缓解:高变更阈值信息隐藏，增量开发(将变更推迟到以后的增量)
7。外部供应部件的短缺
问题:该项目所依赖的项目是否存在交付风险？
缓解:基准测试、检查、参考检查、兼容性分析
8。外部执行任务的不足
问题:该项目或其任何任务是否依赖于外部项目开发工作的完成？
缓解:背景调查、授标前审计、授标费用合同、竞争性设计或原型制作、团队建设
9。 实时性能不足
问题:系统响应时间的要求是否已经定义？
问题:是否定义了数据存储、内存&处理速度的要求？
问题:用户支持(数量)需求是否已经定义？
缓解:模拟、基准测试、建模、原型制作、测试、调优
10。训练计算机科学能力
问题:组织是否已经使用类似的工具交付了类似的系统？
缓解:技术分析、成本效益分析、原型制作、背景调查
头脑风暴
将不同的利益相关者聚集在一个房间里，试图产生尽可能多的风险。没有不好的建议。最初，在关注一些风险并以此为基础(聚合思维)之前，你会寻找尽可能多的风险(发散思维)。如果团队陷入困境，那么引导他们实现不同的项目目标(进度、范围、质量、预算)和任务(需求、测试等)。)
你可能想使用这个链接来计划你的头脑风暴会议，并利用最佳实践来进行头脑风暴。
约束和假设分析(CAA)
您的项目已经有了已知的约束，并且建立在多个假设之上。把这些都拿过来，把它们翻转过来。现在，每一个都应该重写，就像它们失败了一样。现在，您已经确定了一系列重大风险。例如，如果您最初的假设是您的新网站将使用某个支付提供商，那么反过来说，您现在无法使用该支付提供商。为什么会发生这种情况，你能做些什么来处理这种情况？
三点估计的标准偏差
有些做法只是通过经验学来的。这个是我的。我根据这个方法识别出了这么多潜在的风险。这背后有复杂的逻辑，但可以简单地解释为:在三点( PERT )估算中，如果最小数字(乐观)和最大数字(悲观)之间的差值很大，那么你已经发现了一个风险。这通常发生在评估任务的人甚至没有意识到的情况下。
未发现风险
- 乐观估计= 3
- 最可能的估计= 5 (+2)
- 悲观估计:= 7 (+4，+2)
已识别的风险
- 乐观估计= 3
- 最有可能的估计= 5
- 悲观估计:= 12 (+9，+7)
我还为你们的同行&竞争对手发布了一篇更详细的风险识别文章。如果您希望更深入地挖掘以发现更复杂的风险，您可能也会喜欢。下一次，我们将回顾各种分析技术，这些技术可用于确定您发现的风险的大小和优先级。