最近跟幾個朋友聊到這幾年的工作性質，才發現我們大部分都在做 FDE（Forward Deployed Engineer）的內容，只是當時這個名詞還不流行。
但對於身上流過創業血的我來說，每一場需求專案，就像是一場微型創業。從一個模糊的問題開始，在有限的時間與資源下找出方向、驗證假設，最後把東西真正做出來。用這種精神面對客戶也是我們能這麼快速成為 GCP Focus Partner 的關鍵因素之一。
舉例來說，最近有個大案子，因為其他廠商的成果不滿意，因緣際會介紹到我們團隊。幾個禮拜釐清需求痛點，提供建議，可能架構範，快速的 PoC，及可持續優化的流程方案等一輪流程，整個案子活過來了。
說說我們「打專案」的日常吧
🔍【需求訪談】
第一步是與客戶各層級的利害關係人進行訪談，包含 C-Level、IT、Data、Infra，以及真正使用系統的 User。
訪談內容從需求、現有流程、權限、痛點，一路談到最後想達成的目標。目的，是把模糊的商業訴求，轉換為精確、可執行的工程需求。
這時候不免會遇到幾場大亂鬥。因為很多事情即使在大型企業內部，也可能從來沒有真正對過。不同部門對問題、流程與目標的理解，經常完全不同。
🎯【收斂需求及成功指標】
訪談是發散，收斂才是選擇。
各部門都有自己的期待，但時間、預算與人力有限，不可能一次解完所有問題。所以需要要從大亂鬥中找出共同目標、排出優先順序，並定義這次專案怎樣才算成功。
成功指標不能只是「完成一個 PoC」，而要進一步回答：
- 這個方案改善了什麼？
- 節省多少時間？
- 降低多少錯誤？
- 使用者願不願意真的使用？
就像創業不能只說「我要做一個很厲害的產品」，而要先確認自己究竟在解決誰的什麼問題。
🧪【規劃 PoC 及時程】
PoC 不是把正式產品縮小做一遍，而是用有限的時間，驗證最重要、風險也最高的假設。
哪些功能一定要做，才能證明方向可行？哪些需求可以先放掉？
每個階段要取得什麼資訊，才能決定下一步？
這很像規劃 MVP。重點不是一次到位，而是用最小成本，盡快知道方向對不對。
🏗️【架構設計】
架構設計不是技術上可行就好。
還要考慮既有的系統、資料位置、存取權限、資安規範、成本，以及未來有沒有能力維運。
有時候最「先進」的架構，不一定是「最適合」客戶的架構。
真正的挑戰，是在理想與現實之間，設計出一套可以先跑起來、未來也能繼續擴充的方案。
🛡️【行動邊界】
尤其現在做 AI Agent，除了設計它能做什麼，更要先定義它「不能」做什麼。
- 它可以讀取哪些資料？
- 可以呼叫哪些系統？
- 哪些動作可以自動完成？
- 什麼情況下一定要由人確認？
很多風險不是模型回答錯誤，而是模型在不該行動的時候採取了行動。
所以除了設計 Happy Path（Golden path），也要想好它不知道、做不到或出錯時，如何安全地停下來。
📏【評估機制】
如果沒有事先定義評估方式，PoC 最後很容易變成一句：
「看起來不錯，但不知道能不能上線。」
模型表現是一層，系統穩定度是一層；真正放進工作流程後，有沒有創造價值，又是另一層。評估機制必須回到一開始的成功指標，確認我解決的，不只是一個技術問題，而是需求方真正想解決的問題。
🔭【可觀測性】
當系統開始運作，還要看得見裡面發生了什麼。
- 哪一筆資料進來？
- 模型做了什麼判斷？
- 呼叫了哪些工具？
- 在哪個環節失敗？（比起成功我們更關注失敗）
- 花了多少時間與成本？
沒有可觀測性，出問題時只能靠猜。有了可觀測性，才能快速定位與修正，也才能逐漸建立對系統的信任。
🔁【反饋迴圈】
再完整的訪談，也不可能在專案開始前就知道所有答案。很多問題，只有等使用者真正開始操作後才會浮現。
- 哪些回答不符合預期？
- 哪些流程使用者根本不買單？
- 哪些原本以為重要的功能，其實沒有人使用？
這些反饋都要回到下一輪需求、架構與評估，讓系統持續修正，而不是交付後就停在那裡。
FDE 的價值，不只是懂多少技術，或把一套系統建起來。
而是能不能站在需求方的現場，把模糊的商業訴求，一路推進成可以評估、可以運作，也能持續迭代的成果。