客户亲和力
2006年7月28日
当人们在探讨是什么造就了一流的企业软件开发人员时,谈话往往会转向对框架和语言的了解,或者可能是理解复杂算法和数据结构的能力。对我来说,程序员或开发团队最重要的特质之一,我称之为“客户亲和力”。 这是指开发人员对软件所解决的业务问题以及生活在该业务领域中的人们的兴趣和密切程度。
客户亲和力有很多方面。 首先是对业务、流程和规则的兴趣。我一直着迷于我工作过的领域:医疗保健、衍生品、工资单、租赁——这些都是非常有趣的领域问题,具有很多需要组织和理解的复杂性。对我来说,对象关系映射、远程过程通信等项目方面——我认为是企业系统的“管道工程”,并没有那么大的兴趣。
团队必须确保“管道工程”正常运行并得到控制,但我相信,投入到业务问题中的精力越多,团队就越能有效地提供价值。 这就是使用尽可能解决和简化“管道工程”的框架的一个很好的理由。
客户亲和力的另一个方面是与领域专家合作的能力。我认为对程序员来说,详细的领域知识并不是一件很重要的事情;有用,但并不重要。 比知识更重要的是与拥有知识的人合作的能力。
我对客户亲和力的重视是我如此推崇极限编程和其他敏捷方法的主要原因之一。我发现一个非常重要的现象,当Kent Beck在创造“敏捷”一词的雪鸟研讨会上向他的敏捷同行总结XP时,他选择描述的不是XP的技术元素,而是他想要改变客户/开发者互动性质的愿望。
我经常听到人们对这种关系的错误描述。 特别是在某些方面,有一种观点认为,客户团队只是提出了他们抛给开发人员的故事。这种描述很像这样一种观念,即需求只是摆在那里等待收集。 无论哪种方式,这都不是什么合作。 相反,开发人员需要与领域人员一起工作,以产生想法,并在此过程中让开发人员更多地了解业务。
Kent对“敏捷”的建议名称之一是“对话式”软件开发——关键在于这是一种双向沟通。 这不像你可以定义的电信协议,而是关于软件如何增强业务的来回讨论,这才是真正价值所在。 这种对话的很大一部分是半生不熟的想法,其中一些想法会发展成有价值的功能——通常是客户最初没有想到的功能。
让我感到沮丧的一件事是,组织经常试图压制客户的亲和力。 这不是人们承认在做的事情,但它是其他决定带来的常见后果。 组织障碍可能会导致压制——我遇到过这样的情况:你必须让你的经理与另一位经理安排,这样你才能与业务部门的人交谈。 这几乎不会鼓励你深入了解业务的运作方式。
我经常听到有人说企业软件很无聊,只是在处理数据,有才能的人会做需要复杂算法、硬件破解或大量数学运算的“真正”软件。 我觉得这通常是由于缺乏客户亲和力造成的。 商业软件真正的智力挑战是弄清楚软件对企业的真正贡献是什么。 你需要良好的技术和业务知识才能找到答案。 与业务人员密切合作以发展这种知识,并在这样做的过程中取悦客户,这才是企业软件开发的乐趣所在——而动力是做好工作和高效工作的关键。
有很多聪明能干的人想了解他们为之编写软件的业务。 组织往往让他们很难做到这一点。 除非这种情况发生改变,否则我们的行业将继续无法充分发挥我们的潜力。
转载于2012年4月26日