朝着产品经理的方向
大步走去

如何减少软件项目的不确定性带给我们的惊讶

项目会有什么潜在风险

计划编制风险

计划、资源和产品的定义完全由客户或上层领导决定,忽略了软件项目组的意见,并且这些决定不完全一致。
计划忽略了必要的任务和活动。
计划不切实际。
计划基于特定的项目组人员,而这样的项目组人员得不到。
软件规模估算过于乐观。
工作量估算过于乐观。
进度的压力造成生产率的下降。
目标日期提前,但没有相应地调整产品范围和可用资源。
一个关键任务的延迟导致其他相关任务的连锁反应。

组织和管理风险

缺乏强有力、有凝聚力的领导。
解雇人员导致软件项目小组能力下降。
削减预算打乱软件项目计划。
仅由管理层和市场人员进行技术决策。
低效的项目组织结构降低软件开发的生产率。
管理层审查/决策的周期比预期时间长。
管理层作出了打击软件项目组积极性的决定。
非技术的第三方的工作比预期要长(如采购硬件设备)。
计划性太差,无法适应期望的开发速度。
软件项目计划由于压力而放弃,导致开发混乱。
管理方面的英雄主义,忽视客观确切的状态报告,降低发现和改正问题的能力。

开发环境风险

开发设施和工具不能及时到位。
开发设施和工具到位但不配套。
开发设施和工具不如期望的那样有效。
开发人员需要更换开发设施和工具。
开发设施和工具的学习期比预期要长。
开发设施和工具的选择不是基于技术需求,不能提供计划要求的功能。

最终用户风险

最终用户坚持新的需求。
最终用户对交付的软件产品不满意,要求重新开发。
最终用户不买进项目产品,无法提供后续支持。
最终用户的意见未被采纳,造成软件产品无法满足用户要求。

承包商风险

承包商没有按照承诺交付软件产品。
承包商提供的软件产品质量低下,必须花时间改进质量。
承包商提供的软件产品达不到性能要求。

需求风险

需求已经成为软件项目基准,但仍在变化。
需求定义欠佳:不清晰、不准确、不一致。
增加了额外的需求。

产品风险

错误发生率高的模块,需要更多的时间对它进行测试和重构。
矫正质量低下的软件产品需要更多的时间对它进行测试和重构。
由于功能错误,导致需要重新进行设计和实现。
开发额外不需要的功能延长了进度。
要满足软件产品规模和速度要求,需要更多的时间。
严格要求与现有系统兼容,需要更多的时间。
要求软件重用,需要更多的时间。

人员风险

招聘人员所需的时间比预期要长。
作为开发人员参与工作的先决条件(如培训、其它项目的完成等)不能按时完成。
开发人员与管理层关系不佳导致决策迟缓、影响全局。
项目组人员没有全身心地投入到项目中,无法达到所需的软件产品功能和性能需求。
缺乏激励措施、士气低下。
缺乏必要的规范,增加工作失误,重复工作,降低工作质量。
缺乏工作基础(语言、经验、工具等)。
项目结束前,项目组人员离开软件项目组。
项目后期,加入新的软件开发人员,额外的培训和沟通降低了软件项目组人员的开发效率。
项目组人员不能有效的在一起工作。
由于项目组人员间的冲突,导致沟通不畅,设计欠佳,接口错误和额外重复的工作。
有问题的项目组人员没有及时调离软件项目组,影响其他人员的工作积极性。
最佳人选没有加入软件项目组,或者加入软件项目组但没有合理使用。
项目组关键人员只能兼职参与。
项目组人员的数目不足。
任务的分配和人员的技能不匹配。
人员工作的进展比预期的要慢。
项目管理人员怠工,导致计划和进度失效。
技术人员怠工导致工作遗漏、质量低下,工作需要重做。

设计和实现风险

设计过于简单,考虑不仔细、不全面,导致重新设计和实现。
设计过于复杂,导致一些不必要的工作,影响效率。
设计质量低下,导致重新设计和实现。
使用不熟悉的方法,导致需要额外的培训时间。
产品使用低级语言编写,导致开发效率较低。
分别开发的模块无法有效集成,需要重新设计和实现。

过程风险

跟踪不准确,导致无法预知项目进展是否落后于计划。
前期的质量保证行为不真实,导致后期的重复工作。
没有遵循标准,导致沟通不足,质量问题和重复工作。
风险管理粗心,导致没有发现重大的软件项目风险。
风险影响多大

发生可能性

怎么应对

制定风险管理计划

针对各个重要风险制定风险管理计划,并确保它们的一致性;

 避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。

风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。

变化是可以控制的 纠偏

未经允许,不得转载本站任何文章:任平的博客 » 如何减少软件项目的不确定性带给我们的惊讶

分享到:更多 ()

评论 抢沙发

验证码 *
Time limit is exhausted. Please reload CAPTCHA.

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址