機緣巧合鱼鼓，近距離接觸了一個比較坑的外包團隊，長了一丟丟扯皮的經(jīng)驗该编，寫個小結(jié)迄本，填坑。
了解對方開發(fā)情況
提前申請好 fabric课竣、Bugly 等集成監(jiān)控工具的賬號嘉赎，讓對方開發(fā)過程中全程都集成這些工具置媳，develop 版本和 release 版本用不同的 id，這樣可以區(qū)分出 Bugly 中顯示的崩潰是 release 版本中影響用戶體驗的 bug公条，還是開發(fā)過程中程序員為了測試故意觸發(fā)的 crash半开。
Bugly 是可以精確記錄崩潰發(fā)生的各種信息的，包括設(shè)備型號赃份、系統(tǒng)版本寂拆、觸發(fā)崩潰的代碼等，這樣在無法復(fù)現(xiàn) bug 的時候也有證據(jù)和對方談抓韩，不至于讓對方賴賬纠永。fabric 可以做到實時統(tǒng)計，根據(jù)開發(fā)版本的應(yīng)用活躍程度谒拴，可以對對方的開發(fā)過程有一個大概的估計尝江，至少當(dāng)你看見 fabric 顯示 app 沒有任何動靜（app 啟動次數(shù)、session length）英上，那肯定對方是沒在進行客戶端調(diào)試的炭序。
謹慎考慮技術(shù)方案
有些外包團隊的技術(shù)人員，是畢業(yè)之后培訓(xùn)兩三個月就上崗了那種苍日，能力比較成問題惭聂，在技術(shù)的選擇上也會很隨意，可以嘗試從以下幾個角度來去把控：
- 通過 git 來時常查看他們的代碼提交記錄相恃，不要讓他們每次都把代碼打包發(fā)過來辜纲，這樣方便項目后續(xù)交接給其他人繼續(xù)開發(fā)。
- 對于他們大量使用了拦耐，而自己又不太熟悉的第三方框架耕腾，多去查一下，看看這些框架有沒有不成熟杀糯、或者已經(jīng)不再維護的問題扫俺，否則框架本身出現(xiàn) bug，后期可能一時移除不掉固翰，他們又沒有自己修改框架的能力狼纬。
- 技術(shù)上最好選擇通用、最好可移植平臺的方案倦挂。比如同等情況下畸颅，在 Win 桌面端盡量選擇 C++ 而不是 C# 去開發(fā)，后期可以移植其他平臺方援；后端盡量用 C++ 或者 Java 去實現(xiàn)没炒，否則他們用 PHP 做了之后，以后找人接手項目也比較麻煩。
- 假如想要用 React Native 去做客戶端開發(fā)送火，要考慮這樣是不是相對原生開發(fā)可以省下接近一半的費用拳话？如果可以的話，后期找人接手這個 RN 項目种吸，短期是不是可以找得到會 RN 的人弃衍？
有效傳遞反饋意見
一方面，對方可能會有賴賬的想法坚俗；另一方面镜盯，有些程序 bug 確實是偶發(fā)性的，不好復(fù)現(xiàn)猖败。于是就可能出現(xiàn)速缆，你說程序有問題，對方不承認的問題恩闻。所以要多注意：
- 在反饋 bug 的時候艺糜，通過 Bugly 等工具，告知對方幢尚，出問題的代碼在哪
- 在不至于導(dǎo)致崩潰破停，但某些機型上又表現(xiàn)不正常的時候，盡量在測試時尉剩，全過程錄視頻真慢，給乙方反饋的時候，直接截取出那一部分視頻边涕，就不存在推脫責(zé)任的問題
產(chǎn)品設(shè)計問題與 bug
在和外包團隊接觸過程中晤碘，遇到這樣一個問題：有些動態(tài)的東西，比如滑動列表時隱藏搜索框功蜓，這些相對細致的內(nèi)容，可能無法在原型設(shè)計中得到充分的體現(xiàn)宠蚂。
而你又無法依賴對方的人員素質(zhì)式撼，來讓他們自行優(yōu)化這些細節(jié)。就要充分考量實際開發(fā)情況求厕，在原型不方便體現(xiàn)細節(jié)的時候著隆，用文檔或其他方式進行充分的說明。否則最后產(chǎn)品做出來呀癣，你覺得某個地方不合理美浦，是他們應(yīng)該修復(fù)的 bug，但是由于原型项栏、設(shè)計稿沒有體現(xiàn)浦辨，他們可以認為這些是需求變更、二次優(yōu)化沼沈，再找你收一次錢流酬。
簽訂合同的時候币厕，要嚴格定義出“交付項目的要求”，項目還沒交付的時候芽腾，產(chǎn)品設(shè)計有問題（交互旦装、邏輯等）算是雙方溝通不夠深入，項目交付之后摊滔，任何改動都是新需求阴绢，都要再算一次錢。又比如所有功能都開發(fā)完成艰躺，但是 bug 很多旱函，用戶體驗極差，可不可以交付項目描滔；以及開發(fā)過程完成后棒妨，需要產(chǎn)品成功上架 App Store 與國內(nèi)各大安卓應(yīng)用商店，否則你這邊覺得東西做完了含长，之后屢屢被 App Store 審核團隊拒絕券腔，也沒地方說理。
后續(xù)遇到新型扯皮拘泞，再繼續(xù)更新……
