默认异步
Source: Dev.to
概览
我的团队有 90 % 的成员是远程工作的。我们花了好几年才弄清楚什么时候开会，什么时候写代码。
行业研究表明，开发者只有很小一部分时间在写代码。其余时间用于代码审查、编写文档、在不同渠道上沟通以及参加会议。这些活动可以归为两类：独自工作和协作工作。两者都很重要。
- 个人工作是指产生代码——也就是产生价值的过程。
- 协作是对个人工作的支持，但通常不会直接产生价值。在人数大于一人的组织中，协作是不可避免的。
真正的问题是： 我们如何在与他人协作和个人工作之间找到恰当的平衡？
实现这种平衡往往是一个挑战。
- 一方面是被会议淹没的技术组织。开发者没有时间写代码，关键的技术工作进展缓慢。
- 另一方面是反会议文化。开发者与业务和彼此之间失去联系，错位加剧，技术债务积累速度超出预期，团队凝聚力受损。
我倾向于通过将部分协作转移到 异步模式 来平衡协作与个人工作。例如：
- 与其召开状态更新会议，不如让每个人在团队的 Slack 频道里写更新。
- 将面对面的架构设计会议转为异步 RFC 审阅。（关于内部 RFC 的更多使用方法，请参见此处：）
异步活动难度从低到高的排序
1. 信息传递
各种报告和状态更新都可以通过 Slack、电子邮件或书面备忘录异步完成。书面更新易于共享，且可以在以后查阅。
2. 问题解决
许多技术问题更适合异步处理。当有人需要输入、反馈或审查时，可以把提案或原型分享给团队，成员在自己的时间里给出想法。这可以减少打断，促成更深思熟虑的贡献。
3. 决策制定
决策并不总是需要会议。如果事实清晰且共识不是关键，异步决策效果很好。当不确定性高或需要明确的团队认同时，同步对话值得投入时间。这是工程负责人需要做出的关键判断。
4. 创新
创新可以异步进行，但最佳创意往往来源于实时互动，如工作坊和黑客马拉松。当目标是创造力时，同步时间拥有一种异步无法完全取代的魔力。
5. 建立个人联系
仅靠聊天和邮件难以培养个人联系；人们在同一地点相聚时才会真正建立联系。线下聚会、面对面会议以及定期的现场交流有助于团队建立信任并更好地协作。两天的线下活动所产生的信任，往往超过数月的 Slack 信息。
实施异步的策略
将计划拆分为两部分
- 启动会（特性或大幅增量）采用面对面方式进行，让团队对整体蓝图有共同的理解。
- 详细技术规划主要通过异步方式（如 RFC）完成。这可以避免过早的深度探讨，同时让个人能够在自己的时间表上完善细节。
每日站会：保留还是跳过？
对于远程团队来说，打开摄像头的每日会议可能是必不可少的——每日站会可能是许多开发者唯一的接触点，兼具信息传递和联络的功能。
对于主要在现场的团队，每日站会可以改为异步进行，同步会议则保留用于解决阻塞问题。
异步 UI 设计评审
我们使用屏幕录制（有时配以语音解说）进行 UI 设计评审。评审请求会设定明确的截止日期并指派评审人。这种方式节省时间并产生更好的结果，因为评审者有时间消化提案。
评估你的协作模式
自问：
- 这个活动真的需要同步进行吗？
- 团队成员之间是否感到足够连接？
- 更多的面对面时间会有帮助吗？对彼此？对利益相关者？
- 哪些地方缺乏异步的清晰度？
- 哪些地方缺乏同步的能量？
找到正确的平衡可以显著提升团队的速度、对齐度和幸福感。