UML软件工程组织

软件开发工程的冤枉路
2006.04.12
   客户基本不理解本身的需求,又如何能够告诉我们所期待的“需求”呢?又如何会认同技术人员收集到的“需求”及确认所谓“需求说明书”呢?

   软件开发的冤枉路

  大部分软件开发从业人员常诉说“很难把握客户的需求”。笔者认为这句话不应该从一个专业人员口中说出来,你听过一个装修工人告诉你他不能把握客户的装修需求吗?但这却是事实。如何能够“把握客户的需求”便成为软件工程中急需解决的问题。

  很多专家发表很多关于“应该如何才能够把握客户的需求”,“需要采用哪些手段”等理论。但笔者以过去三十多年科技企业软件开发的经验告诉大家,基本不用去“把握”客户的“需求”。

  软件开发的冤枉路,带来目前IT项目管理的另一段冤枉路,我们是继续朝这条冤枉路走下去,还是找寻软件工程的正确路线?希望各从业人员自己判断,并做出适当结论。

  国内对需求的解释

  笔者从1972年开始从事软件开发,1979年开始成为开发小组主管,1984年正式成为项目经理,到今天已经积累了三十多年的开发及二十多年的管理经验。笔者最近这两年在国内从事教育及咨询的工作中,发觉国内软件从业人员所谈的“需求”和过去在国外执行软件开发时所谈的“需求”有很大的差异。

  在国外建设系统的时候,“需求”是技术人员建立的,不是从客户提出的。但国内的软件从业人员所谈的“需求”是在“调研”过程中由客户提出的。坦白说,客户基本不理解本身的需求,又如何能够告诉我们所期待的“需求”呢?又如何会认同技术人员收集到的“需求”及确认所谓“需求说明书”呢?

  试想想,当我们要研制一件产品的时候,我们会问消费者他们对产品的需求吗?也许我们会咨询他们的意见,但生产商会综合消费者的意见,厂商本身对市场的理解,和最终客户群的采购“目的”来制定产品功能需求,最后成为产品的规格,才投入生产,推广到市场中。这个道理很简单,但我国软件从业人员却认为软件工程与产品开发是不一样的,不能用同一方法处理,一直在走冤枉路。

  我们的做法是,从项目开始进行“调研”(另一个软件工业的重大误区),对客户的基层人员进行访谈,希望能够在调研期间让客户说出本身的需求,从而把握客户的需求,编写所谓调研报告或需求说明书。

  其实,所谓调研是进行调查,继而进行研究,这是两个工作,但我们常把它变成一个工作来进行。国内对“gather requirements”(收集需求)的理解是从客户的访谈、调查、研究过程中发掘客户的需求,由于客户对需求不明确,技术人员未能把握需求,所以一调研便花费很长时间。

  国外对需求的诠译

  国外软件行业基本没有所谓“调研”的概念。我们在项目的起始阶段只有“fact finding”(或FF,即“找寻事实”)。顾名思义,FF的目的是理解客户如何执行工作,技术人员对客户进行访谈,目的并不是把握客户的需求,而是理解客户目前如何执行自身的工作。访谈报告只包括目前工作如何在部门中实施,是现状的描述,所以往往能够得到客户的认同及确认。

  他们在访谈结束后,开始对现状进行分析,考虑整个工作流程是否合理,如何才能够达到项目的目标,从如何达到项目的目标来决定项目的需求。

  国内外的差异

  我们必须认识到一点, 软件开发的目的是为企业提升生产率(Productivity improvement),提升工作效率(efficiency improvement)及建立商业效益(business benefits),而不是为了满足某一些需求。

  如果项目的目的是为了满足某一些需求来解决一些运营上的问题,那么这些便是系统维护项目,不是系统开发项目。而且这些项目的需求通常比较明确,客户清楚地知道需要增加哪些功能,可以直接告诉技术人员有关功能的需求。在现有系统中附加该功能,便能够完成项目。而且这方面的需求可以得到各阶层人员的认同。

  软件开发是为了提供一套完整工具(软件加硬件)来完成一个部门或一家企业的“运营目标”,如何可以利用科技来使企业的运营更理想,是软件开发的主要原因。所以当我们完成分析后,明确地理解需要哪些功能才能够让企业或部门更有效地达到目标,这些功能才是系统的真正需求。我们所说的“收集需求(gather requirements),”基本上是包括找寻事实(Fact Findings)和分析(Analysis)两个阶段的结果,不是国内所执行的“调研”一个工作希望直接带出来的结果。

  整体解决方案

  当完成分析后,有了全面的功能需求,接下来便需要让客户认识到,他们的最终目的需要哪些功能和如何可以利用科技(软件及硬件)的结合来完成,这便是我们所说的解决方案。这时候还没有对系统进行设计,只是让客户认识他们所希望的目标需要哪些系统功能来完成。我们的目的是让客户认同,只要我们的系统可以提供这些功能,便能够达到他们的最终目的,这便是确认需求的目的。同时在确认这些需求的时候,把项目的范围牢牢的建立起来。

  客户的确认

  到这里,相信大家都知道为什么我们在国外可以让客户确认需求,而国内的技术人员却未能让客户确认需求了。很多同业往往感觉困惑,为什么访谈结果可以让被访者接受,但每当要求对方主管确认的时候又被打回头票?

  国内把握需求的方法,一般是希望从访谈的用户口中提供系统的功能需求,这意味着把专业工作交给客户来执行,他们又如何能够完成我们本身做不到的工作呢?纵然访谈的客户可以很明确地认识到本身工作上的需求,同时可以确认你递交的调研报告或需求说明书,但这只属于他本人工作岗位及工作层次上的需求。而部门主管及企业领导的需求是比较全面,肯定与相关工作人员所提出的需求有所不同,这份调研报告又如何能够让用户主管或客户确认呢。

  未能把握整个解决方案的目标,未能分析整体工作的过程来建立目标的功能,这样提出来的需求只能解决局部的问题,未能做到“解决方案”的目标。其实我们只需要确认业主的项目投资最终目标,从结果分析来建立所需的功能,便能够有效地让客户认同这些主要功能,认同项目的需求。

  开发的另一误区

  我常看到一些开发人员把过去一些案例让客户观看,希望客户从中理解自身的需求,然后在项目建设的过程中慢慢把需求建立起来。但这种方法往往让我们无法把握项目的真正范围,让范围不断蔓延,导致项目不断延误,未能有效的完成交付。

  每一个客户有本身的思想,有独特的需求,有企业的特色,观看别人的案例只让客户增加对结果的期盼,不能完全确定项目需求的最终目的。尤其是近年来的项目多是概念性的项目。所谓概念性项目是从商业概念所产生的项目,例如“客户管理系统”来对客户进行管理和提供客户的服务,建立客户满意度等类似的项目,又或者是客户需要建立一个“市场管理系统”来对企业产品销售进行有效的分析及开拓市场方向等项目。这些项目便是我们现在所说的“信息化”项目的建设。

  技术人员不能把握这些概念性项目的需求,也成为目前国内信息化过程的延误和信息化结果的最大障碍。九零年代中期,国际企业开始进行信息化,在无数惨痛教训后理解到技术人员本身的局限—对商业运营的最终目标认识不清,所以特意在软件开发项目中建立一个新岗位—商业分析师(Business Analyst)。

  商业分析师可以是资深的系统分析师,但必须曾经在工作的过程中对某一个行业的运营相当了解,这包括在某个行业中曾经负责开发多种不同的项目,对企业的运营需求和运营方向全面理解。

  商业分析师也可能是一个部门的业务经理,经过培训后理解如何进行分析,如何建立商业模式等方法,这样才负责项目初期的信息收集,分析及设计工作。

  设立商业分析师这一岗位,从客户建立系统的最终目的中建立商业模式(Business Model),再从商业模式中建立主要的工作模块(Process Modules),从工作模块中建立运营流程(Business procedures),再从运营流程中建立项目需求,这时候才转交技术人员建立项目功能规格。

  我国要改善软件工程的困境,必须理解本身的问题,才能够提升我国软件工业的发展潜力。高校的老师及导师必须理解我国软件工业过去所走的冤枉路,才能够培育更优秀的技术人员和软件工程管理人员。

  软件服务商的领导必须认识企业的缺点,盲目去进行各种认证只能治标,不能全面解决本身的服务缺憾。企业需要建立本身的体系及制度,建立企业的开发文化,更需要全力提升管理人员,对软件工程的开发进行有效管理。而各应用单位的领导更需要认识本身必须投入项目的开发过程,才能够有效的让项目投资带来回报。

  未能把握整个解决方案的目标,未能分析整体工作的过程来建立目标的功能,这样提出来的需求只能解决局部的问题,未能做到“解决方案”的目标。


版权所有:UML软件工程组织