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

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

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

　　功能需求变动是导致软件工程在开发过程中进行修改的主要原因，那是说我们在软件工程项目启动的时候没有把握好项目的范围，才会发生我们面对的问题。所以，我们首先需要理解范围与功能需求的关系，什么是范围?什么原因导致需求模糊?能够明确理解两者的异同，才能够找出解决的方法，建立明确的项目范围，转换成功能需求。让我们能够从模糊的需求转变成为明确的需求。
项目经理博客
　　建立明确的项目范围代替不明确的范围，才能够减少开发过程中的修改。本人最近一直从过去30多年的科技项目开发和管理经验中，结合近年回国后对国内IT企业运营模式的理解，我国技术人员的工作习惯，客户的思维、心态和期盼，总结出一套建立明确项目范围的方法，特在此与读者分享，共同改善我国软件企业的困境。

　　70年代的项目范围与需求
项目管理培训
　　项目范围与项目需求是两个完全不同的概念，但两者却不能单独处理。让我们回到上世纪70年代的时候，国外企业正进行自动化的过程。项目基本上是把人工作业流程转变成计算机程序。那时候并没有项目范围这个名称，我们用Terms of Reference (ToR)来界定项目的边界，采用文字描述的方法说明这个项目要做什么。例如，要为希赛公司建立一个库存管理系统，这个项目的ToR会说明货品从进入仓库开始，到货品因应生产或销售申领要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计、申领数目、检货、提取货品、准备出仓，最后更新货品存量统计等工作过程。这个项目的Term of Reference只说明这个项目的范围，包括一些需要执行的工作和记录等。
项目经理圈子
　　在项目实施过程中，系统分析员会对库存管理全过程进行调查或调研，采用访谈或观察等方法，记录上述范围中的整个工序的过程，每一个数据的更新，参考记录数据的报告格式和任何有关的工作单据。这些工序，数据更新时间和地点，报告打印等工作最后便成为系统的功能需求。这些需求能够让最终用户明确开发人员已经把握了整个工作流程，明确每一个工作的内容，保证完成的系统能够提供库存管理的功能。 

 

场上哪个地域的市场需要和进行产品调整或改善，属于哪类消费群，如何开拓一个新市场等，又或者希望利用因特网为企业提供一个产品推广和销售渠道。 管理者联盟

 

　　这些项目可能包含现有市场的地域或推进到新的地域环境，包含一个或多个部门的分工与协调，也可能包含现有数据库的组合、信息分享或需要成立新的数据来提供所需的信息，但大多数需要包含现有系统和建立新系统的集成体。如何实现项目的人工或系统操作流程等等多是客户在项目启动前没有考虑过的内容。在这张情况下，范围的建设依据是一个相当困难去完成的子项目。客户在项目调研过程中能够提供的只能是一部份的愿景和期盼，需要技术人员透过这些信息建立项目的范围，才能够降低后期的变动。

　　大部分技术人员在软件开发过程中对开发体系的应用未能融合信息化项目的特色。盲目依从开发体系的过程，忘记开发体系应用前的一些先决条件：建立项目的范围。所以从90年代开始，项目管理开始扮演重要的角色，在项目章程(Project Charter)中建立范围、预算、资源和投资回报等内容，让技术人员依据项目章程的指导，更能有效地发挥技术应用的能力。

　　如何实现用户的愿景，便需要项目经理、技术人员与用户共同寻找实现的过程，才能够把握有关的需求，才能够利用科技让用户获取期盼的项目最终交付物。很多项目的重点已经不是科技的应用，而是科技应用所带出来的价值。今天的项目主要是支撑业务的发展，辅助市场的开拓，创新的科研成果等最终目标，SOW已经不能够在项目初期进行编制，项目范围也无法在项目前期界定。

　　大部分愿景型的项目中，要提供一个全面的项目范围，我们必须进行信息搜集、分析后组合成业务流、数据流。建设出具体的操作过程，再转换成SOWs后才能够建立项目的范围，然后才能够从范围建立项目的明确的功能需求，这些工作都应该在项目启动前便执行，是项目章程的主要内容，但可惜大部分用户缺乏这个概念，而我国技术人员从不重视、也不理解范围的重要性，只把工作重点放在“调研”过程，希望从调研过程中理解客户的需求。

　　项目在缺乏明确范围的时候要能够把握系统的功能需求相当困难。项目愿景是客户希望最终能够达到的目标，如何达到预期的目标?过程如何操作?将来需要哪些类型的工作人员负责执行?应用过程，处理的方法和模式如何应用?这些问题客户可能从来没有考虑过，更不能够为技术人员提供所谓需求，只希望透过技术人员的专业知识和经验，提供客户能够达到目的的应用系统。 项目经理圈子

　　今天软件工程的挑战

　　要能够有效完成项目的交付，我们便需要在项目前期建立明确的范围，只要我们能够完成范围内的工作，客户便能够进行有效的验收过程。但是我们在软件工程中没有把范围建立起来，我们便需要不断满足客户的思维，来提供客户所希望达到的目的。
　很多IT项目经理在项目启动的时候，把工作重点放在把握“客户需求”上，但执行调研的技术人员却把“客户需求”误解成系统的“功能需求”，希望通过调研的过程去理解系统需要哪些应用功能。回顾20世纪70、80年代的开发过程，客户需求是项目范围，与开发过程中的“需求说明(Requirement Statements)有一定的差异。

　　我国的软件产业有本身的特色，我国的技术人员也有本身的工作习惯，我国的用户对软件要求有个别的期盼和要求，这些都影响软件开发模式的应用，采用欧美的软件开发制度基本上不能够满足我国的软件产业现状，也不一定能够解决我国软件产业的困境。大部分软件项目的失败不是技术应用的失败，是未能把握项目的焦点和项目重心所导致的失败。那么软件项目的焦点和项目重心究竟是什么呢?

　　客户提供的所谓需求，实际上在今天的项目中是未来交付中所必须涵盖的功能，也是交付物的一些基本质量要求。客户对项目的验收是依据我们在项目完成后的最终交付物，我们必须摆脱过去的传统思维，不要在项目起动的时候尝试把握那些基本上不存在的需求，必须明确项目交付的验收目标，在项目启动时能够把有关的最终交付明确下来，便能够降低项目失败的比例。