最近给高管领导做了一项平台架构的年度方案汇报，受到了高管及其他相关团队领导的肯定，赢得了领导们对方案的支持。

  但是经过这一次高强度的汇报，大约持续的4小时单人SOLO后，对于汇报有了一些更底层、更通用的认知提升。

  在影响力层面，汇报往往是让领导或者更高层领导，了解并支持你的工作的主要或者唯一手段，同样也是你提升组织影响力的重要途径。

  在具体方案层面，优秀的方案能够赢得相关领导的支持，在组织层面认可后，各个层面基本上没有阻力，并且可能取得授权、资源预算。

  如果说我们的工作也符合帕累托定律（即著名的二八原则），那么“汇报”肯定属于最终的20%。

  网络上流行嘲讽“干活的不如画PPT”的，有一定的道理，我们要吸取经验的是，主要提高个人对手业务领域的思维认知，而不是纯粹的画酷炫的PPT页面。

  俗话说“人靠衣裳马靠鞍”，汇报的PPT起码不要“丑陋”，起码在中等水准以上。

  毕竟人都是感性动物，过于“丑陋”的展示肯定回产生副作用，当你汇报对象强忍着对展示的“审美”批判时，就产生了精力消耗。

  只要收集一下组织内，属于你要汇报的层次的一些汇报模板，拿过来直接复用就好了。

  笔者也曾经非常头痛这样的一个问题，甚至专门花费298元购买了一些PPT培训课程，当然下载了其提供的一些素材模板后，就放在电脑中“吃灰”了。

  我们要做的是“汇报”而不是“PPT”，所以要有意识的积累日常工作中的一些素材、模板。

  尤其是对于程序员来说，在PPT方面如果自由发挥，一般都是“越修改，越丑陋”。

  对了，这句话来自许岑的keynote教程，他给老罗做演讲幻灯片，也是笔者当时挣扎着想要提升汇报能力时学习的诸多课程之一。

  这句话让笔者发现了自己的“审美”以及精力，完全不可能也没必要成长为一个PPT高手后，笔者转换成“拿来主义”。

  并且，后来发现最终提高个人“汇报”能力的，反而是李运华的下面的一本书，他讲解的是晋升答辩，但是里面的汇报原则却非常通用，笔者写年终总结或者绩效事项的时候，一直在应用。

  以笔者在金融科技领域做架构汇报的经验来说，刨除个性化的业务领域，在逻辑架构组织上有下面很重要的四个大原则。

  在架构方案领域，“总”一般包含业务背景、技术现状两方面。“分”指的是通过背景现状的分析，发现要达到“目标架构”的“关键举措”。

  我们知道对公司架构来说，BA业务架构是一切的蓝图基石，我们的AA应用架构是基于BA的，所以一定要先讲述业务背景情况。

  同时，高管分管的条线领域非常多，这一部分还能将高管领导的思维限定在这一部分业务领域，避免过多的发散问题。

  笔者习惯在PPT一开始页面后，来一个背景综述，讲述一下本次方案汇报的背景原因，以及希望达到什么目的。

  引导大家聚焦进入汇报内容，避免大家莫名其妙，在没有背景限定的情况下，产生各种个性化的理解与疑问。

  要包含当前平台/系统/领域的文字概述，当前应用架构图，以及结合上面的综述，说明通过现状发现的问题。其中A1\A2等标号，是应用架构层面发现的问题。

  发现了当前存在的问题，接下来应该提出来对应的关键举措，以及最终的目标架构情况，为了面显的体现变动情况，要上上一个现状分析页保持元素摆布一致。

  在进行关键举措以及目标架构的讲述后，接下来应更进一步展示当前的系统模块与目标系统模块的变化情况。

  例如上面的技术概览中，我们先讲了当前现状与问题，自然就引出来要处理问题的关键举措，实施这些举措之后，我们要达成什么样的目标架构。

  例如，如果是运维的领导，关心的是日常运维风险与工作量，那么着重体现的就该是系统下线整合，降低运行风险。

  上文提到过，笔者是一个坚定的“拿来主义者”，反对自己从头开始搭建每一项PPT的页面元素。

  每一页的标题建议都用黑体，正文内容用楷体，图例颜色要备注好，体现专业性。

  对于同一样颜色，同样的元素（矩形、虚线框等）要表达在同一层次的内容，也是所谓的“同一逻辑抽象层次”。

  在应用架构汇报方案中，非常常用的就是对比法，当前的系统模块情况、应用型架构情况，我们的目标架构情况，形成显示的对比。

  首先，这个逻辑框架蕴含着汇报者对整体的领域的认知，在组织汇报材料的时候，可根据这几个方面做组合裁剪，汇报的时候也给人一种条理分明、逻辑清晰的感受。

  其次，通过符合人逻辑认知主线递进与层层拆解，减少被汇报人的认知负担，减少个性化的思虑疑问。

  汇报过程，其实就是一个对被汇报者的思维梳理过程，很重要的一点，不要把对方当做一个“领导”，而是当做一个“合作者”，大家一起来推进完成这件事。

  还是要强调一点，这种汇报框架的适用边界是笔者的应用领域“金融科技”领域的架构方案汇报。

  所以，一个最重要的经验，却无法量化出来的，是打破各种自我设限、别人建议的框架。