琢奧科技 DropOut Tech
INITIALIZING_NEURAL_ROUTE…0%
DO_CORE|NEURAL_MATCH
轉型實戰 // FDE

為什麼矽谷不「賣軟體」，
改成把工程師派進你公司？

這篇想跟你聊一個叫 FDE（Forward Deployed Engineer，前線部署工程師）的東西。 它不是什麼新潮流——Palantir 做了十幾年，這兩年連 OpenAI、Anthropic 都在搶著做。 我用白話講一遍它的來歷、怎麼運作、為什麼有效，還有它跟你認知裡的「找工程師」差在哪。

李孟一 DreamOne · 琢奧科技共同創辦人2026.07.27

先說一個我這幾年最常遇到的場景。我幫不少老闆健檢他們的系統，開場白幾乎都一模一樣：「當初花了幾十萬做的東西，現在根本沒人在用。」

說真的，我一點都不意外。因為大部分人找技術，找的是「一個會寫程式的人」或「一間接案公司」， 把需求丟過去、驗收、上線，然後⋯⋯就沒有然後了。生意是活的，系統卻停在交付那天。 半年後業務流程變了、市場變了，那套系統就變成一具沒人維護的空殼。

問題從來不在技術。你要解決的，其實是商業問題—— 怎麼收錢更順、怎麼少犯錯、怎麼讓客戶不流失。而這件事，矽谷其實早在十幾年前就想通了。

先說個故事

一家軟體公司，為什麼決定「不賣軟體」？

你可能沒聽過 Palantir，但它現在是美股上千億市值的公司。2000 年代它想把資料整合軟體賣給情報與國防單位， 結果賣不動。不是軟體不夠強，是這些單位的狀況太複雜、資料不能外流、流程還一直在變， 客戶拿到再厲害的工具也用不起來。

於是 Palantir 做了一件很反直覺的事：不賣軟體了，改「派工程師」。 把自家最強的工程師直接送進客戶的辦公室，坐在承辦人旁邊，用他們真實的資料、在他們真實的限制下，把東西一路做到能用為止。 這批人內部代號叫 Delta，也就是後來大家說的 FDE。

這招有多關鍵？到 2016 年為止，Palantir 公司裡的 FDE 比一般產品工程師還多。 這不是人力配置失誤，而是他們認清了一件事：光把軟體交出去，永遠不夠。

有趣的是，這套做法一開始被投資人罵翻——他們覺得「派工程師進客戶端」根本是在做服務業、不是做軟體，怎麼看都不對。 第一個跳下去做的，正是後來當上 Palantir 技術長的 Shyam Sankar；他回憶那時「投資人恨死這個模式，但它對使用者顯然就是對的」。 連創辦人 Alex Karp 都半開玩笑說：只有像 007 一樣性感的東西，才能說服全世界最強的工程師去做「資料整合」這種無聊事。 他們的訣竅其實很簡單——不挑性感的問題，挑重要的問題，再找到那些覺得「重要問題很性感」的人。

所以，FDE 到底是什麼？

講白一點：FDE 不是「接你案子的乙方」，而是被派到你前線、跟你並肩作戰、對「結果」負責的工程能力。

差別在最後三個字——對「結果」負責。一般工程師交付的標準是「功能有沒有照規格做出來」； FDE 的標準是「你的生意有沒有真的變好」。做出來沒人用，對 FDE 來說就是沒做完。

所以你真正該找的，不是「更便宜的工程師」，而是一個懂商業的技術人。 他得同時扛得起三件事：

懂商業

先聽懂你的營收、流程與真正的痛點。

+
會技術

真的寫得出能上線、production 級的系統。

+
對結果負責

不是交付就走，是你生意真的變好才算數。

=懂商業的技術人才（FDE）
他們怎麼做事

兩個我很喜歡的做事原則

一、第一天就對真實資料出貨

FDE 不搞那種「先花三個月訪談、寫一本厚厚的需求規格書」的儀式。 他們一進場就用你真實的資料做出一個能動的東西，讓你當天就看到價值，再邊跑邊修。 因為只有碰到真實資料，你才會發現那些訪談永遠問不出來的魔鬼細節。

二、碎石路先鋪，再升級成高速公路

Palantir 內部有個說法叫「gravel road to paved highway」。 意思是：先為單一客戶做一條堪用的碎石路（快、髒、但能走）， 等累積夠多客戶、看清楚共通的模式，再把它鋪成人人可用的柏油高速公路。 對你來說的好處是——你不用等一個完美系統，你先有一條能走的路，而且它會愈走愈好。

「好點子不會在帕羅奧圖吃著草莓時冒出來。它們出現在吉布地的火線上、底特律的工廠裡——在那些你能親眼看到真實情況的地方。」
— Shyam Sankar，Palantir 技術長、Palantir 第一位 FDE
這兩年為什麼突然紅

連 OpenAI 都放下身段，派人進客戶公司

本來 FDE 是 Palantir 的獨門功夫，玩了快十五年。結果 AI 一來，整個矽谷突然都在抄。原因很簡單：模型變強的速度，遠比企業「用得起來」的速度快太多了。 買了 API、開了帳號，然後呢？大部分公司卡在「試玩」到「真的上線」中間那道鴻溝。

2025 年，OpenAI 直接成立了一支 Forward Deployed Engineer 團隊。帶隊的 Colin Jarvis 講過一個案例： 他們幫一家財富管理公司做 AI，技術本身六到八週就搭好了，但要讓理財顧問願意信任、真的用起來，又多花了四個月跑試點、收回饋、反覆調整。 最後呢？大約 98% 的顧問把它用了起來。

OpenAI 還嫌不夠——又砸了 40 億美金另外開一家專做部署的公司，甚至直接併購一支現成的 FDE 團隊。 Anthropic 幾乎在同一時間做了一模一樣的事。這些最會做模型的公司都想通了同一件事：真正難的不是技術，是把技術塞進你複雜的營運現實裡，還要有人負責到它真的產生效果。

一次性外包 vs FDE，一眼看懂

傳統一次性外包
  1. 1. 寫規格 → 開發數月（過程看不到東西）
  2. 2. 一次性上線（賭這一刻就做對）
  3. 3. 交付後沒人持續照顧
  4. 4. 半年後被打入冷宮 ✗
FDE 前線部署
  1. 1. 第一天就對真實資料出貨
  2. 2. 邊用邊修、持續迭代
  3. 3. 針對營運例外即時調整
  4. 4. 愈用愈好、真正落地 ✓
回到台灣的中小企業

為什麼「一次性外包」特別容易踩雷？

我知道你可能想說：矽谷那套燒錢的玩法，關我什麼事？但下面這三個數字，中小企業其實踩得更慘—— 因為你的每一分預算都更該花在刀口上。

17%
大型 IT 專案嚴重到足以威脅公司存續

痛點 1：一次性外包，賭的是「一次就做對」

傳統一次性外包把成敗全壓在上線那一刻。McKinsey 與牛津大學分析 5,400 個大型 IT 專案發現，平均超支 45%、交付價值比預期少 56%，更有 17% 的專案嚴重到足以威脅公司存續。上線後沒有人持續針對營運例外狀況修補，系統就會慢慢被放生。

資料來源：McKinsey Digital & University of Oxford (2012)．Delivering large-scale IT projects on time, on budget, and on value
64%
軟體功能「極少或從未」被使用

痛點 2：開工前的規格書，正在燒掉你的預算

Standish Group 由創辦人 Jim Johnson 於 XP2002 發表的研究發現，軟體交付的功能中有 64% 極少或從未被使用（45% 從未、19% 很少）。開工前死板的需求規格書（SRS）與過度的規格膨脹，讓大筆預算流進沒人用的功能黑洞。

資料來源：Johnson, J. (2002)．Standish Group, XP2002；亦見 CHAOS Manifesto 2013
≈1/3
開發者工時耗在維護與技術債

痛點 3：系統交出去之後，帳單才開始跑

Stripe《The Developer Coefficient》(2018) 調查發現，開發者平均每週 41 小時中有 17.3 小時（約三分之一工時）耗在維護、除錯與技術債，全球每年因此損失約 850 億美元機會成本。缺乏持續照顧的系統，技術債只會越滾越大，最終逼你打掉重練。

資料來源：Stripe & Harris Poll (2018)．The Developer Coefficient

那 FDE 跟「找一個駐點工程師」差在哪？

很多人第一反應是「不就是外包／派遣嗎」。真的不一樣，差在下面這幾點。

面向傳統駐點工程師FDE（我們）
成本結構全職薪資＋勞健保＋獎金＋管理成本，忙時不夠、閒時浪費按月租用一個團隊的能力，需求起伏可彈性伸縮
技能廣度單一工程師技能有限（前端 or 後端 or 維運）架構、開發、自動化、AI Agent 一整組能力隨叫隨到
知識延續知識綁在個人腦袋，離職即斷層知識沉澱在系統、文件與流程，換人不斷線
營運例外被日常維運綁住，難兼顧策略持續針對營運例外即時修補，並對齊商業目標
責任歸屬你要自己管理、考核、扛技術決策風險我們扛技術決策與交付品質，做完不落跑

算給你聽：FDE 幫你省下的四筆錢

它不是多一筆開銷，而是把你本來就在流失的錢收回來。

01

省下養團隊的固定成本

不必負擔全職技術長／工程師的薪資、勞健保、招募與管理成本，把固定成本轉為彈性月費。

02

省下賭一次性外包的風險

不把成敗壓在上線那一刻。以持續節奏交付、驗證、修正，避開「上線即棄用」的黑洞。

03

省下無用功能的預算

從最短板與高價值需求開始做，不做沒人用的功能，讓每一分預算都對齊營收與效率。

04

省下技術債累積成重寫的代價

持續維運與迭代，讓技術債被即時清理，避免幾年後被迫打掉重練的巨額成本。

說到底，你要的從來不是一套軟體，是有人幫你把生意裡卡住的地方真正弄通。 這就是我跟琢奧的夥伴們想做的事——把矽谷那套「派懂商業的技術人進你公司」的邏輯， 用中小企業付得起的方式做出來。

與其再賭一次外包，
不如先跟我們聊三十分鐘

預約免費諮詢查看服務方案

參考資料 / References

  1. Wikipedia. Forward Deployed Engineer. 連結
  2. Business Insider. (2025). An OpenAI exec shares how his growing forward-deployed team helps companies adopt AI (Colin Jarvis). 連結
  3. Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey Digital & University of Oxford. 連結
  4. Johnson, J. (2002). Feature usage study. The Standish Group, XP2002；亦見 CHAOS Manifesto 2013. 連結
  5. Stripe & Harris Poll. (2018). The Developer Coefficient. 連結
  6. Sankar, S. (2024). Escaping the Cargo Cult. Palantir Blog；名言與軼聞亦見 Shawn Ryan Show #190 與 CNN（2013）People and computers need each other. 連結

註：上述數據與案例引用自公開產業與學術研究，用於說明產業普遍現象；個別企業的實際情形會因產業、規模與系統成熟度而異。