作者出版社

我們是一支成立5年的技術外包服務團隊； 2016年，我們堅持變革，團隊經歷了分離、重生、重構的過程。

我會告訴正在戰斗的弟兄們和以后加入這場斗爭的弟兄們，為什么我們會做出這樣的選擇。

選擇很重要，比堅持更重要。 選擇道路，義無反顧地堅持，是一種優秀的品質； 發現問題，及時改正，付出代價改變的決心更加珍惜，更加堅定。

耀東

2016 年 8 月

技術外包怎么樣

2011-2012，快樂五年。

接到項目后，技術團隊全力以赴跳起來； 完成后，客戶結清了付款。

完美的結合，漂亮的初檢會，穩定的客戶貸款。

當時我在和一個同學談另外一個項目，每次和他喝水的時候，我的包里都差點有個協議。 新項目很棒，但我仍然很難全心投入。

和客戶打交道，2013年逐漸感受到一些變化； 有些不同。

技術外包團隊模型如下：

1、尋找客戶并參與投標

2.招標要求將與上游供應商溝通

3、投標中標，參與與客戶的深度交流

4.寫產品需求，根據客戶意向調整部分需求 5.開始開發項目（沉默）

5、開展項目測試，交付項目上線測試

6、驗收報告會，初檢報告簽字

七、付款

8.等待服務期結束，尾款支付

整個過程中，團隊如非必要，很少與其他兄弟公司有交集。 參與投標的企業是投標環境中的競爭對手； 即使他們同時中標，他們也會在項目實施過程中相互廝殺。

過去我們在項目合作上也和外包兄弟有過很多合作，也和國際大鱷說明了業務發展方向。

獨立組建公司五年后，我們的眼光失敗了。 待在溫馨舒適的環境中，難免會讓整個團隊變得一文不值。

回頭一看，我們都驚呆了。

如何突破？

建立合作關系不是簡單的和同學小酌一杯，而是要有業務層面的競爭和相互嵌入的實質內容。

首先想到的是將我們的開發項目轉化為運營項目。 從2013年下半年開始，我就以各種項目的名義在找一些投資，這是我們要打破什么的開始。 失敗在所難免，內部運營轉型不合適，外部溝通很多都是阻力。

唯一好的項目是供應鏈，即：企業采購項目。 由于現金流量巨大，在遇到合適的投資者后成功變現。

技術外包的七大罪過

技術外包服務有幾個難點，這是由整個行業的特點決定的。 可以說是整個行業的悖論。 大家都害怕甲方項目結束后會發生什么，乙方害怕項目交付不了，乙方又害怕交付后的后續協議沒有希望……

各種精彩的場景伴隨著整個技術服務流程展開，詮釋著七大罪。

技術狹窄，難以深入

2013年SaaS大??規模投入的時候，我預測國內沒有好的SaaS服務人才，至少需要3-5年的人才培養才能迎來第二次高潮。

現在看來，整個預言早就應驗了。

為什么？ 就是因為在企業服務領域還沒有足夠的優秀人才來支撐SaaS企業的發展。 前些年，大量人才聚集在技術服務外包行業，整個行業的技術實力和能力都非常高端。

一個客戶，不管他的企業有多大，都不可能超過100萬個并發會話。 代碼的健壯性是非常真實的。 一個剛大學畢業的中學生寫的代碼只要不違反基本的邏輯規則，處理一個企業的業務（包括：企業的上下游服務業務）是非常容易的。

1. 不需要掌握中級技術能力即可勝任；

2. 完成項目不需要高薪。

那么，我們為什么需要高薪、高素質的人才呢？

客戶態度導致整個行業“產品化”是一個偽命題。 基礎技術，如數據庫、中間件等，多為美國產品； 應用層技術，比如工作流，如果美國沒有開源產品，國外就不可能有好的服務商。

五年來，中國的火熱就是如此。 基本被美國淘汰，我們不能快速擁抱新技術，還在平臺上升溫。 客戶自然很難信任國外的產品，客戶也不愿意為培養優秀的國外服務商付出代價（比如：日本，日本的情況，妄想。）。

在ToB領域的人力資源外包服務中，Java工程師從來沒有寫過JS代碼，而是手寫了整個項目的后臺腳本。

之前遇到過幾次，一個甲乙方的人力資源外包服務商，Java工程師寫PC端的JS腳本，在聯通端很難跑，他們的聯通頁面都是用我們的。

中級技術服務人才大多在ToC服務領域。 阿里的雙十二對技術有著極其強烈的依賴和需求。 SaaS所需要的技術人才儲備不在ToB原來的服務商，而是在ToC的企業。

乙方把握需求，但難以了解真正的市場需求

面向乙方就是面向市場。 一個大大的“不”！

乙方就是乙方，乙方的需要就是乙方的需要。 甲方的外包服務商很清楚有多少需求來自哪里。

面臨選擇時，他依然冷靜，誤導了自己：我們是市場化企業。

沒有足夠的資金支持企業梳理客戶需求，并將其開發成客戶需要的產品； 并且沒有客戶配合完成項目的產品化過程。 面向市場對于外包服務商來說是一個偽命題。

依托資源獲取客戶

以“五鐵”關系為代表的資源型獲客在國內外都是毋庸置疑的，但我們對資源的依賴已經變成了純粹的資源依賴。

有資源的“公司”拿到客戶項目，交給沒有資源的技術團隊，技術團隊再把自己不擅長的部分外包出去。

獲得客戶的資源方會先通過各種方式對項目進行測試； 開發公司自己都知道，遇到bug或問題，會有人幫他們改掉。 為什么要在某個項目上投入100%的項目人力，一個人承擔更多的項目會更好。

由于 A 將技術能力外包給 B，因此它也依賴于資源。

部分黑色區域

一言以蔽之。

實施方為獲取利益而非項目成功或乙方利益考慮的后續協議

之前網上貼了一段代碼：delay=10000。

實施方項目負責人考慮的問題不是如何優化產品，如何合理控制項目實施時間，……，如何獲得乙方的持續同意才是最關鍵的問題。

各種代碼pc運維外包，或者說各種服務支持，都會在乙方與甲方的關系中體現出來。

好處不同，自然結果也不同。

乙方呼吁多項目少資金

一句話也提到了這一點。

獨立項目和孤獨的團隊

技術外包團隊的成員都是孤獨的。

他們在乙方公司pc運維外包，他們不是乙方的員工，不享受乙方的一切約束，而是接受乙方的管理。 我自己的公司負責工資和各種福利，但享受不到公司本身的團隊溫度。

一個外包項目長則數年，短則一兩個月。 員工們的遭遇是難以想象的。 當這樣的團隊聚在一起在母公司下一起工作時，真不知道他們的歸屬感和凝聚力在哪里。

一個剛畢業的大學生，下班第二天就被分配到某個項目。 必須迅速接受項目的一些原始規則和暗流。 他未來的成長，還真是要靠“造化”。

我們堅持不做人力資源外包，這是一種激勵。

我們努力改變

作為外包服務商的一份子，我們不能孤軍奮戰。

不做企業內部信息化項目

我非常反對OA。 知道的人都知道，公司不應該有OA，所有的事情都是基于“任務”，而不是管理者； 人力資源管理交給HR系統。

不做企業內部管理系統，做幫助乙方獲得客戶或服務于乙方與供應商關系的項目。

或多或少讓我們乞求企業內部信息帶來的“服從”。

項目需求管理必須面向N個項目

我們從不做人力資源外包，只做項目外包，讓我們有同時開展N個項目的價值，歷史項目可以重新開發。 （二次開發的價值在整個行業是非常難得的。1.外包人員的流動性是6個月，30%；2A項目的技術沉淀B項目根本不知道，即使有KM或者內部BBS交流。 )

N 個項目促使我們做技術研討會，并有能力提取協同工作內容以改進我們自己的代碼庫和協同工作組件。

兩年完成：

1、自有工作流平臺

2. .0/2.0 基于客戶和員工通訊錄的統一認證

3、基于RBAC的權限管理

4、基于模式的企業內部IM（另一種是基于XMPP合約）

5.服務于底層系統的高并發服務能力

...

依托項目管理機制，建立技術開發團隊周會和雙周代碼評審，加強內部學習。 帶來的療效是：員工離職率提高，工程完工優良率提高。

備注：請將“我們努力改變”的內容發短信給我。

當我們正在為完成一個外包項目而苦苦掙扎時，

我們感到孤獨。

改變是必要的，如何改變這三個字我們付出了沉重的代價。

試錯的結果是曾經的模式和邏輯

游戲結束。

為了獲得新的機遇和發展，我們必須

重生。

續（近期播出）：《連接最重要——依靠產品能力開啟新征程》

牛社特約撰稿人

其實你可以看到...

點擊圖片或標題閱讀