|
客户基本不理解本身的需求，又如何能够告诉我们所期待的“需求”呢？又如何会认同技术人员收集到的“需求”及确认所谓“需求说明书”呢？ 软件开发的冤枉路 大部分软
件开发从业人员常诉说“很难把握客户的需求”。笔者认为这句话不应该从一个专业人员口中说出来，你听过一个装修工人告诉你他不能把握客户的装修需求吗？但这却是事实。如何能够“把握客户的需求”便成为软件工程中急需解决的问题。 很多专家发表很多关于“应该如何才能够把握客户的需求”，“需要采用哪些手段”等理论。但笔者以过去三十多年科技企业软件开发的经验告诉大家，基本不用去“把握”客户的“需求”。 软件开发的冤枉路，带来目前IT项目管理的另一段冤枉路，我们是继续朝这条冤枉路走下去，还是找寻软件工程的正确路线？希望各从业人员自己判断，并做出适当结论。 国内对需求的解释 笔者从1972年开始从事软件开发，1979年开始成为开发小组主管，1984年正式成为项目经理，到今天已经积累了三十多年的开发及二十多年的管理经验。笔者最近这两年在国内从事教育及咨询的工作中，发觉国内软件从业人员所谈的“需求”和过去在国外执行软件开发时所谈的“需求”有很大的差异。 在国外建设系统的时候，“需求”是技术人员建立的，不是从客户提出的。但国内的软件从业人员所谈的“需求”是在“调研”过程中由客户提出的。坦白说，客户基本不理解本身的需求，又如何能够告诉我们所期待的“需求”呢？又如何会认同技术人员收集到的“需求”及确认所谓“需求说明书”呢？ 试想想，当我们要研制一件产品的时候，我们会问消费者他们对产品的需求吗？也许我们会咨询他们的意见，但生产商会综合消费者的意见，厂商本身对市场的理解，和最终客户群的采购“目的”来制定产品功能需求，最后成为产品的规格，才投入生产，推广到市场中。这个道理很简单，但我国软件从业人员却认为软件工程与产品开发是不一样的，不能用同一方法处理，一直在走冤枉路。 我们的做法是，从项目开始进行“调研”（另一个软件工业的重大误区），对客户的基层人员进行访谈，希望能够在调研期间让客户说出本身的需求，从而把握客户的需求，编写所谓调研报告或需求说明书。 其实，所谓调研是进行调查，继而进行研究，这是两个工作，但我们常把它变成一个工作来进行。国内对“gather requirements”（收集需求）的理解是从客户的访谈、调查、研究过程中发掘客户的需求，由于客户对需求不明确，技术人员未能把握需求，所以一调研便花费很长时间。 国外对需求的诠译 国外软件行业基本没有所谓“调研”的概念。我们在项目的起始阶段只有“fact finding”（或FF，即“找寻事实”）。顾名思义，FF的目的是理解客户如何执行工作，技术人员对客户进行访谈，目的并不是把握客户的需求，而是理解客户目前如何执行自身的工作。访谈报告只包括目前工作如何在部门中实施，是现状的描述，所以往往能够得到客户的认同及确认。 他们在访谈结束后，开始对现状进行分析，考虑整个工作流程是否合理，如何才能够达到项目的目标，从如何达到项目的目标来决定项目的需求。 国内外的差异 我们必须认识到一点， 软件开发的目的是为企业提升生产率（Productivity improvement），提升工作效率（efficiency improvement）及建立商业效益（business benefits），而不是为了满足某一些需求。 如果项目的目的是为了满足某一些需求来解决一些运营上的问题，那么这些便是系统维护项目，不是系统开发项目。而且这些项目的需求通常比较明确，客户清楚地知道需要增加哪些功能，可以直接告诉技术人员有关功能的需求。在现有系统中附加该功能，便能够完成项目。而且这方面的需求可以得到各阶层人员的认同。 软件开发是为了提供一套完整工具（软件加硬件）来完成一个部门或一家企业的“运营目标”，如何可以利用科技来使企业的运营更理想，是软件开发的主要原因。所以当我们完成分析后，明确地理解需要哪些功能才能够让企业或部门更有效地达到目标，这些功能才是系统的真正需求。我们所说的“收集需求（gather requirements），”基本上是包括找寻事实（Fact Findings)和分析（Analysis）两个阶段的结果，不是国内所执行的“调研”一个工作希望直接带出来的结果。 整体解决方案 当完成分析后，有了全面的功能需求，接下来便需要让客户认识到，他们的最终目的需要哪些功能和如何可以利用科技（软件及硬件）的结合来完成，这便是我们所说的解决方案。这时候还没有对系统进行设计，只是让客户认识他们所希望的目标需要哪些系统功能来完成。我们的目的是让客户认同，只要我们的系统可以提供这些功能，便能够达到他们的最终目的，这便是确认需求的目的。同时在确认这些需求的时候，把项目的范围牢牢的建立起来
|
文章搜索
