来自西半球的时差之痛来自西半球的时差之痛

背景在全球化的大背景下，越来越多的大公司选择服务供应商时也是面向全世界，软件服务行业尤显突出。我司的一个客户也不例外。客户的坐标在美国达拉斯，而客户的软件服务供应商则来自全球各地，中国、印度、巴西等等。显然，全球化的服务为客户节约了成本达到利益最大化，但许多问题也随之慢慢浮现出来。其中沟通成本的增加尤为明显，也成了我们项目组不可避免的痛点，可谓是痛中之痛。
产生的原因

时差，在西半球的美国离东半球的中国有几乎高达12个小时的时差，比如成都和达拉斯之间就有13个小时的时差，可谓黑白颠倒。由于上班时间完全错开，那么交流起来就显得特别困难。毕竟，无论是客户还是我们，谁也不想花大把工作之外的时间。
与第三方提供商协作，客户除了我们之外还有许多其他第三方的服务供应商，其中有一个项目组与我们强相关。他们是来自南美的一家公司，由于没有直接利益关系，大家很显然都只想各扫门前雪，沟通起来就显得更加困难。

具体事例

【来自西半球的时差之痛】确认需求
-- 每个迭代开始时，作为敏捷的实践者，我们都会与客户开一个叫做 IPM （Iteration Planning Meeting）的会议，通过这个会议来和客户在需求上达成共识，以确保我们的开发是在做正确的事。但往往有许多隐含的需求在 IPM 中会被忽略掉。比如某些表单的缓存处理；用户在某个页面上的 back/forward 行为的结果是什么；当某个页面出现了 session expire 时是将用户到会主页还是提示用户登录后继续使用等等。当我们在开发过程中遇到这些问题，但它们并没有在 IPM 上没有被明确时，就需要和客户再次确认需求。而这个再次确认的过程对于有13小时时差的我们显得非常痛苦。由于双方工作时间颠倒，通常情况下，我们会以邮件的形式明确需求，往往一个来回的时间就是24小时，但在需求比较复杂的情况下，往往需要更多的时间才能与客户达成共识。
迭代中的需求变更
-- 在敏捷宣言中有一项便是拥抱变化高于遵循计划，我司作为敏捷的实践者自然也是拥抱变化的。但在迭代中的需求变更还是造成诸多问题，尤其是在我们这样的离岸交付项目团队中，需求变更带来的沟通成本无疑被扩大了。
API 报错
-- 与我们强相关的第三方供应商（称之为 NT 团队）为我们的前端项目提供 BFF（Backend For Frontend）服务。但当他们提供的 API 出现 bug 时所带来的沟通成本非常之巨大。通常情况下，当 API 出现 bug 时，首先需要我们的开发人员分析 bug 出现的原因，确认 bug 的确来自于 BFF 层而不是更底层的服务，这一过程非常耗时，需要开发人员远程登录到构建的美国的物理服务器查看日志，从数以万计的日志条目中找到需要的数据以佐证 bug 来自于 BFF 层。之后，需要开发人员将数据，应用截图进行整理，最后以邮件的形式通知 NT 进行改正。最好的结果是 NT 能看懂我们写的邮件并迅速的修复，但真实的情况非常骨感。有些时候他们会看不懂邮件的内容，于是他们会在邮件中提出他们的问题，这样一来二去再加上时差的原因，往往3、4天时间就过去了。有些时候他们会误解邮件的内容造成错误了修改，这种时候最令人头痛，双方都会付出更多的资源消耗。

解决方案

规范化邮件格式
与客户或第三方供应商交流时，更多的额外付出来自于邮件内容上的不清晰，造成对方的疑问或误解。基于这样的情况对于某些可以规范化的内容，比如 API 报错，我们进行了邮件的规范化。规范化的标题、内容让对方能轻易的从中找到自己想要的东西，也使问题得到更好的记录和追踪。
并行开发
当一个 feature 的需求需要确认时，根据经验往往需要 block 1到5天的时间，而这段时间开发人员就会处于闲置状态，为了避免这种情况，一个迭代当中我们往往会同时并行开发多个 feature 的 story。这样可以有效地避免上述情况的产生，虽然单个 feature 的开发周期可能变得更长，但总的来说整个 app 的开发效率是提升的。
团队协作以及个人牺牲
在长达13个小时时差的情况下要想进行良好的沟通，团队的鼎力协作与个人牺牲是不可避免的。首先，在客户现场会有我们团队的人长期出差，更好的与客户和第三方服务提供商进行面对面的交流。带有态度的生动形象的表达往往好过冷冰冰的文字。其次，每个 role 都有属于他们自己的 catch up。比如我们的开发会与客户的开发每周会有一次大约30分钟的 tech huddle，我们的 QA 与客户和第三方供应商的 QA 每周也会有 QA catch up，包括 BA， TL，PM 等等，都会至少每周一次的与客户的人进行 catch up。而 catch up 都是以视频会议的形式进行，这样的交流效果要比发邮件好上许多倍，与此同时也可以增强彼此间的了解和信任。而这里谈到的个人牺牲就是这样的 catch up 会发生在下班时间，但每周一次的频率也是大家可以接受的。
除此之外，上面我们谈到了规范化邮件格式来报告 API 错误。但那样的方式仍然需要我们的开发人员耗费大量的时间去查看日志，截图等等。而大部分开发并不会乐于去做这样的工作，这大大的降低了开发工作中的乐趣。之后我们团队提出了新的方式，我们会对找到的 bug 在虚拟工作白板上新建一张 story 对这个问题进行简单的描述，然后通知在客户现场的同事与 NT 在客户现场的成员沟通，确定这个 bug 是否应该有他们来解决。由于他们工作时间一致，大多数情况下第二天我们就能知道这个 bug 的处理结果。这又进一步提高了我们的效率。
Pre-IPM
前面的事例中也提到在 IPM 中，我们可能会忽略掉某些隐藏的需求。针对这一点，我们提出来 Pre-IPM 的概念。顾名思义，就是在正式的与客户进行 IPM 之前，我们会有一次内部的 IPM，将所有的 story 提前过一遍，提前思考隐藏的问题、不明确的需求等等。这样在正式与客户的 IPM 上就能大大的减少隐藏需求的出现，与此同时，也提高了正式 IPM 的效率，因为很多问题提前思考过，也能给客户提出更加专业的建议。
争取客户的信任
前面提到，当隐性需求出现时，我们需要跟客户交流从而在需求上达成一致。而这样做，尤其是在离岸交付项目中会消耗大量的时间，使得工作效率低下。但如果我们在对业务十分了解并且取得了客户充分信任的情况下我们的工作流程就会是这样：
不明的确需求出现 --> offshore BA 和 TL 做决策 --> 通知客户 --> 客户满意决策。
如此，就省去了一来二去的讨论过程，客户只需要看到最后他们想要的决策。当我们拥有用户的充分信任时，就好比拥有了“尚方宝剑”，可“先斩后奏”。但这样做的前提是我们对业务充分理解，知道客户的需求并且拥有良好的解决方案时才能做到。不然，不仅会返工，而且可能会逐渐失去客户的信任或是造成误解。所以这种方法一般适用于比较成熟的团队，他们拥有客户的信任，并且拥有强大的实战经验。
分支预测法
顾名思义，当有一个决策需要多个回合来决定时，并且我们拥有一些初步可行的想法时，可以先简单实现多种可行的方案。这样代码中就可能同时存在 Plan A 和 Plan B，直到客户选定其中一种。这样做的好处显而易见，客户可以清楚的看到两种方案的优劣，缺点也很明显，那就是需要更多的 effort，毕竟同时实现了两套方案。不过在特定的一些场景中这样的方法还是很适用的，比如同时开发多个 Plan 的 effort 小于沟通带来的 effort。

总结确实，在全球化的大背景下，这样跨时区的合作会越来越多，也给我们带来了新的挑战。但只要迎难而上，通过理性的观察、记录、分心、总结，我们就能汲取经验提出良好的应对方法，即使不能彻底的解决问题，也可以提高工作的效率，让项目更健康的进行。
思考

良好的面对面沟通是重中之重。针对我们项目组来说，由于团队的收益比较高，所以有条件始终保持有1至2名成员在客户现场工作，但如果对于一些没有这些条件的团队，他们又如何去攻克这个问题呢？也许他们需要牺牲更多的个人时间来和客户人员沟通。但我认为不论如何，面对面的沟通是必要的，而且必须要以一定频率的进行，因为良好的沟通能在解决问题的同时增强彼此的信赖感，从而增强我们在客户一方的影响力，提高客户将更多优质项目提供给我们的体会。
让客户明白沟通的重要性会直接给项目带来巨大的收益。我们项目组非常的幸运，客户都很理解也很支持我们的敏捷开发流程，也乐于与我们进行良好的、有效的沟通，建立彼此的信赖关系。也正是如此，我们的项目从2016年到2018年一直为客户提供各种服务，实现了许多功能，客户满意我们的工作而我们公司也得到了巨大的收益。然而，如果我们反过来思考一下，如果客户不乐于与我们沟通，瀑布式的提出需求，也不接受我们的反馈，那么我们实现的东西可能就和客户期望的东西出现偏差，造成客户的不满，可能就会丧失机会。不仅如此，这样的结果也可能在业界带给我们一些负面影响从而失去一些隐藏的机会。

鸣谢感谢我的 sponsor 贺思聪对本文提出的修改意见，同时感谢项目组的 TL 李思阳以及 PM 姜珊珊的检阅。