相信很多產品同學都面臨過接手“爛攤子”項目的情況，風格千奇百怪的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 協議