开始是需求不明确,客户都不知道要做成什么样,只有一个大概的粗略的描述。等到大楼盖好了,给客户,却发现大楼应该是这样那样的。。。客户方和开发方在一起( WorkShop) 还好,如果分开在两地就更糟糕。。。
永远不变的就是变化,这个大家都知道,但关键是如何合理的控制需求变更?
我以前做的上百人一年多一个的大项目,完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线,以后需求变更的时候有需求变更委员会(CCB)或专门负责的角色(通常由客户方需求人员来收集和评估最初需求并提交给QA,QA牵头需求变更流程)来处理需求变更,具体做法是:
1. 先是客户或项目组成员提出的需求申请,填写《变更申请单》并提交给项目经理。
2. 项目经理组织项目相关人员对需求变更进行评估和调研,然后组织 需求变更评审。
3. 如果同意变更则由CCB授权配置管理员检出配置项由项目组成员对相关的文档(用户需求说明书、需求规格说明书)进行修改,修改后评审(同时 填写《变更管理记录表》)通过后由高层经理审批,然后提交用户确认,最后纳入配置库,更新《需求追踪矩阵》,确保需求和工作产品的一致性;
4. 如果不同意变 更,则项目经理、部门经理与客户共同协商,协商后同意变更,则对相关的文档进行修改。协商后依然不统一,则需求变更结束。
5. 所有的需求变更都需要总经理理进 行审批。需求变更的影响:利用《需求跟踪矩阵》对变更影响进行评估;估计对项目参数的影响—规模、工作量、进度影响;超出阀值(整个项目进度的10%- 15%,里程碑30%)的,应提交高层评审/批准。
6. 妥善保存变更产生的相关文档。
现在公司做的项目规范较小,完全按照CMMI的规范来有点多余,所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化,持续重构和改进,迭代开发,频繁交付。在需求变更管理上我们还没有一套完整的合适的流程,具体做法是:
1. 客户提出新需求;
2. 开发人员或项目经理评估后答应了;
3. 继续开发,时间表按照重新评估后的进行;
4. 基本上很少拒绝客户;一方面是为了维护客户关系,另一方面对自己team的开发能力很自信; 结果是上头答应了客户,下头的只能加班加点赶工。
另外还有一些控制需求的做法:
1. 项目前期会首先快速开发一个产品原型(Prototype)给客户,有界面的先用visio画个界面,以验证业务规则、业务流程和大概GUI等。另外,产品原型也有助于进一步挖掘用户的需求。
2. 会粗略的列出大体的需求并签字
3. 频繁交付给客户,短周期的交付可工作的产品,以印证需求与实现是否一致,同时兼做客户教育工作。
问题是如果需求变更无休止,则需求变更几乎就不可控,项目开发也无休止。所以我觉得我们公司在需求管理上还缺乏:
1. 需求基线管理,经过评审的双方确认签字的需求基线。以后如果要超出或修改需求基线,则必须有专门的人员对此提出异议,由CCB审核后方可修改;
2. 专门的需求控制负责人。现在基本上是技术人员或是项目经理收到客户需求变更,然后自己评估下就答应了。缺乏专门的需求控制负责人,因而没有需求评审,没有一套专门的严格可控的需求变更流程。
3. 需求功能点列表的书面确认。现在签的只是非常粗略的大体需求,定性而没有定量,以后扯皮发生的可能性非常大;
4. 适当时候应该拒绝客户的要求。虽然用户有众多的理由,比如他认为改动不大,竞争对手已经拥有该功能,或是新的业务需要,但如果评估后的结果是没有必要,或不合理,或优先级不高,或风险大于必要,则坚定的拒绝。另外一种变通的方法是,根据优先级重要性有条件的答应,比如放在下一次版本之后。
5. 需求Scope的管理,不仅要明确做什么,而且要明确不做什么。什么是我们负责的,什么不是我们应该负责和提供的。
另外在需求变更管理中,和客户有效的沟通、协调和教育非常重要。说的好点,就是“要讲究沟通的艺术”,“多引导客户”;说得俗点,就是“摆平客户”。如果能够对客户进行很好的客户教育,很多时候客户是可以理解开发过程中的困难,从而达到妥协或折中。比如客户理解了项目后期进度紧张,技术架构难以大改,就会在资源、进度、功能上做一些折中的选择,比如把功能分主要功能先实现,次要功能后实现;核心业务保稳定,次要业务不能牺牲核心业务的稳定性等等。反之,如果没有和客户有效的沟通、协调和教育,则会双方各执一词,搞业务的只讲业务、流程和功能,不考虑技术可行性,不考虑资源和时间表;搞技术的只讲技术,没有倾听客户的正当的商业需求,不能满足客户利益的最大化,这样双方就很难达成双赢的结果。所以,有效的沟通是软件项目成功的关键。