很多研发人员对于汇报这件事比较恐惧，一直做不好，今天聊一些关键点，让你做好技术汇报。
首先目标导向，一个技术汇报的目的是什么？
简单总结来说，目的是：高质量的内容，高效的信息传递。
整体汇报结构可以以下面几点作为要求。
首先起好标题，标题是中心思想，ppt的每一页，用一句精简的结论或观点概括本页想要表达的主题，一目了然，降低受众理解压力。
结构化采用金字塔原理的四段论，问题定义，问题分析，解决方案，最终结果。
对于关键的要表达的内容和观点，要加粗、描红，让人一眼看到它。
要化繁为简，可以关键词先行，不要长篇大论，大段文字给人极大的阅读负担，可以加上上下文解释。
数据先行，有数据讲数据，没数据讲案例，没案例讲感受。
不要一文走天下，要有听众视角，区分听众做修改。
切记流水账、面面俱到，要结合目的重点突出。
不要做成业务汇报，要聚焦技术的价值体现。
不要报喜不报忧、只讲成果，有质量的反思更能体现思考力。
不要只讲 how，要讲 what 和 why。
不要只定性，能定量尽量定量，这样才能牵引众人。
听众视角
首先要有听众视角，区分听众，基于听众视角判断关注点，有的放矢。
面向高级别领导汇报：比如cto、事业部总经理、ceo要结论先行，逻辑自洽，论据充分，格外注意不要啰嗦。他们的认知能力和快速理解力，远超你想象。
面向主管汇报：通常主管对于你的工作背景和内容都已经比较熟悉了，应侧重how，对几个关键的技术点讲透，从方案对比，技术选型，技术挑战，解决方案，实现效果几个维度展开阐述。以okr作为主线比较合理。要突出因你而不同、功劳而非苦劳、反思总结。
面向团队分享：侧重整体性，帮助团队所有成员很好的理解组织目标，团队大图，各部分的关系。全面性，涵盖团队的主要工作，让大集对自己工作成果有成就和参与感。有态度有判断，敢于点出不足和短板，有深刻的反思和动作，清晰明确的传达给团队要和不要。
要重点突出
很多人喜欢面面俱到，而不是重点突出，习惯做加法而不是减法。
事情无非这几类：
- 重要且紧急：必须要攻克的难题，高价值，承诺型；
- 重要不紧急：这种往往短期价值被高估，长期价值被低估，长期主义，日拱一卒，坚持投入；
- 不重要不紧急：往往可以归类为苦劳一类；
因此要重点去讲重要且紧急和重要不紧急的部分，不重要不紧急的可以完全不讲。事情的多少不重要，做得好才重要。
聚焦于贡献而不是苦劳
技术人作总结，往往陷入一种误区，就是过多汇报产品或业务的结果。以至于难以或忘记了表达技术的贡献。
业务成功要讲，这体现技术贡献度最直接的维度，需要注意的是，不要过度讲，要考虑技术相关度。因为业务做得好，不代表技术做得好，业务做得不好，技术可能也做得不错。
技术人要想讲好技术贡献，首先要清晰的理解业务问题，并且转变为技术问题，通过自己的专业能力，解决技术问题，进而解决业务问题。
如果问题定义清楚了，就能够容易的讲清楚技术贡献，以及技术与业务成果的关系。
要有反思总结
年终总结切忌变成庆功会，只讲成果。高质量的反思同样重要，他会促进个人和组织的成长，也可以表现这个人的思考力。
想要有质量的反思，可以多对自己提问，提高自己的判断力。
情景分析法，当时是什么情景，任务是什么，行动是什么，结果是什么。通过以上四个维度将一件事情重新回顾、复盘，分析哪里再做一次的话，可以改进或者优化的，复盘是很有用的一个思维模型。
反思的目的是为了改进，如果反思的结果能够落地成PDCA循环，大概率是一个有质量的反思。
不要只讲how，要讲what和why
当专注做一件事的时候，往往会不自觉的被各种细节束缚，埋头赶路也要抬头看路，年终总结是一个很好的跳出细节，重新思考的机会。
上面说了，如果受众是主管，可以侧重讲how，受众是跨级别主管，侧重讲what和why。
How的讲解要化繁为简，不要面面俱到，不要罗列堆砌，要抓住重点，化繁为简，这是一个架构师的核心能力。
不要只定性，要定量
很多同学缺少数据思维，不习惯把目标或收益数据化。
能够把成果定量，更容易理解和令人信服。
定义指标：先找到一个合理的指标来衡量事情的进展和效果，这是最难的。给的建议是，要知道任何一个指标都只是事物的一个视角而已，不要追求完美的指标。
定义基线：基于上述指标，确定某一个时刻或状态下的值，这就是基线，是后续对比的基础。
持续跟进指标变化：有了指标和基线，通过不断的优化，观察指标变化，总结问题，解决问题，使得指标持续向好。
指标可以随着认知和外部变化而迭代：指标随着目标、方向、环境的变化而变化。
不要罗列数据：不要念数，要体现出数据背后的分析结论，也就是，这些数意味着什么。
批判性思维
为了写出一个别人看得懂，认可的报告，需要自己向自己提问。
Why、why now、why us。这对我们日常分析问题很有帮助。
如果想的透彻清楚，你不仅可以做一个高质量的总结，也代表了你具备强大的洞察力和思维力，你的成功是可以复制的。
通过灵魂拷问，不断的让自己对事物的理解变得清晰，这是认知深化的过程。
可以问自己这几个问题：
- 问题定义：为什么做这件事，要解决的到底是什么问题，这个问题真的需要被解决吗，不解决会怎样，为什么需要现在解决，明年解决会有什么问题，为什么是我来解决，有没有其他更合适的人。
- 价值拷问：这件事的收益是什么，投入是什么，产出是什么，成本收益如果换算成钱会怎样，ROI怎么样，我在过程中的取舍是什么。
- 找到不一样：核心的技术挑战是什么，我通过什么样的方法解决了，这个方案的缺陷是什么，业界或其他团队有没有解决过类似的问题，他们如何解决的，我的方案和他们有什么不同，优劣是什么。
什么是技术挑战？
很多技术同学在复盘自己做的事情，觉得找不到技术挑战。
因为在他们脑中有个定式，就是没有几十万qps好像就不算技术挑战。
除了高并发、高可用，技术挑战也有很多：
- 简化领域复杂度：一些领域具有一定的复杂度，特别是营销、供应链等系统，他的技术调整在于对领域复杂度的抽象。优秀的业务理解和领域建模能力，会带来业务价值，模型设计带来的灵活性和扩展性，对效率的提升和迭代有帮助，这就是技术的贡献和亮点。
- 降低链路复杂度：如果可以把全链路梳理清楚，找到薄弱点，甚至简化优化链路，带了稳定性和协同效率的提升，难度很大，也是有技术挑战的。
- 降低成本：通过技术手段降低成本，比如通过冷热分离，冗余膨胀数据治理，合理的算法和优化降低qps带来的资源，这些都是技术价值。
- 提升效率：通过工具、框架、低代码、配置化等手段，提升团队的研发效率，或者通过机器人等解决解决效率，都是通过技术手段解决繁琐的劳动，这也是技术价值。
- 提升质量：bug数少，系统更稳定，这也是技术的价值。
- 简化方案：很多人擅长做加法，但很少人擅长做减法，如果可以通过取舍、调研、对比、验证得到一个非常简单的解决方案，解决了业务问题，这背后也是技术思维的胜利，也是架构师的关键能力。
希望你变成一个写文档的高手。
