“ 很多公司和團隊選擇把整個軟件項目或項目中某些模塊或過程（比如測試）整體外包給另一家公司或團隊。本文將和你一起來探討爲什麼公司或團隊有外包的衝動，爲什麼項目外包問題多和我對外包的建議。”
01
—
爲什麼有外包的衝動
公司或團隊選擇把項目外包，無非就是想省錢、省事和轉移風險。
省錢
一個軟件項目需要各種專業角色，包括項目經理、技術主管、架構設計師、需求分析師、程序員、測試員、環境工程師等。具備這些專業技能的人才除了在市場上比一般人才的工資要高以外，培養這些人才的能力，都需要高昂的人力成本。
理論上，外包公司已經具備這樣的人才。通過項目整體外包，作爲甲方只需要關注項目的整體預算。乙方公司招聘、培育人才的成本會被平攤到各個外包項目中。
省事
還是和人有關。自己維持一個項目團隊，涉及到招聘、培訓、管理、團建、激勵、績效等多種人事管理開銷。而作爲甲方，短期而言，真正想要的是項目的產出——軟件系統，而非一個專業團隊。
項目管理和項目交付過程也是超級麻煩事，外包可以只關注結果，不需要管過程。
風險轉移
項目交付存在巨大的不確定性，過程中充滿風險。項目外包，也可以把項目交付出現問題的責任轉移給外包公司。
這些因素都充滿誘惑力。
但事情真的有那麼美好嗎？
02
—
爲什麼軟件開發問題多
從我的標題，大家已經可以知道我的結論，就是我不建議軟件開發通過外包的形式來完成。
我們知道，現代社會是一個陌生人協作的社會。一個組織、一家公司、一個團隊的能力和精力都是有限的。把非核心能力的業務外包給其他組織、公司、團隊是再正常不過的事情，我並非反對一切外包行爲。
我想說的是，有些東西可以外包，有些則不能。要看某項事物是否適合外包。爲什麼軟件開發就不太適合外包呢？
我們來看軟件開發有什麼特性。我將通過邊界、估算、驗收和合同四個方面來分享我的觀點。
邊界
一談到軟件項目，大家一定會想到超支、延期、加班等等。所有這些，都和一個重要因素有關，就是邊界不清晰。
光是在需求這個源頭，就經常出現需求不清晰、需求氾濫等問題。這些情況，就算是我們自己開發，和用戶坐在一起都會經常遇到和難以解決。我們怎麼能指望離岸的外包團隊能更好地解決這些問題呢？
另外一個最核心的問題是，有人總結得很好，從農業時代、工業時代過渡到知識時代，最大的變化就是我們的工作對象從物品變成了事情。物品的邊界是清晰的，所需要的工作時間是有限的。所以在工廠，可以通過計件來量度一個工人的產出和效率。
而事情的邊界是可以無限擴充的，可以膨脹成任何規模的工作。也很難量度一個知識工作者的產出。
幾乎所有的知識工作，都有這樣的特性。軟件項目也是其中的典型例子。一個看似簡單的需求，一旦挖掘到細節，就可以無限氾濫。我想這是所有軟件人的痛。
簡單總結就是，如果對象是物品，由於邊界清晰，完全可以外包。所以在工業領域，供應鏈已經被證明是最有效的生產協作方式，很多手機廠商，把銷售和設計以外的所有環節都外包了。如果對象是事情，由於邊界模糊，外包的有效性就會大打折扣。
估算難題
還有一個問題是，軟件項目的估算永遠不準確，根源也和上面提到的邊界問題有關。
軟件項目每次都在實現不同的目標、完成不同的東西，每次都是陌生的，充滿“意外”，所以無法準確估算所需要的時間。
但作爲甲方，我們需要乙方提供估算，以便確定外包合同的金額和交付日期。己所不欲勿施於人，如果估算這件事情我們都覺得頭疼，怎麼能指望乙方估得準。
在這種情況下，無非兩個結果：
乙方在估算時加入大量的緩衝時間，導致合同金額過高；
乙方在合同金額內無法完成約定交付，要麼甲方追加投入，要麼中止合作，得到一個爛攤子。
驗收標準
由於每個項目和需求都是不一樣，針對項目和需求的驗收標準都必然不一樣。針對每個需求，測試和驗收所需要花的功夫和難度其實和設計、編程等過程其實是相當的。
需求分析、設計、編程、測試都需要對需求進行深入的理解，都是深度的知識工作，都同等重要，不分貴賤。
當我們把整個軟件項目或項目中某些模塊或過程（比如測試）整體外包後，如何驗收就成了難題。更難的是，爲了避免甲乙雙方的糾紛，驗收標準應該約定在合同中。但也因爲剛纔提到的因素，在項目開始前對每個需求約定具體的驗收條件幾乎是不可能的，有這個功夫，半個項目已經完成了。
這也和前面提到的邊界問題有關，如果對象是物品，每個物品（比如某個零件）都應該是一樣的，其驗收條件完全可以標準化，清晰地寫入到合同裏。知識工作則很難滿足這樣的條件。
這就導致了項目的驗收條件和合同中相應的條款是開放的，而非封閉的。驗收標準一旦不能在一開始統一，將來的糾紛和扯皮就不可避免了。
合同模式
目前比較流行的外包合同模式無非就是以下兩種：
固定金額——雙方根據項目估算約定一個金額。甲方不管乙方交付項目的實際成本，只支付合同約定的金額。這種模式 ，相當於乙方承擔項目交付的所有風險。
時間與材料（Time & Material，T&M）——甲方按照乙方投入人員的工作時間支付費用，不管乙方是否交付預期的成果。這種模式，相當於甲方承擔項目交付的所有風險。
我們可以看到，在邊界、估算、驗收等問題的存在下，不管是哪種合同模式，都有一方明顯吃虧。
但其實，不管表面上是哪方吃虧，最終後果其實都是甲方承擔。我們在第一部分提到，甲方試圖外包項目，無非就是想省錢、省事和轉移風險。但大多數情況下，這三個目標都難以實現。
省錢
如果雙方籤的是固定金額合同，由於邊界難以釐清，估算無法準確，乙方肯定需要在其估算基礎上加大量的緩衝來降低自身風險，導致合同金額高昂。
如果雙方籤的是T&M合同，則更容易陷入“只收錢不出工”的窘況。
而且，對於甲方來說，最大的成本在於得不到一個想要的產品。外包過程中，交付團隊與甲方的用戶缺乏默契、缺乏對業務的深入理解，交付正確產品的機率本身就不高。
省事
表面上，外包團隊的所有人事甲方都不需要管。但是著名的管理大師德魯克總結道，所有的知識工作者都是管理者。要做好軟件交付這件事情，需要交付團隊每個人都有豐富的知識、技術、軟技能（溝通與協調）和經驗。
我們期望外包公司有現成的人員配備，但是實際情況往往是，外包公司由於要承擔人力成本，在沒有項目的時候，會盡早解散人員。所以很少在新項目啓動前就組織好所有人員，往往都是在項目啓動時才臨時到人才市場上聘用，人員素質良莠不齊，培訓不到位。
另外，參與項目人員的業務、領域知識往往非常重要，這些知識需要長期在某個具體的業務領域長期浸淫才能累積。我很難想象一個外包團隊何以在短期內掌握這些知識。
如果外包團隊的人員達不到甲方的這些預期，我看不到甲方如何省事。
轉移風險
對於甲方而言，外包的另一個好處是，一旦項目交付出現問題，可以找到一個明確的責任方。然而，我們可以轉移責任，卻無法轉移項目交付問題的後果。一個家居裝修搞砸了，承擔這個後果的只能是業主，而不是裝修隊。
還有一種外包形式是購買市場上現成的供應商產品。如果該產品能完全滿足公司業務的需要，倒還好。但真實情況是，由於每家公司的具體業務都有差異性，也有自己的合規要求，即使是購買供應商產品，也勢必需要供應商進行大量的定製化開發，這就衍生出和項目外包一樣的問題了。
03
—
我的建議
如果軟件開發項目外包不可行，但甲方確實有省錢、省事和轉移風險的需要，怎麼辦呢？
一個很典型的例子是，公司需要啓動一個大型項目，短期需要大量人員。但一旦這個項目結束了，就不再需要這麼多人員。所以會存在一個人員數量大幅波動的情況。
這種情況，如果全部靠公司自己組建團隊，則在項目啓動時需要招聘大量人員，項目結束時又要解僱人員，這爲公司帶來不必要的管理成本和風險。
公司通過勞務派遣的形式，就可以較好地解決這個問題，也就是說，通過借用外包公司的人員，而不是外包項目。外包人員可以嵌入到公司組建的交付團隊中，與公司員工一起在公司內完成項目。
這種形式可以滿足甲方省錢、省事和轉移風險的需要：
省錢——在國內，甲方引入乙方人員的成本往往比自聘人員的人力成本要低。即使單個人員成本更高，由於是短期操作，相對於短期大量招聘和大量辭退的摩擦成本，也是值得的。
省事——甲方無需投入到乙方人員的招聘、一般性技能培訓、績效等人事工作（但我還是建議甲方管理人員在其他方面對乙方人員一視同仁。同是知識工作者，乙方人員的工作積極性也是項目成敗的關鍵。對乙方人員給予同等的關懷和激勵也是對人起碼的尊重）。
轉移風險——人員嵌入到自己的團隊，更能把控，把項目風險降到最低。也能規避人員數量大幅波動對公司帶來的名譽和法律風險。
這種形式甲方通常與乙方簽署T&M合同來實現——按照派遣的人員數量和時間來結算。
另外，敏捷與DevOps也一直倡導把項目制轉換成產品制。傳統的交付模式都以項目爲單位。而項目往往是一次性的短期行爲，而且通常比較複雜，週期長，風險高。爲項目組建的團隊也是短期的。項目對於系統也缺乏長期投入使之持續改善的意願。
所謂產品制就是以業務產品爲出發點，併爲其組建團隊和搭建系統，由於產品的生命週期遠遠大於項目，團隊在滿足業務需求的同時，也會堅持持續改善，清除技術債，以不斷提升交付效率。產品的需求也會被拆成更小的特性，通過持續交付不斷實現業務價值，不像項目這樣憋一大股勁一次性交付帶來的巨大不確定性和風險。
這種情況下，交付模式會從項目預算驅動型轉換爲人員供應驅動型——業務產品團隊的人員規模是相對固定的，不會有很大的波動，在這個限制條件下，業務代表（PO）選擇最有價值的需求，實現價值驅動交付。
04
—
總結
很多公司和團隊選擇把整個軟件項目或項目中某些模塊或過程整體外包給另一家公司或團隊，試圖省錢、省事和轉移風險。
然而，由於軟件項目存在邊界模糊、估算不準確、驗收無法標準化、缺乏兩全其美的合同模式等問題，軟件項目外包很難實現省錢、省事和轉移風險的目標。
建議的外包形式是外包人而不外包事。從項目制轉型到產品制，也是一種很好的方法。
近期必讀：
關於作者
劉華（Kenneth）
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
敏於思 捷於行
堅持每週輸出一篇高質量文章
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言。