写在前面
几乎所有的技术团队都在进行技术分享，有时组织分享总觉得不够好，总想把技术分享做得更好一些。本篇总结了我们团队技术分享的过程，帮助团队提高技术分享质量。若有更好的提升建议，欢迎留言交流。
为什么要做技术分享
技术分享的好处多多，这里就简单写几个；
- 扩大知识领域，能有更广的知识储备
- 快速了解新知识
- 使原本会的知识更扎实
- 完善知识体系
- 给队员一个展示自我的机会
- 组建学习型技术团队，使公司更有竞争力
- 留下文字或者影像资料，跳槽时加薪。目前知识付费时代，若能坚持可以有不小的收益
- 扩大自己影响力，升职加薪指日可待
有的时候腼腆的程序员们不情愿去分享，只是因为自己不自信。这就需要TL的帮助和队员们的鼓励，帮助这些队员成长。
痛点
技术分享都有共同都痛点
- 不知道该分享什么
- 听众的水平比我高
- 该怎么准备分享
这些痛点尤其是对新团队和刚入行的程序员来说是很犯愁的。以下从如何组织和如何准备一个分享两个方面总结我们IT分享的经验。
“听众的水平比我高”，这是一个伪命题。若分享人充分准备至少比90%的听众更加深入了解某一领域。台下若有1-2个大佬，能帮助分享人指正、完善也是极好的。无论怎样，收益最多的还是分享人本人！
如何组织分享
PS：首先需要一个持续学习的TL，如果团队的Tech-Leader都停止学习，那IT分享肯定没戏。这里向带领我们一步一步提高技术的 Jim 老板表示感谢，
如何选题
TL 组织队员们集思广益，把想要了解的技术都列出来并分类，按照可进行一次分享的颗粒划分。比如
前端： -- reactjs + redux -- vuejs + vuex + vue-router
reactjs 其实本身并不难，实战中需要了解redux，hoc等。所以在40分钟左右的分享中，仅仅分享一个react语法显然是索然无味的。对于题目的选择和范围，都是需要提前确定，保证40分钟干活满满。Sharing is not teaching. 没有必要手把手的去交给每个与会人员所有的细节。
组织过程
确定了分享题目后，需要安排分享人和主持人。主持人负责确定订会议室、跟进分享人确定分享能按计划进行、收取分享人的PPT和听众的预习资料，并分发给与会人员、分享前邮件通知所有与会人员。 这里感谢兢兢业业的主持人Jackson，帮助我们成功的组织了一次又一次的分享。主持人的角色非常重要，不建议换人。
总结分享
每次分享Q&A结束后，整个分享并没有结束。我们会一起讨论此次分享的优劣得失。好的继续保持，糟糕的地方需要改进。比如提前准备的情况情况，时间把控情况，PPT的制作等。这对于分享人是一个很大的提高。三人行必有我师，择其善者而从之，其不善者而改之。听众也可以从总结中提升自己，为下次自己的分享做准备。
如何准备分享
这里记录个人浅见，若有不足请批评指正。
分享前准备
- 了解听众技术水平，确定讲解的深度；
- 查阅题目相关资料，自学并demo。这里要保留资料出处，写在PPT结尾的资料参考中。可以筛选一些听众提前预习的资料，提前给主持人；
- 制作分享PPT:（你见哪个BOSS在台上演讲时，大屏幕显示的是白底黑字的记事本？）
- 一图胜千言: 可以多贴图，使难理解的概念更容易被听众接受。图片同样要表明出处。
分享中
展示分享人的控场能力和演讲能力时候到了。如果BOSS从会议室门口经过时，看到精彩的PPT和神采飞扬的分享人，升职加薪离他还会远么？
这里列举几个分享要求及技巧。
- 要求分享人站着面对听众分享（会议室要有大屏幕或者投影）；
- 需要与听众有互动（听众有时候会开个小差，你懂的）；
- 把控时间（分享一般在40分钟左右），另外再有 Q&A 5-10分钟；
- 好好准备PPT，尽量不要跳出PPT去敲代码或者查阅官网。这写东西都可以截图展示；
- 很多演讲技巧：如目光环视全场、站姿、手势、语调等等这里不细讲，每个细节全是学问，要好好准备好好练习。
分享后
一般在PPT最后一页都会有一个大大的“THANKS”，此时答谢听众并把话语权交给主持人。进行下一阶段Q&A时间。有的分享人也喜欢自己主持Q&A阶段，这都是OK的。看个人喜好。
总结
技术分享对每个人每个团队都很重要，学如逆水行舟不进则退，坚持学习，保持精进，希望大家都能在技术的道路上越走越好。与君共勉！