SERU需求过程框架

    今天在《程序员》2008第10期中看到一篇关于如何做需求分析的文章，觉得很有启发，因此又找到他的另外两篇系列文章来。

    需求分析是进入项目实施的第一个阶段，需求分析的好坏，是影响软件质量以及后期工作能够正常进展的决定性因素。

    然而，软件固有的复杂性、易变性和不可见性，使得软件开发周期长、代价高和质量低的问题依然存在，尤其是在需求与设计之间仍存在一条很难逾越的鸿沟，即缺乏能够反映做决策的中间过程，从而很难有效地将需求转换为相应的设计。大量实践统计表明：大系统软件开发中70％的错误是由需求和软件设计阶段引入的，而且错误在系统中存在的时间愈长则愈难发现，解决这些错误的代价也愈高。

    平时的需求分析，其实要不就是业务无法运用有效沟通来获取，要不就是无法用适当的形式来表达，从而使得需求分析很费力，这篇文章对我需求分析中需要注意的事项给出了一些建议，以及需求分析中常见的问题，受益匪浅。另外，《软件需求最佳实践：SERU过程框架原理与应用》也是很值得一看，等我理解透彻下面三篇系列文章，准备也找来参考一下！

文章作者简介：中国系统分析员顾问团软件工程首席顾问，中国软件技术大会杰出贡献专家，资深咨询顾问。主要研究领域为需求工程、系统分析与设计、软件估算，致力于推动软件工程方法论的落地应用。本文节选(并改编)于笔者新著《软件需求最佳实践：SERU过程框架原理与应用》

老图新说话需求----SERU需求过程框架系列文章

老图新说话需求

在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题根源之所在。

引言

关于软件项目所存在的问题，互联网上曾经流传着一幅漫画(如图1所示)，它十分生动地展现了这些问题。也许很多人看完之后只是一笑置之，但如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的。

 

 

沟通失真

究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。因此，对于软件需求工程而言，克服沟通失真就成了一个要点。

根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4%(如图2示)，这是一个十分可怕的结果。

 

 

怎样才能够更好地避免这种问题的出现呢?其实关键的手段有两个：

 

l 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通，这一点在后面还会提到。

l Review：在此有意使用了英文，因为国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义，Review就是再(Re)看(View)一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。 

 

 

隐喻：

经理叫来了小张，然后就下一阶段的工作做出了一些重要的指示和安排：“$%#^@(*)#@……”。

小张正要扭头走的时候，经理叫住了他，说到：“你简单地说说看，我刚才给你交待的任务有哪些”(看来管理人员早已掌握了这一招)。

提示：

如果有一个测试人员对你说：“我前天仔细测试了一下你写的程序，发现一个问题也没有，恭喜你!”。你会怎么想呢?

a. 觉得自己的程序写得很好!

b. 觉得测试人员方法不得当或测试不细致。

我想大多数人都会做出“b”的选择!可是到了需求评审时为什么却转了180度的弯呢?为什么期望需求评审时一点问题也没有呢?

“沟通失真”高度概括了其中所蕴藏的问题，但如果我们细细地思考第1、2、3、4、10幅图(这五幅图中的景象与需求活动有很大的相关性)，并将其两两比较就会得到一些有益的启发。下面我们就一起来看看。

客户：放大需求

当我们比较图1中的1幅和第10幅图时，就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢?我认为至少有两方面关键因素：

(1) 客户希望支付的成本尽可能少，获得的效益尽可能多

这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了;因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。

要有效地克服这个因素的困扰，核心的要点在于建立客户对开发团队的信任度，而建立信任度的要点有两个方面：一是需求人员必须提升自己的专业主义(关于这一点我将在后续的文章中说明);二是需求人员要多站在用户的角度想问题，让用户感觉需求人员的目标是帮助自己解决问题，而非一味谋取利益。

(2) 解决方案的选择权交给了不熟悉技术的客户

也就是用户经常会谈解决方案，甚至许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么(What)，而不太关心用户提出需求的真正动机(Why)。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而客户代表选择的解决方案不是最合适的话，就必将引发后续的需求变更。

案例&场景：

在一次CRM软件开发的过程中……

负责输入客户信息的用户向开发人员提出：“你看这个界面，光电话就有快10个输入框，太麻烦了，每次按tab键都按酸了。我希望把他们合并成两个，一个为常用电话，一个为其他电话”。

“那有多个电话怎么办?”，开发人员回应道。

“其他电话的输入框可以设置为多行的、较宽的，这样我可以输入多个，中间用逗号分开它!”。

“好的，没问题” 。

　……

当经理看到了这些客户信息之后，向开发人员提出：“我需要一个功能，输入任何电话号码，自动找出相应的客户。”

“啊……”

如果我们细究这个场景，分析一下负责输入客户信息的用户所提出的变更就会发现：“将10个电话输入框合并成两个”显然是解决方案，而真正的需求是“输入太麻烦了，每次按tab键都按酸了”。你或许就会想到如下所示的解决方案：

 

 

也就是说，默认情况上只显示左边的部分，当需要时点击“其它>>”按钮就可以将右边的不常用输入项显示出来。

总而言之，因为对于一个特定的问题可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于在需求捕获的过程中多问“为什么”。

 

 

项目经理：控制需求

当我们比较图1中第1幅和第2幅图时，就会发现项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职，项目管理、需求分析、架构设计一肩挑，因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制需求的范围。

就像这里，从图1中第1幅图看，客户需要的可能是一个“秋千”或者是“上树工具”，但不管真正的需求是什么，第2幅图中的解决方案却都无法有效地满足。如果要做“秋千”，不应该被树干挡住;如果要做“上树工具”，木板的数量显然太少了。

究其原因不难发现，需求人员首先从项目经理的视角按工作量对需求进行了控制：将“三层”板的工作量减成“一层”板，如果不小心控制掉的是对业务很重要的东西，那么最终一定会以变更的形式“回报”给开发团队的。然后需求人员又从架构师的角度进行了“改良”：不稳定的“全挂在一个树枝上”改成“挂在两个树枝上”，结果根本无法使用。

因此具有多个角色的需求人员，必须在需求的过程中“戴正自己的帽子”，真正从理解业务的角度来捕获需求。

分析人员：技术加工

每次看图1中第3幅图时，就会想起这样的一幕：

案例&场景：

分析员小张：“嘿，伙伴们!我有个提议，我们研究Hibernate已经有一段时间了，一直没时间真正动手用一用。我看这个项目就不错，不算太大，就用它试试吧!”。

“好主意!”，大家纷纷表示赞同。

……

“约定时间已经过去1个月，现在项目进展到底如何了?什么时候可以交付?”，客户方CIO质问到。

分析员小张：“现在主要困扰我们的是一些需求细节一直存在变化，开发团队又有了一些人离职，所以……”(真正的情况是：由于团队第一次使用Hibernate，有些数据访问层的问题一直没有有效解决，导致进展不断失控。)

现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。对于这种现象，究其根源，关键还在于“技术能力”对他们的未来发展更为重要，而“业务能力”却不是那么重要。但为了使需求工作有更好的提高，我会强烈呼吁那些Title上有“分析”之类名称的人们，加强业务分析吧!

编程人员：断章取义

对于第4幅图，可以用一句生动的话来概括：“你要绳子，我给你了;你要木板，我也给你了;你为什么说这不是你想要的呢?”。我想程序员也有类似的问题想问自己的客户，“你要文本框，我提供了;你要一个表单，我也有了;你为什么说这个程序不是你想要的呢?”。这让我想起了这样一幕：

案例&场景：

叮铃铃……，程序员小赵的电话急促地响起。小赵刚接起电话就听到了对面迫不急待地抱怨声“仓库管理员反应，入库模块没法使用!你马上查一下，尽快解决一下!”。

小赵放下电话就开始Check out、Builder、Run、Debug……等一系列操作。经过一番测试之后，小赵没好气地提起电话回复说：“这些客户真是笨!这哪有问题，肯定是操作上出了问题!我怎么用都是好的，你们客户服务的人也应该加强对用户的培训，别什么事都扔给我们!”。

……

可是，问题仍然没有解决!开发人员到了现场一看，终于发现了问题的所在：这是一套基于B/S的仓库管理系统，在入库时，仓库管理员首先需要录入入库单，然后填入“验收情况”，最后点击“入库”按钮。但当仓库管理员录入完入库单，逐一验过入库货物之后再回到电脑前时，等待他的却是一个令其不知所措的问题，Session超期!

一肚子气的小赵一个电话就打到需求分析员小钱那里：“你们的需求是怎么写的!这么重要的东西也不写明白，我们怎么知道填完入库单后要验货那么长时间，才填写验收情况呀!”。

“哦，这也算是需求吗?如果这也算的话，那我们岂不成了业务人员了!”，小钱很强势地回答到。

这是需求吗?也许很多读者会有不同的看法!但如果缺乏对业务场景的了解，又如何能够真正理解需求呢?断了“业务场景”之章，必将导致取出的“需求”之义有所偏差呀!

 

                                                      需求捕获中的心理战--SERU需求过程框架系列文章之二

　需求捕获的过程是和人打交道的过程，而只要是和人打交道就一定会遇到各种心理现象，而有些负面、消极的心理现象必将对需求捕获造成巨大的障碍。笔者在自己的工作实践中也遇到了很多这样的大山，栽过了很多跟头。

关键字：需求 SERU 需求过程

　　《SERU需求过程框架系列文章之二》

　　需求捕获中的心理战

　　需求捕获的过程是和人打交道的过程，而只要是和人打交道就一定会遇到各种心理现象，而有些负面、消极的心理现象必将对需求捕获造成巨大的障碍。笔者在自己的工作实践中也遇到了很多这样的大山，栽过了很多跟头。但只要我们能够洞察这些心理现象背后的动机，就一定能够找到解决它的方法。下面我就针对五种最典型的心理现象作一些分析，分享一种有效的缓解手段。

 

　　言过其实心理

　　在很多的需求捕获活动中，我们总会遇到一些喜欢夸夸其谈的用户(最容易出现在中层管理者身上)，说出来的流程都是很理想化、很规范化的。但到了系统开发与实施时，却会发现他们说的与实际情况有很大的差距，或者按照他们说的流程是无法真正落实和实施的。这就是言过其实心理的典型体现。

　　案例&场景：

　　有一次，小李在开发一个物资管理系统的时候就遇到了这样的一个用户。在谈及物资管理的基本单位时，这位用户说：“我们的设备价值都比较高，看起来不起眼的东西都动辄几千块，甚至上万块!因此必须采用按个管理的模式，每个设备都将拥有一个惟一的ID，系统需要能够对其整个生命周期进行跟踪。”

　　可以当系统实施后，却一直使用不起来。后来才发现，虽然这些物资、设备的价值不菲，但量却也不少，而且很多是备件，因此调配很频繁。再加上人手不足(只有2个)，所以不管是主观还是客观上，都很难做到按个管理。

　　要解决这个问题，首先需要能够事先发现用户有“言过其实”的现象。那么如何才能够发现呢?有时我们可以通过观察用户的说法方式来发现，通常这种“言过其实”的表述都会以非常肯定的语气，并且讲述时十分流畅，没有什么打断;因为这个时候只需要创造，而不需要回忆!另外，还可以通过“明显背离”来发现，例如在前面这个案例2个人要实现对大量备品按个管理显然是有困难的。

　　当你怀疑用户可能存在“言过其实”的可能时，还需要进一步验证。那么如何验证呢?心理学中这样的一个研究结论：在没有串供的情况下，天下的谎言是不会相同的!

　　也就是说，我们应该就关键流程、有怀疑的流程进一步验证，方法很简单：就是访谈结束后，再找一个相关的用户代表来进行访谈(可以是全面访谈，也可以只针对部分信息进行访谈)。如果两次获得的信息不相同，那么就说明可能遇到了这方面的问题。

　　不过有时这种抽样验证需要采用迂回的问题，例如如果在前面的案例中发现了“言过其实”的可能，如果直接问具体人员：“你们经理说备品备件是按个管理的，是这样吗?”，那么肯定会得到肯定的回答。在实际的场景中，或许可以问“备品备件上的条形码掉了的时候，你们通常是如何处理的呢?”，通常就会得到更加真实的回答。

　　找到了这样的问题之后，就可以寻找针对性的解决方案。在不同的场景中，采用的方法也不尽相同，不过也有一些相对通用的策略：

　　l 差异展现法：也就是将不同用户代表的访谈结果进行整理，在系统开发之前把这些差异展示给中高层管理人员，就如何解决达成共识。

　　l 瓶颈分析法：对流程执行过程中的瓶颈进行分析，例如时间瓶颈、人员瓶颈(例如所有的申请都要由处长审批)等方面，以避免流程瓶颈导致系统无法顺利运转起来。

 

　　越俎代庖心理

　　在企业/组织中，往往“懂得越多的人越忙”，这将对需求捕获造成很大的负面影响。而有些企业/组织中会有一批不算太忙(同时懂得也不算太多，通常是一些资深的工作人员)的人经常会在需求捕获过程中侃侃而谈。

　　他们的特点是：不管是不是自己负责的流程，都会津津热道，并且将根据自己的理解、想象进行肯定的描述。这种现象造成的结果想必大家都知道，那就是最终不得不返工。那么我们应该如何更加有效地避免这一现象，或者如何更加有效的利用这群用户的智慧呢?

　　要解决这个问题，关键在于需求捕获人员能够识别出正确的被访谈者，也就是回答你要问的问题最佳的人选是谁。这里有两层意思：

　　l 问题的层次是否正确：高层管理人员解决宏观问题，中层管理人员解决脉络问题，操作者解决细节问题;在本书后续的内容中还会更详细地说明。

　　l 根据业务背景判断：也就是有效地识别该问题所针对的业务环节是由谁负责处理的?执行者往往是回答问题的最佳人选。

　　不过在实际的工作中，我们不可能不去访谈这些人，即使这样做了，或许要访谈的人也见不着，或者没有足够的时间。因此从现实的操作角度上看，我们必须有所变通。基于笔者的经验，建议大家这样来处理：

　　l 仍然对这类人群进行访谈，并且对访谈的结果按业务脉络进行分类，并不属于他负责的部分标识出来，并确定它的最佳回答人选是谁。

　　l 然后在后续的需求捕获活动中安排对这些最佳回答人选的访谈，由于有了一定的基础，访谈时间可以大大减少!如果连访谈的时间都没有，那么可以通过验证的手段来参与，或是文档验证、或是评审会。

 

　　非正事心理

　　案例&场景：

　　在某个企业信息化的项目的需求捕获阶段，小林好不容易发现对方一个很重要的部门经理在办公室，因此走了进去，争取到了一次访谈的机会。

　　但还没谈几分钟，就有人找这个部门经理，访谈被迫中断。等他处理完成这件事情后和小林说：“真抱歉，刚才有件急事必须处理一下!我们继续开始吧，刚才我们谈到哪里了?”。

　　“……”

　　而且在不到一小时的访谈中，这位部门经理电话不断，诸如“刚才我们谈到哪里?”之类的问题也不绝于耳。

　　相信大家对类似于此的场景并不陌生，而且也一定知道这种访谈的效果并不好，效率也极为低下。我把这种现象称为“非正事心事”，也就是说，被访谈者并没有把这次访谈当作一件优先级很高的事情。

　　为什么会出现这种现象?又应该如何解决这类的问题呢?这种现象的背后有主观和客观两种潜在的因素，如表1所示：

　　表1 非正事心理的应对之道

　　隐喻：

　　当你走到饮水机边倒水时，刚好被经理看到，然后接到这样的指示：“xx，这位客人你接待一下”时，你从内心会怎样看待这件事?

　　我相信绝大多数的人都会把这件事当作一件低优先级的事，因为偶发的事件都会给人这种感觉。

 

　　抗拒心理

　　案例&场景：

　　在一次电子政务的项目，老徐在调研一些窗口人员(负责受理企业申请的服务人员)时遇到了一件很尴尬的事情。

　　“你们又来了!”，一位姓张的窗口人员看到他们脸都放下来了。

　　小李感到十分不解，他并不认识这位窗口人员呀!其实原因是这样：窗口人员是接触信息系统最多的岗位之一，对这些IT公司的人员是很熟悉的，一看拎着电脑包就能猜个八九不离十。

　　这就是抗拒心理的典型表现，这在操作层的用户中最为常见。原因很简单，很多信息系统对于操作层而言效益并不明显(开发人员也不关注于此)，而且经常还会使其工作量有所增加，并且还带来了许多培训的负担。

　　这样就会使操作层用户代表在需求捕获过程中将对信息系统的敌对转化成对需求捕获人员的敌对。在这种敌对的状态下，是无法形成有效沟通的，因此我们需要先“化敌为友”。这是主导的策略，实际的方法有很多，下面就是一个采用“激将法”的例子。

　　案例&场景：

　　好在老徐也算是久经风浪，看到这种情况马上想到了一种方法。虽然这位窗口人员并不欢迎，让他还是有礼貌的坐了下来，说了一句很奇妙的话：“看样子，你们的工作也比较清闲嘛!”。

　　这时对方的脸马上阴转暴雨，大声地说到：“我们清闲!我们可不像那些科室的人，我们的工作经常是一天到晚忙不停的，甚至经常会超出下班时间!你一会儿就会看到，来办事的企业是多么多!”。

　　这样的回答早在老徐的预料之中，马上回应：“噢，那真是辛苦!你觉得是什么原因导致这种现象的呢?有没有什么好的方法呢?”。

　　“唉，实际上就是上了很多的系统的缘故，我们打字也不快，而且现在流程也比原来手工作业时更复杂……”

　　看到这里，大家是否有些触动，需求也经开始出来了!而且通过这种方法，往往会有效地改进双方的关系。

 

　　推卸责任心理

　　案例&场景：

　　小张在一次系统的调研中切实地感受到了需求工作的困难。当他找到中层管理人员时，他得到的信息是：“你和基层的人员多做沟通，看看有哪些地方可以通过上系统解决问题、提高效率”。

　　可是当你找到基层的操作层用户代表时，他们却简单地回应：“我们没需求，这事你得找领导!”。

　　中层管理人员的回应体现的问题是项目的目标不够明确，我们在此就不再讨论了;而操作层用户代表的回应则是另一种常见的现象，那就是推卸责任心理。

　　由于信息系统在企业/组织中并没有被广泛认同，因此很多人会抱着“事不关已，高高挂起”的态度。而且最令人为难的地方在于：他们说没有需求，你也不好多说什么，因为这只是能力的问题，不了解信息系统并不是错。

　　遇到这种情况，我们该怎么办呢?其实这时被访谈者处于“设防心态”，心想我只要回答不知道，看你能够怎么样?对于这种情况，如果你能让他连续回答几个无法回答不知道的问题就能够突破这种心态。

　　具体来说，最简单、最有效的策略是先从工作场景开始访谈。先问问你从事哪些工作，这些工作是如何进行的?这些问题是他们无法拒绝回答的。然后再逐步过渡到存在什么样的障碍，有什么困难等问题上来，慢慢就会发现你已经开始听到需求信息了。

 

                                    需求沟通中的“乾坤大挪移”--SERU需求过程框架系列文章之三

在需求沟通的过程中，如果能够有效地利用事物的多面性，发挥出“转换”这一“乾坤大挪移”式的技巧，有时可以出奇效，取得良好的沟通结果。

关键字：需求沟通 SERU 需求过程

　　《SERU需求过程框架系列文章之三》

　　需求沟通中的“乾坤大挪移”

　　在需求沟通的过程中，如果能够有效地利用事物的多面性，发挥出“转换”这一“乾坤大挪移”式的技巧，有时可以出奇效，取得良好的沟通结果。下面我们就结合一些实例说明四种常见的转换策略，以便大家从中汲取相关经验。

 

　　未知问题到已知问题的转换

　　我们先来看这样一个问题：图1所示的是一个国际象棋棋盘的缩小版[1]，中间摆着一只马，要求写一个程序为这只马[2]寻找一系列的移动步骤，使马走完每个方格，并且落在任何一个方格中有且只有一次。

图1 马的遍历问题

 

　　很多时候我们都会将其当作一个新的回溯问题来处理，因为我们了解回溯算法;所以问题的关键就在于找到回溯判断条件，这本身也就是一种问题域的转换。

　　但这种转换还不够精彩，因为还可以找到更好的转换方法，将其转换成一个具有已知解的问题。具体的思想是，将每个格式编上号码，然后根据马能够到达到线路将每个格子用线连起来，如图2所示：

图2 对马的遍历问题进行转换

 

　　看到这里，那些对数据结构和算法不太陌生的读者就马上会发现：马的遍历问题被转换成了连通图的遍历问题了。

　　而在实际的项目过程中，特别是我们已经有自己的产品时，在和客户沟通时就应该注意如何将客户的需求转换成自己的已有产品;而不是简单地全部重新开发。

 

　　相对重要到相对次要的转换

　　需求的优先级、重要性都是相对而言的，这一点在需求捕获过程中应该予以充分重视，经常会有特殊的效果。下面我们就来看一个成功的通过该策略防止了需求蔓延的真实案例：

　　案例&场景：

　　在一个设备告警平台系统的开发过程中，值班室的小李要求开发人员实现值班日志的自动生成功能，而且必须是实时的，也就是每条告警生成后就要马上更新值班日志。

　　这是一个优先级很高的需求吗?至少可以判断得出不是一个实现起来很简单的东西。因此当时开发团队的项目经理就应用了转换策略“相对重要à相对次要”。

　　他告诉小李：“要实现这个功能并不难，不过实现它可以会影响到告警短信自动发送功能(这是分管值班室的部门经理提出的功能需求，这点小李也知道)。”

　　“哦，那就先不开发这个功能吧，以后再看吧”，小李无奈地回答到。

　　在这个案例中，自动生成实时值班日志功能相对于小李而言是重要的，但相对于告警短信自动发送功能则是次要的。通过这样的转换，成功地判断了需求的优先级。

　　在需求捕获中，如果用户代表有意无意不指定优先级、或将所有需求都置为高优先级时，就可以采用这一策略。具体来说，就是选择一个其上层领导提出的、他也知道的需求来比较!如果这个需求并不是那么紧急，通常他自己就会放弃;如果这个需求对方一定坚持，就说明了它的不可或缺性。

 

　　关注点转换

　　事物都具有多面性，都各有优劣;而关注点转换的核心思想就是利用其多面性，引导对方向有利自己的关注点进行思考，从而为自己赢得机会。这一点，在许多有销售技巧相关的培训中经常会出现，例如“扑克营销游戏”就是用来揭示这一技巧的。

　　隐喻：

　　扑克营销游戏的规则是这样，让游戏者随意从54张扑克牌抽出一张，然后向大家推荐这张扑克牌，使大家认可它是一张好牌。

　　如果抽到的是一张黑桃A，那么营销词可以这么说：黑色代表庄严、黑桃在四色中是排在第一位的，A是一色牌中最大的一张。

　　但如果抽到的是一张红桃2呢?那么可能要说：红色代表喜庆，黑色代表悲伤!所以要选择红色;而红桃看起来比方块色调更正统，所以应该是红桃;而2嘛，在打争上游、跑得快时(我们就不打八十分了)显然是最大的!

　　但如果抽到的是黑桃3呢?那就应该引导到拱猪游戏上了，黑桃3用来拱猪(黑桃Q)最好!

　　……

　　当然并不是要把每张牌都变得王牌，而是变成可接受的牌，其关键技巧在于给它创设场景，让人们从你引导的角度去审视。

　　接下来，我们还是来看一个与软件开发相关的例子。不过事先要申明一点，这个场景的主角的做法并不值得推荐，但他的确把关注点转换发挥到了极致。

　　案例&场景：

　　有一次，某财务软件公司的一位客服人员接到了一个用户投诉，用户很生气地向她吼到：“你们软件的查询速度太慢了，比xxx、xxx、xxx(几乎列出了市场上所有的财务软件)都慢!”。

　　而她却温和地、慢条斯理的回答到：“慢，那就对了!”。

　　“……”，大家不难想象投诉者为何无言以对吧!

　　她接着用同样温柔的声音说：“我们认为财务软件中的数据是十分重要的，事关企业的核心机密!为了防止有人恶意访问数据库，这样就可能跳开财务软件阅读这些数据!所以我们将数据库的数据做了一些加密处理!你想呀，对加密过的数据进行查询当然要慢一些的。不过你的意见我们一定虚心接受，我会马上向技术团队反馈，让他们做进一步的优化。”

　　对于这样合情合理、态度友好的解释，用户当然很乐意接受。

　　当投诉的用户挂机之后，这位客服人员就马上联络了技术团队，建议他们尽快对查询功能进行优化，以便提高用户的满意度、提升产品在市场上的竞争力。

　　在这个案例中，用户最初的关注点在于速度、性能;而这位客服人员将用户的注意力带到一个更重要的角度，那就是安全性。通过这种关注点的转换，有效地赢得了改进的时间。

　　隐喻

　　隐喻就是打比方，是用对方熟悉领域的事物来解释深奥问题的手段，它也是转换技巧中最精彩的一个。在与人沟通时，隐喻能够起到很好的润滑作用;而需求捕获人员通常是介于问题域和解决方案域之间，打交道的人通常对技术知识的了解并不深入，因此隐喻就显得更加重要了。

　　案例&场景：

　　在笔者职业生涯早期负责的一个项目中，客户在系统试运行时提出一些对表结构进行修改的变更，绝大部分我们都予以了满足，但有两个由于牵扯到系统中的核心表，因此改动起来影响面很大。

　　为了能够保证系统按时验收，我们希望能够将这些影响核心表的修改推到验收之后再进行。但客户表示很不理解，质疑到：“不就是改个字段，真的有这么为难!”。

　　我想了一下，马上说了一个隐喻：“你说如果想在家里的卧室中安排个水龙水会怎么呀!”。

　　“开玩笑，没有预留水路怎么能安装呢?”，这位客户一边回答，一边就会心地笑了一下。

　　“是呀，字段修改就像安水龙头一样是小事，但由于时空的不同，所产生的影响和工作量是不同的!就像这两个字段一样，由于它涉及的表是系统多处使用的核心表，因此就会带来大量的额外工作量”，我还是继续作了解释。

　　就像这里的例子一样，生活中的例子总能够使得沟通更加顺畅，同时也能够更好地提高自己的专业素养。小的隐喻能够提高沟通效果，而好的隐喻则会让人感到精彩绝伦，下面就是一个令人拍案叫好的隐喻。

　　案例&场景：

　　这个精彩的隐喻源于一次ERP软件的推荐演示会，由于该厂商被安排在最后一场，轮到他时已经是华灯初上时分了。这时所有的听众早已又饿又乏，难以集中精力了。

　　而这位演讲者突然想到了一个办法，走上台后从钱包中掏出了一张百元大钞，然后当众用打火机把它付之一炬。这时所有的听众都被这个令人匪夷所思的动作深深吸引上来!

　　然后他不慌不忙地说：“这个动作让大家有什么样的感觉?很糟蹋吧!可是贵企业的许多环节却是每一天都在做这样的动作，而且烧的量比我大得多!想知道是怎么烧的吗?有什么好办法来解决吗?下面我们……(介绍了一些企业库存管理、生产计划不当而导致的成本浪费的现象，并说明软件是如何解决这样的问题的”。

　　有了这个成功的开头，他完成了一次很生动的推荐，也成功地获得了用户的认可，获得了合同。并且有人总结到：我总算是搞明白了，ERP的核心价值之一就是控制成本……

　　生活是最好的老师!只要你细心观察生活，就能够找到许多生动的隐喻，为沟通建立良好的基础。当需求人员掌握了隐喻的技巧之后，就能够更好地在用户面前建立“专业主义”的形象，也就能够更好地展开相关的工作。