【转载】远程办公文化思考

2020 年是个不平凡的年，在年后，很多单位因为疫情的原因，不得不开启了远程办公的新模式，这种新型的办公方式也给我们带来了新的碰撞。这篇文章聊聊关于远程办公的文化。

网络技术大神陈皓（网名“左耳朵耗子”）创办的 MegaEase 公司，从初创到现在一直都是远程办公的模式，据陈浩介绍，其公司初创时期的 8 个员工来自 5 个城市，现在的 20 多个员工来自 8 个城市 2 个国家，公司的整个文化就是远程办公的文化。陈浩在其博客酷壳中有一篇文章，叫《MEGAEASE 的远程工作文化》，对于其公司的远程办公的经验与感悟做了分享。读后深受启发。本文对陈皓的博文做个摘录，若侵权则删除。

宏观管理

对于远程办公，对于公司领导者的管理能力要求比较高，如果能够解决好管理相关的问题，远程办公还是集中办公，都不是大的问题。对于远程办公需要关注的点主要包括以下内容。

努力找到对的人

人是关键因素，对于远程办公的团队，人需要以下的特质：

• 能够独当一面；
• 沟通能力很强；
• 能够自我管理，能够自我驱动。

具备这样特质的人，可以被称为人才，到任何一家公司都是具有领导力的。因此，远程办公，对人的要求很高，说白了就是需要优秀的人才。

设定共同的目标与使命

因为远程团队不能够经常的见面，比较缺乏交流与沟通，因此，需要团队内所有的人能够对要做的事情有一个统一的认识，具有共同的目标与使命。对于远程团队内的所有人，知道需要做什么，不要做什么，知道取舍。

如果没有共同的目标与使命，就会出现很多不必要的误解与冲突，因此要求领导者花时间花精力去统一团队成员的目标与使命。

倾向使用小团队

因为远程办公的沟通成本的问题，远程团队更为倾向于使用小团队，只有小团队才能驾驭复杂的系统，亚马逊的“两个披萨团队”的文化，就是将整个系统拆分为微服务架构，小团队能够完全自主的管理自己的领域，这样可以大幅提升系统的效率，其表现在，可以并发开发，可以专注于一个功能，可以更利于解决复杂问题，可以更容易的运维，可以更容易规模化，等等。

人数越多的团队，可以说，就越接近于劳动密集型团队，而不是知识密集型团队。对于小团队，因为人数不够，所以整个团队每天都会在想什么事情更重要，什么事情可以自动化，怎么做更有效率等，而大团队不会关注这些，所有做事情的侧重点也就不一样。

微观实践

在远程工作中，由很多微观的实践操作，可以让远程工作的更好。主要包括：

• 文档驱动。远程办公时，对于讨论问题，需要发起人先写一个文档，然后团队其他人员可以基于这个文档进行讨论。比如 git 的 issue，googledoc 等；
• 自动化与简化。从软件的单元测试、功能测试、性能测试、到 K8S 的自动化部署，团队追求提交代码后即自动化上线；
• Owner 文化。即事情按照责任人机制推进，如果没有责任人，则事情逐渐就会变为没人管。
• Review 文化。有效率的开会，仅仅有议题是不够的，还需要高质量的议案，议案包括问题背景、目标、可选方案，方案引用数据等；
• 目标承诺。每个人给自己制定的计划最好是在 1~2 周之内；
• 自我管理。远程团队办公，没有审批制度。休假、出差、报销等均由团队成员自行安排，需要团队成员具有自我管理能力，具有诚信；
• 闲聊与自行见面。鼓励远程团队的成员之间的闲聊与自行见面；
• 知识分享会。每周进行知识分享，每次最多半个小时；
• 就地奖励文化。项目利润，除了公司的部分，其余团队就地分掉，这样可以激励团队成员去想着怎么赢的利润；
• 外包支持性的工作。比如 HR、行政、财务、测试人员、定制化开发等，尽可能的使用外包，这样使得团队的规模保持在最小，团队更内聚，也更利于远程；
• 异步编程。使用 github 这样的协议工作，远程编码会变得很方便。

远程办公工具

陈皓公司的远程办公工具主要为：

• 开发环境。使用 AWS；
• 协作工具。使用 github，主要是 pull request、issue，project 里的看板与 wiki，以及 Google 全家桶，包括 Google、Google Group、Google Driver、Google Docs 等；
• 语音沟通。主要使用 Zoom；
• 工作沟通。主要使用 Slack；
• 吹水群。主要是 Telegram，据说比微信好太多……

当然以上的大部分工具都在墙外，因此还需要一个稳定可靠的科学上网的工具。

远程工作协议

陈皓还分享了其公司的远程工作协议，这是每一个远程工作人员需要同意，并严格遵守的协议，以下为该工作协议的摘抄。

MegaEase 远程工作团队协作协议 v1.3

Principles

0）Ownership & Leadership

每个人都是 Owner，都是 Leader， 如果看到团队或是项目有问题的时候，不要等，也不忍，请马上说出来，并给出相应的方案， 自己跳出来召集开会，及时调整。不要闷在那里，自己憋！

1）Initiative

每人个都必需是主动的，都需要自己发起要做的事，或是自己要认领要做的事，如果发现自己没有事情了， 需要学会主动发现问题，主动找到可以 improve 的地方，创新来源于此。没有路要学会自己造路！

2）Objectives Oriented

每个人都是产品经理，也都是项目经理，每个人都必需把自己的工作和我们大的目标连接在一起，知道什么是重点，重点的东西就是两件事：一）从用户的角度出发，二）从产品的角度出发。 这意味着我们要随时观察整个产品的样子，而不只是自己这一块东西 。

3）Insists on High Standard

举法其上，得乎其中，举法其中，得乎其下，举法其下，法不得也。我们要坚持用高的标准要求自己，对于高标准的目标不妥协，但是在实施路径和策略上可以妥协。

Practices

0）Online

工作的时候必需在线。如果不在线了，需要说一下不在线的时长, 目前我们工作的事宜在通讯工具采用 Slack， 如果需要请假的情况，如果不是紧急情况，需要提前一天 在 MegaEase 的 Slack random 频道中提前说明。如果是紧急情况，也需要提前在 random 频道中告知大家。

1) Documentation Driven

面对面交谈、电话语音、微信、Slack 虽然是比较实时的反馈工具，但是只有文档是可以把重要信息给结构化的，而且写文档其实是比起前面的方式来说是更为深度的思考，因为会让你自己审视自己的想法。所以，对于一些重要 “功能”、“流程”、“业务逻辑” 、“设计”、“问题”，以及“想法”，最好都以文档化的方式进行。请使用 Github 的 wiki、project、issue 这些工具或是使用 Google Doc.

2）Design Review

对于一些重要的问题或是工作（每个人都能够判断什么是关键问题和工作）， 需要先把自己的想法 share 出来，而不是先实现 。

一个好的 Design 文档需要包括如下项：

• Background。交待这个事的背景、需求和要解决问题。
• Objectives。说明这个事的目标和意义。
• Alternative Solutions。 给出多个解决方案，并能够进行 Pros/Cons 对比。
• Reference。方案需要有权威引用支持。
• Data。方案需要有相关数据数据支持。
• Conclusion。结论是什么。

3) Simplification & Automation

简化和自动化是软件工程所追求的两大目标，简化不是简陋，简化是对事物一种抽象和归纳能力，其能够提升软件的复用能力和扩展性，自动化是工程能力的重要体现，一方面，远程工作中自动化的能力可以让整个团队更高效地协作，另一方面，自动化是规模化的提条件。所以，我们要无时无刻地思考如何简化和自动化现有的事情。

4）Review & Re-factory

无论是代码还是工作都是需要反思和重构的。反思是进步的源泉，项目告一段落时，出现问题时，都应该召集团队做集体反思，把好的东西坚持下去，把不好的东西优化掉。这样才能进步和改进。但是任何的优化措施是可执行的。

5）Milestone Commitment

对于一个项目，每个人都需要有自己的 milestone 计划， 这个计划最好是在 2 周以内，1 周内是最好的。而且要承诺到 。

6）Evidence Driven

任何讨论和分析都要基于权威的证据、数据或是引用。在我们做设计的时候，或是有争论的时候，说服对方最好的方式就是拿出证据、数据或是权威引用。比如：我的 XX 设计参考了 TCP 协议中的 XX 设计，我的 XX 观点是基于 XX 开源软件的实现……如果争论不休就停止争论，然后各自收集和调查自己观点的佐证。

7）Demo Day

把自己做的东西跟团队做一次实时的演示。这样有助于开发人员从产品角度思考自己的工作。除了演示产品功能，还可以演示算法，设计，甚至代码。

8) Effective Meeting

会议主要处理三件事：提出议案、发现问题、共识结论。

会议不仅仅要有议题，最好还有议案。
会议期间不解决问题，只发现问题，和跟踪问题。
会议必需要有共识和结论，如果不能达到共识和结论，那就当成问题处理，由问题的负责人跟进问题。
关于周会或是临时性的团队会议（私下讨论不属于会议），会议组织者需要在事前收集会议议题，其中包括如下分类：

项目类：需要事先有项目进度计划表（任何分项最好控制在 1-2 人周内）
方案类：需要事先写好相关的方案和设计才能讨论（参看 Design Review 章节）
问题类：需要事先写好相关的问题和解决提案（参看 Design Review 章节）
决策类：需要事先写好整事的前因后果以及利弊分析
信息类：需要事先写好相关的事宜说明
组织者需要在周五的时候发出会议议题收集，其中包括：

自己知道的项目的进度跟进（需要相相关的项目负责人准备相关的项目计划）
方案和问题类的需要各个项目负责人提出来，并有相关的设计文档可供 Review
信息类和决策类的事宜可以写在 Google Doc 上，也可以写在 Team 的 Issue 里
其它负责人可以在会议上加入自己团队的东西，或是要求其他团队提供更多的信息。

9）1-2-3 Escalation

遇到问题的时候，自己一个人处理 1 小时内没有思路，请找他人小范围讨论，如果与他人 2 小时内没有结果，请上升到团队范围，如果在团队范围 3 小时内没有思路，我们就需要借助外部力量了。

A）3PS Update

每个人更新进度的时候，不要只是一个 check-in，而是需要更 meaningful 的说一下工作内容，在工作告一段落的时候，希望简单的说一下工作总结。这里的 practice 是： 3PS – Plan，Proirity，Problem，Summary， – 你的计划是什么？优先级是什么？遇到了什么问题？当前的工作摘要 。

B) Disagree and Commitment

在我们开发的时候，团队的成员都会有自己风格，必然会对同一个问题产生较大的争议（Disagree），我们鼓励有争议，但是是在团队的决议作出之前。一旦团队形成决议，团队的成员就必须支持这个决议，并在这个方向上做出贡献。

但是关于决议的形成过程肯定充斥着各种的争论，对于这些争论，我们可以按照下面的 Guidline 来处理争议：

Owner 要负责对重大的讨论推进，尽快形成结论。
在决议过程中，要有纪要，要更新到 Github 相关项目的 Issue 或 Pull Request 里，并且要让整个团队知道，信息平等很重要。
不要妥协，坚持高的标准。第一标准是工业标准，第二标准是国外的大公司标准（如：google, fb, github, aws…），第三标准才是国内的标准。
那怕再复杂，只要是标准，就可以说服用户。用户再无理，也不可能反对工业级的标准。
Release 出去的东西，只要被用户用上了，要改就难了，所以要谨慎而果敢。

推荐资料

在 github 上有一些大神整理了远程工作的资料。总结比较全的是中国远程工作资料大全。

最后推荐一本关于远程办公文化的书籍：《Remote》，作者贾森·弗里德与戴维·海涅迈尔·汉森是美国软件公司 Basecamp 的创始人。Basecamp 原名 37signals，是全世界效率最高的软件公司之一，推出并持续维护着世界上最受欢迎的项目管理工具 Basecamp。他们始终保持着“小，美，酷”的特征，维持着小团队规 模，三十多个员工分散在世界各地远程办公，是通过远程方式协同工作的典范。弗里德与汉森合著的第一本书《重来》（Rework）高居《纽约时报》畅销书榜前列，书中推崇的管理理念在国内商业领域也产生了巨大影响。