互聯(lián)網(wǎng)公司做了10多年數(shù)據(jù)產品經(jīng)理，現(xiàn)在轉行一年有余了。經(jīng)歷了幾個項目后，總結一下用外包開發(fā)踩過的坑，對于數(shù)字化產品落地的項目，如果需要找外包開發(fā)人員合作，進行前后端的開發(fā)，和產品落地，可能有參考意義。尤其是對于一些技術人員和技術能力都不足以支撐數(shù)字化轉型的企業(yè)來說，同樣會面臨外包開發(fā)管理的痛點。
曾經(jīng)找朋友吐槽，外包開發(fā)的質量怎么都這么差。然后回復到“開發(fā)技術好，誰會去做外包？”，一直在思考，事實真的是這樣嗎？
一、外包業(yè)務的主要需求方
國企或政府單位是軟件外包行業(yè)的大戶，項目規(guī)模動輒千萬甚至億級別，也養(yǎng)活了不少國內頭部的軟件外包企業(yè)。如疫情期間，四川健康碼與某外包公司的愛恨情仇。一般這種項目，軟件做的好不好，不是影響項目驗收交付的關鍵要素，主要是關系要夠硬，總結下來，不是技術驅動，而是關系驅動。
對于項目驅動的需求方，不是說不需要關系，而是說還要更注重產品和質量，因為做的項目是企業(yè)自己用，或者要交付給甲方爸爸用的，如果軟件做不好，坑的是自己。所以，對于這類需求方，能否找到高質量的靠譜的軟件外包開發(fā)人員，將直接影響項目的成敗。
二、外包資源的主要供給形式
外包的合作模式上，一般可以分為項目外包、人力外包、遠程開發(fā)、兼職開發(fā)等
項目外包： 直接將整個項目報給外包公司，甲方負責需求澄清和交付驗收，外包公司賺差價，項目外包一般小項目大的外包公司看不上。
人力外包： 甲方提用人需求，人力外包公司進行簡歷推薦、組織面試，賺人力費用差價，比如給甲方報價高級開發(fā)工程師4W人月，實際付給外包人月的可能2.5W人月，屬于倒賣人頭費
遠程開發(fā)： 現(xiàn)在一些數(shù)字游民，slogan是至工作不上班，可能在老家的某個鄉(xiāng)村小路上，只要連了網(wǎng)，就可以coding了。這種可以遇到一些技術的確不錯的，比如大廠工作多年后，積累了一些財富，前期996消耗了大量的體力，想要修養(yǎng)身心，體驗下生活。電鴨、圓領等平臺上，聚集了一些這種數(shù)字游民，但是也要注意甄別，前面項目招聘，收了很多工作近20年的簡歷，但是技不配齡，一些基礎的技術問題一問三不知，這種大概率是年齡大了，35歲以上，但是技術沉淀又不行，被裁員失業(yè)的。
兼職開發(fā)： 主業(yè)空閑時間比較多，想搞個副業(yè)，但副業(yè)始終是副業(yè)，一旦遇到工作上的事情需要處理，肯定保主業(yè)飯碗為首要目標，副業(yè)“小錢”,大不了不要了。曾經(jīng)合作過一個后端開發(fā)，接項目時信誓旦旦承諾時間投入，但一個版本沒開發(fā)完中途找工作入職跑路了，還得重新找開發(fā)資源替他填坑，這種你說他職業(yè)道德有問題也沒有意義，扣錢也沒用（實際也是正常支付費用，小錢鬧僵沒必要）。
三、供需匹配的主要痛點及應對方案
對于需求方來說，在使用外包過程的主要痛點包括：開放質量差、延期風險高、時間難協(xié)調、變更成本大，且不可持續(xù)。
開發(fā)質量差： 見識了很多個前后端開發(fā)，總體來說外包的開發(fā)質量是真的差到難以想象。但是就算再爛最終也還是得保障項目的順利交付，所以一定不要按照排期的時間去要結果，你要相信外包開發(fā)出來的東西開始的時候可能就是一坨X，尤其是遇到既不懂業(yè)務，理解力也差，技術能力也差的開發(fā)。
延期風險大， 因為涉及到一些需求理解差異帶來的返工，開發(fā)不符合需求等問題，往往會導致項目延期，但是對于乙方交付類的項目，跟客戶不同層級的人匯報的時間、產品上線時間都是卡死的，不管是加人加時間也好，也要力保deadline，或許你可能會說，跟外包都是簽了合同的，延期了，開發(fā)不符合需求，扣他們錢。但是一旦問題發(fā)生了，首先是要彌補和解決問題，扣錢的事情沒有意義，不是企業(yè)內部開發(fā)，復盤一下，甩個鍋后面接著干，差的不是錢，而是客戶的口碑，項目的按期交付。
交付不順利， 數(shù)據(jù)化的工具和產品最終需要移交客戶的開發(fā)或運維團隊，開發(fā)過程中，技術架構、開發(fā)規(guī)范、代碼質量可能會影響項目最終的順利交付，比如要額外多出一個迭代，來按照客戶要去進行整改，但是如果是架構層面的問題，改動成本就是非常巨大的。
應對方案（實踐經(jīng)驗）
1.需要一個資深的技術專家
這個可以是企業(yè)內部或者外聘，兼職即可。職責是項目前基于客戶開發(fā)要求確定技術架構，項目中負責開發(fā)架構和開發(fā)規(guī)范的評審，項目后期負責代碼review，這個人最好不要來源于外包團隊，因為代碼層面的東西，尤其是后端代碼是黑盒，如果既是運動員也是裁判員，很難客觀評判。
2.預留足夠的buffer
切記和開發(fā)約定的交付時間和客戶承諾時間一定要預留至少一個版本的buffer，這樣即使前面的開發(fā)質量再差，延期再多，更換資源或者增加開發(fā)資源重新做，時間也是來得及的，否則一旦出了問題，就沒有補救辦法了。
3.分功能分階段驗收
一定要分階段驗收，介入測試，一定不要過于樂觀地相信開發(fā)出來就能用，就是滿足需求的東西，而是要最悲觀的想象第一版開發(fā)出來的就是一坨X，需要你逐個把問題拋出來，一個個bug改，逐步把這個X整出你想要的形狀。因為往往開發(fā)都會自我感覺良好，需求理解了嘛，理解了。開發(fā)進度怎么樣，正常。最后測試驗收了，發(fā)現(xiàn)提測等于重新開發(fā)。
本文來自微信公眾號“數(shù)據(jù)干飯人”（ID：zhuangxiu1314），作者：千冰儀
