ts)，而不是为了满足某一些需求。
如果项目的目的是为了满足某一些需求来解决一些运营上的问题，那么这些便是系统维护项目，不是系统开发项目。而且这些项目的需求通常比较明确，客户清楚地知道需要增加哪些功能，可以直接告诉技术人员有关功能的需求。在现有系统中附加该功能，便能够完成项目。而且这方面的需求可以得到各阶层人员的认同。
软件开发是为了提供一套完整工具(软件加硬件)来完成一个部门或一家企业的“运营目标”，如何可以利用科技来使企业的运营更理想，是软件开发的主要原因。所以当我们完成分析后，明确地理解需要哪些功能才能够让企业或部门更有效地达到目标，这些功能才是系统的真正需求。我们所说的“收集需求(gather requirements)，”基本上是包括找寻事实(Fact Findings)和分析(Analysis)两个阶段的结果，不是国内所执行的“调研”一个工作希望直接带出来的结果。
整体解决方案
当完成分析后，有了全面的功能需求，接下来便需要让客户认识到，他们的最终目的需要哪些功能和如何可以利用科技(软件及硬件)的结合来完成，这便是我们所说的解决方案。这时候还没有对系统进行设计，只是让客户认识他们所希望的目标需要哪些系统功能来完成。我们的目的是让客户认同，只要我们的系统可以提供这些功能，便能够达到他们的最终目的，这便是确认需求的目的。同时在确认这些需求的时候，把项目的范围牢牢的建立起来。
客户的确认
到这里，相信大家都知道为什么我们在国外可以让客户确认需求，而国内的技术人员却未能让客户确认需求了。很多同业往往感觉困惑，为什么访谈结果可以让被访者接受，但每当要求对方主管确认的时候又被打回头票?
国内把握需求的方法，一般是希望从访谈的用户口中提供系统的功能需求，这意味着把专业工作交给客户来执行，他们又如何能够完成我们本身做不到的工作呢?纵然访谈的客户可以很明确地认识到本身工作上的需求，同时可以确认你递交的调研报告或需求说明书，但这只属于他本人工作岗位及工作层次上的需求。而部门主管及企业领导的需求是比较全面，肯定与相关工作人员所提出的需求有所不同，这份调研报告又如何能够让用户主管或客户确认呢。
未能把握整个解决方案的目标，未能分析整体工作的过程来建立目标的功能，这样提出来的需求只能解决局部的问题，未能做到“解决方案”的目标。其实我们只需要确认业主的项目投资最终目标，从结果分析来建立所需的功能，便能够有效地让客户认同这些主要功能，认同项目的需求。
开发的另一误区
我常看到一些开发人员把过去一些案例让客户观看，希望客户从中理解自身的需求，然后在项目建设的过程中慢慢把需求建立起来。但这种方法往往让我们无法把握项目的真正范围，让范围不断蔓延，导致项目不断延误，未能有效的完成交付。
每一个客户有本身的思想，有独特的需求，有企业的特色，观看别人的案例只让客户增加对结果的期盼，不能完全确定项目需求的最终目的。尤其是近年来的项目多是概念性的项目。所谓概念性项目是从商业概念所产生的项目，例如“客户管理系统”来对客户进行管理和提供客户的服务，建立客户满意度等类似的项目，又或者是客户需要建立一个“市场管理系统”来对企业产品销售进行有效的分析及开拓市场方向等项目。这些项目便是我们现在所说的“信息化”项目的建设。
技术人员不能把握这些概念性项目的需求，也成为目前国内信息化过程的延误和信息化结果的最大障碍。九零年代中期，国际企业开始进行信息化，在无数惨痛教训后理解到技术人员本身的局限—对商业运营的最终目标认识不清，所以特意在软件开发项目中建立
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
