[转]需求变更的烦恼

开始是需求不明确&＃xff0c;客户都不知道要做成什么样&＃xff0c;只有一个大概的粗略的描述。等到大楼盖好了&＃xff0c;给客户&＃xff0c;却发现大楼应该是这样那样的。。。客户方和开发方在一起( WorkShop) 还好&＃xff0c;如果分开在两地就更糟糕。。。

永远不变的就是变化&＃xff0c;这个大家都知道&＃xff0c;但关键是如何合理的控制需求变更&＃xff1f;

我以前做的上百人一年多一个的大项目&＃xff0c;完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线&＃xff0c;以后需求变更的时候有需求变更委员会&＃xff08;CCB&＃xff09;或专门负责的角色&＃xff08;通常由客户方需求人员来收集和评估最初需求并提交给QA&＃xff0c;QA牵头需求变更流程&＃xff09;来处理需求变更&＃xff0c;具体做法是&＃xff1a;

1.         先是客户或项目组成员提出的需求申请&＃xff0c;填写《变更申请单》并提交给项目经理。

2.         项目经理组织项目相关人员对需求变更进行评估和调研&＃xff0c;然后组织 需求变更评审。

3.         如果同意变更则由CCB授权配置管理员检出配置项由项目组成员对相关的文档&＃xff08;用户需求说明书、需求规格说明书&＃xff09;进行修改&＃xff0c;修改后评审&＃xff08;同时 填写《变更管理记录表》&＃xff09;通过后由高层经理审批&＃xff0c;然后提交用户确认&＃xff0c;最后纳入配置库&＃xff0c;更新《需求追踪矩阵》&＃xff0c;确保需求和工作产品的一致性&＃xff1b;

4.         如果不同意变 更&＃xff0c;则项目经理、部门经理与客户共同协商&＃xff0c;协商后同意变更&＃xff0c;则对相关的文档进行修改。协商后依然不统一&＃xff0c;则需求变更结束。

5.         所有的需求变更都需要总经理理进 行审批。需求变更的影响&＃xff1a;利用《需求跟踪矩阵》对变更影响进行评估&＃xff1b;估计对项目参数的影响—规模、工作量、进度影响&＃xff1b;超出阀值&＃xff08;整个项目进度的10%- 15%&＃xff0c;里程碑30%&＃xff09;的&＃xff0c;应提交高层评审/批准。

6.         妥善保存变更产生的相关文档。

现在公司做的项目规范较小&＃xff0c;完全按照CMMI的规范来有点多余&＃xff0c;所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化&＃xff0c;持续重构和改进&＃xff0c;迭代开发&＃xff0c;频繁交付。在需求变更管理上我们还没有一套完整的合适的流程&＃xff0c;具体做法是&＃xff1a;

1.         客户提出新需求;

2.         开发人员或项目经理评估后答应了;

3.         继续开发&＃xff0c;时间表按照重新评估后的进行;

4.         基本上很少拒绝客户&＃xff1b;一方面是为了维护客户关系&＃xff0c;另一方面对自己team的开发能力很自信; 结果是上头答应了客户&＃xff0c;下头的只能加班加点赶工。 

另外还有一些控制需求的做法&＃xff1a; 

1.         项目前期会首先快速开发一个产品原型(Prototype)给客户&＃xff0c;有界面的先用visio画个界面&＃xff0c;以验证业务规则、业务流程和大概GUI等。另外&＃xff0c;产品原型也有助于进一步挖掘用户的需求。 

2.         会粗略的列出大体的需求并签字 

3.         频繁交付给客户&＃xff0c;短周期的交付可工作的产品&＃xff0c;以印证需求与实现是否一致&＃xff0c;同时兼做客户教育工作。

问题是如果需求变更无休止&＃xff0c;则需求变更几乎就不可控&＃xff0c;项目开发也无休止。所以我觉得我们公司在需求管理上还缺乏&＃xff1a;

1.         需求基线管理&＃xff0c;经过评审的双方确认签字的需求基线。以后如果要超出或修改需求基线&＃xff0c;则必须有专门的人员对此提出异议&＃xff0c;由CCB审核后方可修改&＃xff1b;

2.         专门的需求控制负责人。现在基本上是技术人员或是项目经理收到客户需求变更&＃xff0c;然后自己评估下就答应了。缺乏专门的需求控制负责人&＃xff0c;因而没有需求评审&＃xff0c;没有一套专门的严格可控的需求变更流程。

3.         需求功能点列表的书面确认。现在签的只是非常粗略的大体需求&＃xff0c;定性而没有定量&＃xff0c;以后扯皮发生的可能性非常大&＃xff1b;

4.         适 当时候应该拒绝客户的要求。虽然用户有众多的理由&＃xff0c;比如他认为改动不大&＃xff0c;竞争对手已经拥有该功能&＃xff0c;或是新的业务需要&＃xff0c;但如果评估后的结果是没有必要&＃xff0c;或不 合理&＃xff0c;或优先级不高&＃xff0c;或风险大于必要&＃xff0c;则坚定的拒绝。另外一种变通的方法是&＃xff0c;根据优先级重要性有条件的答应&＃xff0c;比如放在下一次版本之后。

5.    需求Scope的管理&＃xff0c;不仅要明确做什么&＃xff0c;而且要明确不做什么。什么是我们负责的&＃xff0c;什么不是我们应该负责和提供的。 

另 外在需求变更管理中&＃xff0c;和客户有效的沟通、协调和教育非常重要。说的好点&＃xff0c;就是“要讲究沟通的艺术”&＃xff0c;“多引导客户”&＃xff1b;说得俗点&＃xff0c;就是“摆平客户”。如果能 够对客户进行很好的客户教育&＃xff0c;很多时候客户是可以理解开发过程中的困难&＃xff0c;从而达到妥协或折中。比如客户理解了项目后期进度紧张&＃xff0c;技术架构难以大改&＃xff0c;就会在 资源、进度、功能上做一些折中的选择&＃xff0c;比如把功能分主要功能先实现&＃xff0c;次要功能后实现&＃xff1b;核心业务保稳定&＃xff0c;次要业务不能牺牲核心业务的稳定性等等。反之&＃xff0c;如果 没有和客户有效的沟通、协调和教育&＃xff0c;则会双方各执一词&＃xff0c;搞业务的只讲业务、流程和功能&＃xff0c;不考虑技术可行性&＃xff0c;不考虑资源和时间表&＃xff1b;搞技术的只讲技术&＃xff0c;没有倾 听客户的正当的商业需求&＃xff0c;不能满足客户利益的最大化&＃xff0c;这样双方就很难达成双赢的结果。所以&＃xff0c;有效的沟通是软件项目成功的关键。