这大概是全世界最后一篇 2020 年的年度总结了吧？（而且还是上篇_）

首先要跟各位催更的朋友道个歉。由于年初需要全力准备晋级答辩，所以一切其他不紧急的事务都尽量被我延后了，包括这篇年度总结。今年的客户端组答辩是定在了春节后，所以整个春节我几乎也没有休息，一直在优化和排练我的 slides 。一直拖到答辩结束，这才开始能腾出时间来完成这篇总结。

总的而言，2020 年是非常特殊的一年，对我而言更是如此。这一年有很多的酸楚和困惑，但也迎来了很多新的转机和希望。

特殊的年份要有特殊的总结方式。按照惯例，这次的总结依然会分几个主题来回顾：正经事（工作、开源、博客），不正经事（居家、旅行、游戏、健康、看书、感情）。但因为我再过几天就要去做个近视激光手术，预计术后会有一段时间不能盯着屏幕，而直到现在我的总结都还没赶完。所以为了避免这篇总结被拖到 2022 年，我把这次的总结拆成两篇:dog:。

本篇是上部分：正经事部分。

工作

2020，千里之行

2020 年最让我感慨万千的就是工作部分。因为各方面的原因，在这一年我的职场生活经历了一场大变动，我也因为这场大变动成长了很多。

先说下疫情期间做的事情吧。 因为春节期间疫情加剧，所以课堂在春节期间就打响了 “停课不停学” 的战斗：紧急开发课堂极速版和课堂 iPad 版。作为兄弟团队，我和组里的另外两名高工也参与了这一场战役，现学现卖 Flutter ，协同完成了课堂 iPad 版第一个版本的开发上线。

那段期间，虽然我们是在家办公，省去了很多通勤时间，但是因为时间很紧（iPad 版半个月内上线，开发时间只有不到一周），所以我们每天几乎都过着接近通宵的爆肝生活。

奋战到天明

近半个月的奋战虽然艰苦，但现在回想起来，却又多了一种革命情感：每个人都觉得自己正在做的事情充满了意义。所以虽然很累，但是大家一起咬着牙坚持到了最后。

职业接锅

也因为那段期间的付出，我们一起拿下了公司级的 “卓越研发奖”、“腾讯战役特别贡献奖”、“腾讯‘同心战役’特别贡献奖” 等多个奖项。

抗疫期间获得的奖项

疫情固然严峻，但在那段期间，组里的成员的流失给我带来了更大的打击。 在 3 月份，我们组立马有 4 个成员因为各种原因提出了离职或者转岗。还有一个同事因为家里发生了一些事情，所以休了两个月。在最困难的时候，我们组从年前的 10 个人缩减到了只剩 5 个人，其中 iOS 开发更是一个都不剩。

坦白来说，自从工作以来，这是最让我感到沮丧难过的一段时间，不仅惊慌失措，还深深陷入了自我的怀疑和否定中。这段期间我甚至因为焦虑而开始失眠。为了对抗焦虑，我脑海里不断回想起卡耐基的《人性的优点》里的办法：

事情的最坏后果是什么？
做好接受最坏的后果的思想准备。
想办法改善最坏的情况，立刻采取行动。

也在 jolt 的建议下，我诚恳地跟 4 个成员进行了交谈，了解了他们想离开的真正原因。通过与他们的交谈，我也意识到了自己在管理上依然存在一些不足：

没有充分沟通绩效结果，并让每个员工都认同绩效评定结果。这是造成其中 2 个成员离开的主要原因。
缺乏倾听，因而对员工的情绪缺乏感知。这是造成另一个成员离开的主要原因。也是我在 19 年的回顾中自我检讨的问题。
没有做好梯队管理，iOS 成员全数流失给团队带来了沉重打击。

事情既然已经无可避免地发生，我就做好了心理上的准备。当务之急就是做好交接工作，并且在这些人正式离开之前招到人。于是我为每个人安排好具体的交接事务和时间点，并且把我几乎所有其他空余时间都用在了捞简历和面试上。让人崩溃的是，那段期间正好碰上我们正在从 Cocos Creator 1.10 升级到 Cocos Creator 2.2，升级后遇到了非常多的兼容性 bug ，而且在系统测试期间各种新发现的 bug 层出不穷。在一个个成员相继离开的情况下，剩下的人要顶着越来越大的压力去跟进修复新增问题，整个项目是否能如期上线充满了不确定性；另外，因为疫情的原因，招聘在这个时候也充满了各种变数：有因为疫情家人不让来深圳发展所以放弃 offer 的，有因为疫情上家公司一直拖着没法办理离职导致无法尽快入职的，有技术面表现优秀但卡在背调没过的，有拿了 offer 后被其他公司截胡的 …… 回想起来，那段期间我的生活几乎像是笼罩着一层雾霾。

不管怎么样日子还是得过下去。因为思维的项目马上要开展了，所以为了解决 iOS 人员紧缺的问题，我从企鹅辅导团队里借了 jaelin 过来支援，拉上 galio 一起研究起了 Cocos + Unity 混合开发的可行性。在最困难的时候，我也承担起了修复 iOS 端 crash 的任务。直到 ez 的加入，慢慢接手了项目里的 iOS 模块，我们才总算度过了没有 iOS 开发的难关。

当然，这样的惨痛经历从长远来看未必是一件坏事，它让我深刻意识到了我在管理方面还存在哪些阿克琉斯之踵，然后痛定思痛去改善这些缺陷。之后我在管理方面做了很大调整：

1. 更加重视与每个组员的 OKR 制定、绩效结果沟通

OKR 制定和绩效结果沟通是每一个考核周期的开头和结尾的两件大事。只有 OKR 制定和绩效结果沟通两个都做好了，组员才能感觉到被重视。这在很大幅度上能减少人员流失的情况。

在 OKR 制定上，除了要能为组员定 “任务” 之外，要充分考虑 ta 的职级发展，当前的工作是否有意义，是否有足够挑战。因此从这一年开始，我会先制定整个团队的 OKR 初稿并公开给全组的人，然后让每个组员在这份初稿的基础上，自己去思考能参与其中哪些事务，自己还想做哪些事情。然后我再组织 1v1 面谈。在面谈的时候，我会重点关注 “产出” 和 “挑战” 两大方面，一方面希望组员能保证有足够的产出，另一方面也希望每个组员的工作也有一些挑战性，这有助于他们的职业发展。

在绩效考核上，这一年我也下了很大一番心思去调整。以往的绩效考核比较依赖主观评定，虽然 leader 对孰优孰劣已经有一把秤，但这个感受对于组员而言是信息不对称的。所以我开始尝试用更加量化的方式来评定每个人的绩效表现。具体而言，我将每个组员的绩效按照需求分（分数占比80%）、全面反馈分以及 leader 考虑因素（是否做出技术突破，是否要申请晋升，人员梯队，当期是否有工作上的重大失误酌情给分）来考量。其中，需求分又围绕需求价值、贡献度、完成质量，并结合工作量、难度、效率来综合计分。虽然这样打分非常地累，但是这样的量化调整，可以在团队里释放一个信号：大家是公开平等地接受同一个标准进行考核；同时在分数评定完后，还可以清晰地看出每个人在这次考核周期里的亮点和不足，并以此作为绩效沟通的内容。目前来看，组员们对这样的考评方式接受度挺高。

2. 注重倾听，权力下放

在这一年我所做的另一大改变，就是在处理一些任务的时候，也多向组员请教，或者将权利下放给更适合的人。

在具体落实某个工作的时候，我会更加积极地问自己两个问题：“这件事情怎么才能做得更好？有没有能把这件事做得更好的人？”。

比如，在推动团队申请专利和双周技术分享制度建设方面，我授权给了 driver 来组织，而我需要做的事情是在经费等资源方面尽力给到支持。再比如，团建则交给了 yujie 和 cool 来组织，我则尽力避免做出任何决策。具体执行下来，发现效果比我预想的还要更好，大家也都非常满意。

与组员的 1v1 沟通也成为我非常重视的环节。尤其是新人刚来的前三个月，一旦新人收到要跟上级沟通的邮件，我都会非常乐意约他去喝杯咖啡聊聊他的工作感受甚至生活近况。

说到倾听，去年参与了公司组织的一个培训《教练式领导》，这个课程提倡使用 GROW 模型来展开辅导：

Goal：你的目标是什么？
Reality：现状是什么？
Options：目前有哪些可选方案？
Will：你想怎么做？

GROW 模型

这种理念给我带来了比较大的启发：一直以来我比较喜欢深入到方案细节，对组员提出的方案指点较多。但实际上这并不是好的授权：责任又落回到了我身上。不仅限制了他们的发挥，我也会很累。所以在这一年我在许多方案的决策上，我也尽力使用教练的方式来辅导，让组员能够更大地发挥他的才能。

3. 加强技术氛围建设

技术氛围建设也是去年我在团队管理中重点投入的部分。

前面提到我把专利事务和双周技术分享制度授权给了 driver 来组织。以双周分享制度为例，在征求大家的同意的基础上，driver 制定了一个半强制性的分享制度：要提晋升，需要有 1 到 2 次技术分享。同时，每次分享都会提供零食和饮料，以确保大家有充足的能量可以聆听。

从去年下半年开始施行至今，我们已经进行了 12 次分享。分享的主题涵盖了工作中用到的 Cocos Creator 开发、Native 端通用技术、Git、GPU 编程等，也有个人创业、游学经历、专利撰写、脑机开发等等方向的心得体会，题材五花八门。

组内技术分享

除了内部分享，去年我也在思考怎么加强和外部团队的联系和交流。因为公司里也有其他不少使用 Cocos Creator 开发的团队，所以我建了个内部企微群，把这些团队里的人拉到了大群里互相交流。后来我转念一想也许可以把大家拉到一起做点事情，因为既然大家都用 Cocos Creator 进行开发，难免会遇到很多共性的问题。所以，与其烟囱式踩坑，还不如中台化，我们做一套可以给多个科目、业务复用的架构，这样就能提高每个科目或者业务的质量和效率。于是，我拉上群里的大多数人搞了个线下面基，号召大家一起成立了一个 oteam ，一起做一套 Cocos Creator 的通用组件库 ABCKit 。现在这个 oteam 已经进入孵化阶段，而且第一个版本已经在公司内部开源。

ABCKit 通用组件库

在这一年我们跟 Cocos 社区也有更加密切的互动。先是 BigBear 过来我们这做了一次技术交流；之后我也以 Cocos 社区 KOL 的身份参与了 Cocos 十周年的庆祝活动，并在 Cocos 开发者沙龙上分享了我们所做的基于 Cocos Creator 和 ABCKit 的高性能、高效能的在线教育应用解决方案。

与 Cocos 社区的互动

跟 Cocos 社区的互动带来的一大好处是拓宽了团队的技术视野，能够更加清楚整个业界大家都在做什么，都有哪些大佬，最近又有哪些值得关注的技术。

以上就是去年一年下来我在工作上比较大的一些感悟。现在我的团队已经从最困难的时候的 5 人小组发展成了一支拥有 16 个正式员工的大军。在这 16 个人中，高工占了将近一半；另外还有另外三位 Cocos 社区 KOL 加入了我们团队，战斗力爆表。我也终于在工作生涯的这第 6 年获得了正式任命。现在回想起来，颇有一种 “拨云见日” 的感觉。

Bruce Tuckman 在 1965 年将团队发展模式归为 4 个阶段：

形成期（Forming）
风暴期（Storming）
规范期（Norming）
表现期（Performing）

目前来看，我的团队在去年已经经历了风暴期和规范期两个阶段。今年预计将会进入表现期，值得期待。

开源

2020 年的格子图

今年主要参与了几个项目：

| 项目名 | 简介 | 去年的工作 |
| ----- | ----- | --------- |
| rhubarb-lip-sync-ccc | 一款专用于 Cocos Creator 的嘴型动画生成插件，它可以根据一段语音生成嘴型动画的 Animation Clip 。适合用于制作游戏角色的说话动画。 | 新开源 |
| FedML | 主要用于学术研究的联邦学习（Federated Learning）库 | 新开源 |

rhubarb-lip-sync-ccc

Lip Sync 技术是指根据语音生成嘴型动画的一种技术，通常用在游戏或者动漫的角色制作上。与 Unity 上有很多 Lip Sync 的插件的情况相比，Cocos Creator 生态中似乎还缺少 Lip Sync 的方案。所以我在 DanielSWolf /rhubarb-lip-sync 的基础上添加了对自动生成 Cocos Creator 的 Animation Clip 的支持，为 Cocos Creator 社区贡献了第一个 Lip Sync 插件 rhubarb-lip-sync-ccc 。

Demo：https://www.bilibili.com/video/BV1V5411G7cm

去年 7 月份的时候 Chaoyang 找上我，希望我能够参与到他的 FedML 项目中，帮助他一起推广和维护这套联邦学习库。在了解了联邦学习的特点后，我觉得它将会是未来一个非常重要的机器学习技术方向，所以接受了他的邀请，在业余时间参与了 FedML 的一些维护工作。

FedML

因为那段期间也是我非常忙碌的时候，所以实际上我的贡献并不多，只是帮忙从规范化运营开源项目上给了一些建议和支持。例如帮忙搭建了文档站点、选用 License、设置代码质量 CI 以及设置捐赠信息（我也给这个项目捐赠了 25 刀 :santa: ）。

FedML 拿到了 NeurIPS 2020 的 Best Paper Award

博客

整个 2020 年基本没发过博客，我已经可以预计这个博客站点将会彻底沦落为我的年度总结站点……至于去年提到的写书计划，也因为去年的人力变动以及 Cocos Creator 版本升级被暂时搁置了。我已经开始跟出版社取得了联系，等 ABCKit 对外开源后，我们就会重启这个写书计划。希望最迟在明年我们就能够完成这个小梦想。

关于博客还有一个非常让我不满意的事情，就是 hexo server 在文章数量多了之后渲染速度非常的慢，这还是在我已经把 cache 模式打开的情况下。每次改一点东西，等站点重新 render 要接近 20 秒的时间。这大幅影响了我写作时候的流畅感（嗯，这也是我一直不发总结的借口:dog:）。我需要在这篇总结完成后去优化一下这糟糕的体验。

现在改一次东西需要等待 Hexo 近 20 秒的渲染

（下篇待续）