项目实施过程中的风险控制

项目不同于日常任务，它有明确的起止时间和目标，要在明确的范围、时间和成本约束下，达到相应的质量标准，并取得用户的满意。影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，作为一个项目经理，应该具备良好的风险控制意识，善于识别风险并分析风险的影响，从中发现影响目标的风险点，并施加影响或采取应对措施，把风险的负面影响降到最低，并且风险控制应该贯穿项目始终。

 

风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，导致这些问题的因素主要包括目标及需求不明确、范围蔓延、返工、人员技能不足、缺乏良好的团队协作等。

 

一、目标及需求不明确

为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有形成正式的业务需求文档，我想大多数从事IT的技术人员也深有体会，在没有明确的需求范围的情况下，为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。

 

所以，在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

 

二、范围蔓延

在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目经理针对这种情况一定要采取严格的变更控制流程，不能碍于脸面，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制委员会根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际情况下可以采取一些软措施缓解矛盾。

 

三、返工

返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需求不明确或范围没有有效控制都可能造成返工，另外造成返工的原因是质量没有达到用户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统集成的时候就会发现一大堆问题，不得不花费很大精力回头排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问题留在了后面。这就需要在项目实施过程中采取有效的措施来规避返工的风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查，在编码过程中加入2-3次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

 

四、人员技能不足

项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个生手可能就需要7-10天。项目经理应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包，借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分析。

 

五、缺乏良好的团队协作

软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。

 

项目的实施过程需要不断地识别和应对风险，并加以有效的控制，风险管理的好与坏直接影响项目的实施效果，从某种意义上讲，项目实施对于项目经理就是识别、分析、应对、控制风险的过程，使项目的约束性目标和质量目标朝有利的方向发展。

评论

7 楼 squall140 2010-01-26  

这篇文章写的很好，但是我不认为这些都是项目风险环节上出现的问题。

重在需求分析

6 楼 yiding_he 2009-12-03  

seeckt 写道

为什么做需求一定要带技术人员？ 带了真的保险了么？

如果有这个问题，
说明需求人员和客户都没搞明白什么是需求，什么是达成需求解决方案
在搞用户需求的时候直接把软件需求和开发设计直接做了
要再带上满脑子是怎么编码实现技术人员，
最后肯定一团糟

就是因为没搞明白需求，所以才去做需求。在做需求的过程中，技术人员的作用很重要，能够提供可行性参考。至于你说的“一团糟”，根本原因不在于有没有技术人员，而在于面谈过程缺乏控制。理想情况是，把所有成员都带到客户面前，由项目经理或需求人员控制谈话过程并做出所有的决定。

5 楼 xindeman 2009-12-03  

不带技术人员也是可以的，但还是要把握需求，否则你一拍脑袋技术人员累死，公司赔死。

4 楼 seeckt 2009-12-03  

为什么做需求一定要带技术人员？ 带了真的保险了么？

如果有这个问题，
说明需求人员和客户都没搞明白什么是需求，什么是达成需求解决方案
在搞用户需求的时候直接把软件需求和开发设计直接做了
要再带上满脑子是怎么编码实现技术人员，
最后肯定一团糟

3 楼 black.angel 2009-12-01  

针对 jsntghf 说的,我认为第一条是引起很多项目流产的主要原因.

对需求的确定,一定要带上一个技术人员去一起考察才算真的上了保险.

2 楼 JavaLanguageFun 2009-11-29  

这都是前人总结的一些经验。既然大家都知道 ， 我们应该拿着这些经验去避免

1 楼 yiding_he 2009-11-23  

用户的核心价值。不搞懂这个，就无法引导用户决定事情的优先级。