如何做好一场技术分享

你好，我是 hockor，继上一篇如何打造良好的分享氛围后，很多小伙伴问我分享的时候到底应该怎么做才能达到好的现场效果，我寻思这还算个问题？这不就是坐那儿讲吗？小伙伴给了我这么个表情🙄，所以呢，今天这篇文章我们来聊聊如何才能做好一次技术分享。

首先我们明确一个事情，现场分享的本质是什么？很简单，就是你说他听，但是怎么才能把这四个字的内容做到完美呢？想想看，你现在问别人天气热不热，他跟你说下面超市在的三文鱼在打折，请问你内心什么感受？又或者你现在谈恋爱，你兴致勃勃的跟女朋友介绍着每个奥特曼的区别，奥特曼多么多么厉害（ps：其实我压根不看奥特曼），女朋友甩了个白眼给你，请问你又是什么感受？

如果你看懂了上面 2 个例子，那么恭喜你，其实你已经懂得了分享的秘诀~

如果你没看懂，没关系，接下来我慢慢跟你掰扯掰扯（进入正经模式），我们从两个方面来讲，事和人~

关于事

关于分享这件事，在上一篇我们已经说过了选题的内容，这里再重复一下，技术分享的选题，我觉得可以大致分为以下 3 类：

• 技术解决方案

• 新技术布道

• 个人经验分享

之前的一篇文章限于篇幅，我说的不是特别详细，所以这里我再铺开来说说。

《技术解决方案类》

我们技术分享应该最大头的部分就是技术解决方案类的了，这种内容有个特点，就是容易变成 Code Review大会，你想想，是不是这么个情况。

这类主题的分享大部分都是从实际业务内容着手，将自己做的内容进行拆解，将知识点罗列出来，梳理出自己的解决方案和理解，但是大部分的 IT 从业者会比较较真，觉得 show code 才是自己实力的体验，然后一上来就讲自己碰到了 XX 问题，然后写了 XXX 代码就把问题解决了，导致大家在听的时候根本不知道你的思考过程，不知道为啥要这么做，这么导致的结果就是别人根本没有产生共鸣，对你的分享没有代入感。

同时我不太建议这类分享的主题以《XXX 技术剖析》开展，虽然你确实是用了这个技术来解决问题，原因有 2 点：

• 第一是无形中形成了参会的壁垒，比如你分享数据库，那么可能前端同学压根不感兴趣，而如果你分享“秒杀场景”的解决方案，那么前后端同学可能都会很感兴趣，这样子以实际问题为出发的主题往往在分享前能获得更多的关注点

• 第二个其实跟上一个很类似，就是技术点是灵活多变的，是没有典型性的，但是问题不同，问题能树立典型性，我们实际工作也是，你解决的都是一个一个问题，问题的通用性往往能产生共鸣，所以以具体问题为切入点，才是最好的方案,

最后对于这类分享，我有以下 3 点建议

• 整体的分享路径为：抛出问题 → 剖析问题 → 寻求方案的过程 → 多个技术方案对比 → 最终采取XX 技术的原因 → 整体的收获

• 不要过多的贴代码，变成 code Review大会

• 如果可以，最好在会前先把文档/ppt 给大家看看，让大家带着自己的问题来听分享，而不是一头雾水的一直听你一个人讲。

《新技术布道类》

在技术分享上，还有一类比较常见的主题就是对于新技术的布道，我们都知道技术领域内容繁多，当有一些新技术推出或者一些多专业性知识（比如图形学，音视频等），大家独自学习成本比较高，这时候你可以将自己学习的过程和爬坑过程在团队内做系统性的分享。

但是这种内容又有个特点，要么是容易一直停留在 “ Hello World ”，要么就是讲的云里雾里，大家根本都听不懂，最后成了你自己的自 high 秀，所以针对这类内容，我也有几点建议：

• 把复杂的问题简单话：善于利用一些比喻，将本来很复杂的知识点一下子就让大家能接受，比如之前在讲 webRTC中的建立连接过程，因为每种设备支持的音视频格式都有差异，这个过程很复杂，有些同学可能听着有点晕，于是我就想到了一个很好的例子，将其比喻成 2 个不认识的人想沟通，A 就把自己会的语言写下来，有“中文，英文”，B 也把自己的写下来，有“中文，日文”，于是一对比，看到两个人都会中文，所以你们就用中文交流吧。这种形象的例子让大家非常好去理解一些晦涩的概念。

• 将这类技术和其他类似的技术做对比：这个就很好理解的，就是善于利用大家已经会的知识点让他去接受新内容，比如学 flutter，你就可以去对比着以前大火的 RN，webView 的方案等等。

• 讲清楚他的用途：最后就是一定要讲清楚这个技术的可期待性，比如现在 XX 问题解决不了或者是现在性能上的问题，以后有了这个新技术就能解决了，让参与者知道技术的运用点，帮助他去思考他是否需要学习这项技术。

《个人经验分享类》

最后一类就是一些偏经验性的内容，比如成长经验、人生感悟或业务思考等等，这种内容一般会比较泛，考验的更多是你的内容是否出彩和你的人格魅力了，这个目前我给不了太好的建议，等有一天我有所经历了再来补充吧~

关于人

接着我们再来看看分享中最重要的一块：人

这里也分为分享者和参与者，我一起讲讲他们的一些注意点，你可以参考参考，随着自己的角色变化看看有没有对你有益的内容。

分享者

先来说说分享者，假定你现在是个分享者，你要去做分享，我们可以将你的整个流程分为 3 个阶段：会前，会中，会后。

会前

首先是会前，一个分享者最重要的的事情就是准备分享的材料，一般来讲大部分人在分享的时候都会使用 PPT，所以这里我针对 PPT 的内容有以下几点建议:

• 不要通篇的文字，没人愿意看，而且现场分享情况下，灯光/场地大小等等都会影响阅读；

• 关于图的动画：很多程序员喜欢画架构图，这本来是个很好的习惯，放在分享 PPT 里面也是很好的，但是问题就是很多人喜欢一上来就把架构图全部展示出来，看的人一头雾水，有时候都不知道你讲到哪里去了，最好能有一个动画，让架构图随着你的演讲一步一步的展示；

• 注意基础的色调搭配：很多程序员做 PPT 喜欢白底黑字或者黑底白字，整个 PPT 非常单调，试问这样的 PPT 怎么能让别人喜欢看下去呢？

如果只是做个 PPT 是不是就 ok 了呢？其实不然，如果你是团队内部小分享可能还好，但是如果你是技术大会的分享，那么我希望你能提前准备一份“逐字稿”，李诞在工作手册中提到过，他们工作室的所有脱口秀演员上台之前必须写逐字稿，同样，《得到》的编辑部在他们的介绍中也有提到过，因为我们在一个字一个字写的时候你的脑海就会浮现出表演的画面，当你正式上台分享的时候，你所做的就不是去背一遍稿子了，而是跟着当时的那个画面一步一步重现它。

会中

接下来就是正式由你上台分享了，这里我主要提 2 点

• 自信的表达：这里其实很大一个帮助点就是上面提到的逐字稿，想想你分享的时候有说过多少“嗯。。”“这个，那个”“是吧”，当一个人不自觉的说出这些词的时候，往往意味着他的思绪停顿了或者是他紧张了，所以针对上面提到的逐字稿，如果有需要的话请一定要好好准备。

• 时刻观察现场：分享的时候不是你一个人一直说个不停，而要根据现场氛围和实际情况灵活调整，比如你现在讲的内容大家都很懵，那么你应该停下来问问大家是否有什么疑问，又或者你语速太快，大家都面露难色，那么你应该适当的放慢速度，这一切都需要你积极的观察和眼神互动。

会后

最后在来看看当分享结束以后我们还有什么可以做的呢？我觉得有 2 点你可以考虑一下：

• 寻求听众的反馈：分享完毕以后最好能有个小的调查问卷，让大家对你分享的过程做一个评价，比如材料准备是否合理，分享过程有什么建议等等，可以让你更直观的了解自己，便于改进。

• 听听自己的回放：如果允许的话你可以在分享开始的时候将整个过程录制下来，等分享结束以后你自己尝试着去听一听自己的分享，你别笑，这个方法可是很多播音专业的必备技巧，通过这个过程你会更深入的了解自己，还能发现很多别人发现不了的问题。

参与者

好，最后我们再来简单看看参与者应该注意些什么。

对于参与者其实需要我们做的内容并不是太多，但是有一点是我很想提到的，就是你的心态，我在之前的文章有提到过学习者的三种心态，分别是 犯人、过客、探索者，如果忘记了你可以再回去温习一下。

这里再补充一下，针对于参加外部分享大会的这种场景，我觉得有一点可以补充：一般情况下大部分人参加分享大会都是奔着学技术的目的去的，包括我自己之前参加 GMTC 等等也是一样的，但是我后面想明白了一点，这种规模的分享大会你根本不可能再那么短短的 30-45 分钟时间正儿八经学到一项技术，更别说还有很多你未曾涉足的领域，可能你更加听得云里雾里，最多最多你能记住几个别人解决问题的方案，那么你说我们去到底干嘛呢？我后来想了下顿悟了，其本质应该是让你去结实朋友，融入圈子的。

这个场合下如果你有幸认识了那帮自己欣赏的人，那么就可以学习他们的思维方式，汲取他们的经验，甚至是融入他们的技术圈子自己也去做输出，所以对于这种场合，你一定要带着这样的心态去参加，并且在整个过程中逼迫自己多思考，多总结。

总结

最后对于技术分享我还有2句话啰嗦一下：

• 分享的过程就是一个人与人互动的过程，所以一定要善于利用语言去制作气氛，这一点需要你自己做大量的学习和刻意练习才能达到。

• 对自己要有高要求，在李世民作的《帝范》中有这么一句话：“法乎其上，得乎其中，法乎其中，仅得其下”，意思是取上等的为准则，也只能得到中等的。取中等的为准则，最后只能获取下等的结果，对于分享这件小事也是一样，只有我们放宽视野，给自己定一个高目标，才能取得令自己满意的成果。

好了，以上就是本文的全部内容了，感谢你看到这里，希望以上内容能对你有所启发和帮助，我是 hockor，我们下次再见~