客户亲和力

原文： CustomerAffinity    敏捷        2006年7月28日            Bliki 索引

当人们一谈起“具备哪些技能方可成就一名顶级的企业软件开发者”，话题常会转入“要掌握框架和语言”，或者“要能理解复杂的算法和数据结构”。依我之见，不论是对一名程序员还是一个开发团队，最重要的品质却是另外一样东西——我称之为“客户亲和力”——就是看开发者有没有兴趣密切地关注软件所要面向的业务问题以及那个业务领域里的人。

客户亲和力体现在多个方面，第一就是对业务本身的兴趣，包括各种业务流程和业务规则。我做过不少领域的工作：卫生保健、金融衍生业务、薪资管理、租赁业务等等——我被深深吸引住了，它们都充满了十分有趣的领域问题，需要理出条理，真正理解之后才能解决。在我看来，诸如O-R映射、远程进程交互这些方面对于一个企业应用系统就好比是供热供水的管道工程对于一栋大厦一样，它们对我的吸引力与前者是不同的。

一个团队能把管道工程干得漂漂亮亮固然重要，但我认为，在业务问题上投入的精力越多，这个团队就会越有效地彰显自身价值——这正好解释了为什么一个问题只要属管道工程之列就宜借框架之力来简化、解决。

客户亲和力的另一方面是与领域专家协作的能力。在我看来，程序员们并不需要像那些专家们那样精通领域知识，详尽的领域知识对程序员有帮助，但并非最重要的——更关键的是与具备那些知识的专家们良好协作的能力。

我对客户亲和力如此的重视，正是我那么爱好极限编程和其他敏捷方法的一个主要原因。在“敏捷”这个“新词”诞生的Snowbird讨论会上 _{（译注1）}，Kent Beck向其他同好总结XP的时候，他选择描述的并非XP的技术方面，而是他对转变客户与开发者之间交互的原本特性的期望。

对于客户与开发者之间关系，我常听到种种不恰当的描述，尤其有一种错误观念认为：那无非是客户们想出一些需求，再把它们丢给开发者；与之相反相成的，还有一种观念认为：需求都摊在那里，得由开发者们自己去收集。这两种方式都没什么交互协作，取代它们的应该是：开发者要与领域内人士协同工作，在这个过程中了解业务问题学习业务知识，同时产生设计思路。

Kent为“敏捷”这一概念提供的名字之一叫做“交谈式软件开发”——其着眼点即软件开发是一种双向交流的过程。这与电信协议之类的东西不同，后者你可以定义出来，而前者强调的是：双方就“软件如何促进业务”这一问题有来有往的讨论体现了真正有价值的东西。这种讨论得出的想法常是半成熟的，其中有一部分可以演化成颇有意义的特性——而这一部分往往并非客户最初所考虑的东西。

一件让我失望的事是：客户亲和力的发展常受到来自组织机构的压制——尽管有些人不承认那么做了，但那常是其他一些决策的直接后果。例如，机构之间的界线常起到压制客户亲和力的作用——我见过不少地方，你要想与业务方面的某某人交谈，就先得告诉你的经理，让他再与对方经理沟通好，这次交谈才可能实现 ——这种沟通障碍怎么会不打击你探究业务问题的积极性呢？

我经常听到人们说做企业软件枯燥乏味，无非是把数据传来传去，真正有本事的人得做真正地道的软件——需要很炫的算法，还得死磕硬件，没准还有满篇的数学。我觉得发生这种情况通常就是由于缺失了客户亲和力。企业软件开发对智力水平的真正挑战来自：对某一业务领域，如何弄清软件在哪些地方能产生什么样的实际贡献。要做好这件事，扎实的技术功底不能少，齐备的业务知识也不可或缺——与业务人员密切合作以积累业务知识，在此过程中 取悦你的客户，企业软件开发的乐趣就在于此——另外，激励机制是使工作做得漂亮、团队富有生产力的关键所在。

许多聪明且有能力的人都希望了解他们编写的软件要服务的行业，但无奈各个组织机构频频为此设置障碍，只有这种状况改变了，我们的职业才能持续地体现出我们的潜质。


_{译注1：详情参见http://agilemanifesto.org/history.htm}