公司内部做一次好的技术分享需要注意哪些事情？

• 資深大佬 : rodrick

  抱着谦虚分享的态度，不要把分享的东西话说的太满，容易被打脸。

• 資深大佬 : liujavamail

  不要现场写代码，容易翻车

• 資深大佬 : taowen

  先要在最初的几页把听众的兴趣给激发出来，不要向上课一样，直接就是信息的罗列。你要把 why 说明白，大家为啥要坐在下面听你讲一个小时。

  其次设计几个问题穿插在内容中。可以是很显而易见的问题，就是让下面的同学有一个站起来发言的机会。

  table of contents 不仅仅要出现在第一页，在每个章节前面也加一下。让听众能够知道你讲到哪里了。

• 資深大佬 : baiyi

  最好是像演讲一样，如果只是枯燥信息的输出，听众会打哈欠。

  除非讲的东西真的很有价值，那么听众打着哈欠也要听完。

• 資深大佬 : Enya

  PPT 不要写超过 20 页。
  我以前有个同事一个小时的技术分享搞了 200 多页的 PPT，全都是截图，才讲到 26 也就被老板叫停了。

• 資深大佬 : Suddoo

  @liujavamail 哈哈哈哈

• 資深大佬 : Suddoo

  尽量讲一些有意思的主题吧，之前我们组内搞技术分享，很多人都跟老师讲课一样，念 PPT，完全不想听

• 資深大佬 : boris93

  what – 这次分享讲了什么
  why – 为什么要用到这次讲的东西，它解决了什么问题
  how – 怎么用，实现的大致原理是什么

• 資深大佬 : TargaryenChen

  确定自己真搞懂了要讲的内容

• 資深大佬 : gowk

  内容大于形式

  可以参考这个，用 marp （ markdown 语法）代替 PPT：
  https://github.com/jeremyxu2010/k8s-share
  作者写的 blog: https://jeremyxu2010.github.io/2020/05/%E6%8A%80%E6%9C%AF%E5%88%86%E4%BA%AB%E4%B9%8B%E5%B7%A5%E5%85%B7%E6%8E%A8%E8%8D%90/

• 資深大佬 : jadeborner

  有啥好分享的，没干货或者照本宣科领导观众不满意，有干货且通俗易懂岂不是给别人培训

• 資深大佬 : JoStar

  @boris93 what why how 我自己也非常喜欢用，但是我的顺序是 why what how 。

  鄙人认为先问 why 有助于更好地理解 what

• 主 資深大佬 : balckjoker

  @JoStar 是的，我觉得能有点互动就更好了。但是这种纯技术的不好加一些段子什么的。

• 資深大佬 : JoStar

  其实超过 30 分钟，人的注意力很容易分散了。我自己现在开会或是分享会尽量控制 30 分钟以内，如果内容确实太多，可以穿插几分钟的休息。

  如果演示代码，你的代码要提前写好，就像教师有教案一样。

  最后可以有一个总结，新知识是不容易被接受的，而且大家可能也没有那么集中注意力。所以要留一个 1-2 分钟的总结，只要在这段时间好好听了，可以得到相对划算的收益。

• 資深大佬 : mayufo

  讲好段子！

• 資深大佬 : proger

  1 如果你不是大牛,或者是真的很熟悉,很有把握的东西,不要讲的太满,抱有互相交流的态度
  2 提前自己先过一遍,讲一遍给自己听吧,因为真正讲的时候很容易卡壳

• 資深大佬 : fatpower

  金字塔原理

• 資深大佬 : Justin13

  要么选自己很懂的，要么选他们不懂的，千万别选半懂不懂的。
  准备几个问题和笑点，前者抓注意力，后者活跃气氛。
  别指望一口吃个胖子，重点有 2，3 个就够了，再多吃不下。

• 資深大佬 : Jooooooooo

  公司内部技术分享收获最大的是自己, 好好准备能学到新东西就可以.

• 資深大佬 : more1sec

  准时结束

• 資深大佬 : wobuhuicode

  看到上说的不要现场代码。
  这个我可以给点小技巧。在编辑器先做好几个代码片段。
  到时候输出把关键变量填上就可以了。

• 資深大佬 : soulmt

  @wobuhuicode 我都是写好 demo，然后分段放开注释，算是投机取巧了。哈哈

• 資深大佬 : murmur

  一个小时吹个牛逼就完了，真要推技术得配上项目的，不用一下大家呵呵就忘了

• 資深大佬 : zhoushushu

  如果是下班后的技术分享会，随便讲，没人会在意；
  如果是上班时间的技术分享会，随便讲，没人会在意；

• 資深大佬 : sugars

  在以上各位大佬的建议里，演讲里再加点幽默就更好了

• 資深大佬 : auh

  只讲干货，少说废话。从抛出问题，开始，一点点解答。最后梳理全部内容。
  段子，带情绪的话，谦卑，激情，还有所谓的幽默。纯属浪费大家时间。除了能像罗永浩一样。

• 資深大佬 : raaaaaar

  讲在实际工作中会遇到的问题，这样收获更大，和别人也容易交流，在交流的过程中也可以聊聊相关的技术实现，不一定非得聊上面的主题。

  一定要和下面的交流，不要在上面自己讲自己的。

  黄金圈理论，也就是 what why how 的方式去梳理思路，千万不要自己讲自己的，很多人一来就讲一些非常细节的东西，下面的人根本不知道它在讲些什么东西。

  尽量讲高一点层面的知识，也就是说最好不要具体到代码细节，真要用到代码也要提前准备好。

  讲前写好技术文档，注意排版，思路

  总之就是，多讲大家都会用到，都能用到的实际工作中的知识，讲的人一定思路清晰，知道自己在讲些什么，要多和下面的人交互，就像平时交流一样，但是话题需要你自己来掌控。

  其实如同上面的兄弟说的，交流会其实主讲人的收获最大，自己主动去了解知识，系统化，自己去表达知识，和别人交流，这些都是能很好锻炼自己的，尤其是以前没有这么做过的人。

• 資深大佬 : deplives

  提前写好代码，调试好，县城写代码十有八九会翻车

• 資深大佬 : barfi1316

  @JoStar 有经验，有没有推荐分享过的主题。谢谢。

• 資深大佬 : barfi1316

  @balckjoker 主现在有没有好的主题推荐？

• 資深大佬 : dgjungle

  最好的办法就是提前准备，能用代码绝对不用文字描述

• 資深大佬 : Lemeng

  由浅入深，抱着详细点，而又言简意赅的就行

• 資深大佬 : 0zero0

  了解你演讲针对的目标用户，看他们想听什么，有针对性的准备。

• 資深大佬 : xxy973211

  @liujavamail 老哥经验丰富

• 資深大佬 : available2099

  讲一些别人不懂最好，净听你忽悠

• 資深大佬 : renmu123

  可以向 leader 建议，搞成闪电演讲，比如每个人十五分钟，十五分钟到了必须下台，轮到下一个月，多人参与。这种形式会比一个人在台上 balabala 讲一个小时有趣的多。一个小时真的直打呵欠

• 資深大佬 : xxy973211

  @Enya 狠人

• 資深大佬 : JoStar

  @barfi1316 我分享的基本都是前端主题。如果你不局限于前端的话，我觉得 RX 系列挺好的，不过学习门槛有点高，要讲个入门并不容易

• 資深大佬 : hitmanx

  @jadeborner
  “有干货且通俗易懂岂不是给别人培训”

  真没必要想得这么狭隘。

  做分享其实收获最大的人永远是自己，你再体会体会。这和费曼学习法是一样的，通过把信息讲给别人，这是个督促自己把信息重新咀嚼、整理的机会，而且加深了自己对这个知识的印象，一举多得。

  再说了，看了尖子生的笔记就成为尖子生了吗？不是的，知识不是你自己走心整理出来的，别人把精华放在你面前，你转眼就忘了。

• 資深大佬 : yuruizhe

  提前一周把演示材料发给大家，一周后让大家带着问题与不同的见解参与讨论，不然大家会一头雾水

• 資深大佬 : TigerK

  保持谦虚的态度，坚持“分享”而不是“说教”，确保在正式开始之前经过至少一次的完整演示 or 彩排。

  如果时间足够的话，提前演练的次数越多，最后的效果越好。

• 資深大佬 : wensonsmith

  左耳朵陈皓写的 Sharing Guideline： https://twitter.com/haoel/status/1356423697679060992

• 資深大佬 : fucUup

  开源系统我是作者，直接打开 git，讲 commit 的历史

• 資深大佬 : SSSDDD

  才上班几天就入职了，效率也太高了吧

• 資深大佬 : wupher

  有内容：讲的东西是大家感兴趣的

  形式：
  * 有互动环节
  * 多图少字
  * 时间、信息密度、节奏的控制

• 資深大佬 : tydl

  注意就是，不好搞

• 資深大佬 : mindsucker

  最好把内容写成博客，然后根据博客整理成文档，然后就是演示 demo

• 資深大佬 : wr516516

  以前每次开分享会,我有时候会现场提问一下,但是经常吧分享的人给问懵了.
  之后也就不问了,有意思的东西还是自己学自己研究比较好.
  分享经验的话,建议还是越细越小越好,或者不如就随便讲讲常用框架的新版本新特性.
  或者就是针对当前业务的一些优化意见,
  去讲什么某某中间件,某某新框架,体量太大,分享时间不够,而且你大概率也不能全范围覆盖掌握.

• 資深大佬 : james122333

  @hitmanx
  其实搭配需求了解就已经很深入了
  有无分享已经无差 还不用被问到烦
  赞同原回复 自己培训自己就可以
  培训其它人别人不见得感谢你