機緣巧合，近距離接觸了一個比較坑的外包團隊，長了一丟丟扯皮的經驗，寫個小結，填坑。
瞭解對方開發情況
提前申請好 fabric、Bugly 等整合監控工具的賬號，讓對方開發過程中全程都整合這些工具，develop 版本和 release 版本用不同的 id，這樣可以區分出 Bugly 中顯示的崩潰是 release 版本中影響使用者體驗的 bug，還是開發過程中程式設計師為了測試故意觸發的 crash。
Bugly 是可以精確記錄崩潰發生的各種資訊的，包括裝置型號、系統版本、觸發崩潰的程式碼等，這樣在無法復現 bug 的時候也有證據和對方談，不至於讓對方賴賬。
相對 Bugly 次日才能給出統計資訊，fabric 可以做到實時統計，根據開發版本的應用活躍程度，可以對對方的開發過程有一個大概的估計，至少當你看見 fabric 顯示 app 沒有任何動靜（app 啟動次數、session length），那肯定對方是沒在進行客戶端除錯的。
謹慎考慮技術方案
有些外包團隊的技術人員，是畢業之後培訓兩三個月就上崗了那種，能力比較成問題，在技術的選擇上也會很隨意，可以嘗試從以下幾個角度來去把控：
- 通過 git 來時常檢視他們的程式碼提交記錄，不要讓他們每次都把程式碼打包發過來，這樣方便專案後續交接給其他人繼續開發。
- 對於他們大量使用了，而自己又不太熟悉的第三方框架，多去查一下，看看這些框架有沒有不成熟、或者已經不再維護的問題，否則框架本身出現 bug，後期可能一時移除不掉，他們又沒有自己修改框架的能力。
- 技術上最好選擇通用、最好可移植平臺的方案。比如同等情況下，在 Win 桌面端儘量選擇 C++ 而不是 C# 去開發，後期可以移植其他平臺；後端儘量用 C++ 或者 Java 去實現，否則他們用 PHP 做了之後，以後找人接手專案也比較麻煩。
- 假如想要用 React Native 去做客戶端開發，要考慮這樣是不是相對原生開發可以省下接近一半的費用？如果可以的話，後期找人接手這個 RN 專案，短期是不是可以找得到會 RN 的人？
有效傳遞反饋意見
一方面，對方可能會有賴賬的想法；另一方面，有些程式 bug 確實是偶發性的，不好復現。於是就可能出現，你說程式有問題，對方不承認的問題。所以要多注意：
- 在反饋 bug 的時候，通過 Bugly 等工具，告知對方，出問題的程式碼在哪
- 在不至於導致崩潰，但某些機型上又表現不正常的時候，儘量在測試時，全過程錄視訊，給乙方反饋的時候，直接擷取出那一部分視訊，就不存在推脫責任的問題
產品設計問題與 bug
在和外包團隊接觸過程中，遇到這樣一個問題：有些動態的東西，比如滑動列表時隱藏搜尋框，這些相對細緻的內容，可能無法在原型設計中得到充分的體現。
而你又無法依賴對方的人員素質，來讓他們自行優化這些細節。就要充分考量實際開發情況，在原型不方便體現細節的時候，用文件或其他方式進行充分的說明。否則最後產品做出來，你覺得某個地方不合理，是他們應該修復的 bug，但是由於原型、設計稿沒有體現，他們可以認為這些是需求變更、二次優化，再找你收一次錢。
簽訂合同的時候，要嚴格定義出“交付專案的要求”，專案還沒交付的時候，產品設計有問題（互動、邏輯等）算是雙方溝通不夠深入，專案交付之後，任何改動都是新需求，都要再算一次錢。又比如所有功能都開發完成，但是 bug 很多，使用者體驗極差，可不可以交付專案；以及開發過程完成後，需要產品成功上架 App Store 與國內各大安卓應用商店，否則你這邊覺得東西做完了，之後屢屢被 App Store 稽核團隊拒絕，也沒地方說理。
後續遇到新型扯皮，再繼續更新……