在CMM1.1版本中第一个KPA(关键过程域)就是需求管理。虽然在CMM2级的标准文本中对需求管理的论述篇幅最少,但它却是最容易让开发人员和项目经理提出疑问的一个KPA。如何进行有效的需求管理?笔者将需求管理的基本原则与方法总结为以下几点:
-必须与需求工程的其它活动紧密整合 谈需求管理一定不能脱离需求工程。从完整意义上讲,需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理。狭义上,需求管理关心的是需求管理过程的建立,在企业或项目组中需要有一套规范的需求管理过程。而实际上从项目经理的角度上看,可能还有50%甚至更多的精力是用于关注结果的,所以对需求内容的管理与对需求形式的管理是密不可分的。
-需求必须是文档化的、正确的、最新的、可管理的、可理解的 需求必须有文档来记录,该文档必须是正确的,是经过验证的,是在受控的状态下变更的。而很多开发人员往往会问:“简单的系统就不用写需求了吧?”其实简单的系统未必简单,只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。有一次,笔者安排2名开发人员编写一个简单的单据录入模块。由于这两名开发人员以前均做过类似的系统,所以笔者仅给出了数据库的设计,并简单讲了一下模块的需求。然而,当系统交付时,才发现与想象中的系统差距非常大,很多需求在提出者看来是理所当然的,却被开发人员全部忽略了。
-只要需求变化了,需求变更的影响就必须被评估 无论需求变化的程度如何,只要需求变化了就必须进行评估,这是基本的原则。此外,在一个项目组中必须明确定义一个需求管理员,由他负责整个项目的需求管理工作,确保在发生需求变更时,受影响的产品能得到修改并与需求的变更保持一致,受影响的其它组也必须与客户协商一致。
-需求必须分优先级 需求的优先级可能比需求本身更加重要。在每一次产品开发过程中,都会遇到这样一个问题:负责产品需求的领域专家罗列了长长的功能列表,每个功能似乎都是不可或缺的,而当排出进度表后,却发现工期是公司不能接受的,没办法,必须裁剪需求。没有需求就不会有产品,而没有产品就没有利润。如果需求过多,反而可能是陷阱——只有投入,没有产出。一个好的项目需求,必须有需求的优先级,便于进行项目的整体平衡。
-需求一定要分类管理 在做工程项目的时候一定要将需求分出层次,不同层次的需求侧重点是不一样的,描述的方式是不同的,管理的方式也是不同的。比如说,在企业里高层领导提出来的是目标性需求,中层管理人员提出来的是具体的业务流程的需求,而作业人员提出来的是更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚,但这是项目的决策性需求,需要很稳定,不能轻易更改,在确定的时候需要慎之又慎。
|