怎么搞一个好的内部分享？

背景

Q2 看到性能小组的技术分享，感觉很不错，我们在 Q2 的技术分享都没怎么搞，打算在 Q3 也开始搞起来。

虽然我们问题多，不用担心主题，但是担心其实分享的质量不行，先探探路。

定义

如何评价一个技术分享是有质量的？

  1. 分享的内容是有很长的保质期的，甚至历久弥新；
  2. 会被大范围的传递。

我之前学习 js 模块化的时候，看到的一篇黄玄的分享 js-module-7day ，就让我有这种感觉，这是一个非常有质量的分享。虽然这是一个好几年前的分享了，而且随着 js 模块化的日益完善，其中的内容今天看来都没有什么价值了，但是其实每次看，还是能从中有新的收获。

我觉得这篇分享，就非常符合好分享的定义：

  1. 把复杂的问题讲解的很简单也很清楚；

    1. 用各种简单通俗通懂的话把各种复杂的知识讲的清清楚楚；
    2. 把复杂的问题，拆解成简单的问题；

  2. 有各种各样的推导和方案的比较，让你知其然知其所以然；

    1. 有方案的推导，理解更透彻；
    2. 有方案的比较，获得更全面的认知；

    原理、为什么、思路、方法论让人一通百通；

那么如何做到这些呢?

最佳实践路径

先描述好一个问题

不要吝啬问题的篇幅，描述好一个问题能够将受众带入进来，如果这个问题是他们感同身受的，那是最好了。千万不要一上来，绕过问题，直接就谈方案，这是非常难受的。其实我们现在很多的团队评审里面，就会发生这种现象，背景描述的不够全面，让人理解不了。方案上就提不出什么问题。

how 比 what 更重要

这一切的大背景，就是上面的描述好一个问题。描述好问题之后，也就自然而然的可以讲到如何解决这个问题了。

要有一个解决问题的推导过程，要有最终不同技术的比较。

一定要有Best Practice或方法论总结

要给出实际的最佳实践，要带有方法论的总结，上升高度。

模型

大纲: 问题 –> 方案 –> 总结

  • 用问题来吸引受众，带着受众来一起思考
    • 尽量缩小主题的范围，less is more !
  • 用问题模型来框住受众的思考范围，让受众聚焦
  • 给出几种不同的解决方案，比较他们的优缺点，让受众有一种解决问题的参与感。
  • 最后，给出最佳实践，方法论或套路，因为有了前三步的铺垫，受众欣然接受。
  • 整个过程会让受众有强烈的成长感和收获感。

额外

  1. 依据场合，让分享更轻松；比如依据受众，可以用用表情包、玩玩梗之类的；
  2. 要分享自己的分享，接受更广泛受众的评价；
  3. 分享是学习知识的最难的方式。分享者获得的好处是最多的，而不是听众。
  4. 分享可以为听众打开知识的大门，但能不能获得知识还要靠自己。

总结

希望我们组能参考自己认为优秀的分享内容，或者我提到的黄玄的分享 js-module-7day 这篇的分享方式，来书写我们三季度待解决问题的分享。要求的不是形似，二是神似，有问题、有方案、有总结，让我们最终的分享上有收获。三季度多多产出高质量的分享。