项目管理：如何把握不存在的需求

任何从事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可以成为一个独立的项目，“子项目”的名称也是在这个时候诞生。

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



系统集成项目在PMBOK论述的范围管理仍然有效，但在软件工程中能否包含全部SOW是影响范围变动的主要因素，遗漏了一个SOW便会带来范围变动，所以当时的软件工程多以SOW为主，需要客户方确认，只要客户确认SOW后，任何不包括在SOW中的功能便成为范围变动，也是PMBOK中范围变动管理的主要意义。改变范围便需要改变项目基线，增加工作量和项目成本，延长项目工期。我国的软件产业发展从2O世纪90年代中期到本世纪初期才开始进行系统集成的过程。
自动化到信息化的年代

IT在上世纪70、80年代的项目是流程自动化与系统集成年代，基本上是先确认范围后才开始把握功能需求，大部份项目所采用的开发体系也是依据这个构思对软件开发进行管理。但到了90年代进入信息化年代，范围的意识开始模糊，范围开始被误解成为需求，最主要的原因是技术人员仍然采用过去流程自动化的开发思维，希望客户能够明确说明范围，但在范围建立的过程中，每当客户提出“我需要这个系统能够提供 …… ”，技术人员便把客户的说明演绎成为系统需求。

故此从90年代中期开始到现在，很多软件工程师对需求的定义非常模糊，系统需求与功能需求把握不准，把范围建设的过程与功能需求混在一起，导致今天大部份软件在开发过程中不断修改，让项目不断延误。

90年代的项目范围与需求

自上世纪90年代中期开始，企业从流程自动化的“科技应用方法”开始转型到信息化的“科技应用价值”为最终目标。项目的目标也渐渐地从明确的技术应用过程转变成为如何利用科技来完成虚拟的理想及模糊的愿景。例如，建立一个系统为企业提供业务方向决策，让管理层能够判断产品在市场上哪个地域的市场需要和进行产品调整或改善，属于哪类消费群，如何开拓一个新市场等，又或者希望利用因特网为企业提供一个产品推广和销售渠道。