如何更好带领技术团队

几年前入职新公司的时候，领导为了加强团队的技术氛围拉了个一周一次的技术分享会。在一群不善言辞不爱社交的程序员中开辟如此社交性强的活动，想想就知道是有多尬。没有人自愿报名分享，咱就排个号轮流上。而被逼上梁山的朋友则一边展示着粗糙的 PPT，一边抖着手磕磕巴巴地讲，看到下面会议室一片寂静，不少小伙伴或木着脸，或低头刷着手机，内心越发地没有自信。

你说咱程序员安安静静写程序不就好了吗？ 这你就大错特错了。

准备分享的过程能大大地强化对知识点的理解。大多时候我们在学习新技术和知识的时候只是看听讲，以为自己已经掌握但实际上遗漏了不少重点。准备分享的时候，我们为了能把一个点讲明白，必须理清来龙去脉，自圆其说。在这过程中便能发现之前理解中的错漏，甚至更进一步。

多分享能带动并增强团队技术氛围。在团队领导的支持下积极分享会鼓励小伙伴们更多地参与进来，在工作之余学习更好的实践、新的技术并输出给团队，形成一个正向的循环，让在团队里的所有成员都获益并快速成长。

分享能锻炼演讲这项重要的软技能。在职业发展的长路上，软技能会随着工龄的增长变得越发重要。不论身在大厂小厂，优秀的演讲能力一定会为你的晋升提供不少助力。

展示所学所知可以树立强化自品牌。名牌效应也是可以应用到人身上，我们在不断分享的过程中实际上就在团队内外将自己的名字广而告之，让别人一看到某个技术就想到你的名字。

既然分享有这么多好处，新手该从哪里开始呢？

首先，调整好心态

对于上台分享，你是不是有以下这些想法？

我大脑空空实在想不出分享什么好。

制定分享的主题就跟写作文一样，不是说有就有的，需要一定的积累。这让我们在下一节中详细讨论。

大家都比我懂，我哪来的自信分享？

首先，太在意别人对自己的看法会极大地限制自身的发展，甚至身心的健康。

其次，团队里每个人对技术的关注点不同，总是有些知识点是他们不熟悉或遗漏的，他们就可以在你的分享中查漏补缺。

再次，资深的老神棍和领导们对分享本身的看法已经超越了分享的内容本身，内容深浅和分享的质量已经不那么重要，反倒看中你的成长，并感激你积极参与带动团队的技术氛围。

我上台就紧张，大脑一片空白，根本没法讲。

哪怕经常上国际技术大会的大佬上台还是会紧张的，在乎观众的反应、演讲的效果使紧张成为一种必然的生理反应。所以我们要做的不是“消灭”它，而是习惯这种紧张的感觉，让它不再阻碍我们发挥。

关于这点我认为长期最有效的方法是刻意练习多，并在每次分享之前都演练。练习的方法有很多种，对着镜子讲，对着家人讲，对着好友讲，先在小团队里分享，再逐渐扩大观众范围。把非舒适区练成舒适区。

在这个过程中还有许多辅助的方法可以利用，比如把每一句台词写下来，练习的时候对着读，一边读一边调整。在正式分享的时候握着这篇反复修改的稿子，不太确信接下来讲什么的时候看一眼。

阻碍你迈出这一步的都是“借口”。只要调整好自己的心态并积极面对这些挑战，完全可以轻松克服。

建立主题池

你会不会在看到别人讨论一个话题，阅读一篇博客，修复一个 bug 的时候，产生这个点“值得深入挖掘”或“值得与大家讨论分享”的想法？

如果有，我建议你把它记录下来，立刻，马上。

这样的灵感转瞬即逝，而它恰恰可以成为你未来某天分享的主题。在任何触手可及的笔记软件里保存这样一个主题池，你就再也不会面临大脑空白的窘境了。面对满满的主题列表，成就感给予大脑的激励使其更加富有创造力，灵感也会越发源源不断而来。

主题池的内容可随时删减修改，也不必有时间限制和特定顺序。它最大的作用只是在你需要的时候提供选项。

没有灵感也可以从自己了解的，或者感兴趣的技术出发，聊一下：

• 发展史
• 最近更新的内容
• 如何应用
• 跟类似技术的对比
• 最佳实践
• 实现原理

等等。

确定分享的形式

每个主题可以用不同的方式展开。

最常规的单人演讲形式是最容易准备、最适合入门的。只需把内容安排妥当，对着 PPT 从头讲到尾即大功告成。

然而，很快你会发现技术演讲光对着 PPT 是不够的，时不时需要展示一下效果。最简便的方式是截图，更近一步可做动图放视频。如果想让观众沉浸式体验代码的效果效果，那就来个现场写码运行，边演示边讲解。

现场手写代码的操作要求很高。如果不太自信或源码比较长的时候，也可考虑事先准备一部分代码，演示时或直接运行，或复制黏贴，或补全关键部分。另外，现场演示也常出意外。你可能会因为紧张，犯各种低级错误，也可能时运不佳遇到电脑问题或网络问题。做好充足的心理准备以应对各种意外。

面向特定人群（比如新人培训）分享时，也可以考虑Workshop的形式。Workshop 有点类似上计算机课程，通常只安排少量的演讲和演示，用精心设计好的的实现步骤带领观众一步一步实现，以获得相关知识点。

当内容较长，一个人准备较累时，也可以拉上小伙伴一起分工合作，减轻负担。这样的分享在谷歌大会上就非常常见。在准备分享的同时还可以交流学习不同思路，及时获取反馈。

选择分享的结构

像写作一样，分享也需要用结构化套路，即如何安排分享内容的先后顺序、开头结尾等。合适清晰的结构可以让整个分享变得更有条理，更引人入胜。

以下列举几个常见也容易上手的结构，合理搭配使用的效果更佳。

金字塔形/树形

顾名思义，这个结构从一个点出发，列举几个关键点，再由各个关键点深入细节。这种结构非常适用于介绍一个新产品，讲解一个知识点，论证一个观点，谈论对于一个话题的思考。

你可以从一个被人熟知的知识点出发。像这个CSS Houdini的分享。

你也可以从一个观点、一个话题出发。像这位仁兄的An Effective Code Review。

你也可以从一个悬念，一个疑问出发。经典如乔帮主的 iphone 发布会，充分吊起大家的好奇心，再逐步深入讲解。

时间轴

时间轴结构就像讲故事一样，根据时间先后复述一些经历，非常适用于分享解决方案的形成与演进，一个项目的完成过程等。

比如像尤大在 JSConf 上讨论他对框架设计上的思考的分享——Seeking the Balance in Framework Design。

再如一位小哥在 ReactEurope 上分享他用 CodeSandbox 的经历——A year of CodeSandbox。

What? How? Why?

什么？怎么做？为什么？这三个经典的问题又称黄金圈。任何一样东西都可以从解答这三个问题来解释。

回答的顺序却决定了效果的不同。

拿乔帮主的 iphone 发布会来说，乔帮主先抛出了 Why——即苹果不断革新的宗旨，然后缓缓道出 How——即将上网、听音乐、打电话在一部手机上实现，吊足了观众的胃口后揭示 What——iPhone 神秘的面纱。思考一下，如果乔帮主先说我们介绍新品 iPhone，它的革新是怎么怎么样的，为什么推出这款产品就变得索然无味了。

先列大纲

同写文一样，分享也建议先列大纲后填内容。

**列大纲可以整理一遍思路。**思路不够清晰、完整的时候，填充的内容会显得杂乱无章。东一块西一块，该讲的重点的没讲，上下联系不够紧密，都会让听众感到云里雾里无法享受你的分享。

**列好大纲也可以让我们在比较长的准备周期中不偏离重点，按照原有的思路进行。**对我们忙碌的程序员来说，很少有大块连续的时间来一次完成一整个分享，有了大纲后就可以拆成小块利用碎片时间填充完善。

填充内容

有了大纲后填充内容就变得顺其自然，轻松很多。然而光填充是远远不够的，还需反复斟酌。

任何东西的初稿都是狗屎。 ——海明威

首先来一轮删减。分享的重点足够突出吗？有没有被不重要的内容喧兵夺主？整个分享的时长有没有超过 40 分钟？如果你只有 15 分钟可以怎么讲？

研究证明人类的专注持续时间可以有 15 分钟，极限是 40 分钟。也就是说大部分人听了 15 分钟之后思维就开始飘，讲多了没有用。所以 TED 演讲都控制在 15 分钟以下，这个时限“逼”演讲者只专注于重点，摒弃一切可有可无的内容。

然后以目标观众小白级别的角度去体验是否容易理解。表述是否清晰明确？目标观众是否能理解缩写和专业名词？配图和示例是否一眼能让人明白用意？

对于自己烂熟于心的内容我们往往有无法设身处地体会到的“盲点”。那何不找一位熟悉的同事、朋友，甚至家人演练，获得即时反馈并改进？

再进一步，思考一下哪一步可以加入一些互动环节？自导自演哪怕干货多多也始终会让人觉得无趣。

你可以让用过的听众举手（线上可以发弹幕、聊天室发消息之类）。也可以问一个问题、给出一些选项让观众现场答题。还可以分组讨论 10 分钟再一起分享讨论结果。

刻意练习，在反馈中提升

任何技能都可以通过多练习得到提升。但要想少走弯路，需及时获取反馈并调整。

在上文中有提到可以找一位熟悉的同事、朋友，甚至家人演练，演练的同时可以获得反馈并当场调整。平时也可以自己对着镜子练习，可以以观众的角度直观地看到自己的面部表情和肢体语言是否达到理想的状态，比起对着别人讲也不会那么紧张。

除此之外还可以通过分享后匿名问卷调查的方式获得一些反馈，顺便鼓励培养团队的反馈文化。

如果情况允许，还可以与分享组织者共同发起这些活动，建立一个反馈闭环，长远来看好处多多。

跨出舒适区的第一步总是最难的，跨出去之后能坚持走下去的总能获益匪浅。不论是以上主动获取反馈的方式也好，通过临场观察观众反应被动获取反馈的方式也好，提升自我的路上总有不顺的地方。把这些让人气馁的“拦路虎”都看作挑战一一克服，相信有一天你能成为大会上闪耀的大神。