平安壹账通吕书峰：架构师要具备「讲故事」的能力

吕书峰目前在平安壹账通担任核心系统产品及研发负责人，拥有超过 20 年的银行核心领域技术研发和产品管理经验，曾担任包括在香港的虚拟银行系统建设在内的多家数字银行项目的总架构师。

在 7 月份的 ArchSummit 全球架构师峰会（深圳站）晚场交流活动上，吕书峰和其他几位技术专家聊到架构师成长之路的时候，大家都有一个共同的感受，那就是很多优秀的架构师沉醉在底层技术工作；而有的架构师偏应用，能讲出很好的故事。其实这两类架构师，业界都需要。但是很多架构师还是缺乏讲故事的能力。

毋庸置疑，如果你想要更快的提升职业高度，具备会讲故事的能力可以更好的帮到你。当然，能终身以技术架构为业也是令人幸福的选择，即使如此，非技术因素往往和技术因素交织，用更易懂的故事语言讲清楚技术思路，也能在解决复杂问题的时候事半功倍。

接下来，就通过几个小故事开始，以吕书峰老师第一人称的口吻讲述他的观点，希望有助于你理解，也希望你能够从中有所启发。

说服客户

金融软件系统的要求是高可靠性，高稳定性，同时也要做好损失其他某些要求的取舍。但也有追求完美的客户。我之前做某一海外项目，有位客户的数字银行业务，期望在新加坡和香港做到数据中心的异地双活，换句话说，双机房在一定负载策略下要求双路可用率指标达到 99.99%。很多有经验的银行业架构师都清楚，针对银行的业务系统的事务型模式而言，尤其是我们还没有成熟可用的分布式关系型数据库的时候，这一要求很难，或者即时能做到，成本也是很高的。

其实呢，我们所接触的这家客户的 CTO 是一个分布式微服务架构的理想主义者，通晓相关架构原则的方方面面，在跟他的交流过程中，我发现他有个很可人的特性，如果某件事说到他心里去，他会替你把剩下的话讲完，你只需要表达充分认可就能博得他的赞赏。

针对那个远超成本的期望，我并没有急于反驳，我和对方讲了我们自己的过往经历，踩过坑，吃过亏，流过血，我们的技术架构选型遇到过哪些问题，如何为业务赋能等故事，客户也听的津津有味。同时，我还向他们介绍国内银行（海外颇为认可中国技术应用的先进经验）是怎么做的，出过什么问题，他们很惊讶，原来还有这么多复杂的麻烦事。后来我们和他继续谈了蛮久，最后客户妥协了，接受了我们国内通常主流的同城双活和远程灾备的方案。

客户也讲了自己很多业务上的痛点，但是我发现他提到的痛点，和双活架构关系不大，而是业务领域的问题，业务运营、交互上的问题。我就知道了他真正的痛点是什么。

我又找到了他们掌管业务运营的 VP，银行的 CEO 去沟通，侧重点沟通是业务运营，效率提升，业务改进上。作为行业里的架构师，如果你的经验丰富，能找到共同语言。回过头来再做对应的解决方案，很清晰的以问题为导向的思路，告诉他在产品上，基础设施上，分别配套的解决方案是什么。因此，最终定稿的从业务顶层出发到基础设施建设的完整方案成功获得了一致认同。

这个案例也给了我一些启发，尤其是在沟通层面，技术专家面临这样的问题，要了解问题的本质，这需要架构师有深厚的知识积累，和技术积累，我个人一个自我要求是，每年读 20 本专业图书，我也建议各个行业的系统架构师每年都能通过更广泛的系统化专业化的读书积累，避免碎片化阅读，深度积累行业知识体系，不管当下是否有用，但是以后一定能派得上用场。

要有业务意识，我自己作表率

另外一个 case 是，和业务层面的沟通，技术人要有业务 sense，这也是老生常谈的话题。

我之前接触过一个香港的客户，当时我们主要是给他们提供一些资金系统上的技术支持，当时有一个契机，要给他们提供技术平台升级的服务，一年的合作费大概几十万美金。

全世界都在说数字化转型这个趋势，他们的业务需求依然相当的传统，我就和客户说，你们是不是要结合现在数字化转型的大趋势，做一些准备，应该会对业务、技术有一些帮助。我还把数字化转型后会有什么样的产出，用户体验会有哪些变化等等都告诉他。当时客户就说，好啊，你可以出个方案，我们看看。我前前后后花了两个小时，收集了香港当地做这类服务的案例，做了一个 PPT 给他，讲了现在数字化转型的必要性，可能会存在哪些技术需求。他就把这个 PPT 故事讲给他老板听，正好他老板当时也苦于不知道数字化转型该怎么做的时候，看到这个 PPT 后，很爽快就同意了，继续采纳我们的服务，并多给了 60%的预算。

架构师要有意识的去找业务上的需求点，能主动的站在客户的角度。当然，要不断的积累，把握住机遇。我个人认为架构师还是很有优势的，因为架构师代表了一个受人尊重的专业人士形象，大部分人是愿意听你的新思路的（但很多时候听不懂，别人听不懂是你的问题）。所以，架构师要力图避免别人对你敬而远之。

鼓励团队成员「讲故事」

我现在也在带团队，因为产品线的目标很大，所以需要很多人协助才能达成目标。

不管是对内要提升大家的能力，还是对外要不断的赢得客户的认可，产品是否能不断的改进用户体验，这些都是需要寻求各方面资源的加持。既要启发激励工程师做更多的探索，也要鼓励他们讲故事。

但是，我发现有些年轻的架构师或工程师不擅长做投入产出评估这件事，经常有拿不出像样的评估结果出来。比如说，我们需要快速的做一个小项目的成本评估，他会说我要仔细了解需求细节，甚至说要分析相应的代码，但是即使我给他足够时间，往往也给不出准确且让人满意的结果，可是我可以一拍脑袋就得出一个大体可用的结论。

后来，我就和他们说，这里面有窍门，不用那么精准的数据。我偷师了 Jon Bentley 的名作《编程珠玑》中的粗略估算一文（好吧，这本书可能暴露了我的年纪），把密西西比河换成我们的黄浦江并略作修改：如果我们要估算黄浦江入海口每年带入海里的泥沙量是多少？ 我坚持要大家在无专业背景的条件下思考这个问题。我就和他们去讲，如何做预估。很简单，就是常识加上数学运算。一个启发是：先做假设，一天多少拖沙船，每艘船大概拖沙多少顿？水流是多少？或者设想用一杯水做沉淀，最后你觉得水清澈后杯子底部有多少泥沙量（读者可以继续下去）。虽然结果不精确，但是在一个大体数量级上是很有希望的。我就是希望大家动脑筋，对误差的认识，有一个基本的判断。

在软件工程业务领域，常做一些工程评估，快速的预估出一个数量级，这在管理当中，是一个很有用的技能。 

会讲故事，才会有惊喜

会讲故事的架构师，尤其是在应用行业，获得认可的机会更大，不管做上层设计还是解决具体技术难题都容易获得更多支持。

在垂直的技术领域，讲故事的方式和技巧，决定了他和团队沟通协作的效率，很多技术人都是这样的。上面提到 Jon Bentley 是个讲故事的高手，他以及他的著作带出了多少大师级的学徒啊。Martin Fowler 的演讲和著作总是娓娓道来，像讲故事一样，而他确实很有故事。甚至 Knuth 的算法习题里都有不少津津有味的故事设计。不用说，满天飞的商业计划书之类的所谓规划（鬼话）不都是各种故事吗？哎吆，有点跑题了。

总之，能讲故事，和不能讲故事，差别是很大的。如果你想不断的突破，扩大影响力，毋庸置疑，需要你会讲故事。哪怕是在相对安静的技术领域，成为一流的专家，需要会讲故事，才能让更多的人从你这里获益。 

【活动推荐】

业界像吕书峰老师这样的经验之谈，其实有很多，架构师不仅仅要会讲故事，还要掌握很多软技能，判断力、独立思考能力等等。9 月 26-17 日，我们会在杭州举办ArchSummit架构师会议，邀请了阿里、58 集团等公司的资深技术专家来讲讲他们的职业技能提升之路，给你提供不一样的思路。感兴趣的可以点击【阅读原文】，查看会议日程。购票可以联系瑞丽 18514549229（同微信）