作者：AWS企业市场战略总监 Stephen Orban
“客户并不关心我们了解多少，而只关心我们有多在乎。”
——戴蒙·理查兹
正如我在本系列文章的上一篇中所言，客户服务正是企业机构在实现DevOps文化过程中所必须重视的三大基本原则之一。
如今的世界充斥着各类技术解决方案。无论我们抱有怎样的需求，都能够在市场上找到大量足以起效的方案选项。对于那些专门负责交付技术解决方案的朋友，良好的工作成果意味着我们不仅需要提供出色的产品，同时也要提供理想的客户服务。客户服务的水平越高，客户从竞争对手处物色替代性产品的可能性也就越低。
从传统意义角度看，客户也就是那些购买我们产品及服务的群体——他们可以是Amazon.com网站上的购物者，也可以是使用AWS方案的企业受众。
而在企业IT内部，我们的客户往往正是自己身边的同事。作为内部相关者，他们可以是企业中的任何一位成员，且需要借助技术方案的力量来完成自己的日常工作。有时候他们来自其它业务部门（例如市场营销、销售或者其它团队），而有时候他们自己也同样属于技术人员。
那么在内部DevOps体系当中，到底是谁在消费相关产品及服务呢？当然，具体答案需要具体分析，不过通常来讲应该是企业中的应用程序开发人员及其它技术团队，因为加快产品开发速度正是集中式DevOps所要实现的首要目标。相较于传统模式下只关心自身所面临挑战因素的队伍，能够与各个部门协作并征求其意见的集中式团队将能够更为准确地预测出客户需求，从而拿出更理想的客户服务方案。
在企业当中，至少有以下两大重要理由支持着我们将客户服务作为优先考量：
1.以客户服务为核心的机制能够改善IT品牌效应
二十年前，企业技术体系由且只能由IT部门负责支持，那个时候技术就是复杂性的代名词。曾几何时，从业者需要具备丰富的专业知识储备才能顺利搞定相关工作。而且与主张“谁构建、谁运行”的DevOps文化不同，当初的企业倾向于将这部分权力集中在少数人手中，只有他们了解如何购买及部署技术方案。这就意味着IT客户——具体来讲，也就是企业中的其他成员——在满足自身IT需求时几乎没有什么选择空间。
不过时至今日，客户已经拥有更多产品及解决方案，且足以顺利应对自己的实际问题。技术的消费化趋势正不断凸显，越来越多的普通员工正以前所未有的热情使用计算机、智能手机、网站以及应用等手段在家庭或者办公环境当中处理工作。这种趋势也彻底改变了技术领导者看待客户服务的方式——特别是着眼于企业内部环境。
根据我的个人经历，当人们发现了一种更为便捷的工作进行方式时，他们往往会不假思索地加以运用。而如果他们无法从IT部门处获得所需要的服务，则会将寻觅的目光投向他处。如果IT部门无法快速提供对应的审核版本，编辑部成员可能会从网站上直接下载新型编辑软件。人力资源部门可能在内部日程环境之外寻求其它规划工具，而市场营销团队则可能雇用第三方对品牌网站进行重新构建。技术业界将这种作法统称为“影子IT”，这种趋势将使大规模IT环境下的管理与安全保障工作变得难以实现。不过从实际角度分析，影子IT之所以客观存在，其核心原因在于IT部门所提供的方案并不能让内部相关人士满意、或者后者不知道该如何从IT部门处获取自己需要的技术支持。
建立一套以客户服务为核心的集中式DevOps体系往往能够很好地解决以上难题。当大家设身处地为客户着想时，我们就有能力理解他们的需求及关注方向，并思考如何解决这些需求并将解决举措融入企业整体。不要简单粗暴地表示“你不能用这种方式处理工作”，而应该询问“你想达成的目标是什么，我又该如何有效地帮你解决问题？”每当应用程序团队实现了某项DevOps原本无法交付的成果，后者都可以从中学习到具体实现方式并意识到自身的不足之处，进而思考是否该在未来的工作中作出针对性调整。DevOps团队能否通过一系列努力来满足未来可能出现的需求？在多数情况下答案恐怕会是否定的，不过有时候我们也确实能够做出一些尝试——但企业应当对此类变更进行认真评估。无论如何，如此一来IT部门将逐步成为企业当中的“实现者”、而非业务人员传统印象中的“拒绝者”。通过这种合作方式，内部客户将更乐于同DevOps员工并肩战斗、而非主动避开。
2.以客户服务为核心的思维方式有利于职业发展
在DevOps模式当中，应用程序团队需要同时负责运行自己所构建、拥有的技术成果以及客户服务。我很幸运地在自己效力过的每家企业当中，都亲自接触过其关键性绩效指标。这正是彭博公司的核心价值取向之一，我们也将这种思维引入到道琼斯的IT部门内，并最终将其作为Amazon公司的领导原则之一。
所谓拥有关系，可以理解为任何对某款产品或者服务负责的个人都应当将该产品或者服务视为自身业务的一部分。产品与服务可以体现为任何形式，包括网站、移动应用程序、企业电子邮件服务、桌面系统支持、安全工具、CMS或者其它任何可以交付给客户的解决方案。
这种拥有关系会带来更为出色的客户服务效果，因为它将责任与信誉与相关产品监督者直接挂钩。反过来，对应的员工也会因此而受到激励，从而更为积极地倾听他人意见、了解潜在的替代方案并不断探索产品该如何实现深层改进。当问题出现时，负责对应产品的员工不能简单地“推卸责任”——他们有意义了解问题的出现原因，并为相关客户提供帮助。
而个人职业生涯的收益也恰恰体现在这里：每个人都希望拥有属于自己的一款产品，并为其保持良好的客户合作关系，这同时也将帮助企业赢得可靠、值得依赖且坚实稳定的声誉。
这还仅仅是客户服务如此重要的两项理由，在规模更大且复杂程度更高的企业中同类因素还有更多，特别是对于那些正在考虑采用DevOps机制的企业而言。大家对此有何高见？请在评论栏中与我们分享。
革命尚未成功，同志们还要多多加油！