年初刚换了一家公司,leader 安排做一次技术分享。主要是在部门内部大概时间是一个小时左右,之前自己纯技术分享做的比较少,所以想请教大家一下有没有相关的要注意的点。
1
rodrick 2021-02-24 10:45:25 +08:00 2
抱着谦虚分享的态度,不要把分享的东西话说的太满,容易被打脸。
|
2
liujavamail 2021-02-24 10:48:21 +08:00 18
不要现场写代码,容易翻车
|
3
taowen 2021-02-24 10:49:07 +08:00 18
先要在最初的几页把听众的兴趣给激发出来,不要向上课一样,直接就是信息的罗列。你要把 why 说明白,大家为啥要坐在下面听你讲一个小时。
其次设计几个问题穿插在内容中。可以是很显而易见的问题,就是让下面的同学有一个站起来发言的机会。 table of contents 不仅仅要出现在第一页,在每个章节前面也加一下。让听众能够知道你讲到哪里了。 |
4
baiyi 2021-02-24 10:59:46 +08:00
最好是像演讲一样,如果只是枯燥信息的输出,听众会打哈欠。
除非讲的东西真的很有价值,那么听众打着哈欠也要听完。 |
5
Enya 2021-02-24 11:05:17 +08:00
PPT 不要写超过 20 页。
我以前有个同事一个小时的技术分享搞了 200 多页的 PPT,全都是截图,才讲到 26 也就被老板叫停了。 |
6
Suddoo 2021-02-24 11:06:10 +08:00
@liujavamail 哈哈哈哈
|
7
Suddoo 2021-02-24 11:07:38 +08:00
尽量讲一些有意思的主题吧,之前我们组内搞技术分享,很多人都跟老师讲课一样,念 PPT,完全不想听
|
8
boris93 2021-02-24 11:08:37 +08:00 via iPhone 9
what - 这次分享讲了什么
why - 为什么要用到这次讲的东西,它解决了什么问题 how - 怎么用,实现的大致原理是什么 |
9
TargaryenChen 2021-02-24 11:10:41 +08:00
确定自己真搞懂了要讲的内容
|
10
gowk 2021-02-24 11:14:24 +08:00
内容大于形式
可以参考这个,用 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/ |
11
jadeborner 2021-02-24 11:18:10 +08:00 1
有啥好分享的,没干货或者照本宣科领导观众不满意,有干货且通俗易懂岂不是给别人培训
|
12
JoStar 2021-02-24 11:55:31 +08:00 2
|
13
balckjoker OP @JoStar 是的,我觉得能有点互动就更好了。但是这种纯技术的不好加一些段子什么的。
|
14
JoStar 2021-02-24 12:04:05 +08:00
其实超过 30 分钟,人的注意力很容易分散了。我自己现在开会或是分享会尽量控制 30 分钟以内,如果内容确实太多,可以穿插几分钟的休息。
如果演示代码,你的代码要提前写好,就像教师有教案一样。 最后可以有一个总结,新知识是不容易被接受的,而且大家可能也没有那么集中注意力。所以要留一个 1-2 分钟的总结,只要在这段时间好好听了,可以得到相对划算的收益。 |
15
mayufo 2021-02-24 13:02:03 +08:00
讲好段子!
|
16
proger 2021-02-24 13:05:12 +08:00
1 如果你不是大牛,或者是真的很熟悉,很有把握的东西,不要讲的太满,抱有互相交流的态度
2 提前自己先过一遍,讲一遍给自己听吧,因为真正讲的时候很容易卡壳 |
17
fatpower 2021-02-24 14:05:10 +08:00
金字塔原理
|
18
Justin13 2021-02-24 14:05:46 +08:00 via Android
要么选自己很懂的,要么选他们不懂的,千万别选半懂不懂的。
准备几个问题和笑点,前者抓注意力,后者活跃气氛。 别指望一口吃个胖子,重点有 2,3 个就够了,再多吃不下。 |
19
Jooooooooo 2021-02-24 14:19:19 +08:00
公司内部技术分享收获最大的是自己, 好好准备能学到新东西就可以.
|
20
more1sec 2021-02-24 14:40:53 +08:00
准时结束
|
21
wobuhuicode 2021-02-24 14:47:53 +08:00 via iPhone
看到楼上说的不要现场代码。
这个我可以给点小技巧。在编辑器先做好几个代码片段。 到时候输出把关键变量填上就可以了。 |
22
soulmt 2021-02-24 15:06:25 +08:00
@wobuhuicode 我都是写好 demo,然后分段放开注释,算是投机取巧了。哈哈
|
23
murmur 2021-02-24 15:08:56 +08:00
一个小时吹个牛逼就完了,真要推技术得配上项目的,不用一下大家呵呵就忘了
|
24
zhoushushu 2021-02-24 15:15:41 +08:00 2
如果是下班后的技术分享会,随便讲,没人会在意;
如果是上班时间的技术分享会,随便讲,没人会在意; |
25
sugars 2021-02-24 15:20:54 +08:00
在以上各位大佬的建议里,演讲里再加点幽默就更好了
|
26
auh 2021-02-24 15:31:51 +08:00
只讲干货,少说废话。从抛出问题,开始,一点点解答。最后梳理全部内容。
段子,带情绪的话,谦卑,激情,还有所谓的幽默。纯属浪费大家时间。除了能像罗永浩一样。 |
27
raaaaaar 2021-02-24 15:36:53 +08:00 1
讲在实际工作中会遇到的问题,这样收获更大,和别人也容易交流,在交流的过程中也可以聊聊相关的技术实现,不一定非得聊上面的主题。
一定要和下面的交流,不要在上面自己讲自己的。 黄金圈理论,也就是 what why how 的方式去梳理思路,千万不要自己讲自己的,很多人一来就讲一些非常细节的东西,下面的人根本不知道它在讲些什么东西。 尽量讲高一点层面的知识,也就是说最好不要具体到代码细节,真要用到代码也要提前准备好。 讲前写好技术文档,注意排版,思路 总之就是,多讲大家都会用到,都能用到的实际工作中的知识,讲的人一定思路清晰,知道自己在讲些什么,要多和下面的人交互,就像平时交流一样,但是话题需要你自己来掌控。 其实如同上面的兄弟说的,交流会其实主讲人的收获最大,自己主动去了解知识,系统化,自己去表达知识,和别人交流,这些都是能很好锻炼自己的,尤其是以前没有这么做过的人。 |
28
deplives 2021-02-24 15:55:18 +08:00
提前写好代码,调试好,县城写代码十有八九会翻车
|
30
barfi1316 2021-02-24 17:19:34 +08:00
@balckjoker 楼主现在有没有好的主题推荐?
|
31
dgjungle 2021-02-24 17:24:13 +08:00
最好的办法就是提前准备,能用代码绝对不用文字描述
|
32
Lemeng 2021-02-24 17:42:57 +08:00
由浅入深,抱着详细点,而又言简意赅的就行
|
33
0zero0 2021-02-24 17:47:54 +08:00
了解你演讲针对的目标用户,看他们想听什么,有针对性的准备。
|
34
xxy973211 2021-02-24 17:56:38 +08:00
@liujavamail 老哥经验丰富
|
35
available2099 2021-02-24 18:00:40 +08:00
讲一些别人不懂最好,净听你忽悠
|
36
renmu123 2021-02-24 18:01:44 +08:00 via Android
可以向 leader 建议,搞成闪电演讲,比如每个人十五分钟,十五分钟到了必须下台,轮到下一个月,多人参与。这种形式会比一个人在台上 balabala 讲一个小时有趣的多。一个小时真的直打呵欠
|
38
JoStar 2021-02-24 18:03:58 +08:00
@barfi1316 我分享的基本都是前端主题。如果你不局限于前端的话,我觉得 RX 系列挺好的,不过学习门槛有点高,要讲个入门并不容易
|
39
hitmanx 2021-02-24 18:49:35 +08:00 1
@jadeborner
“有干货且通俗易懂岂不是给别人培训” 真没必要想得这么狭隘。 做分享其实收获最大的人永远是自己,你再体会体会。这和费曼学习法是一样的,通过把信息讲给别人,这是个督促自己把信息重新咀嚼、整理的机会,而且加深了自己对这个知识的印象,一举多得。 再说了,看了尖子生的笔记就成为尖子生了吗?不是的,知识不是你自己走心整理出来的,别人把精华放在你面前,你转眼就忘了。 |
40
yuruizhe 2021-02-24 19:54:29 +08:00
提前一周把演示材料发给大家,一周后让大家带着问题与不同的见解参与讨论,不然大家会一头雾水
|
41
TigerK 2021-02-24 20:39:01 +08:00
保持谦虚的态度,坚持“分享”而不是“说教”,确保在正式开始之前经过至少一次的完整演示 or 彩排。
如果时间足够的话,提前演练的次数越多,最后的效果越好。 |
42
wensonsmith 2021-02-24 21:37:37 +08:00
左耳朵陈皓写的 Sharing Guideline: https://twitter.com/haoel/status/1356423697679060992
|
43
fucUup 2021-02-24 22:27:35 +08:00 via Android
开源系统我是作者,直接打开 git,讲 commit 的历史
|
44
SSSDDD 2021-02-24 22:42:32 +08:00
才上班几天就入职了,效率也太高了吧
|
45
wupher 2021-02-25 09:44:23 +08:00
有内容:讲的东西是大家感兴趣的
形式: * 有互动环节 * 多图少字 * 时间、信息密度、节奏的控制 |
46
tydl 2021-02-25 14:03:50 +08:00
注意就是,不好搞
|
47
mindsucker 2021-02-25 15:19:24 +08:00
最好把内容写成博客,然后根据博客整理成文档,然后就是演示 demo
|
48
wr516516 2021-02-25 17:53:02 +08:00
以前每次开分享会,我有时候会现场提问一下,但是经常吧分享的人给问懵了.
之后也就不问了,有意思的东西还是自己学自己研究比较好. 分享经验的话,建议还是越细越小越好,或者不如就随便讲讲常用框架的新版本新特性. 或者就是针对当前业务的一些优化意见, 去讲什么某某中间件,某某新框架,体量太大,分享时间不够,而且你大概率也不能全范围覆盖掌握. |
49
james122333 2021-02-25 21:51:23 +08:00 via Android
|