是否该让开发人员跟客户直接交流?

交流

“如果你让我做这个,我宁愿辞职。”

德米瞪着我,不是愤怒,更多的是焦虑。他显然被我的请求所震惊,我只是想让他跟一个客户打个电话,解释一下关于公司软件产品的几个技术性问题。

德米是我们开发团队的一个头头。他人很文静,知识丰富,当和他的开发组同事讨论问题时会变的非常活跃。

但有一点很明确。德米不喜欢跟办公室里非技术的人员做太多的接触。

通常,这没什么问题。然而,这回我想让他给客户打个电话,是因为负责这个客户的销售工程师请病假了。而其他的销售工程师都在外出差。

除此之外,我还知道一个事实,对于这个客户最感兴趣最想了解的这个模块,德米很熟。

我尝试着恭维他。

“德米,我看见你在团队里、甚至测试组、技术支持组里谈论这些功能特征时都自信无比。架构是你搭建的,主要也是你开发的。这次和这个客户只是在电话中交流,说说这些你绝对熟悉、绝对专长的东西有什么难度吗?

他又对我怒目而视。“不干。”

我几乎要放弃,让一个不太有经验的开发人员完成这个任务,但这次是个大生意。我知道如果这个电话搞砸了,负责这个客户的业务经理会倒大霉。问题不在于她会对失掉这次机会有多么生气。我的上司,CEO都不会高兴 – 这绝对会是个问题。

于是我打同情牌。

“德米,请考虑一下我的处境。如果我让一个经验不足的人去跟客户交流,那我是在给自己制造大麻烦。所有你要做的事情只是回答几个关于你最了解的东西上问题。这能有多难?除此之外,这个客户不是很懂技术。”

没有回应。我又尝试”Feel – Felt – Found”的说服策略。

“我完全知道你的感受。当我还做开发时,我的经理曾让我和一群用户坐在一起解释一个新的应用程序如何使用。我和你的感受是一样的 — 怕的要死。但是你知道吗?一旦我谈论起这个应用,我十分熟悉的应用,我发现根本没有什么好担心的。如果你真懂所谈论的东西,你会受到尊敬,被大家接受的。”

他只是摇着头。当他起身开始向我的办公室门口走时,他说:“抱歉,我的职责描述中不包括这个。”

于是,我只好抛出杀手锏。

“明年你还想去参加微软的Tech·Ed大会吗?”

德米停步了,开始犹豫。

“当然,”他含糊的说。

我笑了。

“那么,如果你帮我这个忙,给这个客户打电话,我会批准这个会议。”

当然,我很愿意批准去参加这个会议,但我必须等待下一年度的预算出来之后才能做决定。我很阴险吗?很烂的招?也许。

他很挣扎,好像肩头扛了一座山。“那好吧。但不要有第二次。

“成交!”

下午晚些时候,德米、业务经理、我围做着一个大会议桌旁,桌上有个麦克风,看起来像个小UTO。丹尼,我们的业务经理,拨通了电话。

我看了德米一眼,发现他脸色苍白。我看着他的眼睛,用鼓励的表情向他微笑。“你不会有问题的。简单回答几个咨询。”他紧张快速的看了我一眼。

客户接了电话。出乎意料,他介绍了第二个人来接这个电话。“希望你们不要介意,我让我的朋友杰尼来接电话。他对这类应用程序是个专家。”

丹尼大声说到:“完全没有问题,我相信他会对我们的软件留下深刻的印象的,欢迎他给出意见。”

丹尼不知道德米很紧张。当丹尼介绍完了之后,我小声对德米说“别担心”。我注意到他的腿子在桌子底下以每小时100公里的速度抖动。

这个客户,之前的电话中显得和气平易,这次一句话都没说。当听到他的“专家”顾问一上来就说“我下载了你们的试用版软件,说实话,我没有什么特别的感觉,”我的心一沉。

“数据库连接没有问题,但当我执行更新步骤时,跑了12个小时仍然没有完成。这完全不可接受,即使是针对夜间的批处理操作。”

一段尴尬的沉默后,我说,“真是抱歉。更新过程不应该超过1小时的。” 我看了德米一眼,示意他打个圆场。

德米做了个深呼吸,用他那柔软细小的声音说,“你肯定什么东西能错了。程序里不会有任何东西能让它耽搁这么久。”

我战战兢兢的听这个“专家”说道:“我可以保证,我绝对是按照信中的操作指令做的,而且系统满足软件的最小需求。我还必须说的是,我们处理的数据还不超过1gig。”

德米的脸上开始变红,嗓门也提高了。“如果你是安装我们的操作指令做的,那它一定不会有问题。”

丹尼立刻插了进去。“嘿,我们可以另外安排时间谈这个问题。我想我们今天主要针对软件功能特征。”“专家”回应道:“如果产品不能像承诺的那样运行,还有什么好谈的?而且你们的操作界面很不直观。

德米现在站了起来,握着拳头向前一步。“是吗,那你肯定不太聪明,因为10岁的都能毫无问题的使用这个界面。”

丹尼惊讶的张大了嘴巴。我赶紧插话,试图结束这场灾难。

“各位,各位,我们定个时间等销售工程师回来后看看你的安装,我们肯定能解决这个问题。”

我们的客户终于发话,让我们逃离了尴尬境地。“的确,丹尼,我想我们的观点不太一致。但还是要感谢你腾出来时间。”

就这样结束了。德米一脸痛苦,“我早就跟你说过”,他快步离去。丹尼只是坐在那里抱着头。

猜猜怎么着?后来发现所谓的”专家“是竞争对手派来的,蓄意破坏。丹尼承认这个电话从一开始就是个陷阱,因此才使德米做出看不合适的举动,这是一场必败的战斗。幸运的是,CEO没有把主要责任放在我头上。

至于德米,他想为此事道歉,我阻止了他。相反,我为不该把他推到他不愿意的处境而道歉。

总结:即使最出色的程序员也未必就有能力把他的知识传达到他的技术圈之外。德米的力量在于做架构和编程,不是客户交流。

从此我明白了,有些程序员有天生的技术交流的能力,但未必都适合销售的职务。德米回去继续写他优秀的程序、高高兴兴的参加他的大会,我再也没有要求他去跟客户交流。很显然,我很高兴他没有选择辞职。

[英文原文:Should Developers Be Allowed to Talk to Customers? ]
分享这篇文章:

10 Responses to 是否该让开发人员跟客户直接交流?

  1. zoujia says:

    我也是一个程序员,但我还是觉得有一点能力跟客户沟通还是非常有必要的,除非这个程序员永远给别人打工,永远活在自己的小圈子里,毕竟多接触一些人总是有好处的!

  2. 同意“zoujia”的说法,不过我个人感觉术业有专攻,如果真的是对技术有着强烈的追求,那么专心做好开发对他来说也是很好的

  3. gcyy0106 says:

    两者都是对的,关键看自己的兴趣,做自己想做的事是对的

  4. lfsfxy9 says:

    程序员,有好有坏,好坏也分不同的领域。

    所以,选定一个圈圈,做最优秀的,如果能再多一点优秀,那么这个圈圈会扩大。

  5. karl says:

    我觉得国外的例子跟国内不太一样,德米这样的大牛跟国内的大牛,我觉得不是一个层次的深入技术。

  6. james Lee 对这篇文章的反应是标题党
  7. 谢先生 对这篇文章的反应是赞一个
  8. 孙建明 对这篇文章的反应是赞一个
  9. shady 对这篇文章的反应是赞一个
  10. 111 对这篇文章的反应是赞一个

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据