外包避坑經驗小結

機緣巧合，近距離接觸了一個比較坑的外包團隊，長了一丟丟扯皮的經驗，寫個小結，填坑。

瞭解對方開發狀況

提早申請好 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 確實是偶發性的，很差復現。因而就可能出現，你說程序有問題，對方不認可的問題。因此要多注意：

1. 在反饋 bug 的時候，經過 Bugly 等工具，告知對方，出問題的代碼在哪
2. 在不至於致使崩潰，但某些機型上又表現不正常的時候，儘可能在測試時，全過程錄視頻，給乙方反饋的時候，直接截取出那一部分視頻，就不存在推脫責任的問題

產品設計問題與 bug

在和外包團隊接觸過程當中，遇到這樣一個問題：有些動態的東西，好比滑動列表時隱藏搜索框，這些相對細緻的內容，可能沒法在原型設計中獲得充分的體現。

而你又沒法依賴對方的人員素質，來讓他們自行優化這些細節。就要充分考量實際開發狀況，在原型不方便體現細節的時候，用文檔或其餘方式進行充分的說明。不然最後產品作出來，你以爲某個地方不合理，是他們應該修復的 bug，可是因爲原型、設計稿沒有體現，他們能夠認爲這些是需求變動、二次優化，再找你收一次錢。

簽定合同的時候，要嚴格定義出「交付項目的要求」，項目還沒交付的時候，產品設計有問題（交互、邏輯等）算是雙方溝通不夠深刻，項目交付以後，任何改動都是新需求，都要再算一次錢。又好比全部功能都開發完成，可是 bug 不少，用戶體驗極差，可不能夠交付項目；以及開發過程完成後，須要產品成功上架 App Store 與國內各大安卓應用商店，不然你這邊以爲東西作完了，以後屢屢被 App Store 審覈團隊拒絕，也沒地方說理。

---

後續遇到新型扯皮，再繼續更新……