《软件项目风险的主要来源以及如何规范》

《软件项目风险的主要来源以及如何规范》

软件项目的风险可以分为外部风险和内部风险两大类。外部分析又称为需求风险、客户风险，内部风险又分为计划编制风险、组织和管理风险、人员风险、开发环境风险、产品风险设计和实现风险、过程风险。

需求风险：需求是一个项目标准的基准，但是客户的需求可能随时变化。有的需求欠佳，而进一步的定义会扩展项目的范畴，产品定义含混的部分比预期需要更多的时间，在做需求中，客户的参与度不够高，缺少有效的需求变化的管理过程。

计划编制风险：计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；产品规模比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

组织和管理风险：仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；低效的项目组结构降低生产率；管理层审查
决策的周期比预期的时间长；预算削减，打乱项目计划；管理层作出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

人员风险：作为先决条件的任务(如培训及其他项目)不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；没有找到项目急需的具有特定技能的人。

开发环境风险：设施未及时到位；设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。

客户风险：客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户对规划、原型和规格的审核
决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

产品风险：矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能(镀金)，延长了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块将比预期花费更长的时间；依赖正在开发中的技术将延长计划进度。

设计和实现风险：设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。

过程风险：大量的纸面工作导致进程比预期的慢；前期的质量保证行为不真实，导致后期的重复工作；太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。

对于这些潜在的风险，我们需要趁早发现乘早解决，不要忽略参考以前的相关的项目经验，俗话说的好：前车之鉴后车之师，以前的项目无论是项目的风险识别还是应对方面都能够给现在的项目一些其实和经验。要充分考虑项目成员对风险的态度风险管理不是项目经理一个人的事，需要全员的参与，而不同成员对风险的态度往往也会在某种程度上决定风险应对的措施。对于风险追逐型的组员，就要考虑其对风险的分析和认识是不是偏于乐观，同时也不能由于某些风险保守型成员对风险的态度而止步不前；需求人员还得跟老板商量商量需求确认需求，避免中途大幅度的修改需求，总之，项目的风险需要项目经理和成员共同重视，发现解决才能做出一个好的项目出来。