你好

第96节 OpenIM 远程工作团队协作协议 v1.3


❤️💕💕记录sealosopen in new window开源项目的学习过程。k8s,docker和云原生的学习open in new window。Myblog:http://nsddd.topopen in new window

[TOC]

OpenIM 远程工作团队协作协议 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 频道中提前说明。如果是紧急情况，也需要提前在insider频道中告知大家。

“工作时，请确保在线。若需离线，务必在Slack #insider 频道提前通知。”

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小时内没有思路，我们就需要借助外部力量了。

“当遇到问题，如果1小时内不能自己解决，请与同事讨论。2小时内与同事未能解决，提升至团队讨论。若3小时内团队未能解决，考虑寻求外部帮助。”

A）3PS Update

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

“3PS进度更新”和调整描述：“在更新工作进度时，分享你的计划(Plan)，优先级(Priority)，遇到的问题(Problem)，以及工作摘要(Summary)。”

B) Disagree and Commitment

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

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

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

“在团队决定之后，即使有不同意见，也需要全力支持团队的决策。”

OpenIM Remote Team Collaboration Protocol v1.3

Principles

0) Ownership & Leadership

When you see issues with the team or project, don't wait or endure. Speak up immediately, propose solutions, initiate a meeting yourself, and adjust promptly. Don't suppress your concerns!

"Every team member embodies the roles of both Owner and Leader. When issues arise, be proactive in pointing them out and offering solutions. Don’t just wait or stay silent."

1) Initiative

Everyone must take the initiative. Whether it’s about starting something or claiming a task, if you find yourself idle, proactively identify problems and areas of improvement. Innovation stems from this. If there’s no path, pave one yourself!

"Drive innovation and improvements for the team."

2) Objectives Oriented

Everyone is a product manager and project manager. Everyone needs to link their work to our broader objectives, understanding what's crucial. Two main things matter: 1) From the user's perspective, 2) From the product's perspective. This means we must always observe the entire product, not just our specific segment.

"Always maintain a dual perspective of users and products, ensuring that work aligns with the overarching goals."

3) Insists on High Standards

Aim high, achieve the middle; aim for the middle, fall short; aim low, miss altogether. We must persistently hold ourselves to high standards, not compromising on these high objectives, but being flexible in our approaches and strategies.

"Always maintain high standards, ensuring quality. Be flexible during the execution, but never compromise on the ultimate high standards."

Practices

0) Online

You must be online when working. If you go offline, notify others about the duration. For communication, we use Slack. If you need time off, unless it's urgent, inform a day in advance on MegaEase's Slack #random channel. In urgent situations, notify the insider channel.

"When working, ensure you are online. If you need to go offline, notify in advance on Slack's #insider channel."

1) Documentation Driven

Face-to-face conversations, calls, WeChat, and Slack provide real-time feedback, but only documentation offers structured vital information. Writing documents also facilitates deeper thinking as it allows you to scrutinize your ideas. Hence, crucial "functions", "processes", "business logic", "designs", "issues", and "ideas" should ideally be documented. Use tools like Github's wiki, project, issue, or Google Doc.

"Ensure key information is persistent and traceable."

2) Design Review

For critical tasks or issues (everyone can discern what’s vital), share your ideas first before implementing.

A good design document should include:

  • Background: Context, requirements, and problem description.
  • Objectives: Aim and significance of the task.
  • Alternative Solutions: Provide various solutions and compare their pros and cons.
    • Reference: Solutions must have authoritative references.
    • Data: Solutions must be backed by relevant data.
  • Conclusion: Final takeaways.

"Before initiating, ensure that you share your ideas with the team and gain consensus."

3) Simplification & Automation

Simplification and automation are two main goals in software engineering. Simplification isn't about being simplistic but about abstraction and induction, enhancing software reusability and scalability. Automation showcases engineering prowess. In remote work, automation boosts team efficiency, and on the other hand, it's a prerequisite for scaling. Therefore, we must always think about how to simplify and automate existing tasks.

4) Review & Re-factory

Everything, be it code or work processes, requires introspection and refactoring. Introspection is the key to improvement. At the end of a project or when issues arise, call a team meeting for collective reflection. Keep the good practices and optimize the rest. But any optimization must be actionable.

5) Milestone Commitment

For every project, everyone should have their own milestone plans. These plans ideally should be within a week, but definitely within two weeks. And they must be committed to.

"Ensure milestones are set and adhered to for every project."

6) Evidence Driven

All discussions and analyses should be based on authoritative evidence, data, or references. When designing or in disagreements, the best way to persuade others is by presenting evidence, data, or authoritative references. If debates go on endlessly, stop and collect supporting evidence for your arguments.

7) Demo Day

Show and tell with the team what you've created. This helps developers think about their work from a product perspective. Besides product features, you can also showcase algorithms, designs, and even codes.

"This encourages team members to learn from and share with each other."

8) Effective Meeting

Meetings primarily deal with three things: proposing agendas, identifying problems, and reaching conclusions.

  • Meetings should have more than just topics; agendas are even better.
  • Meetings shouldn't solve problems, just identify and track them.
  • Meetings must reach a consensus and conclusion. If not, treat it as a problem for the responsible individual to handle.

For weekly or ad-hoc team meetings (excluding private discussions), the meeting organizer should gather topics in advance, categorized as:

  • Project-Based: A prior project progress plan is required.
  • Solution-Based: Relevant designs must be prepared before discussions.
  • Problem-Based: Problems and solutions must be documented.
  • Decision-Based: The context, repercussions, and a pros-cons analysis should be available.
  • Information-Based: Necessary details should be prepared.

Meeting organizers should send out meeting topics by Friday.

"Ensure that every meeting is efficient and productive."

9) 1-2-3 Escalation

When facing problems, if you can't find a solution within 1 hour, discuss with others. If after 2 hours of discussion there's no resolution, elevate it to the whole team. If after 3 hours the team hasn't found a solution, it's time to seek external assistance.

"When encountering problems, if you can't resolve them within 1 hour, discuss with colleagues. If it's unresolved after 2 hours, escalate it to the team. If after 3 hours the team can't find a solution, consider seeking external help."

A) 3PS Update

When updating progress, make it more meaningful than just a check-in. At the end of a task, summarize your work. Practice the 3PS – Plan, Priority, Problem, Summary – What's your plan? What's the priority? What problems did you face? What's your current task summary?

"During progress updates, share your Plan, Priority, Problem, and a Summary of your work."

B) Disagree and Commitment

During development, team members will have different styles and opinions, leading to disagreements. We encourage disagreements, but only before a team decision is made. Once a decision is made, all must support and contribute towards it. However, the decision-making process can be filled with debates. Guidelines to handle disputes include:

  • Owners must push forward significant discussions, aiming for swift conclusions.
  • During decision-making, minutes must be updated to Github's related project Issue or Pull Request

END 链接