项目需求变更分析和解决之道(二)

日期: 2012-05-08 作者:卢国辉 来源:TechTarget中国 英文

  三、需求变更控制

  《项目需求变更分析和解决之道》的前半部分已经说过了,在软件开发项目开始之前,就要消除“绝不允许发生需求变更”的思想。在项目进行,一旦发生需求变更,更不要不一味的抱怨,也不要去一味地迎合客户的“新需求”,而是要管理和控制需求变更。

  1、分级管理客户需求

  软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全的正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到了客户的投入收益,所以有的时候项目经理反倒应该为客户着想。

  对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。

  一级需求(或变更)是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成员的所有努力,所以定为“Urgent”。这通常是属于补救性的debug类型,要救火。

  二级需求(或变更)是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续,所以是“Necessary”。一般新模块关键性的基础组件,属于这个级别。

  三级需求是后续重要的需求,如果不被满足会令整体项目工作的价值下降,为了体现项目价值,也是开发人员自已的技术价值的证明,所以定为“Needed”。一般性的重大的有价值的全新模块开发,属于这个级别。项目管理者联盟,项目管理问题。

  以上三个等级是应该实施的,但时间性上可以作优先级的排列。

  四级需求是改良性需求,没有满足这类需求并不影响已有功能的使用,但如果实现了则会更好,定级为“Better”。界面和使用方式的需求,一般在这个档次。

  五级需求是可选性需求,更多的是偶是一种设想,以及一种可能,通常只是客户的的一种个人喜好而已,定级为“Maybe”。

  对于四级需求,如果时间和资源条件都允许的话,不妨做下去。对于五级需求,正如对它的描述一样,做与不做是“Maybe”。
 
  2、全生命周期的需求变更管理

  各种规模和类型的软件项目的生命周期大致可以分为三个阶段,即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段,而是要贯穿在整个项目生命周期的全过程中。

  站在全局角度的需求变更管理,需要采用综合变更控制的方法。

  (1)项目启动阶段的变更预防

  正如前面强调的,对于任何软件项目,需求变更都无可避免,也无从逃避,无论是项目经理还是开发人员只能积极应对,而这个应对应该是从项目启动的需求分析阶段就开始了。

  对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理提出需求变更的几率就越小。如果需求没做好,基准文件里的范围含糊不清,被客户发现还有很大的“新需求空间”,这时候项目组往往要付出许多无谓的牺牲。

  如果需求分析做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候,项目经理一定要据理力争,此时这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。

  (2)项目实施阶段的需求变更

  成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。

  项目经理应该树立一个理念,即“需求变更是必然的、可控的,并且是有益的”。项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。

  控制需求渐变需要注意以下几点:

  需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。所以,在项目的开始,无论是开发方还是出资方都要明确这一条:需求变,软件开发的投人也要变。

  需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。

  小的需求变更也要经过正规的需求管理流程,否则会积少成多。

  在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。

  精确的需求与范围定义并不会阻止需求的变更。

  并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的,并非需求写细了,它就不会变化了。

  注意沟通的技巧

  项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。

  (3)、项目收尾阶段的总结

  能力的提高往往不是从成功的经验中来,而是从失败的教训中得来。许多项目经理不注重经验教训总结和积累,即使在项目运作过程中碰得头破血流,也只是抱怨运气、环境和团队配合不好,很少系统地分析总结,或者不知道如何分析总结,以至于同样的问题反复出现。

  事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结,也包括项目中发生的变更和项目中发生问题的分析统计的总结。

  3、需求变更管理原则

  虽然需求变更的内容和类型有各种各样,但需求变更管理的原则却是万变不离其宗。实施需求变更管理需要遵循如下原则:

  (1)建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

  (2)制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。

  (3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。

  (4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。

  (5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。

作者:

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐

  • 信息化项目实施过程中如何做数据规划

    因为基础数据问题而导致的系统实施困境依然常常发生,如何合理科学的开展数据的准备工作?如何有效的进行数据整理?什么才是数据整理的有效方法?

  • BI并不适合所有的企业

    根据笔者这么几年的项目经验,可以负责任的告诉大家,并不是所有的企业都适合采用BI系统。那么到底什么样的企业该使用BI系统呢?

  • IT项目管理,技术重要还是管理重要?

    在中国,“技优则管”是一个普遍现象,很多人员都是毕业后先做技术在漫漫的提拔升为管理层面。但是这种情况在最近发生了变化……

  • 项目经理在企业中的职责和作用

    在现代企业激烈竞争中,企业拥有优秀项目经理的多少和相应技术、管理水平的高低,将直接决定项目管理质量的优劣、项目管理的成败及在同行业的声望和客户信心。