软件项目成败十大因素分析

      经过CHAOS Report的统计，发现软件项目成功的十大保证中，有三个到四个（其中一个是需求定义，我们也认为和需求相关），差不多占到40%左右，这是一个很大的比例了。而十大败因中，直接和需求相关的更是超过了50%，也就是说，需求一旦出现问题，项目基本上就是失败了，包括完全失败、在项目成本的大幅度超支、在项目进度上的较多的delay……

     更多的信息可以在下面的网站去查找：

http://www.projectsmart.co.uk/whitepapers.html

 

 

成功因素	权重	失败因素	权重
用户的参与（需求）	15.9%	不完整的需求（需求）	13.1%
执行层的支持（项目管理）	13.9%	缺乏用户参与（需求）	12.4%
清晰的需求描述（需求）	13.0%	资源不足（资源）	10.6%
合适的规划 （需求定义和项目管理）	9.6%	不切实际的用户期望（需求）	9.9%
现实的客户期望（需求）	8.2%	缺乏执行层的支持（项目管理）	9.3%
较小的里程碑（项目管理）	7.7%	需求变更频繁（需求）	8.7%
有才能的员工（资源）	7.2%	规划不足（需求定义、项目管理）	8.1%
主权	5.3%	提供了不再需要的（需求、项目管理）	7.5%
清晰的愿景和目标（需求定义）	2.9%	缺乏IT管理（项目管理）	6.2%
努力的工作和稳定的员工（环境、资源）	2.4%	技术能力缺乏（资源）	4.3%
其他	13.9%	其他	9.9%

 

     

      下面，简单的对需求的几个败因做简单的分析：

      一、不完整的需求：

       出现的环节及应对策略：

       1、需求的捕获阶段，该捕获的项目干系人没有访谈到，导致部分需求缺失，不完整，另外，也有可能是忽视了非功能性需求。//按需求层次，列出需要访谈的对象，并请客户和重要项目干系人确认；加强需求评审环节；重视非功能性需求。

       2、需求分析，在需求的漏斗出现了问题，过滤掉了本不该过滤掉的需求。//加强需求评审环节。

       3、在需求表述环节出现了问题。//加强需求评审环节。

       4、在需求评审环节出现了问题，需求评审的效率不高、没有找全必须的评审者、或者过于形式化//正确的认识评审的作用，并做好评审。

      二、缺乏用户参与：

      这也是一个很常见的例子，一方面可能是开发方或者实施方对客户的参与度重视不够，因为各种原因低估了用户参与的作用，另外，也有可能是客户方的不重视，由不合适的人拍板，用户没有或者很难参与进来，这往往是客户方项目经理或者客户高层的问题。

     可能的原因及应对策略：

      1、实施、开发方没有重视到客户参与的作用、意义，也可能是出于项目进度的压力故意压制客户的需求而导致。比如形式化的需求工程，过于走过场，希望项目早点结束，比如不只关注核心项目干系人的需求、意见。//重视用户的参与，给足需求阶段的时间安排。

      2、客户的问题。客户方不重视用户的参与，往往是因为客户资源的进展，比如大家都很忙，或者客户的项目领导比较武断，喜欢拍板而导致用户没有办法参与进来，或者用户即使能参与过来，他们的意见也不太被重视而逃离。//重视用户的参与，他们才是真正的受益者或者受害者，把领导的期望和基层用户的需求联系起来，或者领导更多的考虑流程的规范性和报表的需求，而把操作和业务需求交给真正的人来负责。

      三、不切实际的用户期望

      这是长常见的，主要是用户的期望过高，项目经理没有给客户一个合适的期望，客户也没有引导最终用户到合适的期望值。

      这是我们常说的，项目管理，要注重管理客户的期望，如果客户的期望是“5层楼”那么高的话，我们要想办法把他降到“3层楼”，然后把实际的交付交付到“4层楼”。假设“5层楼”是我们在项目实施前“忽悠”的高度（首先给用户一个好的期望，才会选择我们嘛），“4层楼”是一个合理的期望高度的话。//管理用户的期望，很重要！低期望，高交付，这样实际上就超出用户的期望了，从而提高了项目的满意度。当然，也不能管理的太低，否则客户就会没有信息，怀疑实施这么项目的意义和必要性。

      四、需求变更频繁

      需求变更，其实很大程度上和客户没有关系，更多的是我们自己出了问题，在需求开发环节没有做好，当然，也有可能是需求控制方面出了问题。

      1、没有深入到用户需求的本质，需求分析的深度不够，过于形式化。很可能是我们只找到了部分what，没有找到why//要引导、去分析用户为什么要这样，不这样会怎么样。另外，重视需求评审，提高评审的质量！

      2、没有需求的冻结期。导致用户提需求和需求变更的成本太低，认为这是理所当然。//一定要有需求冻结期，使用户重视需求冻结期前的时间来提需求，在需求冻结期引入规范的需求控制流程，并对用户每次的变更做记录和反馈，让用户自己惭愧，并意识到我们的难度和工作量。

      五、提供了用户不再需求的     

      可能的原因及应对策略：

      1、有些需求可能只是拍脑袋，一时兴起。//要区分哪些是稳定的需求，哪些是用户的一时兴起，不稳定的需求可以先不做，拖拖再说。

      2、市场的变化太快或者我们开发、研发的进度太慢，没有跟上市场的节奏。//正确分析产品的生命周期，不在饱和期和衰退期切入。要充分分析自己的研发能力。