通過軟件項目外包的形式獲得令人滿意的產品並非易事，想想當初爲何美國國防部要求卡內基梅隆大學的軟件工程研究所（SEI）制定現在廣爲人知的CMM就明白了。在此，我想就我的工作體會談一談軟件項目外包之路爲何如此坎坷。
首先要明白的一點是，軟件外包項目承包商（後面簡稱爲“承包商”）與僱主之間的關係更多的是博奕，而非真正意義上的合作，因爲兩者之間存在利益衝突。僱主爲了確保外包項目獲得成功，必然會爲承包商制定嚴格的成功評價標準，比如缺陷數不能大於多少，等等。承包商爲了達到僱主所制定的成功評價標準，必然想法設法保證評價標準的穩定。要做到這一點，這就需要僱主做好需求管理
— 提供恰當、穩定的需求，然而即使僱主擁有經驗豐富的架構師要做到這一點並非易事，最終結果就是很容易因爲需求的不確定性而出現雙方扯皮，從而影響了開發效率。
造成承包商與僱主之間成爲博奕關係的另一個原因與項目開發時間的估算有關。@Thinker姜志輝在MPD的演講中指出，“估計項目開發時間的的目的是爲了適應變化，而非評估本身有多精確”，他還讓與會者通過做硬幣遊戲的方式深刻理解這一觀點。儘管我本人完全認同這一觀點，但該觀點卻無法在軟件外包項目上獲得認可而實踐。理由很簡單，僱主是以軟件的完成時間支付外包費用的
— 軟件開發所花費的時間越長，僱主所支付的報酬就越多。正因爲做到精確評估項目所需開發週期不可能，這就使得開發時間的估算成爲了承包商與僱主爭奪的“制高點”。
在“制高點”的爭奪戰中，會形成一種有趣的動態變化過程。如果承包商評估的時間存在富裕（這是她生存使然的行爲），一旦被僱主感知（後面我們會談僱主是如何感知的），僱主就會在項目的下一階段通過某種方式的施壓而壓縮評估時間。承包商一旦接受，很有可能在開發的過程中發現時間不夠，就會採用犧牲長遠質量的做法，達到在承諾的時間內“完成”項目，承包商所採取的短視行爲讓項目欠下了技術債。由於技術債的存在，承包商在下一個階段中會向僱主施壓獲取更多的估算時間，僱主由於產品面市方面的壓力，即使覺得不合理也會答應承包商的要求（更換承包商會拉長項目週期）。這種“拉鋸戰”的最終結果往往不會是產品質量穩步上升（功能數量確實會穩步上升），反而是承包商在過程中不斷地累積更多的技術債。最終僱主會發現，她花錢爲自己製造了壁壘
— 項目只有該承包商可做，否則就得承擔更大的損失。
前面還留下了一問題，即僱主是如何感知評估時間是否過於富裕的呢？有兩種途徑。最“菜”的方式是通過項目階段性“生產”出的代碼行。之所以說這種方法“菜”，是因爲這會誘導承包商採用copy-paste的方法“生產”出大量的冗餘代碼。另一種方式是評估軟件的設計質量（注意，不是評估缺陷數量）。很不幸，真正懂軟件設計的人其實很少，這一點我在《軟件開發：個人與團隊是永遠的核心》中通過“能力金字塔”已指出。就我在Motorola的經歷來看，與承包商打交道的架構師正是因爲不懂軟件設計而使得不能及時地發現項目中存在的風險（很多架構師雖有其名，但由於長時間脫離代碼，最終蛻變成對軟件設計質量毫無鑑別能力）。我曾經就某外包項目的軟件設計質量對與承包商接口的架構師進言，他當時很氣憤地質疑我“show
me evidence”。戲據性的是，該架構師最後因爲項目質量問題而調離了崗位，最後項目從承包商手中收回，並由Motorola的美國與中國團隊進行了大規模的重新設計。
軟件項目外包的困境並非完全來自承包商與僱主之間，還來自承包商的內部。承包商通常不只爲一個僱主服務，也很有可能承接多個項目。由於各項目存在不同的優先級，從而使得各項目間存在公司資源競爭。一旦某項目因爲無法從公司內部獲取好的人才，這勢必影響項目的進展和質量。
另外，由於承包商並不擁有產品，對於他們來說只能是做一單是一單，談不上對所做的產品進行長期規劃，這在很大程度上會影響軟件人才的培養進程。在這類企業工作的工程師通常不會有很強的歸屬感，也不容易激發他們的學習興趣，職場晉升的機會也相對少。如果你懷疑這一點，去了解一下大連的外包產業就知道了，據說大連的一些外包商已經在做相應的轉型了。
至此我們不難得出結論，要真正使外包項目成功，不光要承包商具備很強的專業性（不是指通過CMM5認證什麼的，如果你還相信CMM能帶來成功，多少有點幼稚。我所指的專業性在《軟件開發：個人與團隊是永遠的核心》中有些闡述），還要求僱主對項目質量具備很強的控制能力（主要是架構師的能力。什麼？靠項目經理？找死！），否則失敗是早晚的事。由於人才的稀缺性，要滿足這兩個條件中的一個已不是易事，更別說兩個。
本文出自李雲的博客，請務必保留此出處：http://blog.csdn.net/hzliyun/article/details/7844896。