如何把握不存在的需求

  作者:黄绍良
2009/7/2 11:32:49
客户对项目的验收是依据项目完成后的最终交付物,我们必须摆脱传统的思维,不要在项目起动时尝试把握基本上不存在的需求。

本文关键字: 项目管理 需求

任何从事IT行业的人员都清楚,软件开发项目失败的其中一个主要原因是项目在启动的时候功能需求模糊,导致开发过程的不断修改,让项目不断延误,功能不断扩张,资源越来越吃紧,最终影响交付的质量和客户的满意度。网上有很多文章介绍如何去把握需求,很多业内人士也常在网上分享他们把握客户需求的方法,可惜效果并不太理想。因为我们绝对不能够把握基本上不存在的“客户需求”。

作为一个软件工程的专业人员,如何能够从客户所提供的模糊需求建立一个明确的范围,然后从这个范围中建立整个系统的功能需求,让我们可以控制软件开发的过程,减少项目的范围变动,降低开发过程中的修改需求,让我们能够按预算、按工期,提交符合质量要求的交付物,达到客户的预期目标,我们便需要理解问题的根源,打破过去的工作习惯,寻找一套可行的方法。

项目管理知识体系(PMBOK)中我们学习范围变动管理,而不是需求变动管理,范围变动才是需求变动的主要原因。其实在这里PMBOK做了一个假设,就是有了明确的范围便可以建立明确的功能需求,如果能够控制范围,便能够控制功能需求。

功能需求变动是导致软件工程在开发过程中进行修改的主要原因,那是说我们在软件工程项目启动的时候没有把握好项目的范围,才会发生我们面对的问题。所以,我们首先需要理解范围与功能需求的关系,什么是范围?什么原因导致需求模糊?能够明确理解两者的异同,才能够找出解决的方法,建立明确的项目范围,转换成功能需求。让我们能够从模糊的需求转变成为明确的需求。 项目管理培训

建立明确的项目范围代替不明确的范围,才能够减少开发过程中的修改。本人最近一直从过去30多年的科技项目开发和管理经验中,结合近年回国后对国内IT企业运营模式的理解,我国技术人员的工作习惯,客户的思维、心态和期盼,总结出一套建立明确项目范围的方法,特在此与读者分享,共同改善我国软件企业的困境。

70年代的项目范围与需求

项目范围与项目需求是两个完全不同的概念,但两者却不能单独处理。让我们回到上世纪70年代的时候,国外企业正进行自动化的过程。项目基本上是把人工作业流程转变成计算机程序。那时候并没有项目范围这个名称,我们用Terms of Reference (ToR)来界定项目的边界,采用文字描述的方法说明这个项目要做什么。例如,要为希赛公司建立一个库存管理系统,这个项目的ToR会说明货品从进入仓库开始,到货品因应生产或销售申领要求离开仓库为止,其中包括货品存入量的统计,存放位置记录,总库存量统计、申领数目、检货、提取货品、准备出仓,最后更新货品存量统计等工作过程。这个项目的Term of Reference只说明这个项目的范围,包括一些需要执行的工作和记录等。

在项目实施过程中,系统分析员会对库存管理全过程进行调查或调研,采用访谈或观察等方法,记录上述范围中的整个工序的过程,每一个数据的更新,参考记录数据的报告格式和任何有关的工作单据。这些工序,数据更新时间和地点,报告打印等工作最后便成为系统的功能需求。这些需求能够让最终用户明确开发人员已经把握了整个工作流程,明确每一个工作的内容,保证完成的系统能够提供库存管理的功能。
 

这段时间软件工程的焦点是在范围确认后的信息搜集(Facts Finding)和需求分析(Requirement Analysis)中。依据PMBOK的论述,我们在20世纪70年代,的确可以从范围的建立带出明确的功能需求,减少开发过程中的修改,降低项目延误的风险。这个模式在我国软件产业发展初期采用,大概是20世纪80年代后期至90年代中期的时间进行自动化过程。

80年代的项目范围与需求

到上世纪80年代中后期,国外企业的自动化过程已经接近尾声,企业开始整合部门的计算机系统,加上个人电脑开始取代终端,项目多数包括跨部门或跨地区的系统集成、综合数据库应用、远程计算(Remote Access)、网络连接等为项目主体。在这种情况下,传统的ToR已经不能够明确说明项目属于哪个部门,从哪里开始,如何才是项目完结。ToR已经不能够有效地界定项目的范围,所以,我们利用多个工作描述来说明,成为我们知道的工作说明“Statement of Works (SOW)”,其中包括项目开发过程中需要处理(inclusive)的工作说明和开发过程中不需要(NOT-inclusive)处理的工作说明,整合这些SOWs 后成为我们今天所认识的项目范围,利用工作说明以明确的语句来说明项目中包含的每一个工作内容。例如,在一个项目范围中包括的工作说明可能是:“连接A市及B市两地办公室的主机,通过A市数据中心的中央货品库存数据库,为A市工场和B市销售中心提供即时货品存量查询及货品预订功能”。

这些工作说明便成为这个工程需要提交的最终成果。利用项目范围中的SOW替代ToR,一个项目可以容许多个SOW来描述系统建设的内容,所有的SOW描述的建设内容都包含在这个项目的范围中。但实际上每一个SOW的结果如何实现,还是需要技术人员透过调查和进行分析后才能够清楚具体的操作该如何实现。每一个SOW的具体操作过程都成为这个SOW的功能需求。整合全部SOW的个别操作过程,才是项目的最终功能需求。

简明的说,每一个SOW都是一个小范围,它本身也不是一个需求。我们还是需要通过理解SOW的内容才能够把握这个SOW的需求。每一个SOW可以成为一个独立的项目,“子项目”的名称也是在这个时候诞生。

从上述的历程中可以看到,用户或客户告诉我们的永远都不是需求,是客户或用户希望在最后交付物中看到的部分成果,永远不会完整,只是客户或用户的部分期盼、愿景和目标。如果把这些期盼、愿景和目标当作了需求,那么我们永远不能在项目初期建立满足用户对交付物的期盼。需求从来不是用户或客户提供,需求是技术人员依据范围中需要实施的工作过程进行分析后寻找出来可以提交项目最终交付物的结果,然后才能够把这些需求转变成一个软件工程,在项目指定的范围中利用科技达到用户的最终目的。

共3页: 上一页1 [2] [3]
责编:穆琳琳
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

发表评论

         看不清,换一个

(已有5条评论)
16F2009/9/6 23:09:10匿名用户 说:

我也遇到过.我应该提出需求,希望提出的需求是全面的,不可变更的,但事实证明,提出的需求往往不及后期的渴望.给软件开发及编程人员带来了麻烦,还延误了原本的计划.

11我顶
15F2009/7/16 13:05:14匿名用户 说:

不错,只是谈得不够生动,有学教性质

16我顶
14F2009/7/15 10:00:03风轻云淡 说:

客户提出的业务需求是有局限的,本身就是模糊的。不要指望客户给软件公司提清楚,指望客户对自己提出的需求签字画押,不准变化,都是不现实的。重要的是项目系统分析员要去把握用户需求,确切为用户着想,最最关键的是要把客户的业务需求转换为软件需求,并充分考虑扩展性、可靠性等质量属性。这方面没有什么秘诀,靠个人的能力培养。很大程度上是:“想象力比知识更重要!”

14我顶
13F2009/7/12 11:41:37卧龙小生 说:

同意csai.wonder关于好的系统应由业务专家和软件设计专家一起搞出来的观点。但现时是很多项目缺少业务专家这样的角色,客户没有,集成商也缺乏。我见过N多的所谓业务咨询专家本身对业务都没有搞懂,拿了些所谓方法论的东西就来忽悠客户。真正的咨询师不仅仅需要咨询方法论,还要有客户行业的专业知识,以及对行业进程的时时关注,了解行业动态才能更好地把握发展趋势。其二,咨询师应具备在繁杂的客户业务中,进行业务梳理和分析诊断,并提出业务咨询建议的能力,这才是客户所需的。可惜现在的软件行业非常稀缺这样的人才。所以,我个人认为脱离现状谈理论、谈方法是没有意义地,而说到问题,谁又没有看到这些问题呢。然而,解决之道在哪里?这才是大家所关心的。行业需要观念的转变、行业需要理论和方法,落实到项目需要具备这些能力的人。有了这些再来谈如何,如何吧。如果说道如何把控需求,中国的现状就是7分关系,3分管理。虽然无奈,但这就是现实。
个人观点。

11我顶
12F2009/7/11 8:31:29匿名用户 说:

是云里雾里!

17我顶

声明:在本网的文章页面上进行跟帖或发表言论者,均为网友言论,不代表畅享网观点。

著作权声明:畅享网文章著作权分属畅享网、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918