PingCAP CTO 黄东旭：远程办公 5 年，分布式解决所有问题
The following article is from TGO鲲鹏会 Author 黄东旭
//加入技术琐话读者群讨论，请在公众号回复关键词：读者群。
而相较之下，近期因为新冠疫情蔓延而倒逼形成的无数个短期“远程协作团队”中，一些团队 Leader 或感不适，不适的原因有很多，员工自驱力、远程期间的目标如何统一、每日如何 Check 大家的工作成效……这些问题中，有的已被较为成熟的“分布式团队”经历并验证过，他们已摸索出一套行之有效的方法论来解决。
PingCAP 在工程师远程办公经验上实践了快五年，对于 CTO 黄东旭来说，PingCAP 和他自己都积累了一套“远程办公管理哲学”。为了将这套哲学思考及经验分享给大家，特别是远程新手团队，帮助大家更快更高效地落地“远程协作”，TGO 鲲鹏会对黄东旭在《鲲鹏说》直播栏目中分享的内容进行了全文梳理（有部分内容删减），供大家学习、参考。
获取完整版分享 PPT，请关注本公众号回复“远程办公”查收下载链接。
下方为 B 站指路链接，想在 B 站观看的朋友千万别错过「极客时间 B 站官方账号」：
https://www.bilibili.com/video/av87391984
PingCAP 从公司建立之初，就是一家 Remote（远程）的公司。我们三位创始人（刘奇、崔秋、我），都是程序员出身，都对“打卡”等循规蹈矩的形式主义有些痛恨。即使我们现在在北京、上海、杭州等各大城市都有办公室，但依然有很多小伙伴是远程在家办公。在我看来，在哪上班没有什么区别，一个牛的程序员可以顶几十个普通程序员，但牛的人不一定只在北京、上海这种大城市。因此，PingCAP 本身其实是一家“分布式公司”。
曾经就有一个例子发生在我们的面试环节：PingCAP 的首席架构师唐刘非常厉害，在面试结束时，他提到他的老家在珠海，因此就特别问我说，是不是一定要搬来北京上班。我当时说，“你在哪里上班这都不算什么，在哪上班不都一样吗！”所以，他后来加入了 PingCAP，这件事情后来也成为了一段佳话。
那总的来说，我们为什么拥抱“远程办公”呢？
1、人才。远程办公这个事情，如果你把放在公司招聘的条件里，它其实是对人才的一个特别吸引点。当然，因为我今天的整个分享仅限于研发团队，偏运营或偏向外拓展的一些岗位或团队可能不太适用这个背景条件。
2、提升效率。“远程办公”能让员工更专注于任务，减少中断。从 PingCAP 的实践经验来看，远程办公团队的效率其实高于在线下办公室里的协作效率，因为大家会更方便地专注于手头上的工作。
3、节省隐形成本。至少节约了通勤、办公室成本和扩张新市场的成本，所以其实对我们来说，远程办公其实是非常正确的一个选择。然后这里有个问题，就是什么样的公司适合和什么样的公司不适合远程？我个人觉得，如果你的公司完全是脑力劳动者为主，或者说是基于创意的如设计师、研发这样的团队，其实是我觉得是更适合远程的。
大家如果对美国的公司比较熟悉会发现，基本上美国现在绝大多数的公司（尤其科技公司），其实全都是远程办公了。不远程的话，一是招不到人，二是在应聘者看来，你的公司一点都不酷，别人不会去的。
所以，今天我会更多的从团队的管理者、创始人或者高管团队的角度跟大家介绍。如果你想要在未来打造一个长期的远程团队、远程文化的公司，或者说一个更敏捷的公司，或者说你的研发团队，想去模仿像我们这样的模式的话，你应该从哪些方面去思考，去重点看哪些东西，而不是简单地就教你 Slide 或者某些工具该怎么用。
工具这种东西都很简单，但关键是内功心法。
或者说，当你远程的时候，你该怎么去跟进这些事情的进度、如何去沟通开会、重要的流程应该怎样去管理……我认为这些东西是更重要的。所以，我们在最早期的时候就思考了一个问题（包括大家也可以思考一下），我们自己的团队、我们的公司、我们的产品最核心的竞争力是什么？
后来我们思来想去，核心竞争力并不是我们数据库技术有多牛。其实大家竞争的就是人才，一切事情都是人做的。
所以，当你的公司把人放在最高的位置的时候，公司的制度怎么设计，做事情的某些方式是不是符合人的直觉甚至是不是反人类……这很重要。PingCAP 目前整个公司的规模近 300 人，研发团队超过总人数的 2/3，我不确定规模更大公司的适用度，但至少当前 PingCAP 用这套“远程管理”方法论 work 得很好。
另外在招聘上我们也有一个原则——我宁可用花两个人的钱去招一个特别牛的人才，因为牛的人可能能迅速 cover 住原本三个人的工作。 我宁可招不到，也不太喜欢降低招聘的标准，也不希望招一个与我们文化、思考问题的方式、气质不太一样的人。
在招聘这一关上，有很多公司总说为什么招不到特别好的人才。其实很多时候，每个人口中都说重视，重视招聘或重视人才。但你可以去看看 CEO 或者 CTO 的时间表，你一天中有多少时间花在面试上的？
组织结构与制度原则
同时，只有人才是不足够的，还必须将他放到一个好的组织架构下，才能很好地发挥他的才华。PingCAP 从公司创立开始，我和刘奇就在想，我们应该做一个什么样的公司？
既然是程序员，我们就应该做一家“分布式系统公司”。然后我们就开始思考，分布式系统有什么特点，例如如何”避免单点“，哪些分层测试能调，什么样的系统能 scale，什么样系统不能 scale……我们最后的思考是，一切依赖人的系统都是不能 scale 的。比如，做一件关键的事情，做一家牛的公司或一个牛的产品，如果依赖的是一个特别牛的程序员或特别牛的 CEO，这个事情就是不能 scale 的。
这个背后的逻辑是，你在做任何组织架构调整时，一定尽量避免成为单点。换句话说，一个人要升级成 Manager 或团队 leader，他最重要的能力，是要把自己的能力赋予别人。我不希望作为 Manager 或团队 leader，他只有个人能力特别强，组织能力特别好，或者说他把团队管得特别好。这些在我们 OKR 里其实都不是最重要的，最重要的能力之一是赋能。
所以，我们去做员工个人考核的时候，对于团队 Manager 的考核标准是，有没有培养出优秀的后辈。或者说，在每个人工作时，一个很高优先级的后台任务，应该是想着如何培养接班人。其实这是很特殊的文化，至少是我们自己摸索出来的。
PingCAP 的组织架构更倾向于建立比较机动的小团队，使用小团队协作。
当然，我们会有比较大的虚拟团队，比如说 TiDB 的 SQL 层、存储引擎层等等，每个团队 30-50 人，但每天协作的小伙伴可能也就三五个人。因此，对于这种大的虚拟团队，我们内部其实还会再做一次二级划分，就是尽可能让每一个小伙伴不做太多跨团队的工作，并且尽可能减少每人之间跨团队的工作。
另外，组织架构要尽可能扁平。在 PingCAP 内部，从一线 Engineer 到我，一般就两层职级关系，中间会有一些 Manager 或 TechLead。所以，我们的目标管理和绩效考核其实是是分开的。
在目标管理和绩效考核中，我一直认为，OKR 不是 KPI，不能用来考核。有些同学会（在弹幕里）说，公司在提交考核中写了 OKR，但每次落地时候都感觉和 KPI 差不多。这就是明显把 OKR 用错的例子。很多时候你会发现，KR（Key Results）和 O（Objections）并不完全对等，比如 KR 完成但 O 没达成，或者 O 完成了但 KR 没实现。
那么，推 KPI 的“劣势”和推 OKR 的“优势”各是什么呢？
从我的经验来看，第一，如果团队每个人对自己的 KPI 拆解的不太好，就有可能会发生跨团队“打架”的情况。当 KPI 出现“打架”情况的时候，一定是员工各扫门前雪，就会有各种各样的内耗。第二，在推行 KPI 的时候，一线的员工其实对 KPI 为什么是这个样子很难理解，然后大家的目标可能就变成了，我要完成 KPI。
所以对比之下，OKR 的好处之一就是 OKR 的制定过程和背后的逻辑关系，包括每项大的 OKR 拆成小的 OKR，这背后一定是全员参与的。
整体来说，不管是 OKR 还是 KPI，尤其对于一个远程团队或像 PingCAP 这样的敏捷团队来说，在目标管理这件事上，“开放透明、让每个人都能理解目标背后拆解的原因是什么”，每天做事的时候，整个公司的大目标是不是往前推进的，这个其实是我觉得特别重要的。
千万不要把考核或者升职加薪和 KPI、OKR 绑在一起。我们整个考核体系其实是另外一套完全的不同的考核体系。也就是说，可能你团队的 OKR 完成一塌糊涂，但这个人照样升职加薪。我分享了一篇特别好的对工程师团队绩效考核的文章，当时看到的时候特别有感触，推荐大家也看看（文章链接：https://blog.pragmaticengineer.com/performance-reviews-for-software-engineers/）。
像我们这样的组织，在做规则制定的时候有两个原则，
一是基于「信任」而不是「监督」的角度做规则的设定；
二是一定要公平，规则设定以后，不管你是 CEO 还是创始人，还是一线员工，都要遵守。
以 PingCAP 为例，PingCAP 的分公司（各地 Office）其实是作为虚拟组织存在，Office Manager 的职责更偏行政（office manager 本身可能也负责管理其他职能团队，也属于其他团队的 TechLead）。
在远程协作中，如果工程师对任务拆解得不够好，或者中层管理对任务的 Trace（跟踪）能力不强，任务拆解粒度不够细或不科学，就很容易发生崩盘，团队一下就散了。
所以，我们对腰部力量的管理或者说能力的要求非常高。我觉得在一个实行远程办公的公司里，中层腰部力量很重要。
去年对我影响最深的一个思维方式是“抓重点”。把一个事情的重点抓对了，你就会发现有的时候其实能事半功倍，所以你想的时间比较长，做预测的时间就会短很多。
我教大家两个锻炼“抓重点”能力的方法：
你直接思考手头上的事情，如果你只挑一件事情做，会选哪件？
其他事都不做了又会怎么样？
你把这些利弊想清楚，就会发现很多动作不会“走形”了。
很多时候，不挖到最下面是挖不出水的，但很多公司都是左一铲右一铲，这也是有些公司为什么会死掉的一个原因。所以大家可以去看，一个公司快死的征兆，可能就是它开始去做 10 条（虚拟数词）产品线了。
第二，有很多管理者比较喜欢关注细节，但我个人不太关注特别的细节。你只要告诉我，对于这件事情你觉得最大的风险点是什么？你把风险能够跟你的老板说清楚，或者说你作为老板考核员工的时候，他能把这个事情的风险 ABC 能说清楚的时候，就够了。一件事情，最重要的重点是风险。
第三，远程团队因为线上联络多于线下，所以信息传达可能会存在失真的情况。特别是在制定战略的时候，随着层级之间下达而产生的信息降级，可能很容易产生事情执行过程中，走着走着就走偏了。这里，我也提供一个很接地气的经验，叫“抓头抓尾”。
所谓“抓头抓尾”，就是指传达事情的时候，第一步是跟第一级高管说清楚要这么做，三天以后找一个一线的小伙伴也聊一聊，你觉得这个事情你怎么看？如果他的说法和高管传达的不一样，说明中间肯定有地方脱节了。然后你再去反向递归哪一层出现了失真。
这个方法很适用，前几年 PingCAP 会因为信息失真发生很多问题，原因就是很多中层在“信息拉平”上的能力还没有提升上来，后来当把信息拉平对齐的时候，会发现大家真的能一条心，执行效率和方向就都对了。
第四，Be a coach。这一点其实是对管理者的，我刚刚也说了，你最重要的能力是去教会下属。但如何评估学和教的效果？比如今天你听了这堂课，那么我建议你回去是不是可以开一个分享会，专门分享今天我们讲的远程办公实践，如果你分享的东西你的小伙伴听懂了，那么我觉得你是真听懂了。
第一，透明。
第二，结论文档化。
第三，「饱和式」沟通。
透明这个词有时候很难量化，或者用一个具体事情评估公司的透明度。比如你的产品说明文档没有组织也没人维护，其实这样的透明是没有意义的。
所以我觉得：
一是所有结论性的内容最后都要落成文档；
二是要求文档必须能在类似 Confulence（专业的企业知识管理与协同软件，也可以用于构建企业 wiki）的系统里能索引到；
三是每一个项目，尤其是一级项目，都必须有一个巨大的“作战地图”，在这个地图中，你能看到所有的主任务、每项主任务对应的负责人、事情完成的进度、这个项目对公司整体的影响到底有多少……所有的负责人每天都会更新这个“作战地图”或“文档”，项目成员可以直接在文档中修改内容，或者可以直接做一些 Comments。以项目来驱动时，最重要的一点就是构建“作战地图”。
另外一个工具层面的 Tips 就是工作日历。
我一般会订阅一线管理团队的日历，我会看到大家这几天的事项，然后查看哪些会议是我需要参加。这也是透明的一部分。特别是在工程师团队，作为 Leader，有些事情和信息你是要去推送的，但有些事情应该是用“拉取“的方式，有效做到“推拉平衡”。
同时，远程团队的远程会议礼仪也很重要。
第一，我建议大家会前发 Agenda，会后发 Meeting Notes。特别是在线上做头脑风暴的话，我们一般会用 Google 或石墨这类在线共享文档工具，将提前需要讨论的内容先报一轮。
第二，忌开大会和长会。我们内部有一个要求，一件事情一句话能说明白，或能用大白话讲出来的是最好的，不要讲一大堆理论。当然，有时候冗余的会议也有必要，因为在远程的时候，信息拉平很重要，你要确保别人跟你想的是一样的。
团队至少以周为单位进行例会，每个人同步各自的进展，但切记不要在这类会议上做重要决策。有时候有些 Manager 会犯这个错误，就是在会议上直接对某些事情下结论。这里想说的是，做技术侧的管理层一定不要凭感觉做决策，区分好 Fact 和 Feeling，接到信息之后，回去想清楚了再做决策通报。不要一拍脑袋说干，一拍脑袋说不干，这样对公司对工作都不太负责。
另外，我们每月都有一个公司层面的全员大会（All-hands），在这个会上，会由一个人或一个团队给大家介绍他们做了一件什么有意思的事情。我们比较 Open 的一个实践是，高管团队和创始人也会对匿名系统中收集上来的员工提问进行答疑，我们一般会挑选匿名系统中员工“点赞”（或顶上去）数排名前 5 的问题来回答。如果你的问题排在第 5 名之后，也可以在会议现场“非匿名”的举手提问。
PingCAP 主要会用到这样一些工具：
GitHub：代码托管，公开的 RFC，社区 Issue 反馈，产品发布，Code Review 等。
Zoom：在线会议。
Slack：即时通讯，机器人消息中枢。
微信、企业微信：即时通讯（没错，我们两个都用，但以企业微信为主）。
在线文档：文档协作，幻灯片，表格。
邮件，日历。
Confluence：内部的文档，包括已成型的设计文档（如内部的 RFC 文档），Wiki 等。
Jira：Bug 和 Milestone 跟踪。
Trello：看板，记录一些重要客户和事件的备忘。
Jenkins：持续集成，daily build。
在远程办公环境下，规章制度一定不是靠人去 Follow 和 Trace，所以我觉得，我们至少在研发上是非常依赖一些自动化的工具，在很多的流程上都用“机器人”来解决。因为远程的时候还需要很多时候借助人和人沟通的话，效率是非常低的。我们有非常多的“机器人”，比如“测试机器人”、“合并代码机器人”等等，以后有机会可以专门就工具的问题再和大家做一个分享。
一些建议和“坑”
最后，是一些小 Tips 让大家在这几天的远程办公中能够更快的适应。
一、保持规律的作息，有仪式感的工作。一定不要躺着开会，这也是一种会议礼仪。
二、善用日历来管理自己的时间。我觉得尽可能地用日历把你的时间规划好，每一个小时你要专注在什么事情上。
三、最好能有独立的办公场所。
同时，远程工作中还会有⼀些常见的“坑”：
一、信息碎片化的问题，各种通讯工具上的信息冗余问题。
二、过劳，远程工作情况下，工作和生活没办法分的太开，所以一个普遍的感受，是感觉在家比在办公室办公更累，过劳大家也需要注意。
三、孤独感，为什么 PingCAP 在各个地方要有办公室？因为至少让大家在精神上有见面的机会，能定期吃个饭，减少孤独感。
四、线上文字沟通时的情绪管理，线上文字沟通的时候，最大的问题就是“没有感情”。比如说你再打出一个呵呵一个这样的这种词的时候，对方会揣测你的。所以有时候要多注意文字细节，多站在多方的角度上想话应该怎么说。
//加入技术琐话读者群讨论，请在公众号回复关键词：读者群。
推荐阅读
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。