敏捷程序员与客（用）户沟通的三重境界

下文提到的客户是瑞典最大的旅行社之一——Langley，成立于1984年。其在世界各地以Langley Hotels的名字运营着16家酒店和度假村，为游客提供个性化的服务。

盛安德服务历程摘要：

·      HR系统：做了5年，经历了12个HR，4个Accounting

·      Reservation系统：做了9年，经历了5任Sales Manager，5个Marketing，4个COO

第一阶：与用户一起工作，零距离沟通解决实际问题

前3年客户说什么我们做什么，改变从第一次on-site工作开始，当我们亲眼看着用户使用我们2年前做的系统时，我们才理解一些功能是干嘛用的？当系统速度很慢，某些细节令我们十分“尴尬”时，我们迫不得已开始改系统。2个月之后，我们修改的系统让客户满意了。

因此我们得到了一条宝贵的经验——跟用户在一起工作，才能解决他们的实际问题。

我们至今觉得幸运，项目开始不久就能on-site工作，跟用户近距离接触。我们从ERP系统开始做，得以比较快地从内部接触到用户的实际需求，如果从booking等外部系统开始的话，要走很长的路才能抓住用户反馈，而且还需要很多工具去收集用户信息。

很庆幸我们做的是ERP系统，用户都是内部员工，销售、销售主管、产品经理等人。我们一去，坐在他们旁边看他们工作，看着看着我们自己就不好意思了，就知道系统该怎么改，活儿该怎么干了。我们就是这样学会如何从用户角度思考问题，如何与用户沟通的。

但是，即便你做到了从用户角度思考问题，与用户沟通，你也只能算是刚刚走上“敏捷”程序员的取经之路，前面还有九九八十一难在等着你。

第二阶：沟通尽量免“中介”

很多程序员会说，我天天都在跟客户沟通，客户会给我讲业务，告诉我需求，甚至告诉我怎么实现，帮我测试，告诉我bug……

这些其实都不算与客户沟通，或者只能说是与客户沟通的初级阶段。

要么是客户特别相信你，对你提交的东西不必测试，直接上线；或者客户找其他人测试你提交的东西，但没测出bug……一般情况下，凡是最终实际用户的测试，不存在“零bug”的产品。用户的思路千奇百怪，有时候甚至会另辟一条你都没发现的“蹊径”，找出一些让你始料未及的bug，这非常正常。

我认为什么时候不是客户给你报bug，而是用户，即系统的真正使用者给你报bug，那你才算“敏捷”程序员达标了。这一层次的沟通其实也有一些技巧，容未来有机会我们再展开细说。

第三阶：保持产品价值，而不是某一个客户个人的利益

我主要想讲的是另外一种沟通，比较有意思，还是举例说明吧。

客户方新来的COO肯定要刷存在感，于是新官上任三把火，他给我发了个邮件，问我能不能加“meal board”，实际上我们已经有了这个功能，只不过设计在递进的页面，他不知道罢了。于是我回邮件告诉了他。

接着来了第二把火——他又发了第二封邮件，提出一个关于预订的问题，而且语气比较强硬。于是我的同事花了几个小时检查原因，然后给他回了邮件，说预订功能没找到什么问题。

然后我了解到这个情况，用了一个Log分析工具，查找了一下用户使用的轨迹。这个用户访问了90多个页面，预订后就是不提交，这显然不正常。我们分析他很有可能是个竞争对手，来窥视和“学习”的。然后我们把记录用户访问轨迹的工具发给了COO，他就明白了。

当然，第三把火是不能少的——他发了第三封邮件，提出不要显示“打包价格”，而要显示“单位价格”，因为后者显得“便宜”，更能吸引用户。他这个需求可以理解，因为他同时负责销售，用低价刺激销售是“常用”手段。

但实际上，显示打包价格是我们9年研究用户使用习惯的结论，虽然看起来贵一点，但它更真实。如果只显示单价，尽管当前页面流量会增加，但只要进入下一级页面价格就会“暴涨”，客户难免会有“被欺骗”的感觉。所以我们不能按他的意愿改。但他是客户，是COO，我们到底该不该听他的呢？

如果是在三五年前，我们百分百会照他说的做，但是，现在我们明白他是客户，但对于预订系统他不是用户！自从我们学会做事之前先问why？我们不会再轻易“照做”了。然而面对级别高的客户，我们如何说服他呢？

首先，因为我们很了解客户公司的整个架构和业务流程，很清楚这位COO的职责所在，以及他的需求原因和“情绪”，于是我们请他们的IT Manager一起来跟这位COO沟通，为什么要显示打包价格，IT Manager甚至能比我们更好地向他解释其中的原因，因为他在这公司工作了29年，权威性比我们高多了，这样的说服就事半功倍了。

但是，即便这位COO的三把火似乎都“没有必要”，我们还是要理解他，不要把他当“傻瓜”，从他的立场和视角，他的需求是有道理的。比如他提的第三个需求，其实是因为在预订页面上会显示一些特定的“打折优惠”信息，但在“打包价格”中难以体现，所以后来我们还是在系统中做了相应的细节调整，既满足了COO的要求，又保证了系统的完整性。

重要启示

这个例子中有一项重要启示——保持产品价值，而不是某一个客户个人的利益。即作为一个产品经理，你要对客户公司利益负责，对你们做的系统价值负责，而不是对某一个“客户（客户公司接口的员工，无论级别高低）”负责！

因为职业经理人在进入一家新的企业时，总会带来他之前的“使用习惯”（此处只针对内部系统），那是不是每来一位新的领导，新的对接联系人，你都要改系统以适应他的“使用习惯和需求”呢？还是说你作为产品经理要保持你产品一贯的价值？答案不言而喻。

当然由他们带来的“友商”或其他公司内部系统的一些功能特点也可以丰富你的视野和知识库，如果对你的产品有补益，也有借鉴和参考价值，前提是不影响你的产品价值。

敲黑板，划重点，再加一例

还是这位新任的COO，他的前东家是当地一家知名大公司，他用前任公司内部系统举例，建议我们“改善”系统中“价格搜索”的一些功能，我改还是不改？不改的理由是什么？如何说服他不改？

因为价格搜索是我们系统中的核心部分之一，所有的定价和折扣都由此推导出来，如果照他说的改，那我们系统的1/3都要改，连动的调整就更多了，必然“伤筋动骨”，那可能要一两年的时间。

我们的系统做了9年，不断修正改进，冰冻三尺非一日之寒。我一眼能看出他说的“改善”是为了便于他的操作，但我们这个系统有4个部分，绝大多数员工都已经使用习惯，我们不能因为新任COO的“一发”而动全身。而且，这位COO只是用了一两次，感觉不习惯而已，他并没有深入使用，作为内部系统用户（员工）他是有责任和义务去深入了解和适应系统的。

如果为了他而改变，那其他4个部分系统的使用者可能有几个月的时间都会感觉很“混乱”，而且需要大量的IT资源去支持这些改变，绝对是得不偿失的。但他是COO，是级别很高的客户，我如何面对？

这个时候我只能去找CEO谈，告诉他这一切，说明可以借鉴COO提供的大企业经验的优点，未来集成到我们的系统中，但不能因噎废食，完全照搬。在获得CEO的同意后，我们发起召集了相关高层的会议，把整个情况进了说明和沟通。

这就是我说的，你要在了解公司职权架构和业务体系的前提下，为了保持你做的产品的一贯价值，为客户公司的整体利益去决策，而不是某个人的利益，这样你的决策才有说服力。