在乐思软件，为了保证项目开发成功，我们采用面向客户的快速开发方法，以充分准确了解客户的真正业务目标与软件需求，通过系统模型设计文档让用户了解软件的蓝图规划，获取用户的反馈意见，开发过程中与客户保持沟通，让客户了解开发进度，最终开发出客户真正需要的使用满意的软件。

很多例子可以证明，并非所有开发人员想出的解决方案都适合客户（迟早客户都会发现这一点）。

“面向客户”听起来意思有些含糊，使人难以明白它究竟对提高开发速度能够起多大的作用。但不管怎样，那些将客户关系置于首位的软件企业确实解决了开发过程中的许多问题，包括进度缓慢问题。

当你最终明白客户对开发速度的认可是所有问题的关键时，关注客户的需要变得更加重要。如果客户不喜欢产品，他们不会为之付款，而你对此毫无办法。即使开发速度很快，次品终究是次品。管理人员、市场人员及高级主管之所以关注开发速度，是因为他们认为客户对此很关心。如果你能满足客户的需求，其实也就同时满足了上司、老板以及其他任何人的需求。

“客户”一词的所指在不同项目中具有不同的含义。对某些项目来说，客户是指想花200美元购买一个商业封装软件的人。在另外一些项目中，客户是出资定制专用项目的人，负担整个开发过程的所有费用。还有一些项目中，其中的客户是同一企业内部其他部门的人。不考虑项目投资方，将最终用户看作客户具有很大的好处。在不同情况下，可能分别将“顾客”、“市场部门”、“最终用户”或“上司”看作“客户”。在所有项目中，通过改善客户关系提高开发速度是一条普遍适用的原则。

1、客户对于快速开发的重要性

Standish Group所做的一次关于8000多个项目的调查结果显示，项目成功的第一要素是用户的参与（Standish Group 1994）。一些快速开发方面的专家指出，融洽地与最终用户相处是快速开发项目成功的三个要素之一（Millington and Stapleton 1995）。

对项目开发来说，只有两方面最重要，一个是客户，另一个是产品。如果你对客户给予充分的重视，则他们会成为回头客。但如果仅关注产品，产品却是不会自己找上门的。
——Stanley Marcus(of Neiman Marcus)

在Standish Group的调查中发现，造成项目完成时间延迟、成本超出预算、达不到预期功能的前三个因素分别是缺乏与用户沟通、需求说明不完备以及中途变更需求说明。你可以通过使用面向客户的开发方法克服这几方面的问题。类似地，也可以用这种方法解决使项目被取消的大部分问题。

以下是在一个快速开发的项目中需要花费精力经营客户关系的两个理由。

·良好的客户关系能够提高实际的开发速度。如果拥有与客户的合作而非敌对的关系，能够与之进行较好的沟通，实际上就是消灭了一个导致开发低效，产生严重错误的主要来源。

·良好的客户关系能够让客户感觉开发速度较快。许多客户之所以关心开发速度，是因为他们害怕你根本完成不了项目。如果在开发时表现出明显的进度，则会增加客户对开发人员的信任度，其对速度的关注将相应减少，而把注意力转向功能、质量等方面，开发速度仅是许多重要因素之一。

下面详细阐述对客户关系的关注是如何达到上述两方面效果的。

1.1 提高效率

对于一个客户软件项目来说，客户的参与是非常关键的。通常客户并不清楚为支持快速开发需要做些什么，他们很少花时间审阅文档，管理及监控进度，甚至不考虑自己真正的要求是什么。客户往往不会意识到对一个重要文档的审阅如果拖延了一周，则将导致产品的交付时间也推迟一周。最常见的情形是客户中不同的人提出了若干不同的观点，开发人员无法确定在某特定问题上由谁来做决定。所以说，项目早期便关注客户关系将会有助于减少以上这些使效率降低的现象出现。

1.2 减少返工

软件开发中不应出现的代价最大的错误之一便是由于开发出的软件被客户否定而不得不重新开发。在这种情况下，快速开发是不可能做到的。通常客户并不否定整个软件，而否定其中的某些部分，这意味着必须对这些部分重新设计和实现，其直接后果就是系统交付日期被延误。因而，避免无谓返工是实现快速开发的关键。

1.3 降低风险

客户有时会给进度计划的执行带来风险，表现为以下几个方面：

·客户不完全明白自己的需求。

·客户对开发人员制定的书面需求不认可。

·在成本和进度估算确定后，客户又追加新的需求。

·开发人员与客户的交流不够顺畅。

·客户不愿或没有能力参与评审开发的各个环节。

·客户对技术实现不了解。

·客户不愿让其他人做自己的工作。

·客户对软件开发过程缺乏充分理解。

·一个新客户的出现带来特殊风险发生的不可知性。

建立良好的客户关生活费有助于在项目运作过程中及时发现和监控风险。

1.4 消除矛盾

偶尔我会这么想，“如果没有客户，该有多么好”。
——Naomi Karten

当你不能与客户友好相处时，就不得不花更多的时间用于管理客户关系。这不仅费时，而且分散精力，在设计软件体系的同时，潜意识里还在琢磨怎样向客户解释软件交付时间得推迟三个星期之类的问题。效率因此而降低，积极性也被挫伤，在一个你不喜欢的客户身上额外投入时间是一件很痛苦的事。

在软件行业中由于与客户的矛盾而引发的问题随处可见。对于来自组织外部的软件项目（此时涉及的是真正意义上的客户），开发人员与客户间的矛盾有时激化到双方都考虑取消项目的地步（Jones 1994）。约40%的外部项目和65%的费用固定的项目曾经历过这样的危机。

矛盾有时源于开发者，有时出自客户。由客户引发的矛盾通常是：向开发者提出不可接受的交付日期；追加新需求而不愿增加投资；在合同中省略清晰的承诺标准，坚持在软件的第一个版本中消灭所有“臭虫”；对合同进度的监控缺乏力度等。

由开发人员引发的矛盾包括：承诺在不可能达到的时间内交付产品；人为地降低报价，在缺乏必要技术准备的前提下即开始项目开发；产品质量低劣；不能如期交付；提供的状态报告不够充分等。

将客户纳入项目组中，能使得他们更好地理解技术条件的限制，消除“我现在就要所有的功能都被实现”的想法，客户渐渐会采取合作的态度寻求现实的、双方均满意的、技术上可行的解决方案。

2、面向客户的开发方法

面向客户的开发方法对开发过程有多方面的影响，对以实现快速开发为目标的项目，具体体现为以下4个方面。

·计划：面向客户的开发方法有助于增加客户对项目的满意度。

·需求分析：面向客户的开发方法能帮助开发人员理解客户的真正需求，从而避免返工。

·设计：面向客户的开发方法有益于对客户的需求变更做出快速反应。

·实现：面向客户的开发方法使开发过程充满信心。

这4个方面将在下面的部分中予以详细讨论。此外，下节还将论述如何“合理控制客户的期望值”。

2.1 计划

使用以下关于如何做计划的方法可以增加客户对项目的满意度。

（1）选择恰当的生命期模型。遵循该模型的项目开发应当能够让客户切实看到稳步前进的进度标识，可用模型包括：螺旋式模型、渐进交付法、渐进原型法、阶段交付法等。

（2）弄清项目最终是让谁满意。有时你需要取悦的人并非是接触最多的人。比如，你正为企业内部的另一机构开发软件，则应花最多的时间同该机构的项目联系员进行沟通，然而你的真正意愿是令你的上司满意。又比如，你为一个外部客户开发软件，而该客户所派出的代表对该项目并不持有生杀大权。

因此，一定要弄清楚谁是真正的决策者，并使项目的运作符合他们的意愿。

（3）建立有效的客户沟通渠道。应尽可能地坚持客户方只指派一个负责项目协调工作。或许在有些情况下需要听取来自客户方的各种不同意见并服从多数人的意愿，但在一个快速开发项目中，任何一项决策都要征得若干客户代表的同意显然会影响开发效率。

（4）力争采用双赢的解决方案。首先应用W-理论管理方法来确定项目涉及各方的利益所在，然后制定一个符合各成员利益的计划，最后调整该计划以使各方获利大致均衡。

（5）进行风险管理。要特别注意管理和风险监控计划中与客户有关的部分。

2.2 需求分析

需求分析中最具挑战性的问题是如何获取真正的需求。客户的真正需求有时同开发人员收集到的需求信息是相互冲突，真正的需求往往被忽略了。在很多情况下，必须突破表面现象进行深层次地挖掘才能得到实际的需求信息。正如案例1中所描述的，Carl根据书本知识进行需求分析，但在一开始他便忽略了两份关键报告。客户所提的需求通常很模糊，开发人员易产生误解。对同一份需求报告，客户倾向于认为该需求报告已经足够明确，而开发人员恰恰相反，这是又一个产生矛盾的根源。

面向客户的需求征集方法能够帮助开发人员发掘客户的真正需求，并最大限度地理解这些需求。显然，在掌握真实需求上花的时间越多，此后用于应付客户额外要求的时间就会越少，也就能在最短时间内交付用户满意的产品。

图1显示了使用和没有使用该方法所收集到的需求信息之间的差异。

图1 面向客户的需求征集方法增大了收集到的需求和真正需求间的交集

一个基于经验的研究表明，若客户在需求分析和功能说明的制定过程中有“很高”的参与度，则能将软件生产率提高50%左右（Vosburgh et al. 1984）。

如图2所示，客户的参与度为“中”的时候，生产率比通常大约高出10%，而若客户参与度为“低”，则软件生产率比通常低约20%。

在需求分析和功能说明的制定过程中客度参与度

图2 在需求调查中客户的参与度对生产率的影响（Vosburgh et al. 1984）
（客户的高度参与能大幅度提高软件生产率，但这并不能保证项目一定成功。）

图2也显示了另一方面的问题，即随着客户参与度的升高，生产率的最大值和通常值都显著变大，而最小值没有明显变化。这说明客户的参与确实有助于极大地提高开发速度，但仅凭这一方面来提高生产力是远远不够的。

在说明需求时让客户有多参与固然重要，但同时需要注意的是，需求说明书不能完全由客户书写，否则同样会使生产率降低，这是上述研究的另一个结论。事实上，50%以上由客户制定的需求说明被推翻重写（Vosburgh et al. 1984）。

下述几个方法可用于提高客户在需求征集中的参与度。

·使用需求诱导方法帮助客户找出真正的需求。例如，用户界而原型法、渐进原型法、联合应用开发（JAD）会话法等。

·组成一个中心攻关组，帮助搞清用户到底需要什么。

·把用户使用软件的情况录在录像带上。

·进行客户满意度问卷调查，以便得到你同客户的关系的量度值。

在实际应用中，到底使用哪些面向客户的需求分析方法，取决于“客户”的具体身份。如果是内部客户，可用JAD会话法与渐进原型法，而对于希望购买封装商业软件的外部客户，中心攻关组和客户满意度问卷调查法更为适合。

Jim McCarthy 讲述的一个故事生动地阐述了发现客户真实需求的价值所在（Jim McCarthy 1995a）。McCarthy 曾参加Visual C++1.0版的开发工作，那时Microsoft在C++市场上正受到来自Borland公司的威胁。McCarthy 所在的开发小组做了大量市场调查，并成立了几个专门小组收集需求，结果发现程序员在使用C++方面的最大挑战不是掌握C++的高级特性，而是如何入门。于是，Microsoft将Visual C++1.0版的主要开发目标定为让程序员不必经过繁杂的学习就能用C++构建应用程序。与此同时，Borland公司仍继续将目光关注于高级C++程序员，增加应用模板和异常处理功能，以及其他一些C++的核心特性。

为实现让C++易于使用的目标，Visual C++小组则致力于构造应用程序向导，该工具能够自创建C++应用程序外壳。结果呢？Visual C++1.0一问世，便抢占了数十个百分点的市场份额。

2.3 设计

需求分析阶段的需求征集工作可能完成得很好，也可能不好。因此，在设计阶段还应该可以进一步实现面向客户的目标。

·在系统设计中应允许客户偶尔提出需求变更。

这就要求尽可能想到项目运作过程中可能发生的变化，并有效地利用需求表面之后的隐藏信息。在案例研究1中，开发组制定的计划甚至不能在不影响系统大目标的前提下增两个新的报告，这种缺乏灵活性的设计是该项目的一大弱点。

2.4 实现

若在计划、需求分析、设计等各阶段均打下了良好基础，则到了系统实现阶段，开发人中可以不必过分操心客户的需求了，因为此时客户对开发过程更为关注。

下面所列的几个面向客户的方法有助于在实现阶段做得更好：

·编写易读易改的代码，这能提高应对客户需求变化的能力。

·选择一个能为用户提供稳定明显的进度标识的生命期模型。这在实现阶段尤显重要，否则项目看起来似乎停滞不前了。

选用增量式生命期模型的好处之一是可以连续不断地向客户交付工作成果。每周或每月交付一次阶段性产品比一份常规的状态报告在展示进度方面更具说服力。对客户来说，进度远比口头承诺重要，他们尤其喜欢自己亲自掌握项目进度或者在计算机屏幕上直接看到项目进展情况。

3、合理控制客户的期望值

软件开发领域中的诸多问题，尤期是关于开发速度的争执，大都源于客户对项目持有的不现实的期望。一份调查结果表明，10%的项目由于上述原因被取消了（Standish Group 1994）。作为开发人员，应尽量客观准确地设定自己的期望值，以免客户对进度计划或交付日期寄予不现实的希望。

造成不现实的期望的原因之一来自于进度计划。许多项目在需求和资源尚未确知的情况下，便由客户制定了进度计划。正如本书其他地方提到的，对一份不现实的进度计划表示同意，必然会使客户产生不现实的期望值。因此，协助用户在制定进度计划时树立现实的期望是项目成功的关键之一。

努力弄清客户的期望值可以减少大量的矛盾和额外工作量。1992年，我参与开发的一个运行于Windows 操作系统下的软件产品已进入Beta版测试阶段。这时，客户希望能在产品中做两项改动，并助强调非做不可。第一项改动是在一个工具条上增加一个按钮，点击按钮可插入新的输出页，而此前过错成这一功能需要通过多层菜单导入。第二项改动是增加一张“空白输出”页，用户可直接将在字处理软件、表格处理软件、图表生成系统或其他应用程序中生成的页面拖拉到本系统中，并建立热点链接，当这些页面在相应系统中被修改时，本系统中的页面也自动随之更新。

完成第一项改动是没有问题的，只需花两天时间编写代码，然后再用一点时间设计一个新的测试方案，仅此而已。第二项改动实现起来却是非常困难的，需要完全的OLE支持，而在1992年，这项工作是应当由一个程序员在整个项目运作期间专职负责的。

经过一些询问后，逐渐明白了在这两个特性中，客户认为在工具条上增加按钮是当务之急。这样，一旦理解了第二项改动的实现需要6月9个月的全力投入后，他们便会说“算了！这个功能并不十分重要，先不必考虑它了。”客户之所以提出第二项要求，是由于在Windows下拖拉操作非常容易，于是想当然地认为实现起来也很容易，不过一、两天的工作量而已。

也许你有过这样的经历：开发人员没想到客户不了解系统设计及实现的一些基本知识。例如，客户有时认为凡是在原型系统中有外在表现的功能，产品中也必须予以实现。他们不能理解为什么无法将他们想要的功能全部囊括。他们希望磁盘也能颠倒着反向插入驱动器，他们认为在显示器上看到的彩色画面应该能在激光打印机上输出，他们认为无须多加解释，开发人员也应当完全明白他们的需求。（这些不是假设，都是实例。）

但尽管发生过以上现象，客户却并不是愚蠢。

培训客户以使他们更好地理解软件开发过程，是开发人员应当承担的工作，这使得达到客户的期望值成为可能（见图3）。一旦客户对开发有了较充分的开发后，整个项目的生产力便会相应提高（Jones 1991）。

图3 开发人员和客户看待同一件事情的角度往往截然不同

有时按照客户的期望值，项目根本不可能成功。我就知道这样一个例子，一个企业内部的软件机构在三个月内向一个内部客户交付了三个产品。第一个项目提前完成了，客户指责开发人员没有按估算的计划执行。第二个项目如期完成了，客户说估算过于保守，同时开发人员为赶进度而匆匆完工。第三个项目交付延期，客户又说开发人员没有尽力。

以任何理由（为使一个有争议的项目上马、为给一个项目争取足够的资金、为获得项目开发权等等）使客户对项目进度、费用或功能产生不切实际的期望，都会给项目带来不能克服的风险。软件项目开发想达到中等的期望值都非常艰难，如果期望值过高，即使项目运作良好，也会看起来处于困境之中，即使开发人员做得很好，也总像一个失败者。期望值过高的开发人员将损害自己的可信度，并助破坏同客户的关系。轻易的许诺在项目初期可能会令各方满意，但从长远看，是非常有害的。因此，设定现实的期望值也是开发人员的主要任务之一。

本开发方法出自《快速软件开发》