ZwSe2远程工作团队协作协议v1

背景

经过一个周期两周的远程开发试运行，发现团队还有不少问题，尤其缺乏一个明确的规则指导，之前又看到了左耳朵耗子的《MegaEase远程工作团队协作协议V1.3》觉得很受启发，特别根据团队情况进行了一些微调形成本文。

基本原则

0）责任感 & 领导力

团队中每个人都是 Owner，都是 Leader，
每个人都是产品经理，
每个人都是项目经理，
如果看到团队或是项目有问题的时候，
不要等，也不忍，
请马上说出来，并给出相应的方案，
自己跳出来召集开会，及时调整。
指出来并做起来，
你就有可能改变这个世界！

1）主动性

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

2）目标不妥协

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

3) 透明性

团队中除了涉及到个人隐私以及国家机密的事项，
都可以光明正大的讨论，
团队发展，项目情况，公司政策等信息都将透明的公开，
个人绩效评价方式也是公开透明，
在这里你将有机会证明自己真正的能力和实力。

远程规则

0）在线规则

工作的时候必需在线。
如果不在线了(以十分钟为界)，需要说一下不在线的时长。
同时留下能联系到你的方式，做好onCall准备，
如果不想被人打扰，就在说明上补充上免打扰时间段。
目前我们工作的事宜在通讯工具上采用钉钉，
如果需要请假，如果不是紧急情况，需要提前一天在 钉钉的 #联合团队 频道中提前说明。
如果是紧急情况，也需要提前在 联合团队 频道中告知大家。

扫描二维码关注公众号，回复： 11169331 查看本文章

1) 文档驱动

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

**2) 自动化和简化 **

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

3）证据驱动

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

4）原型优先

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

5) 小步快跑,持续迭代

面对问题不要总试图一次性追求完美，饭要一点一点的吃，事情需要一步一步的做。
要善于将工作划分为一个一个较短的阶段，定期回顾一下，
梳理做的好的地方，总结不好的地方，确定需要小幅改进的点，
在下一个周期中持续的关注改进项，说到做到。
无论是代码还是工作都是需要反思和重构的。
反思是进步的源泉，项目告一段落时，出现问题时，都应该召集团队做集体反思，
把好的东西坚持下去，把不好的东西优化掉。
不断的优化实现和推进组织变革，成为更好的自己。

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

7) 日清

鼓励每日结束工作前，commit-push代码，关闭IDE，关闭计算机。

附录

A）每日站会

每个人在开团队站会时要回答三个问题:1. 我昨天做了什么？2.我今天准备做什么？3.我需要谁的帮助。
团队依次轮流发言，如果有疑问的话，除非你确定是一句话能解释清楚的，那么会后拉人再说，技术负责人维持秩序。
每个人都要打开任务管理工具来进行操作，不提倡代替他人移动任务。

B) 不同意见的处理方式

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

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

Owner 要负责对重大的讨论推进，尽快形成结论。

在决议过程中，要有纪要，要更新到 Github 相关项目的 Issue 或 Pull Request 里，并且要让整个团队知道，信息平等很重要。

不要妥协，坚持高的标准。第一标准是工业标准，第二标准是国外的大公司标准（如：Google, Facebook, GitHub, AWS…），第三标准才是国内的标准。

哪怕再复杂，只要是标准，就可以说服用户。用户再无理，也不可能反对工业级的标准。

Release 出去的东西，只要被用户用上了，要改就难了，所以要谨慎而果敢。

C）设计审查

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

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

Background。交待这个事的背景、需求和要解决问题。

Objectives。说明这个事的目标和意义。

Alternative Solutions。给出多个解决方案，并能够进行 Pros/Cons 对比。Reference——方案需要有权威引用支持；Data——方案需要有相关数据数据支持。

Conclusion。结论是什么。

D) Effective Meeting

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

会议不仅仅要有议题，最好还有议案。

会议期间不解决问题，只发现问题，和跟踪问题。

会议必需要有共识和结论，如果不能达到共识和结论，那就当成问题处理，由问题的负责人跟进问题。

关于周会或是临时性的团队会议（私下讨论不属于会议），会议组织者需要在事前收集会议议题，其中包括如下分类：

• 项目类：需要事先有项目进度计划表（任何分项最好控制在 1-2 人周内）

• 方案类：需要事先写好相关的方案和设计才能讨论（参看 Design Review 章节）

• 问题类：需要事先写好相关的问题和解决提案（参看 Design Review 章节）

• 决策类：需要事先写好整事的前因后果以及利弊分析信息类：需要事先写好相关的事宜说明

• 组织者需要在周五的时候发出会议议题收集，其中包括：

• 自己知道的项目的进度跟进（需要相相关的项目负责人准备相关的项目计划）

• 方案和问题类的需要各个项目负责人提出来，并有相关的设计文档可供 Review

• 信息类和决策类的事宜可以写在 Google Doc 上，也可以写在 Team 的 Issue 里

• 其它负责人可以在会议上加入自己团队的东西，或是要求其他团队提供更多的信息。

参考

1. 《MegaEase远程工作团队协作协议V1.3》