如何做好一次技术分享
分享自己在团队中做技术分享的套路，涵盖明确目标、圈定范围、制定大纲、编写内容、幻灯片准备等全流程方法论，以及介绍性、实践型、原理分析型三类分享的侧重点。
- #tech-sharing
- #presentation
- #writing
- #methodology
一、引言
我们在团队里面经常会做一些小的分享，通过技术分享，我们将自己的知识传递给其他人，这是一个对自己对团队都非常有益的事情。但同时我也会发现一些同事在做分享的时候，不知道如何来准备，通过这篇文章我希望把自己做分享的套路和大家分享一下，希望能对大家在接下来内部的分享活动中有帮助。
一般分享会有两种常见的形式：
- 技术文章
- 公开的演讲（有点像脱口秀？）
后者的难度是更高的——技术文章要做的准备一个不漏，而且还要准备好情绪面对大家的好奇脸。不论是哪种形式，我准备分享的套路大致都是这样的：
- 明确目标
- 圈定范围
- 起个好主题名称
- 制定大纲
- 编写文章 / 演讲稿
- 整理实践代码（如果需要的话）
- 选配图 / 写 Slide
Prep Flow · 七步准备
从「想讲」到「能讲」的流水线
- 01明确目标Goal
- 02圈定范围Scope
- 03起好主题Title
- 04制定大纲Outline
- 05写文稿Draft
- 06整理代码Code
- 07配图/SlideSlide
二、准备流程详解
2.1 明确目标——首先要清楚想讲什么
前期的准备是很多的，首先最重要的就是明确自己的目标究竟是什么——想讲什么？后面准备内容的时候总是来核对一下是否符合自己原来设定的目标，不然分享的内容就容易跑偏。
Target Lock · 对齐目标
先把靶心画出来，再让每一句话瞄准它
2.2 圈定范围——不要试图讲全
确定好明确的目标之后，就圈定自己要分享的范围。自己想讲的一个东西可能涉及的内容会非常多，所以一定需要给自己一些限定的条件，不要试图讲全，讲贴合目标的重点内容。
比如讲 Redis 的集群构建，就不要太关注 Redis 的数据结构，聚焦在 Redis 的哨兵、集群等知识的核心即可。
Scope Focus · 圈定范围
不要试图讲全，圈出真正要讲的那几格
2.3 起个好主题名称——用标题立 Flag
在圈定完范围之后，就可以给自己起个好名字了。通过一个简短有力的主题来表达自己要分享的内容是非常重要的。通过一个标题给自己立下一个 Flag，明确这个主题的核心价值，大家就可以提前了解你想表达的内容，也好准备与你进行互动。
举个例子，有两场关于 Redis 集群的分享，标题分别是：
- A: Redis 集群技术分享
- B: Redis 从单机到规模化部署的实践
哪个标题可以更加吸引你的注意？"Redis 集群技术分享"是一个模糊的概念，不知道是去分析 Redis 的原理还是配置；但第二个标题就明确了自己的目的和分享的内容类型。
Redis 集群技术分享
Redis 从单机到规模化部署的实践
同一场分享，标题不同，读者点进来的概率差出几倍 —— 标题就是把旗插在读者注意力上的那一刻。
2.4 制定大纲——搭建内容骨架
在有了以上的标题和范围之后，我们就可以围绕它们来制定大纲，把要写的范围分步骤逐步罗列出来。最终按照这个大纲来填充每个部分的内容。这样的结构下，自己分享的内容就比较好掌控、不容易跑偏。
- ■分享主题一句话定边界
- ▸背景与问题为什么要讲
- ▸方案与取舍怎么做的、为什么这样
- ▸踩坑与权衡代价是什么
- ·· 范围上限明确不讲什么
- ▸收获与下一步听众带回去什么
先把骨架立起来：边界、章节、不讲的范围 —— 骨架定型之后，往里填内容才不会跑偏。
2.5 从抽象到具体——和写代码一样的套路
从以上的套路可以看出，准备的过程是由抽象到具体的过程，准备的内容是越来越具体的。这就有点像在写代码：
- 先做需求和用例分析
- 识别我们需要的功能范围
- 分解功能和接口
- 编写具体的方法实现
套路基本都是一致的。
⇄同样的套路 —— 从抽象走到具体，是工程化做事的通用节奏。
三、关于幻灯片
刚刚说了，演讲是比文章更加难一些的，原因也是因为准备一次演讲，除了像文章这样组织讲稿之外，还要多一步——整理幻灯片。
幻灯片应该根据我们的讲稿来进行构建，紧贴内容。分享的内容才是核心，讲稿的内容才是主体，幻灯片只是对这个主体的一个补充形式，而非主体。
在幻灯片上应该用尽量少的文字，用一些关键信息来获得听众的注意。不要在上面放大量的文字——复杂的文字需要理解，可能等大家理解到一半的时候，这一页就过去了。
核心的内容应该是讲出来的。同时演讲的过程也要相对简短有力——听众无法通过很短的时间就明白自己学习了很久的知识。可以通过一些比喻将内容简单化，让其他人快速 Get 到重点。
四、分享内容的三种类型
除了形式之外，我们还可以对分享的内容进行一些分类，我大致将内容分为这样几类：
4.1 介绍性分享
介绍性分享会介绍大家接触比较陌生的东西。这一类分享要注重让人产生足够的兴趣去探索这个东西，主要就是：
- 把这个组件 / 思想要应对的问题和使用场景讲出来
- 简单讲讲它的概念，是如何解决当前问题的
- 在结束之后可以准备一些延伸阅读的材料给大家
4.2 实践型分享
实践型分享就会实在很多——就是自己具体顺利解决一类问题的套路。这个套路应该是完整的，大家能够完整了解整个实施过程的文档，可以快速地进行重现。
所以这类分享的重点一定是实施的步骤，要把每一步都讲清楚，里面的概念澄清。可以提供一个代码库，让大家在结束之后自己能尝试。
4.3 原理分析型分享
原理分析型分享是有一定难度的：
- 分享者需要对其有非常深刻的认识，不然容易讲得晦涩难懂，令人失去听讲的兴趣
- 受众可能非常小众（公众号上往往那些简单的"快速入门"阅读量很大，但"深入理解 xxx"的这种文章却只受到很少的关注）
这种分享一定要想办法降低技术的门槛，把一个复杂的技术通过一些比喻、拆分讲得简单好懂。而且一定要去尝试转换成与大家日常工作息息相关的内容。
比如去讲 MySQL B+Tree 的结构——这个内容看着其实挺无聊的，但是结合 explain 来讲 B+Tree 和调优的关系，就可以让大家产生一定的兴趣，让这类原理性的知识具备可操作性。
五、最后的准备与心态
在完成以上的内容之后，内容就准备完了。如果只是一次文章的分享，那么可以准备好把文章发布出来等待反馈了（一般这个时候是会有一种莫名的成就感）。如果是演讲类型的分享，那么这种情况下还需要自己反复地阅读稿子和核对幻灯片，在跟大家分享之前，自己做足够的准备——比如对着镜子给自己讲一遍，消减自己紧张的情绪。
- 稿件script
- 幻灯片slides
- 时间节奏timing
反复排练 · 稳住心态
六、关于技术分享的额外收益
做技术分享、写技术文章，最大的收益者肯定是做分享的人自己。
在做分享之前，准备做一次技术分享，就会逼着自己把一项技术或者一种理念做整理——因为要将其完整地呈现出来给其他人，所以这样就会强迫自己去查资料，反复推敲概念的准确性（毕竟谁都不喜欢丢脸）。在反复的查询和推敲中，既是对知识的复习，也是对知识一次重新地探索。
在做分享的过程中和结束之后，通过反馈获得大家的反馈来改进自己的知识，最终都会转成自己的进步。所以大家应该让知识与更多的人一起分享，让自己更加进步；同时其他人因为自己的努力，也获得了成长，自己也会获得更好的合作伙伴。
同时，你也可以尝试将自己的观点放到网上——比如掘金、博客园、简书等等。更大范围的分享，会给自己打开新的视野。不论自己写的好或者不好，总能获得一些意想不到的收获，在社区中结识到一些朋友。
分享的飞轮
最大受益者是自己
分享即成长 · 飞轮越转越快