客户验收心态让今天的软件从业人员对项目交付的过程带来很大的影响。从软件开发初期的自动化历程，到目前企业进行信息化的终极目标，项目赞助人对自己投资一套软件所希望达到的最终目的非常清晰，不管是为了提升工作效率，还是为了强化企业的能力，往往在项目开始的时候项目赞助人已经有一个明确的思维和方向，问题变成了软件开发的专家如何能够提交项目的交付，满足项目资助人的期盼。

　　这种转变让项目成功的衡量因素也发生了实质上的变化。项目经理被衡量的准则已经不单单是以能否在预算内如期完成交付来衡量这个项目成功与否，而是看他能为项目赞助人和项目关系人提供多少效益和能力。很多时候我们认为项目已经完成，但客户还是不满意，认为未能达到预期的成果，原因就在于项目的交付只能做到科技的应用，但没有带来任何价值可以提升客户的应用效益和能力，所以客户一直认为未能完成验收的确认。

　　惊人的数据

　　从2005年中期开始，在一项对软件开发困境的研究过程中，特别要求23位项目经理提供一些有关返工的简单数据，比如他们在项目开发的过程中记录下的各阶段工作需要返工的次数。不管是客户提出要求或技术人员因开发内容需要主动进行返工，目的都是希望能够把握“变动”在软件开发过程中发生的那些阶段，然后研究该选择哪些开发模式来改变软件开发的法。

　　这批项目分别在6个月内起动，目标是4~12个月完成项目的移交，挑选的项目均可以把开发过程分类成“信息调研”，“需求分析”，“系统设计”，“系统开发”，“用户测试”和“项目移交”等6个阶段。

　　32个月后，有18个项目提供了比较完整的数据，可以进行参考和研究，其中有3个项目在深圳，5个项目在上海，4个项目在武汉，6个项目在北京。而只有1个项目能够顺利依时移交，13个项目需经过不断修改后完成移交，余下4个项目仍处于暂停状态，继续与客户协商中。

　　各阶段中的数据分别可以归类出6种返工内容，分别是逻辑及流程修改，用户界面修改，数据结构或数据组织修改，改变所用的程序语言，系统反应速度和表现未附理想，新增功能或需求的修改，和其他不属于上述类别的修改。以下是18个项目所收集的数据：

　　数据代表的涵义说明

　　上述数据从2005年11月开始收集，分别与23个项目的负责人在数据收集完成后进行访谈，理解数据的准确性和返工背后的原因，最后对5个项目收集的数据因未能确认其准确性，故只采用18个项目中收集到的数据，到去年10月才能够进行汇总、整理和分析。

　　数据说明大部份的返工分别来自开发阶段，共185次，相当于每个项目平均需要10次以上的返工;在用户测试阶段，共103次，相当于每个项目平均需要6次以上的返工;信息调研阶段，共60次，相当于每个项目平均需要3次以上的返工;移交阶段共41次，相当于每个项目需要2次以上的返工。至于需求分析和系统设计两个阶段的返工次数较少，主要原因是客户基本上不重视这两个阶段的成果，他们要看的是编程(开发)的结果，测试的结果和移交(应用)的结果。

　　信息调研阶段

　　这个阶段是针对调研报告提交后，应客户要求对内容调整和修改的次数统计。平均达到3次以上的返工，主要是对逻辑和操作流程的理解，占80%以上，其他20%的修改包括内容不全、需要补充或扩大调研的范围。

　　在这个过程中，项目经理及高级系统分析员主要是跟客户代表进行访谈，透过访谈的内容建立功能需求说明。调研报告的内容主要是说明软件的主要功能需求，但没有任何一个项目以任何形式加上明确的范围说明。客户阅读后会提出修改的反馈，明确说明在调研报告中需要加上哪些功能。经过三次修改后，18个项目的调研报告都没有被客户以任何方式进行确认，提交后项目经理也没有要求客户确认后交回项目组。技术人员便开始进行下阶段的工作。

　　需求分析阶段

　　这一个阶段的修改次数平均只有1.44次，主要原因是大部份项目经理把信息调研阶段中的一些新增功能或需求说明在上阶段中记录并处理。项目经理及系统分析员对信息调研和需求分析的工作内容相当模糊，未能准确分辨两个阶段工作的实际差异。

　　对项目经理及负责进行调研的技术人员来说，不明确需求分析的工作内容主要是透过调研阶段希望客户能够提供系统所需的功能需求，所以没有任何需求分析的工作需要处理，而进行的分析工作只局限于技术如何能够做到，换句话说，在需求分析的过程中，他们的重点是如何利用技术来达到目的，这基本上是属于下一个阶段系统设计的实际工作。

　　系统设计阶段

　　从需求分析到系统设计，常常缺乏一个明确的交接点。像信息调研和需求分析两个阶段的交接一样，缺乏任何明确的阶段交付说明。大部份项目经理也没有对技术人员说明个别阶段的交付物，并监控有关内容，除调研报告外，18个项目都没有提供任何分析说明(Requirement Statements)或系统设计书。

　　在设计阶段过程中，技术人员多开始就客户提供的功能及需求进行编程，首先是编写一两个主要屏幕的影像，进而编写有关逻辑。既然缺乏任何设计说明，那么任何修改的要求自然被编列在开发过程中，故此这个阶段与上阶段一样，修改的次数较少，18个项目只有25次返工，平均为1.389次。

　　系统开发阶段

　　在18个项目中，共记录185次返工要求，平均每个项目达到差不多10次以上的返工或修改，是所有阶段返工率最高的一个环节。而且这些返工的要求往往是口头上的要求，通常发生在每周面向客户汇报进度及成果后，客户审视技术人员的工作成果(多以演示方式进行)后要求对有关程序进行调整或修改。记录的次数只涵盖整体返工的要求，包括移交完成的交付进程中的任何程序的逻辑及界面，并没有分辨记录每一个模块或功能的确切返工次数。有关项目经理也承认实际的返工要求如果针对个别模块或界面进行记录，次数可能达到记录的7倍或更高。

　　大部份返工以界面修改为主，平均每个项目达到4次，共计72次数。第二是新增功能的修改，多基于前期的调研、分析及设计等没有被包括在内的一些额外需求，平均达到2.39次共43次。接下来是逻辑或流程的返工，有37次平均超过2次工。数据的组织及处理方面，平均超过1.33次以上工的达到24次数。往往逻辑及数据组织的返工原因源自功能及界面的返工所影响。

　　用户测试阶段

　　这是开发过程中仅次于系统开发阶段的第二高返工次数，达到103次，平均每个项目有差不多6次的返工要求。返工的内容多以界面修改为主，平均每个项目被要求界面返工的次数达到2.33次，共计43次。接下来是数据结构及组织的修改，平均次数达到1.78次的共32次，占第三位的是新增功能所导致的返工，平均每一个项目有一次的要求工达18次。

　　项目移交阶段

　　比较突出的只有数据结构及组织的返工，平均每一个项目便需要进行1.56次修改的共达到28次数。主要原因来自最终用户对界面中的数据来源不认同，需要来自其他数据库的内容而进行的修改。

　　次数记录分析

　　这次调查的结果相当有意义，从收集到的数据可以很清楚地理解目前软件工业所面对的困境，并希望从中找出一个方向，改善软件工业的未来发展空间。

　　从收集数据后对项目经理进行的访谈中发行，基本上在整个开发过程中没有任何监控及评估。每一个工作的内容互相重叠，尤其是“信息调研”，“需求分析”和“系统设计”这三个阶段，大部分技术人员对每一个阶段的工作目标都不太明确，对于需求的来源更完全依赖客户提供。接下来的“系统设计”和“系统开发”这两个阶段也是互相重叠，一面设计，一面开发。到程序编写完成(同时技术人员完成初步模块测试)后进行用户测试时才发现实际的工作范围远远超过预期的估计，导致大力的返工及修改。正式移交的时候也需要因应用户的应用环境和地理分布对项目进行调整。在整个开发过程中，收集的数据基本上体现了“三边”(边想，边做，边改)的软件开发模式应用。

　　软件开发模型又称软件生命周期模型，它制定了一系列的步骤或活动，软件开发人员或开发团队需要在开发中按照软件模型中指定的步骤来进行软件开发。实际上，很少有某个开发团队完全遵循开发模型的规定，这是因为每个模型都会有一定的限定条件和应用范围，并不是完全适应所有的开发环境。