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

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

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

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

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

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

一、資金與服務的矛盾

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

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

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

主要有兩種情況：

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

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

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

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

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

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

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

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

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

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

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

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

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

二、產品與項目的矛盾

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

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

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

1. 周期的矛盾

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

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

2. 需求范圍的矛盾

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

3. 用戶體驗的矛盾

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

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

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

4. 技術架構的矛盾

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

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

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

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

好的人才往往聚集在大型互聯網公司、國企，或者發展前景好的創業公司，而外包公司的人才水平參差不齊，這跟外包公司的業務性質和成本結構有很大關系。

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

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

（1）人少

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

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

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

（2）人不行

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

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

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

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

（3）人難管

頻跳槽：

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

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

我總結兩點：

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

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

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

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

（4）不服管：

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

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

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

溝通協作的矛盾

6. 異地辦公

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

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

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

7. 溝通心態

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

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

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

8. 無效溝通

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

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

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

三、甲乙管理機制的矛盾

1. 開發管理方式沖突

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

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

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

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

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

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

2. 測試形同虛設

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

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

這里原因有很多，包括：

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

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

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

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

四、契約與人性的矛盾

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

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

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

1. 負面激化矛盾

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