之前的失業日志系列里有講，現在的就業環境不太好，有面試機會的基本都是外包崗位。剛好之前公司和外包有幾次合作，主要是把一部分或者整個項目外包的外包公司，我們技術人員負責一部分的技術支持，通過幾次的合作，對外包的工作也有可一個大概的了解，想談一下自己對外包的了解和看法，以及最后要不要去外包。

外包主要分兩種：項目外包和人力外包。

• 項目外包
  • 企業將項目外包給第三方公司，產品、開發以及最終交付，有的是全部外包出去，有的只外包部分功能，比如有的只是外包開發部門，產品就公司設計。比如某為很多業務都會外包給某軟國際和某通動力。
• 崗位外包
  • 企業通過第三方公司，招聘員工，員工在企業內部工作，員工合同屬于外包公司，由外包管理。工作節奏和正式員工差不多，工作也相對比較輕松。

崗位外包除了待遇稍微差一點之外，相對來說工作壓力比較小，也比較穩定，對這類工作，我本身了解的也不多，本文只討論項目外包。下面根據項目的規模講兩個比較典型外包對接經歷：整項目外包和單個模塊外包。

整項目外包

公司想要重構整個電商系統，想要快速一年時間完成重構，當時技術部人數不到 10 個人，所以就準備找比較比較專業的外包公司來重構整個電商系統，整項目外包是包括前提的需求、設計，以及后期的開發、測試。

當時選了三家公司競標，最后選了一個規模和售前的專業度都更有優勢的一家上市公司。他們公司的售前人員對供應鏈、銷售、ERP系統都十分的了解，基本上提問都有對答如流，前期對接也非常順利。當時定下半年交付核心版，一年交付整個項目的目標，公司想要的效果圖：

但是售前對接完了之后，他們就撤銷了，就換成了具體的實施人員（產品和技術）。這就有點像買家秀和賣家秀，等賣家展示各種優勢條件之后，就換成無論專業和業務差了幾個等級的人。開始是我們這邊的產品負責人給他們的產品講解需求，然后一起討論，出原型。當時整個電商系統是一個 to B 面向企業的應用，用戶不像to C 這么多，但是業務比較復雜，項目初期產品遇到幾個問題：

• 售前高預期,實施部門低能力
• 工期短、業務又復雜

為啥售前和實施具體差這么多呢？是因為外包公司會花很多工資先把行業經驗豐富和口才好的售前人員，而且他們也比較穩定，不會隨便裁員。

而實施人員就沒有那么重要的了，比如產品和技術只要能干活就能進來，給的待遇也比較普通的。所以技術能力比較普通的實施為了完成前面的售前吹得牛，都要各種絞盡腦汁的完成任務。

每個產品負責4,5個板塊，公司幾年累計下來的業務邏輯需要產品幾天內梳理完，產品對于需求理解能力比較慢，復雜的需求給的時間又短，很多都是直接借鑒原來的原型，而且為了快，原型是能省則省，比如某個模塊的列表，只畫一行的數據。如果理解不夠充分的話，后期各個模塊之間一旦關聯起來后，導致后期各種返工問題。

產品問題多，技術問題同樣多，技術開始駐場之后，環境搭建用的他們公司新開發的架構系統，其實就是整合各種 Spring 組件，很多基本問題都沒有解決，比如當時使用微服務架構，本地和測試都使用同一個 nacos，導致所有人的服務都注冊同一個注冊中心上，就會導致幾個問題:

• 服務之間相互調用，比如 A 同學 feign 調用商品服務，就會調到技術B 注冊的商品服務，而技術B的商品代碼很有可能沒有更新，就會調用不成功。
• 測試環境也可能會調用到本地開發服務，就會出現本來改好的功能，反反復復出現問題。

和產品一樣，給技術的工期也很短，只有寫業務代碼的工期，根本就沒時間處理架構問題的時間。沒時間解決，只能每次關閉調自己的服務。很影響開發效率。影響開發效率，沒時間改，只能捂著鼻子硬寫代碼，先把功能實現再說。實際外包做的效果：

后面實在不行，就想到了一個稍微好一點的辦法：修改本地服務名,在服務名后面加一個自己的后綴，比如訂單服務 order 改成 order-a。這樣服務就不會亂調用了。但是就要主要不要把修改文件名提交上去了，不然又會出現問題。

前提產品和開發一些基本模塊，比如商品、用戶、客戶，這種基礎模塊開發基本都是 crud 操作，開發難度也不大。等到后期需要各個模塊之間關聯，以及還要加權限之后，各種問題就來了。

權限和代碼規范問題就像是房子的地基，前期就需要把地基打好，后面建造房子才比較穩固?，F在的模式是先把房子建好，再考慮地基，結果就是權限改了很多版，在外行看來修改權限和修改業務邏輯一樣簡單。

產品和開發基本都是天天加班，工作模式比 996 強度還更高，每天都是從早上忙到晚上，同時需要處理各種邏輯，產品沒考慮的問題，技術要返工。技術沒考慮的問題，產品要返工。suo

即使這么滿負荷的工作，也沒有完成半年交付核心版本的任務，項目的也延期了好幾個月，領導也換了好幾波。但是領導解決問題辦法就是加班，死命的加班。有一次和外包開會，他們領導說了一句經典的名言：

先加他個3天3夜，我就不信做不完，你看附近的xx項目組，凌晨3點還在熱火朝天的討論問題。你當天解決問題，都不用睡覺

其實大部分的領導為了完成任務，也會強調多加班，但是像這么明目張膽的說，我還是第一次聽。

延期幾個月之后，才勉強上線，上線后用戶也反饋系統體驗不好。接手開發之后，也是各種限制，比如前端一定要用他們的組件按照一定的規則寫代碼。

因為當時項目延期比較嚴重，后期我們也輔助他們負責幾個模塊的開發，熟悉了之后，發現他們的工作模式就是有項目的時候，天天加班。沒有項目的時候，天天休假，領最低工資。他們這種外包還會簽項目合同，比如做項目，一天多少錢，沒有項目之后，只能領最低工資。

單模塊外包

說了整個項目外包后，其實還有很多比較小的單模塊開發，比如一個模塊的某個功能外包出去，而且還不是全部外包出去，產品和設計不外包，只外包技術部分。這種項目比上面的整項目報價低，項目周期短。這有兩個問題：

• 為了中標，各種壓低價格和工期
• 需求不明確，一直改來改去

當時是做一個訂單模塊的開發，只是技術外包出去了，開始也是和上面整外包一樣，選了幾家公司備選，產品先給幾家競爭的外包公司講解需求點。公司為了中標，就把工期和價格壓得很低，當時領導就選了一家工期和價格最低的外包。

前期外包面臨幾個問題：

• 產品需求不明確，前期講個大概，原型也比較簡單。實際功能比較多，就要靠自己一個一個去問。又不是駐場外包，溝通成本也高。
• 代碼是在原來的基礎上修改，而甲方為了代碼的安全，只給一部分的代碼，無法調試一個完成的環境，有時候本地沒問題，測試又有問題。
• 業務邏輯需要自己了解和甲方技術講解，這就純看甲方技術負責態度了，如果態度好，也會講解和技術支持。如果技術不支持，就很容易卡住在那里。

當時我們作為技術也比較配合，給外包講解原來的業務邏輯，其他模塊需要修改的業務也能及時的更新。但是還是有很多問題。

比如前面說的，產品原型都是一個比較簡單的原型很多地方都問題文字說明，最后測試才發現需要修改，反復改動需求的時間比開發功能的時間都多。本地無法調用其他模塊的服務的話，只能是造一些假數據。

為什么會有外包

很多公司把一些非核心部分的工作，外包出去。就可以降低公司的運營成本。有需求就有市場，很多外包公司就應運而生。不過他們有一個更好聽的名字服務提供商。

外包公司基本是靠接項目掙錢，比如招標一個項目，標價 100 萬，中標之后，就開始招員工，給的薪水可能會比普通技術會稍微高一點，這里面也是有很多坑的。員工進去之后，不是簽固定工資合同，而是項目合同，項目才能領全額公司，沒有項目只能領底薪。

前幾年行情好的情況，甲方要求也不多，項目也多?，F在行情沒有之前好，甲方要求多，預算少。外包為了中標，會把工期和價格死命的壓低。本來三個月才能做完的，壓到兩個月。那就只能沒日沒夜的加班，一周只能放一天的假，這還只基本操作。還有前期各種需求快速講解，沒有一個適應的過程，又要在短時間之內出原型，只能是一個半成品，需求不明確又是改來改去，開發和產品的壓力都很大。

作為一個技術開發人員，在壓工期的情況下，都沒有時間思考技術方案、數據庫設計、接口或者方法的可擴展性，怎么快怎么來，有的時候恨不得變量名都是越簡單越好。這種情況下很難積累技術能力和行業經驗，也就不難理解為啥很多公司不會招聘外包出來的員工。

再回來看之前提的問題，為啥只有外包的崗位特別多，因為外包的工作模式就是有活干的時候，天天加班。沒活干的時候，只有底薪。假設在深圳領底薪，也就是深圳的最低工資，房租都不夠，基本都會自己離職。等有活的時候，再招新的員工干活，做完再等員工自己離職。

利弊分析

• 優點
  • 進入門檻較低，適合職場新人積累項目經驗。
  • 部分崗位外包工作強度較低，較為穩定。
• 缺點
  • 成長空間有限：外包開發常以快速交付為目標，缺乏對架構設計、技術創新的重視。
  • 不穩定性高：外包崗位受項目周期影響大，工作節奏不穩定。
  • 職業發展受限：長期外包經歷可能導致技術能力與行業經驗不足，不利于后續求職競爭力。

萬不得已，千萬不要去外包

現在行情不太好的情況下，如果一直找不到工作，也可以暫時過度一下，畢竟外包的機會也很多。也有可能有的外包公司還不錯。

剛畢業的時候，年輕體力好，可以加班，也熬的動，外包也可以做，但是長時間的加班，沒有技術的技術的提高，一旦沒有項目就只能換公司，對自己來說也是不劃算的。當年齡增加的時候，也要增加自己的技術能力和行業經驗，這樣即使再換工作的時候，也能找到更好的工作。

總結

外包并非一無是處，但它更多是一個不得已的選擇。對于剛畢業的職場新人或短期面臨就業壓力的人，外包是一個獲取項目經驗的機會；但從長遠來看，應盡快轉向更能提升技術能力、積累行業經驗的正式崗位，才能在職場中走得更遠。

外包公司可能給你一時的工作，但不能給你長久的未來。希望每一位技術人都能為自己找到更適合的職業道路。