【IT168 技术文章】
推荐本文节选（并改编）于笔者新著《软件需求非常好的实践：SERU过程框架原理与应用》（电子工业出版社博文视点）
沟通本来就是一门艺术，而需求沟通的双方通常是不同专业背景的，这就更需要应用一些得当的“艺术性技巧”。接下来，我们就通过几个场景实例来体会一下。
紧扣沟通对象选择话题重心
对于“需求分析人员是用户与开发人员之间的桥梁”的观点大家都不陌生，但对于“需求分析人员还是管理层和用户之间的桥梁”则没有予以足够的重视。相信大家都会发现这样的一个现象：在项目的启动大会时，高层管理人员出席启动大会时通常只会呆很短的时间。
这个看上起并不起眼的细节似乎并没有什么不合理的地方，毕竟他们是很忙的。但实际上有暗藏着一些有价值的信号，那就是实际上是很多项目在沟通过程中没有很好地回应这些人的核心关注点。
如果需求人员能够更好地从这个角度来完成与此类人员的沟通，那么将给项目带来很多积极的正面效面，下面这个小案例就能够从一个侧面印证这个道理。
案例&场景：
这是一个关于某手机分销商的真实案例，虽然在经营中总是遇到这样那样的问题，但李总却一直以为自己并不需要信息化系统，毕竟生意还没有到管不了的程度，加上自己并不熟悉电脑，不想受那个洋罪。
也正是基于这个理由，几年来拒绝的信息化系统厂商无数。一天，又有一个信息系统开发商的销售代表老马找到了他，他正想下送客令时，老马说道：“您近几年的利润率在下降！”。
“哦，您请坐。”，这就是传说中的电梯推销技巧，当问题正中对方下怀时就能够为自己赢得时间。
“通过我的了解和分析，发现一个对贵公司利润率产生负面影响的因素”，老马开始进一步阐述自己的观点，同时在电脑上打开了一张PPT幻灯片，上面是这样一张图：
图1 商业模式示意图I
“您为了鼓励门店多销售利润率高的产品，会对自己利润高的产品给门店更高的利润。但有些二级手机厂商为了提高自己的销售量，会打破这种规则，直接给门店返利润”，老马说着就切换到了如下所示的图上：
图2 商业模式示意图II
“这时门店将转向主推手机厂商B的手机，因为其利润要高于手机厂商A的手机，而这是你不想看到的”。
“说得没错”，李总表示认同：“对这个问题，你有什么建议？”
这时老马不慌不忙地为其展示了一张产品销售分析报表，然后说：“当然要解决这个问题的前提是找到影响利润的这个产品！”，边说着边开始在报表上指点起来。
“太好了！”，李总也顾不上掩饰自己的内心活动，“如何整理出这张报表呢？”。
话题终于转换到老马所要的结果上，那就是：“使用我们的软件系统就能够生成这样的报表，为您的决策提供最真实的依据。”
故事的结局就是这位曾经顽固不化的李总花了一笔钱上了这套系统，而且整个系统实施过程很顺利，因为只要能够满足他这个目标就物有所值了，根本无需刁难老马。
从上面的例子中我们可以得出一个道理，高层用户关心的是“问题/机会”，通常不愿意细化了解系统的内部。其实中层用户关心的是“流程”、“可管理性”、“效果”，而操作层用户则关心“业务活动”、“方便”、“速度”等。
从能引起对方兴趣的角度沟通
在上一篇文章中，我们已经提到过“转换关注点”的技巧。在此，我们再介绍一个有趣的沟通场景。
案例&场景：
有一次，笔者在香港迪士尼游玩时观察到一个管理细节：在太空船游戏区中，在排队区中会先放16人（每一船的容量）进入缓冲区，然后给每个人发一个牌子，上面画着船的号码、入口位置、你将坐的位置、以及进入入口之后的行走方向（如图3所示）。
图3 路线指引牌示例
我对此深有感触，回来之后与一位做嘉年华游乐场的朋友谈起这个事情。可以他的回应却是：“吃饱了没事干呀，有必要管到这么细吗？”
……
我接下来告诉他：“我当时用手表掐了一下时间，每换一船人花掉的时间是2分50秒以内，我们现在到你那掐一下”。
当我们用秒表掐了一下时间，就发现在他这里，每换一船人花掉的时间都在5分钟上下。
我就趁热打铁地说到：“你看看，你这一天要少赚多少钱呢？”这时这位朋友说：“我马上去做一些这样的牌子……”。
为什么这位朋友前后判若两人呢？因为前面的沟通听起来是“管理的成本”，后面的沟通则提到了“经营的效益”。信息系统很多时间都给人一种“管理成本”的印象，因此如果能够多从“经营效益”的角度来沟通，一定会达到更好的效果，这也是高层管理层真正有兴趣的角度。
抓住问题的本质
问题经常会被表象所掩盖，如果不能在问题定义时揭开这个表象，那么经常会给解决方案带来问题。而对此类技巧阐释得最完美的当属温伯格先生的大作《你的灯亮着吗？—发现问题的真正所在》，在这本书中收录了十余个很有意思的故事，而书名正是其中最有代表性的一个。
下面我们就简要地回顾一下这个故事，看看它背后的哲理对日常的软件开发工作有什么样的启示：
隐喻：
话日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。针对这个问题，大家提出了解决方案：“警告！前有隧道请打开车头灯” 。
但不久之后，路政部门接到了一些反馈与投诉：隧道出口风景很美，返回时发现汽车没电，原来是忘了关车头灯！！
这个问题看起来并不难解决，有人马上提出了一个解决方案：在出口处立一个标牌，写上“关掉车灯”。
这样问题解决了吗？当然没有！如果夜行车经过这个隧道时，看到写着这个“关掉车灯”的标题应该作何处理？难道真的关掉车灯，那是多么危险的行为呀！在软件开发过程中，经常也会出现类似的“惯性思维”，看上去解决了问题，实际上将会产生更麻烦的问题。
案例&场景：
小林在一次电子政务项目中遇到了这样一个问题，用户要求对每个政务申请的各种处理都需要记录时间。由于他们选择的是C/S结构，因此取时间时就遇到问题，每台机器上的时间都不尽相同。
“不就是时间不统一吗，让所有客户端登录时先从时间服务器上取一个时间就搞定了！”。
但这个方案在实际的运行时却带来了不小的麻烦，由于时间服务器写得不够稳定，经常会自动退出，当这种情况出现时客户端软件就根本无法进入，严重影响了客户的正常使用。
其实解决这个问题的方法有很多，例如在数据库存储时来处理，即取数据库服务器的当前时间。而且即使采用这种方法，也不应该在时间服务器同步失败时阻止用户登录系统。
隐喻：
既然“关掉车灯”的解决方案是不可行的，那么就换个思路吧：前面的思路是事前预防，那就改成事后补救吧。因此就有人提出一个新的解决方案，那就是建设一个充电站。
但是建充电站也有问题，不仅维护开支很大，而且本身也会出故障。要解决这个矛盾，又有人提出是否将充电站交给私人经营，但这又不符合当地的法规。
“用一个成本很大的解决方案去弥补自己的错误”是很常见的问题，原本不是什么大问题，却花费了巨大的成本。这种现象在软件开发过程中也不少见：
案例&场景：
在小陈负责的一个客户关系管理系统项目中，用户在使用了一段时间之后提出了这样一个问题：客户数据库的数据比较乱，有重名、同客户多条记录等现象。
小陈毫不犹豫地说：“没关系，我可以为你们开发一个功能强大的客户数据清理工具，通过工具可以自动识别出这些混乱的数据，并且提供一些合并、汇总、删除功能”。
随着这个功能的开发，项目的范围也不断扩展，针对这个功能的需求也层出不穷。这就是软件开发过程中的“充电站”，成本付出了，但真的对项目有好处吗？
这样做合适吗？似乎很多人会举手赞成，但是也付出了巨大的成本。如果我们细究一下，这个问题是怎么产生的呢？为什么数据会混乱呢？实际上根源问题是在用户输入数据时，系统对数据的校验不足，因此更科学的方法是加强输入时的数据校验，而不是开发一个大“充电站”来事后补救。
隐喻：
在万般无奈下，有人提出了一个蹩脚的主意：在出口立一个大牌，上面写上“如果是白天，并且车灯开着，请熄灭车灯；如果天色已晚，并且车灯没开，请打开车灯；如果是白天，并且车灯没打，就别打开它；如果天色已晚，并且车灯开着，请别关掉它”。
这样能够解决问题吗？显然不能呀，在汽车行驶过程中谁能够阅读完这么长的一段话呢？
有些时候，软件开发人员也会采用类似的提示语，例如安装过程中的向导就是这样的例子：明知道大家都是闭着眼睛点击“下一步”按钮的，那么为什么还要不断地重复这样的设计呢？这难道不就是这个蹩脚的标牌吗？
那么怎样才能够解决这个问题呢？关键在于对问题的定义，先确定这里到底存在什么样的问题？如果从这个角度来看，不难发现：
图4寻找问题的本源
表现出来的问题是车没电了，而为什么没电了呢？因为司机忘了关大灯。为什么会忘了关大灯呢？往往是没有人提醒他而造成了疏忽。通过这样的分析，我们就知道需要的解决方案是“提醒机制”，这时就不难得出有效的解决方案：
隐喻：
最后终于有一个清醒的人提出了一个有效的解决方案，那就是在出口出立一个标牌，上面写上“你的灯亮着吗？”。
我想这时让你给出类似的解决方案也并非难事，为什么前面会绕了一圈呢？关键就是没有正确地认识到什么是问题？这个案例诠释了“对问题进行了正确的定义，意味着成功解决了一半”的内涵。
