有人说,若是你想掌握好一门技术,那么最好的方式就是去当老师,去教会别人这门技术。在教别人的过程当中,你必需要去深刻的了解这门技术的方方面面,同时还要思考怎么才能让别人理解。每个作过的人都知道,这要比本身学习更难。html
之前我带的团队中,都会有比较好的技术分享的氛围,我会逼着每一个人都按期作一些本身熟悉的技术分享,一方面帮助你们共同成长,同时也让本身有更大的成长。固然我本身也很乐意作这样的技术分享的事,我一直以为能帮助别人是一件快乐的事情。前端
技术分享有主要的形式有写技术文章、作内部技术讲座。不管是哪种形式的技术分享,都有一些基本注意事项:node
每一次的技术分享,篇幅有限,时间有限,听众的注意力也有限,这就要求咱们必须能突出主题,不能什么都讲,最后什么都没印象,而是尽量聚焦于一个点,让听众留下深入印象。事实上,一次技术分享,能让大部分听众在一个知识点上有所理解和掌握,就已经很是成功了。mysql
例如前不久我刚在部门作了一次技术分享,关于一个聊天系统的技术实现,事实上这个系统比较复杂,服务端用到了node、socket、redis、mysql,另外还有一些负载均衡、安全认证等技术,客户端用了React、Redux、React-Router、Immutable、SASS、Gulp、Babel、ES6等知识点,若是要完整的讲一遍,那么一两个小时是不可能讲的完的,因此最终我选取了你们比较感兴趣的热门前端技术,仅围绕客户端React和Redux来说。过后证实效果不错,在一个小时内基本完成,而且让不少同事对React和Redux有了初步的了解。redis
在肯定主题后,接下来一件很重要的事情就是要了解技术分享的听众了,这和作产品须要了解你的目标用户同样,作技术分享也须要了解你的"用户"。有几个点是须要考虑清楚的:sql
例如我作过的技术分享通常有几类听众:编程
这其实本质上也是一种“指望值管理”,只有了解好受众的指望值,才能最后符合指望甚至超出指望。安全
去作技术分享前,若是不是为了装逼须要,大部分仍是愿意让本身内容浅显易懂的,可是真要作起来可不是那么容易,包括我本身,还有不少须要提升的地方,但这些年也总结了一些经验。前端框架
类比对于在作新技术的分享的时候尤其重要,每一个人都或多或少已经创建了本身的知识体系,有必定的积累,用听众已有的知识去类比,会比较容易理解和接受。好比说要给技术人员介绍React,我会类比模版、数据绑定、函数式编程,但若是是不懂技术的或懂一点技术的例如老板,我只会解释说这是一种相似jQuery的前端框架,前期有必定学习成本,对于复杂的应用能够提升开发效率。负载均衡
一图胜千言,好的代码也是如此。写PPT或者文章的时候,我总须要花不少时间去搜索图片,而后本身再画一些简单的框图,帮助说明清楚。
不少技术问题,最终是要反映成代码,尤为是对于技术人员,你费劲解释好久的问题,可能几行代码就写清楚了。
不少时候,费劲讲半天,听众可能还不明白这门技术能作什么事情和带来什么好处,配合一些直观的演示,可让听众很直观的了解能够作什么,有什么好处。
在一次短则半小时多则一小时的技术讲座过程当中,要想让听众一直能集中注意力是很难的,若是只是照本宣科念PPT,恐怕观众很容易以为无聊。而听众互动是一种很是简单有效的方式来提升分享的效果。
互动的方式有不少,例如向听众提问、让听众参与游戏、回答听众疑问。
有一次作项目管理相关的知识分享,我事先设计了一个游戏,把你们分红几个组,而后每一个组在限定的时间内用纸笔设计一个手机,而后再分组上台讲解。游戏完成后,我再结合项目管理的知识点作一些讲解和点评,这样的形式让参加的人都印象深入。相似的还有之前参加过邹老师组织过的一次游戏「创新的时机 – 黄金点游戏」,也是让我印象深入。
除了互动,通常都会有答疑的环节,尤为是对于现场答疑这种,须要的就是平时的积累和现场的反应了。须要注意的是要理解清楚提的问题是什么,若是实在是不会的问题,坦然说明不知道也是很正常的事。
一次分享每每时间有限,因此对节奏的把握很重要,事先要有计划:整体耗时多少,各个阶段要耗时多少,留多少时间答疑。在实际的分享过程当中每每会有些意外环节,例如对于某部份内容讲的太细,或者前期互动太多,这极可能致使后面时间不够,因此在整个过程当中,须要有清醒的意识,当某部分过快或过慢的时候要及时调整。若是有必要,也可让其余人辅助提醒。
之前有个朋友,去讲时间管理,结果原定1个小时的内容,讲了快2小时,最后结束的时候,全部的同窗第一时间冲向厕所:)