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