隔着十二小时安排会议

十二小时的落差没有好的会议时间，把网格涂上颜色也改不了。处理得好的团队会停止寻找，转而改变自己的工作方式。

旧金山与班加罗尔相隔十二个半小时。一边 09:00–18:00 的一天，在另一边还没开始就已经结束。没有哪种巧妙的日历安排能造出一个共同的工作小时，因为压根就没有共同的小时可找。

多数团队是硬试了一遍才明白这一点：给一方定在 21:00，然后闷声记恨十八个月。下面是那些处理得好的团队改用的做法。

首先，对算术诚实

在谈判之前，把真实的数字算出来，因为它们往往比人们以为的更糟——偶尔也更好。

差值不是固定的。纽约与悉尼在北半球的冬天相差 16 小时，在北半球的夏天相差 14 小时，因为两地在相反的季节实行夏令时。这两小时的摆动，正是「有一个共同的小时」与「一个都没有」之间的分界，而且没人改动任何东西它就来了。

两个全年保持同一偏移的城市——比方说印度和日本——它们的差值可以背下来。只有一方实行夏令时的两个城市，差值一年会挪两次。两边都实行但日期不同的城市，差值一年里大约有四个星期是错的。

只有四个，凡是行得通的安排都是它们的组合。

1. 一方永久移动。 某一方的工作日整体挪两三个小时。这管用，也稳定，而且只有在有回报时才谈得上公平——更短的核心工作时段、补偿，或者一个真正的选择权。把它压给最年轻的那支团队，正是人员流失的开端。

2. 轮流承担难受。 那个难受的会轮着来：这个月对班加罗尔来说太早，下个月对旧金山来说太晚。原则上更公平，实践中更难，因为得有人记账并且执行。它最适合数量很少、价值很高的会议。

3. 刻意而狭窄地重叠。 双方约定在靠近各自一天某一端的某个特定小时里保持在线，除此之外不安排任何跨越落差的事。那一小时里发生的全是决策；其余一切都写下来。

4. 干脆不开会。 落差反而成了优势：工作在每天结束时交接出去，在对方一天开始时接手。这是唯一能扩展到两个地点以上的选项，也是对团队实际工作方式要求改动最大的一个。

第四个选项正是十二小时团队要么兴旺、要么散架的分水岭，而这个差别几乎全在于写。

决策要写下来，连同理由。 不是「我们决定用 Postgres」，而是「我们选 Postgres 而不是 DynamoDB，因为查询模式是关系型的，而多维护一个数据存储的运维成本超过了能换来的写入吞吐」。第二种写法能熬过一次交接；第一种会催生一场会议。

提问要带足上下文，让人在你睡觉时就能回答。 「你觉得这个 schema 怎么样？」要花掉整整一天的往返。「schema 需要支持 X 和 Y；方案甲在 X 上更好，方案乙在 Y 上更好；我因为 Z 倾向甲——如果你不同意，请在你那边的早上告诉我」，一个周期就能收敛。

阻塞要在交接之前上报，而不是在交接时。 异步团队里最糟的模式，是在 09:00 才发现对面昨天 17:00 就卡住了，而且十一个小时一声没吭。

进展不用问就看得见。 一块看板、一个频道、一份文档——任何能回答「我睡着的时候发生了什么」而不需要有人醒着的东西。

如果你确实要在很大的落差上排一个周期性通话，请意识到它会漂移。当一方拨钟而另一方不拨，一场锚定在某一方日历上的会议，在另一方就挪了一小时。一年两次，有那么几个星期，它会落在谁都没同意过的位置上。

日历软件在事件带着时区保存时能正确处理这一点——这也是另一个理由：明确挑一个锚定时区，在邀请里写清楚，然后让其他人的日历去做换算。

另一个陷阱，是团队还在三个时区时排下、如今扩到六个时区却仍在跑的那场会。跨大落差的会议会不断积攒新参与者，对他们而言这个时间比对最初那批人糟得多，却从来没有人提议改期，因为改期是别人的麻烦。

洛杉矶和孟买在任何季节都不共享 09:00–18:00 这一天里的任何一分钟。如果你的团队横跨这道落差又需要同步决策，那就一定有人在自己的工作时间之外干活——唯一的问题是谁、多久一次、以及他是否同意。

这是管理问题而不是排期问题，工具解决不了。工具能做的，是别让你到发出邀请时才发现它。

最后成形的那套安排，通常是适合组织内权力最大者的那一套，而且通常是在没有人做过决定的情况下成形的。

留意这样一种模式：最新、最年轻或最边缘的那支团队，总是承担那个难受的时段。它很少是一项决定；它是一堆小小默认值的累积，每一项单独看都合情合理。一旦定型，受益的人看不见它，其他所有人都看得一清二楚。

实际的对策，是把「谁在承担这项成本」写下来，按固定周期复核，并把它当成一条真实的预算项目而不是善意。夏令时切换的日期是复核的方便提醒，反正那时候数字本来就要动。