如果開發團隊不在妳身邊，溝通和執行的難度將進壹步放大。異地開發出現的問題常常導致團隊士氣低落，有人甚至公開質疑異地開發能否真正節約成本。
提高與異地開發團隊之間的溝通效率，我有三條建議。
開發團隊距離越遠，語言、文化、時差帶來的溝通難度越大，確定完善的產品說明文檔就越重要。如果產品經理不確定開發什麽樣的產品（或者反復改變想法），異地開發團隊只能疲於奔命，白費力氣。這簡直就是壹場災難，絲毫不亞於醫生開錯方子。如果妳與開發團隊相隔很遠，無論是溝通產品文檔的內容，還是討論修改產品設計，壹定要借助高保真原型進行交流。閱讀文檔畢竟不輕松，如果文檔是非母語的，或者闡述不清楚，那溝通效率就更低了。
本地的開發團隊很容易發現和解決各種沖突（比如，兩個管理者給出相互抵觸的指導意見）。異地開發團隊則會發生很多意想不到的情況，往往過了好幾個月才發現問題。這是因為異地開發人員不得不揣摩各種不同的意見（但經常揣摩錯）。因此，必須有人在本地負責與異地團隊的協調工作。這並不是說所有溝通工作都必須經過此人，而是應該明確異地開發團隊只接受他的命令。這項工作可以由本地的項目經理、資深開發人員或者其他主管擔任。
如今商業溝通手段很豐富，除了電子郵件和即時消息外，還有視頻會議可供選擇，此外，語音電話業務（VoIP）大大降低了國際長途通話費用支出。盡管如此，當面交流的優勢依然不可替代。每個季度，產品經理至少應該前往異地與開發團隊見壹次面，與軟件架構師、管理者當面交流。面對面交流有助於改善（合作）關系，提高溝通效率。此外，交換人員也是壹種有效的溝通方式，可以讓主程序員來本地與產品經理***同工作壹段時間，或者讓產品經理到異地工作壹段時間。
按照我介紹的方法與優秀的開發團隊合作是壹種特別的享受。如果是與印度外包團隊合作，那麽由於時差的原因這種合作會讓人覺得更加愜意。每天早晨上班時，對方的項目進展已經擺在面前。妳可以用白天（對方的夜晚）檢查、測試代碼，反饋信息，顯著縮短項目的循環周期。
請註意，如果是在異地開展與產品原型相關的工作，由於循環周期非常短（壹天叠代好幾次），妳必須隨時準備處理對方的問題，投入更多的精力。
解決異地開發問題的另壹種方式是在異地聘請產品團隊。這種趨勢正在興起，我相信這種模式會被更多的公司采用。妳大可不必為此擔心。我們曾經用了10年時間在異地培養專業的開發和測試人員，培養專業的產品經理和設計人員很可能還要再花10年時間。
產品經理最擔心聽到開發人員這樣抱怨：不能再增加功能了！我們得停下來重寫代碼。代碼庫壹團糟，就像紙糊的老虎，根本應付不了持續增加的用戶。我們維護不下去了！
這壹幕在很多公司上演過，現在依然在不斷重演。1999年eBay遭遇這壹幕時，公司瀕臨崩潰的情形超出所有人想象。Friendster幾年前也 發生過這種情況，當時他們正在向MySpace開放社交網絡用戶。網景與微軟展開瀏覽器大戰時，也發生過類似的事情，最後的結果大家都知道。事實上，沒幾家公司能渡過難關。
壹旦公司陷入這種困境，開發團隊往往淪為替罪羊。經驗告訴我，這類問題通常是由產品管理失誤引發的。因為產品經理壹直迫使開發團隊滿負荷工作，開發 盡可能多的功能。所有軟件架構都存在功能極限，如果忽視產品的基礎技術構架，壹旦系統越過崩潰的臨界點，就會造成無法挽回的結果。
在重寫代碼的過程中，用戶無法看到產品的任何改進。妳可能認為重寫代碼至多也就幾個月，但是實際花費的時間無壹例外要多得多。妳只能坐在壹旁，眼睜睜看著用戶投奔競爭對手，而這個時候，競爭對手恰恰在不斷地改進產品。
如果妳還沒有遇到這樣的情形，未雨綢繆很有必要妳需要預留壹定的研發技術能力，在eBay被稱為余量（headroom）。很多因產品迅速膨脹產生的問題都與擴展規模有關，余量意味著避免觸及技術能力的上限，為用戶數量的增長預留空間，為事務增長預留空間，為新增功能預留空間，保證產品的基礎技 術構架能夠滿足團隊的要求。
與開發團隊合作應該遵循以下原則：在產品管理上為開發團隊預留20%的自主時間，讓他們自由支配。開發團隊可以利用這些時間重寫代碼、完善架構、重構代碼庫中有缺陷的部分，或者更換數據庫管理系統，提高系統性能，避免我們需要停下來重寫代碼的情形發生。
如果妳的糟糕處境已經初現端倪，應該拿出至少20%的資源進行調整，而我擔心有些團隊連20%都不願意拿出來。如果妳已經身陷重寫的困境，說明公司危在旦夕，這裏給出壹點建議供妳參考。
第壹步，針對開發團隊確定的產品修改目標並制訂切實可行的計劃和時間表。通常，有經驗的開發團隊估計的開發時間八九不離十，但是重寫代碼是個例外，因為多數團隊都沒有重寫代碼的實際經驗，估計往往過於樂觀。妳必須審時度勢，仔細檢查每處細節，確保計劃切實可行。
第二步，只要有可能，最好把重寫目標分成幾大塊，實現遞增修改，讓用戶感受到產品的改進，哪怕會因此把9個月的工作時間延長至2年，也壹定要采用這種方式。重寫代碼時，保證讓用戶看到功能的改進即使會占用少則25%，多則50%的開發資源對保持產品（尤其是互聯網產品）的市場占有率至關重要。
第三步，由於開發用戶可見功能的資源有限，必須謹慎選擇正確的產品特性，並確保產品定義的正確性。
eBay起死回生後，我們發誓絕不重蹈覆轍，馬上開始新壹輪的代碼重寫，把危機甩在身後。事實上，由於發展迅速，eBay已經重寫了三次代碼，最後壹次采用了完全不同的編程語言和架構。開發團隊花了幾年時間，大規模地改寫了幾百萬行代碼，同時在不影響用戶群的情況下，開發了大量新功能。這是我知道的最驚心動魄的中途重建網站的故事。
臨渴掘井不如未雨綢繆，為防患於未然，別忘了預留20%的余量。