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

下文提到的客户是瑞典最大的旅行社之一——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的同意后,我们发起召集了相关高层的会议,把整个情况进了说明和沟通。

 

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

Categories: 
up
0 users have voted.

Add new comment