摘要
當App卡關時，外包可能是那扇你沒想過的逃生門——這篇想聊聊那些在挑選外包夥伴時，沒人告訴你的真實眉角與轉折 歸納要點:
- 需求這東西很妙，一開始覺得自己超清楚，寫下來才發現漏洞一堆——我自己就遇過預算抓了80萬，結果外包商看完規格說『這至少要120萬起跳』的尷尬場面
- 挑廠商時別只盯著案例作品（雖然這很重要），有次我發現某家官網案例超漂亮，實際聯絡才知道主力團隊早離職了...後來學乖會多問『現在團隊有誰參與過類似專案？』
- 簽約前那段拉鋸戰最磨人，但試做小專案真的有用！曾合作過一間堅持要試做兩週的團隊，後來成品比預期早了半個月交付
凌晨的會議室燈光還亮著，空氣裡飄著一點咖啡味，好像誰又加了班。螢幕上那串一直不對勁的程式碼，成了Milo這晚最大的難題。旁邊白板上密密麻麻寫著專案排程、bug清單，有人偶爾走進來問句：「有沒有什麼頭緒？」然後又匆忙走開。其實這種夜裡卡關的情景，很多團隊都碰過——不是每次都能靠自己撐過去。有時候聽說別家公司在類似情境下找外包協力，好像也沒什麼新鮮。不過到底是不是大家都這樣做？初步報導好像提過，將近一半的企業會因為技術短缺考慮外部資源，只是方式各有不同。Milo看著時鐘滴答響，不確定明天醒來是不是就有解法，也許某個陌生團隊的支援正悄悄靠近，但此刻空氣裡還多了幾分遲疑和討論聲。
要挑選適合的軟體外包公司，其實過程沒想像那麼一板一眼。開始時，需求這件事常常在腦中繞來繞去，好像很清楚，寫下來才發現有些地方模糊。有人會先把預算範圍訂個大致，不一定每家公司都能配合，這時候就會自動淘汰一些不符條件的廠商。接著，有些人習慣查供應商網站或論壇討論，也有人只看案例作品和過往合作紀錄。這裡其實容易出現猶豫，要不要深入聯絡？還是再晾一晾觀察？等到名單縮到剩幾家後，通常會透過視訊或面談討論細節，包括技術流程、溝通頻率、交付方式等等。有些專案團隊甚至會安排試做小項目，但並不是每次都採用這種方式。最後，簽約前雙方反覆確認條款，有時候也拉得比較長，大概只有少數情況才一次談妥。整個流程下來，看似順序分明，可是多半伴隨修正與調整，沒有哪一步能完全跳過，也沒辦法保證每次結果都如預期那樣完美。
觀點延伸比較:
| 要素 | 說明 |
|---|---|
| 合作夥伴的穩定性 | 高留任率與團隊延續性有助於減少溝通成本及專案延遲。 |
| 技術能力 vs 協作能力 | 單純的技術力不如協作意願和補位能力重要。 |
| 透明度與責任分界 | 選擇供應商時應注意報價明細、責任劃分是否清晰。 |
| 人員流動影響 | 人員更替可能導致知識斷層，影響專案進行。 |
| 開源紀錄的重要性 | 工程師在公開社群中的互動可反映其協作態度與解決問題能力。 |
)
那時候第一次搞外包合作，印象最深的竟不是技術，而是那些莫名其妙的「驚喜」。有回明明說好交付一份雛型，結果收到的是參差不齊、甚至跟我描述內容八竿子打不著的原始碼。細節部分，有些地方還會自作主張加料，看似貼心，實際用起來卻東漏西補，改一次得多花七八天；偶爾遇到語言對不上頻率的夥伴，每個詞都要解釋半天，事情進度拖成一團。有聽說過Wirtek之前也提過這種溝通卡關在合作裡其實很常見，只能說踩雷次數多了，有些眉角現在才慢慢摸懂。
外包價格標得很低，真的就等於省到錢嗎？這個問題好像每隔一陣子就會被提起。有人說過，某些合約裡面藏著的那些「看不見」的支出，其實才是讓預算超標的主因。像返工、技術交接拖延、溝通修正來回，有時候甚至還有資料轉移弄丟或權責不清的小插曲。DAC Digital幾年前有篇分析，大致上意思是：只看報價數字容易忽略後頭那堆雜項——這種情形在初創公司或經驗不多的團隊裡聽得特別多。專業能力、合作默契和文化適應度，好像也不是能直接從金額推斷。有同事分享過之前挑選供應商時，便宜反而帶來不少糾紛；最後才發現真正花費遠比原本想像多出七八成。總之，「價格低就划算」這種直覺答案，其實背後常常潛伏著不少需要慢慢消化的小成本，也許要等到專案走到一半才慢慢浮現。
)
說到這個，其實矽谷那邊的新創圈，外包用法還真有點不一樣。有些人會說他們就是愛快、喜歡彈性大一點的合作。可能你也聽過，有幾家新創好像特別重視團隊的跨界經驗——不只寫程式還會設計之類。資料上好像顯示，這種策略在某些報導裡蠻常被提及，例如加州科技圈近幾年流行找能主動協作又適應變化的外部團隊。雖然不是每家公司都照單全收，但大家普遍認為這樣比較能跟上市場瞬息萬變的節奏。傳統企業偶爾會學著嘗試，不過結果怎麼樣，好像還得看各自狀況而定。
經過這麼些年，也許不少公司一路換了四五家軟體外包商，才慢慢發現表面炫技好像沒那麼關鍵。有時候剛開始合作看起來熱鬧，方案新穎、展示很會做，但一旦遇到人員流動或項目轉手，知識就像斷線風箏，很快就散了。初步報導也提過，高留任率與團隊延續性常讓企業在後來比較省心、省成本。當然，有些廠商一時反應快、解法多元，不代表長期合作一定順利。其實穩定的夥伴反而比較少出現在公開場合大肆宣傳，多半是默默把事情做好。不只效率提升，就連溝通上也減少很多磨合，這種感覺有點像老朋友間不需要太多語言就能明白彼此意思，只是，好像要花上一段時間才能看出這層價值。
)
有些國際調查（像是IT Outsourcing Summit近年提出的數據）大概提到，七十多的企業其實或多或少都碰過溝通落差導致進度拖延這種事。細看下來，專案延遲不只是因為技術難題，更常見的是彼此理解出現斷層。有人說可能語言不同、有人覺得時區差異才是真的麻煩。這類情況並非只發生在新創公司，許多傳統產業也同樣卡住過。偶爾有外部顧問補充說，其實建立一套固定回饋流程還是能減輕一點溝通成本，只是執行起來沒那麼容易。有些負責人甚至坦言，他們直到第二、三次合作才意識到這問題好像比想像中棘手不少。
「你們的工程師有GitHub嗎？」這問題丟出來時，現場總會有那麼一秒安靜。Milo似乎記得，有次面談正要切入技術細節，對方反而主動把自己在GitHub上的side project攤給大家看，說也奇怪，那些公開的commit、readme其實比三張推薦信還直觀。Hexa這邊有人補充，履歷上寫的專案經驗，有時和實際貢獻差了十萬八千里。據說美國那邊某些新創公司，近幾年開始偷偷把開源紀錄列入初步篩選條件，但好像也不是每個產業都適用。偶爾遇到只講自家內網平台作品的團隊，就很難判斷他們到底擅長什麼。不過綜合一些初步報導來看，若能看到工程師在公開社群裡的互動軌跡，至少協作態度或解決問題能力，大概能猜個七八分吧。
)
挑外包商這事，有時看起來像是在組一支樂團。主唱就算再怎麼會飆高音，現場氣氛炒得多熱，沒有節奏組穩住，一樣會亂成一團。你仔細想想，工程師好比鼓手、測試人員像貝斯手，各自專長不完全重疊，卻都缺一不可。有人說過，大約七十多位新創老闆裡，有超過一半回憶最初選錯外包團隊時，就像找了名氣很大的吉他手，結果排練全靠自顧自炫技，那默契怎麼也湊不起來。某些觀察指出：其實協作意願和補位能力，比單純技術力更難得。有時候，一個願意多聽半句的PM，比那種只會自己衝刺的高手還重要。工程順利與否，好像也跟每個人在樂團裡能不能配合有關，不只是誰的獨奏最響亮。
有時候，遇到廠商回覆得特別熱情、什麼都說沒問題，這種太順利反倒讓人心裡打鼓。像是報價單裡頭細節寫得不清不楚，或一問責任分界就開始推來推去，也有人案例資料交不出來，只會丟幾個看起來很厲害的名單過來。如果初步聯繫時，他們對需求總是含糊其詞，或者溝通態度明顯消極——這些跡象大概就值得警覺。有些企業碰過一兩次後才發現：只盯著價格容易忽略那些隱性風險，返工和協作摩擦也會慢慢浮現。與其等到項目卡關，不如在篩選階段直接剔除那些承諾滿天飛、不透明、責任模糊、經驗無法佐證又懶得溝通的供應商，比較省事。真正適合長期合作的團隊，多半一開始就能把話講清楚，也比較願意花時間解釋流程和做法。
參考來源
在IT 外包公司擔任軟體開發人員是怎樣的體驗？主要優點和缺點
在IT 外包公司擔任軟體開發人員是怎樣的體驗？主要優點和缺點 · 政策明確。內部開發人員對公司的目標、願景和文化有深入的了解。 · 缺乏外部項目。內部 ...
來源： CodeGym
全部
資訊科技
相關討論