相信很多产品同学都面临过接手“烂摊子”项目的情况，风格千奇百怪的UI界面、山路十八弯的处理逻辑以及无数隐藏极深的坑。有些项目因为过于复杂，使我们每做出一小步修改，都需要调研数天甚至数周，却仍然难免线上bug。

而笔者今天要给大家分享的是在此过程中的另一道风景–多国团队一起做重构。这其中既有心酸，也有欢乐，但最重要的是收获到了宝贵的跨团队、跨国家、跨文化的项目合作经验。希望能给大家一些启示。

笔者的这个项目的产品是一款商家端的app，为和公司合作的大、中、小商家提供线下交易、商户/门店自助、查看销售和佣金报告等服务。后端主要对接公司核心数据系统。App的初始版本是由一家捷克的外包公司做的，只有几个很简单的功能。上线后，商户使用人数比较低（平均DAU大约为1500），且每天都有大量的投诉，所以公司决定交由本地产研组进行后续研发。

当我接手这个项目后，通过与捷克开发团队的沟通以及相关文档的阅读，发现了如下的问题：

• 功能过于单一，且几乎没和外部有任何对接
• 没有抓住商户的痛点问题去解决
• 数据混乱
• 迭代周期过慢，没有体现敏捷开发

针对上述出现的问题，经过组内多次的讨论，我们迅速制定了一系列的解决方案：

一、驻地调研

通过前期与部分商户的电话沟通，我们认识到了一个之前产品设计中非常严重的问题：脱离用户的实际需求。也许由于设计者和开发团队都是外国人的原因，他们直接绕过了最开始非常重要的一个环节：用户访谈。只是凭借自己在该领域内的业务经验，按照国外用户的使用习惯设计了一款app。

因此，我和另一名负责该app的同事申请用半个月的时间，在不同类型、不同区域的商户和门店中进行实地调研。通过与商户的深入交流以及观察他们平时使用app的场景中出现的各种细节问题，成功地收集了潜在的用户需求。与此同时，我们还建立了用户微信群，方便商户的问题反馈。

后来事实证明，微信群的建立，不仅方便了商家，更对我们每次推出新的重要功能前的用户调研起到了极大的作用。依靠这种紧密的用户关系，我们还举办了几次用户大会，成功地为公司建立了品牌形象。

二、内部需求整合

在实地调研后，我们回到公司和相关的所有业务部门经过讨论后，将所有需求分成几大模块，并按照优先级进行开发：

• 商户自助服务（新建商户/门店申请、维护人员和银行账户等信息）
• O2O相关（扫码购物、商品维护、营销活动推广、门店预约）
• 数据报告（销售额、佣金）
• 商家学院

三、捷克之旅

在经过一个多月对需求的梳理之后，终于到了本次重构的最关键、最复杂也是最有趣的环节：

跨国团队的合作研发。

在上面提到的问题中，有一个是“数据混乱”。为何会有这种情况发生呢？其实这与app的后台取数逻辑有关。本来app应该直接从主数据系统获取商家信息，但由于前期设计中，主系统是8*5（每天8小时，一周5天）的工作模式，为了满足app的需求，在二者中间加了一个系统，可以支持7*24工作。

但这就带来了一个问题：数据不一致。App端的数据之前是从两个源头取的：源系统的中间系统。而且，数据间的传输方式是异步的，通过RabbitMQ或Kafka，这样在大量数据的情况下，会出现一定的数据丢失。

主系统和中间系统的开发团队都在捷克，因此我正式踏上了异国他乡之旅。

欧洲人十分注重运动，喜欢亲近大自然，这直接体现在他们的上班时间的安排：很多人早上七点多就到了公司，最晚的八点也到了，因为他们只要在公司的时间（包括午休）待满八小时即可下班，且几乎从不加班。因此大多数人下午三四点就可以下班了，你可以在那时看到大街上都是各种跑步，骑车和玩各种运动的人。还有些男士会选择带着孩子在草坪上晒太阳（对，没错，欧洲男士带孩子是很普遍的）。有些领导会三五成群的去酒吧喝酒，看看球赛，然后回家享受亲子时光。

但这就和国内紧张的工作节奏格格不入了。本来中国和欧洲就有六七个小时的时差，做app的中国开发团队等了一上午，终于盼来下午可以和欧洲这边开会讨论了，但他们上班后通常要先喝咖啡调节一下心情，然后才开始一天的工作安排，且通常第一项工作都是开会。这就给对接带来了极大的不便。

更麻烦的是：捷克团队对计划看得极为重要，表现为任何开发只局限于需求文档内的范围，多一点都视为超纲，需要重新走流程，提需求。这是一种严重不符合敏捷模式的开发，虽然大的改动在开发开始后就不建议加进去了，但一些细小的，很容易改的，且对用户体验很关键的点，我认为是可以灵活处理的。

本次的重构，主系统的数据建模以及系统间的数据传输方式的优化是极为重要的，甚至可以说是核心。如果上游系统仍旧一团乱麻，那么下游的app做的再花哨，也无济于事。这也是我此次来捷克的关键原因。

面对这种情况，最关键的还是要和各个环节的核心的人保持良好的沟通。

首先，我和两个主要团队的项目经理做了几次深入的交流，希望双方为了产品的顺利上线对各自团队的工作时间做出一定的调整，比如：中国团队的上班时间晚一些，而捷克团队要更早些，这样确保两个团队的重叠时间能多一点。

其次，针对捷克团队对文档的态度，我在每次需求评审会之后，正式开发之前，组织测试开测试用例分析会，测试同学往往考虑得会更加细致，各种极端和边界条件可以补充的比较到位。这样每份文档基本不会有什么漏洞了，至于一些文字、颜色啥的调整，我会绕过捷克的项目经理，直接找到对应开发同事，靠私人关系做出修改。

此外，与关键人物建立亲密的私人关系在这个项目里尤为重要。毕竟人是感情动物，即便是在欧美这种就事论事，一板一眼的国家，也依旧行得通。比如，我平时会特别留意当地的一些时事新闻，下班后也会陪他们去酒吧喝喝酒，看看球赛，积极融入当地的生活。时间久了，大家的关系也变得更加融洽，遇到关键问题时，总会有人出来帮你一起解决的。

后续我们对主系统也进行了一些优化，比如用智能化审核代替人工审核，审批流的自定义等。这些原本对于捷克人是很复杂的功能，但他们依旧按时完成上线了，这个与上述项目中所做的看似与工作无关的努力是分不开的。正因为沟通的顺畅，所以当遇到难题时，大家才能够一起想办法解决，而不是一再地互相推诿，给对方甩锅。

四、心得

有人或许会问，这些不应该是项目经理的这则范围吗？

在某些公司或项目有可能是，但在笔者的这个项目，每个项目经理只负责各自的app或系统，这种跨系统间的沟通与协调最好是由产品经理来完成。其实，项目管理一直是一个合格的产品经理所应具备的一个能力，因为我们才是最终对产品负责的人，因此在产品上线中的任何一个环节出现漏洞，我们产品人都应当义不容辞的补上去，甚至是开发（某些公司确实有这种情况）。

跨国家团队的开发不仅考验一个产品经理的语言能力，更重要的是对不同文化的理解，这样才能在项目协调过程中找到最适合团队合作的方式。希望笔者上述的经历能给大家在和跨国团队合作时的方式方法带来一些启示。

作者：Dave，消费金融产品经理

本文由 @Dave 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议