To B軟件類產品外包存在的諸多矛盾，資金與服務的矛盾、產品與項目的矛盾、團隊能力的矛盾、契約與人性的矛盾、溝通協(xié)作的矛盾等等，以下是作者七八年產品外包的掉坑經歷整理，希望能給一些初入此行的產品經理們一些啟示，引發(fā)一些共鳴。

這些天，又在與外包團隊進行各種產品問題的討論糾纏，苦惱不堪。

近些年由于To B SAAS市場、互聯(lián)網(wǎng)創(chuàng)業(yè)發(fā)展迅速，產品外包在軟件領域日益興起，很多創(chuàng)業(yè)公司、傳統(tǒng)IT企業(yè)、集成商、運營商都紛紛參與到產品外包的價值鏈中，有的扮演甲方發(fā)包項目，有的扮演乙方承包項目；有的則前腳作為乙方承接項目，后腳就作為甲方轉包給下家。

然而，相比項目的一次性而言，產品卻是一個長期不斷優(yōu)化迭代的過程，因此產品的外包這其中存在太多值得思考和總結的問題。

作為身處產品外包七八年的老兵，今天就圍繞To B軟件類產品外包存在的諸多矛盾，給大家分享下我在此過程中所經歷的一些坑，其中涉及資金與服務的矛盾、產品與項目的矛盾、團隊能力的矛盾、契約與人性的矛盾、溝通協(xié)作的矛盾等等。

希望能給一些初入此行的產品經理們一些啟示，引發(fā)一些共鳴。具體如下：

一、資金與服務的矛盾

“給多少錢，辦多少事”在基于交易的外包中，這條真理常掛在嘴邊，卻也常糾纏不清。

一切服務都和錢掛鉤，給多少錢、提供多少服務、準備多少資源。為了避免扯皮，甲方往往會在合同中對服務有非常明確的要求，它不僅包括基本的功能需求、交付時間、產品質量驗收標準，還包括客觀的管理要求，即外包團隊人數(shù)、人才能力（面試評測）、人才績效考核標準；以及產品開發(fā)過程中有關設計、運營、維護等相關服務的詳細要求。

然而，理想很豐滿，現(xiàn)實很骨感，產品外包中資金往往和服務不能劃等號。

主要有兩種情況：

1. 錢給少了，索要的服務過多

一方面：很多企業(yè)或者創(chuàng)業(yè)者，在產品外包時，總是會極力壓低預算，能省則省，但他們的需求卻有增無減。

誰都想要價廉物美的商品，這當然可以理解，但萬事都得講個“度”。

產品在研發(fā)過程中，需求變化在所難免，如果和乙方協(xié)商處理好就不存在沖突。但有些甲方不僅功能貪多求全，而且在簽完合同之后，完全不考慮乙方的感受，想方設法的追加需求索要服務，甚至自己內部的匯報材料撰寫，或者與項目不相干的事情也讓乙方去做，這一點在政府客戶中比較常見。

這樣的情況，對于乙方，有時候迫于客戶關系，可能會做一些，但這樣的需求多了，且收益包不住成本的時候，要么選擇拒絕，要么偷工減料降低質量。

如果甲方逼得太狠，乙方精力全在扯皮上，心累了直接撂挑子走人。

另一方面：也不乏很多外包團隊，初期為了給自己賺吆喝，為公司業(yè)績增添案例，從而不惜報超低價，只為能夠拿下項目。一旦和這些廠商建立合作，后期風險可想而知，他們如果發(fā)現(xiàn)賺足了吆喝，且出現(xiàn)“入不敷出”的情況，就會立馬減少投入，甚至消失的無影無蹤。

2. 錢給夠了，得到的服務不夠

相反，有時候甲方的資金很充足，但因為乙方為了追求利益最大化，主觀上偷工減料；或者因為內部能力不足、資源調配，從而降低了服務標準，造成產品無法順利完成。

例如：乙方外包團隊往往手里不可能只做一個項目，他會同時承接多個項目。這時候，乙方會根據(jù)項目的規(guī)模、緊急程度、重要性等，對資源進行重新分配，將好的資源分配給重要的項目。

所以即使甲方給的錢充足，但和其他項目比起來，依然沒有足夠吸引力，所以乙方會對原本甲方的項目實施資源減配。

這樣的話，有可能原有項目上能力強的開發(fā)人員就有可能被抽調走，留下的人員還會存在被其他項目復用的情況。本來專注于一個項目的工程師，卻被其他項目牽扯精力，可能一天只有0-10%的精力在甲方產品上，而且會不斷被打斷，影響工作效率，整個團隊的能力和效率會下降一大截。

即便是駐點在甲方現(xiàn)場的開發(fā)形式，也存在這樣的情況，“人在曹營，心在漢”這句諺語用在這里可能比較貼切。

二、產品與項目的矛盾

甲方做的是自己的產品，而乙方做的是別人的項目。

這兩者本身就是相互矛盾的，甲乙方的立場目的完全不一樣，乙方帶著做項目的心態(tài)去做產品，是不可能完全把產品做好的。

雙方的關注重點完全不同，甲方更關注產品本身，希望作出一款用戶需要的好用的產品，以此來打開市場提升銷售業(yè)績。而乙方只看重眼前的利益，做完一單是一單，收完錢就轉移陣地。

1. 周期的矛盾

做產品是沒有完成之日的，是長期的，持續(xù)需要迭代演進；而做項目是有明確完成時間的，是短期且一次性的，一錘子買賣，做完就走，不會維護后續(xù)版本。開發(fā)人員都找不到了，怎么繼續(xù)做優(yōu)化迭代呢？

當然可以協(xié)商做一期、二期，這樣階段性的項目，但這樣的折中方案依舊避免不了這樣的矛盾。

2. 需求范圍的矛盾

產品需求具有不確定性，是根據(jù)市場及客戶需求不斷新增、變化的；而項目需求是有明確項目范圍的，雖然也有變更，但是是在成本、質量、時間的綜合因素條件下決定的，范圍相對可控。

3. 用戶體驗的矛盾

做產品，用戶體驗是必備因素，即便是To B產品也在越來越追求好用的用戶體驗；而做項目，首先追求的是功能，用戶體驗是次要的。

目前很多外包團隊不重視體驗設計，所以缺少交互體驗專員，前期也不會做詳細的交互設計原型，認為只要功能實現(xiàn)即可交付，并且合同中也不可能細化到交互細節(jié)要求。另外很多時候，還以“體驗見仁見智”或者“我認為挺好的”這樣的主觀口吻來搪塞。

許多乙方雖然在前期提供了大量的UI設計稿（圖片），供甲方確認，但最終做出的產品還是會和期望相差太遠。一方面，前期的圖片比較零散并沒有體驗真實交互，另一方面，原型也不能面面俱到，總有疏漏之處，而乙方則以未事先說明且經甲方確認為由不予修改。

4. 技術架構的矛盾

做產品，往往希望采用先進的架構，靈活的插件，以保證產品有較好的穩(wěn)定性、擴展性、兼容性和使用體驗，即便初期架構簡單，后期也要重構。

但很多乙方往往抱著其公司內部老舊的技術體系架構，堅持“一招鮮吃遍天”的打法，每天忙于拓展項目賺錢，完成功能是第一要務；而同時技術重構又需要花費大量的人力和時間，所以他們根本不愿意沉下心來去重構改進。

5. 產品期望與團隊能力的矛盾

人是產品能否成功的關鍵因素，在產品外包中，卻常常因為乙方人才資源的匱乏導致做出的產品總是不盡如人意。

好的人才往往聚集在大型互聯(lián)網(wǎng)公司、國企，或者發(fā)展前景好的創(chuàng)業(yè)公司，而外包公司的人才水平參差不齊，這跟外包公司的業(yè)務性質和成本結構有很大關系。

對于外包團隊而言，人力成本是最大的支出占比，特別在當下IT人才薪水節(jié)節(jié)攀升的時代，外包利潤縮水嚴重，為了謀取外包項目的最大利潤，必需盡量壓低項目的人力成本，這也成為了很多外包團隊能力有限的主要原因。

常見問題我總結為三個方面：

（1）人少

乙方減少單個項目的人數(shù)投入，有的項目甚至只投入0.5-1個人，可謂是極度節(jié)儉。研發(fā)人員捉襟見肘，產品很難保質保量完成。

當然不能僅通過人員數(shù)量來決定團隊能力，就像《啟示錄》中提到的那樣，寧愿選擇5個專業(yè)能力強的高級工程師，也不愿選擇30個能力一般的菜鳥。

在我之前參與的一個產品外包項目中，曾經只有一個人主要負責開發(fā)，但因為能力強，基本可以保證交付的質量，但后期逐漸加人，反而出現(xiàn)了一些麻煩，還需要前期的人來填坑，不僅影響進度還造成了浪費。

（2）人不行

人員能力不行，一直是很多甲方詬病的問題，總是抱怨乙方人員總是不能很好的實現(xiàn)他們的預期，諸如缺少基本的規(guī)范和邏輯、功能無法實現(xiàn)或者開發(fā)時間過長、文檔撰寫太差、溝通能力有限、項目管理能力有限等等。

其實，不管什么團隊，我們都想要優(yōu)秀的人才，但薪水自然要求也比較高，對于乙方，平衡成本之下，不可能都做到高端配置。

所以，乙方會根據(jù)甲方項目的規(guī)模、重要性、時間計劃先后等因素，對多個項目的人力配備進行深入評估，招募和配置不同等級的人才。

一般一個團隊配置1-2個高級人才就已經很奢侈了，另外再招募一些應屆大學生、或者中專、培訓機構出來的人才，這些人的薪資要求很低，既可以達到甲方對團隊人數(shù)的要求又可以降低成本。這里用“濫竽充數(shù)”這個成語再合適不過了。

（3）人難管

頻跳槽：

外包團隊的人員離職變動在IT行業(yè)中可能更加頻繁，有些人今天剛報到，可能三天后就要離職。

而這樣的人員變動，影響最大的就是工作交接所帶來未知風險，不僅需要花費時間去找到下一個合適的接班人，即便是找到了，人員還需要接手和適應的時間，整個周期下來，產品已經停滯兩周了。那外包行業(yè)人員離職的主因是什么呢？

我總結兩點：

工作苦逼沒有歸屬感：外包項目一般都駐點在項目現(xiàn)場，人員工作地點不固定，常常更換，并且駐點時間往往少則三個月，多則一年半載，工作環(huán)境也由甲方提供的場所決定，好點的提供。

多頭項目沒有自我提升時間：特別是能力不錯的人才，由于能力較強，單位工作效率和產出較高，而這樣的人往往公司會給他安排更多的項目去做，有的人甚至成了救火隊員，哪里項目有問題，就派到哪里，到處奔波，身心俱疲。

正所謂“能力越強，責任越大”，這個詞在外包公司這里得到了很好的體現(xiàn)。

長期這樣，沒有時間去自我提升，能力遇到瓶頸，不能與時俱進的更新知識，每天疲于應付項目，所以跳槽是遲早的事兒。

（4）不服管：

這個現(xiàn)象常常出現(xiàn)在甲方現(xiàn)場駐點開發(fā)的場景，正所謂“將在外軍令有所不受”，外包團隊長期駐點，缺少激勵，士氣低迷，且領導不在身邊，沒有約束力。

所以經常出現(xiàn)工作積極性不高、工作時娛樂，不認真工作；并且人員存在逆反心理，主觀不聽從甲方的修改要求。

這里的原因：主要是現(xiàn)場外包人員的個人績效考核權利不在甲方，也就是工資不是甲方發(fā)，所以難以對其形成約束和激勵。

溝通協(xié)作的矛盾

6. 異地辦公

很多外包團隊與產品負責人需要在研發(fā)過程中，針對設計、成果等進行不斷的討論、協(xié)作。

如果他們分屬異地，即便現(xiàn)在有很多互聯(lián)網(wǎng)溝通產品，也無法替代當面溝通的效果。有些產品僅靠幾頁草稿去開發(fā)，幾個月后再看產品，質量可想而知。

所以異地情況，我們一般至少保證每周及重要里程表組織團隊見面，確認每周及階段性進展成果及下一階段計劃。另外，定期郵件往來、QQ、微信、視頻等即時通訊手段給予輔助。

7. 溝通心態(tài)

有些甲方認為花錢后什么都不用管，應該得到全方位的服務，乙方應全權負責產品。這種情況下做出的產品往往沒有好的結果。

就好像把自己的孩子完全托付給別人寄養(yǎng)，幾個月后的性情肯定是這個媽媽無法接受的。如果甲方在一些場合，以“上帝的姿態(tài)”做出過激的行為，可能會觸犯工程師的尊嚴，引起乙方不滿，甚至撂挑子不干。因此，保持一個“開放、平等、合作”的心態(tài)才是項目所必需的。

乙方的不主動溝通也比較常見。一種情況是甲方的需求有時比較模糊，乙方按照自己的想法實施研發(fā)，不事先與甲方溝通。另一種情況是甲方對技術不太精通，有些問題可能乙方早就覺察到了，但因為怕耽誤工期或者投入成本太高，一直捂著不主動提出，等到最后產品上線終于出了問題，那時候的損失就很難控制了。

8. 無效溝通

甲乙方的會議經常從早晨討論到晚上，且非常激烈，但最終卻沒有結果，或者有結果第二天又推翻繼續(xù)討論。一來二去，既耽誤了時間，又耗費了大家的精力。

所以在會議召開之前明確會議主題和目的非常重要，會議中一旦出現(xiàn)偏離，立即打斷，必須保證整個會議的討論朝著一個結果有序進行。

會后，形成會議紀要通告大家，重要問題最好簽字確認，加強儀式感。雖然也會有推翻的可能，但至少在簽字時，每個人都是報著對會議結果負責的態(tài)度。

三、甲乙管理機制的矛盾

1. 開發(fā)管理方式沖突

對于很多互聯(lián)網(wǎng)或者SAAS產品，多采用敏捷的研發(fā)方法，迭代的速度要求也是相當高的，少則一周，多則兩到三周就出一個版本。

而很多傳統(tǒng)外包團隊，依然更多采用瀑布式的開發(fā)方法，按部就班的輸出需求文檔、設計文檔、項目計劃、開發(fā)、測試，整個周期下來2個月之后才能看到成果，這時候也許市場早就沒了。

我不是說所有項目都要敏捷，但有些適合敏捷的項目就應該堅持敏捷。有些文檔完全不需要撰寫，寫了也沒人看。直接出原型給開發(fā)，要比文檔效果更好。

乙方自有的項目管理工具僅在內部使用，不向甲方開放共同協(xié)作使用，例如Bug管理、文檔管理等。

所以，如果甲方發(fā)現(xiàn)軟件某些問題，或者需要查看部分文檔，還需要通知乙方接口人轉達或者獲取，非常影響協(xié)作效率。而且一旦遇到不靠譜的乙方，這些內部管理記錄很多都沒有規(guī)范的執(zhí)行。

因此，作為甲方，建立自有的項目管理工具體系對產品推進有益無害，既可提高溝通效率，也可及時監(jiān)督項目進展，發(fā)現(xiàn)問題。

2. 測試形同虛設

乙方對于開發(fā)完成的產品，常常不重視測試，甚至不做測試。開發(fā)完成之后，草草測試了事，或者直接甩給甲方，讓甲方去驗證發(fā)現(xiàn)問題。

這一點經常讓甲方負責人惱火，一個版本要多次的驗證打回，再驗證再打回，勞心費力，既浪費時間又沒有進展，完全充當了乙方的測試角色。

這里原因有很多，包括：

• 乙方公司規(guī)模較小：專業(yè)的測試人員只配備1-2人，有的甚至沒有測試人員，或者有其他職位的人兼職，測試水平較差。如果乙方承接的項目較多，人力資源有限，有些項目時間緊，根本來不及測試就提交甲方。
• 乙方公司的開發(fā)理念重開發(fā)輕測試：有些公司領導依舊持有這種陳舊的思想，所以在招聘人員上，測試人員的數(shù)量和水平一直不被重視。而且，測試在公司的話語權和交付責任機制，并不是以測試為中心，出了問題也不會找測試問責，這也是造成了這一現(xiàn)象的原因。

3. 內部管理不暢波及項目

有人的地方就有江湖，有時乙方內部的不合理管理和派系斗爭，也會波及到甲方項目。

例如：內部開發(fā)人員與項目經理分屬不同部門，之間存在工作量結算或者內部KPI考核的矛盾；或者內部提交開發(fā)的流程死板，都會影響內部資源的調配和項目推進。

四、契約與人性的矛盾

雖然合同在法律上規(guī)定了甲乙方的責任與義務，但很多時候并不是非黑即白的。

特別是在中國，除了“一紙約定”去約束項目和規(guī)避風險，其實還有甲乙方的中國式關系、以及職業(yè)操守這樣的灰色區(qū)域。這些我把它們歸結為人性，也就是人際關系和誠信問題。

有人的地方就有主觀喜好，這種喜好會表現(xiàn)在對合同執(zhí)行的干預作用，執(zhí)行好的項目可能會被人為破壞，執(zhí)行差的項目可能會被“潤滑”、或者調和改進。

1. 負面激化矛盾

• 甲方的誠信問題：因為乙方在實施過程中，沒有遵循“潛規(guī)則”，使得甲方主要負責人不滿意，從而在項目驗收時，故意刁難、延遲驗收，拖欠款項。乙方隨即暫停工作，使得項目無法收尾。
• 乙方的誠信問題：因為乙方與甲方某位項目關鍵人關系不一般，且大包大攬，不問需求先承諾，甚至以虛假案例最終拿到項目，但之后發(fā)現(xiàn)沒有能力承接，或者二次轉包，最后做成了爛尾產品，即便關系好，合同上也說不過去。

2. 正面化解矛盾

人際關系和契約有時候不一定是激化矛盾，有的時候也可以化解矛盾，成為矛盾的“潤滑劑”。

例如，在合同執(zhí)行時，乙方對甲方不僅項目服務非常到位，關系也維護的很不錯。之后甲方的需求因市場變化有所變更或者蔓延，這時候乙方因為人際關系，可能在成本可控的情況下會更多的承擔一些開發(fā)；而甲方也可能因為人際關系，提出增補合同，追加投資。

再如，項目驗收時，即便有一些產品瑕疵，因為關系好，往往睜一只眼閉一只眼，就驗收通過了，后期乙方再優(yōu)化完善，不影響合同付款進度。

以上就是個人對于以往To B產品外包中趟過的各種坑的一個總結。

也許你會問，這么多坑該怎么避免呢？

如果你是甲方給你幾點建議：

（1）不外包自己干

首先，想好外包的原因，是因為時間來不及、缺少技術、還是資金有限。

如果僅僅是想壓低成本，不建議外包，這個思路做不好產品，特別是核心部分更不建議外包。如果是因為時間緊又沒有技術團隊，可以考慮第一個版本外包，后續(xù)自建團隊接手重構迭代產品。外包是為了尋找專業(yè)的人做你不擅長的事情，而不是僅僅為了少花錢，這一點謹記。

（2）切勿貪大求全

MVP最小可交付產品的精益方法業(yè)界已經熟知，我就不在多說了。

對于傳統(tǒng)行業(yè)創(chuàng)業(yè)者，貪大求全的錯誤還是會犯，在產品外包中，就更要避免。如果要做移動端，你不需要iOS、Android、微信H5全做，你可以先做微信H5，成本小流量多，可以很好的驗證第一版。

（3）選擇靠譜開發(fā)團隊

首先，最好通過熟人關系，真實了解他們團隊的能力及服務。其次，團隊盡量選擇和自己在一個地方，避免異地。

再次，外包團隊要穩(wěn)定并專門負責自己項目，不能被其他項目牽絆。最后，就是項目負責人以及開發(fā)人員要有豐富的開發(fā)經驗等基本考證了。

（4）過程管理抓大放小

過程兩頭重點抓：

開始階段要重點抓需求范圍界定、和交互體驗設計。需求雙方一定要吃透，盡量不要有模糊不清的地方，對于不確定的部分可以不放到第一個版本開發(fā)。

另外，建議輸出高保真原型，并且對部分交互點給予說明。對于體驗設計粗糙的原型一定要嚴格拒絕，重新打回重新設計，不能直接進入開發(fā)，要知道好的原型可以避免很多后期開發(fā)的風險。

開始階段的項目管理模式要雙方明確并嚴格執(zhí)行，比如接口責任人、溝通機制、管理工具的選擇等等，以便為后期項目執(zhí)行打下良好的基礎。

后期的驗收標準、考核懲罰機制和驗收執(zhí)行要重點專注，驗收標準盡量細化，覆蓋產品功能、交互體驗、服務、維護等多個方面，以及相關的考核細則都要在項目開始前明確，并寫到合同中，以規(guī)避風險。

過程中間選擇抓：

“若事無巨細，皆以身親之，則所得至寡，所失至多矣”，所以中間過程僅作節(jié)點提醒和適度監(jiān)理即可。如果事事親為，一方面，分散注意力容易忘記重點，另一方面，要給乙方團隊一定的自由度，手深的太長，會影響團隊原有的節(jié)奏，也容易打擊團隊的積極主動性。

本文由 @包巖 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。