分布式团队:最先失效的不是连接,而是对完成标准的共同理解
我们曾经有三个站点:总部办公室、为降低成本在另一座城市开设的第二个办公室,以及中国的外包团队。除此之外,还有与拥有自己团队的客户共同推进的项目工作。连接本身运转正常——这方面本来就很少出问题。
真正出问题的是另一件事。一个人认为任务已经完成,另一个人却在等待任务中根本不存在的东西,而双方都确信彼此已经达成一致。这种分歧被发现的时间,比在同一间办公室里晚了一到两天,而这一到两天,正是分布式工作真正的代价所在——它不会出现在任何一份效率报表里,却会实实在在地拖慢每一个跨站点交付的节奏。
分布式团队 (distributed team) 失去的不是沟通,而是共同的就绪判据:什么算完成、结果交给谁、什么时候交。在同一间办公室里,分歧会在几分钟内通过偶然信号暴露出来;跨站点则要拖上好几天。解决办法不是增加会议,而是写下一份书面完成标准 (definition of done),并设立一个绑定在系统上、而非停留在对话里的明确交接点。
分布式团队中最先失效的是什么
有必要把通常被笼统归为"沟通"的三件事区分开来。它们失效的顺序不同,解决办法也不同。
连接渠道。很少失效,靠工具就能修好。这是讨论分布式工作时人们通常唯一会谈到的部分。
完成标准 (definition of done)。最先失效,而且几乎总是悄无声息。在同一间办公室里,它靠偶然信号维持:你看到同事起身走向测试人员,你听到一句谈话的片段,你注意到某人脸色不悦。跨站点协同 (cross-site coordination) 时,这些信号都不存在,书面标准通常也不存在。
交接 (handoff) 时刻。第二个失效。在同一间办公室里,交接是物理性的:走过去,说一声,得到确认。在分布式团队里,它变成一条可能没人读的消息,而双方都以为球在对方手里。
| 失效的是什么 | 表现形式 | 靠什么修复 |
|---|---|---|
| 连接渠道 | "没打通""连接卡住了" | 靠工具 |
| 完成标准 | "我以为这个已经做完了" | 靠书面的完成标准 |
| 交接时刻 | "我明明在群里发了" | 靠系统中的事件,而非一条消息 |
| 反馈闭环 | "没人告诉我不能这样做" | 靠针对具体案例的定期复盘 |
第一行靠采购就能解决,后面三行都要靠流程决策。这正是为什么那些把提升分布式工作效率简化为"选一个工具"的项目,最终都没有结果——工具能让消息传得更快,却没法让两个人对"完成"这个词的理解变得一致。
跨站点协同究竟要付出多大代价
这种延迟的具体量级,在一项结合了系统日志与参与者调查的研究中被测量了出来。
一项需要跨站点协同的任务,耗时是同一站点内同类工作的2,5倍:一个部门12,7天对比5天,另一个部门18天对比7天。
这是上世纪九十年代末的数据,早于现代通信工具出现的年代,而且是一项观察性研究,不是实验;涉及的是同一家公司的两个部门。我直接说明这个局限:2,5倍这个倍数不能被当作衡量今天实践的标准照搬过来。真正稳定的是机制本身——跨站点协同会增加延迟,而延迟增加的地方不是此后已被极大改善的连接渠道,而是就"什么算完成"达成一致这件事上。
远程办公 (remote work) 实验说明了什么
在一项随机实验中,居家办公带来了13%的生产率提升:其中约9%来自每班次工作分钟数的增加(休息和病假减少),约4%来自每分钟处理电话数量的增加。
只有一家公司、一种职业,而且参与者是自愿报名的——样本因此偏向那些本来就适合这种工作方式的人。同一项研究还有一个值得注意的事实:居家办公的员工晋升速度下降了。这是一个重要的限定条件:该实验衡量的是任务边界划分得很清楚、完成标准由外部给定、无需协商的工作。
在一家大型公司的呼叫中心转向远程办公后,质量下降最明显的是缺乏经验的员工,远程员工获得晋升的概率也随之下降。生产率差距中约有三分之一可以由远程本身的效应来解释,而不是员工构成的差异。
该研究的时间窗口与一次被迫的转型绑定在一起,这带来了潜在的偏差,而且同样只涉及一家公司、一个行业。但把它和前一项研究放在一起看,呈现出的画面是一致的:分布式工作本身无所谓更好或更差——它对不同群体的影响不同。拥有清晰完成标准的资深员工会因此受益,没有这种标准的新人则会因此吃亏。
我们后来做了什么
第一个解决方案在第一次出现分歧之前,看起来就像官僚主义。完成标准是每类任务三到四条要点,不是一份文档:做了什么、检查了什么、结果放在哪里、交给了谁。
第二个解决方案消除了整整一类"我明明发了"式的争论。群聊消息不算交接:它可能没人读、读了又忘了、或者被错的人读了。系统中的事件会同时记录事实、时间和接收人——关于事件与消息的区别,我另外写过一篇。
第三个解决方案在组织层面代价最高,也最有效。只要一个流程在两个站点各有一位流程责任人 (process owner),他们就会各自本着好意,维护两个不同版本的流程,而且双方都能为自己的版本给出合理的理由——这正是它比前两个方案更难落地、也更容易被回避的原因。
面向多站点团队的四个步骤
写下完成标准
每类任务三到四条要点。检验方式:两个人独立作答,对"这个任务是否完成"给出同样的答案。
把交接变成一个事件
不是一条消息,而是系统中带有接收人和时间戳的状态变更。
指定一位流程责任人
所有站点共用一位。两位责任人意味着一个季度后就会出现两个版本的流程。
把分歧当作完成标准的缺陷来处理
每一句"我以为这个已经做完了",都是补充一条标准的理由,而不是讨论谁不够细心的理由。
如果两个站点的两个人对"这个任务是否完成"给出不同答案,问题既不在连接,也不在人——只是根本没有完成标准。
最常被问到的问题
分布式团队中最先失效的是什么?
是对"完成"的共同理解。在同一间办公室里,它靠偶然信号维持——你能看到、听到同事的工作进行到了哪一步。隔着距离,这些信号都不存在,书面标准通常也不存在,分歧因此要晚几天才会暴露出来。人们谈论最多的连接渠道,实际上是失效最少的部分,而且靠工具就能修好。
分布式团队需要多少次会议?
如果有书面完成标准,需要的会议比通常安排的要少;如果没有,则会更多。会议是在用一种昂贵的方式弥补标准的缺失——占用所有人的同步时间。一个实用的判断标志:如果会议上讨论的是"这个任务是否完成",而不是"接下来该做什么",就说明会议开多了。
分布式团队的工作表现是不是更差?
要看具体是哪一类群体。一项随机实验显示,在任务边界清晰、完成标准由外部给定的工作中,生产率提升了13%。另一项类似环境下的研究则显示,缺乏经验的员工表现下降最明显,远程员工获得晋升的概率也在降低。也就是说,这种工作方式并不会均匀地影响所有人,而是放大了拥有清晰判据的人和没有清晰判据的人之间原本就存在的差距。
站点之间应该如何交接工作?
通过系统中带有明确接收人的状态变更,而不是通过即时通讯工具里的一条消息。消息可能没人读、被错的人读到,或者读了又忘,而这时双方都仍然确信交接已经完成。系统中的事件会记录事实、时间和接收人,并且能看出工作在被接手之前等待了多久。
三站点配置(总部办公室、为降低成本在另一座城市开设的办公室,以及中国的外包团队)以及跨站点协同管理跨职能团队的实践经验,来自Alego.Digital的实际业务以及作者2017至2019年在中国主持的项目。这些是作者所在公司的内部信息,未经独立第三方核实,仅作为机制的示例说明。团队从未对跨站点延迟做过量化测量,因此本文在这个问题上没有内部数字指标;文中所有数字均来自外部资料,并注明了对应的方法。
- Herbsleb J. D., Mockus A. An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE TSE, 29(6), 2003. uni-saarland.de
- Bloom N., Liang J., Roberts J., Ying Z. J. Does Working from Home Work? Evidence from a Chinese Experiment. QJE, 130(1), 2015. nber.org
- Emanuel N., Harrington E. Working Remotely? Selection, Treatment, and the Market for Remote Work. FRBNY Staff Report 1061, 2023. newyorkfed.org