How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

這場演講核心論點是：FTE 應被視為產品職能延伸，而非行銷或客戶成功部門的延伸。 講者以過去在 Palantir、Citadel 和 Kepler 的實戰經驗，論證唯有透過產品策略角度的現場工程實踐，才能贏得客戶信任並構築競爭優勢。

演講開端描述了最初的失敗教訓。Palantir 在與運輸公司合作時，客戶提交了 47 頁的需求文件，要求建造包含 14 個指標、向下鑽取警報的完整商業智慧系統，預計耗時三個月。團隊花了四個月嘗試理解需求，直到有人現場拜訪發現，調度員每天早上第一件事只是檢查卡車是否晚點，然後打電話給調度部門。整個問題其實只需一則 Slack 通知就解決了，四小時內完成交付。這個案例確立了第一個原則：不要被客戶的解決方案方案所迷惑，要挖掘真實問題。 身為 FTE，你的工作是理解客戶遇到的症狀，定義根本問題，然後交付實際有用的解決方案。

第二個轉折點涉及一位堅決反對數據格式遷移的工程師。團隊想將 CSV 遷移至 Parquet 格式以改善管道效能，但這位使用者整年都在反對，聲稱「Parquet 會讓情況更糟」。當講者親臨現場觀察她的工作流程時，真相大白：她手動從 S3 下載 CSV 檔案到 Windows 電腦上，雙擊打開查看數據。Parquet 沒有原生 Windows 讀取器，所以她無法執行這個日常工作。講者那天晚上製作了 Parquet 觀察器，她隔天就批准遷移，管道執行時間從 17 小時降至 2 小時。行動勝於雄辯的真諦在於：觀察使用者重複執行的任務、他們在工具間切換時的惱怒、拿出手機時的挫折感。 這些行為模式隱含著設計機會，而這些機會永遠不會出現在調查問卷或會議室討論中。

第三個學習圍繞本體論（Ontology）與語言定義。同一組客戶實體在不同部門有五種稱呼：銷售稱「顧客」、營運稱「客戶」、財務稱「結算實體」、開發稱「組織 ID」。這種語言混亂導致整合失敗、數據品質問題、管道故障。講者意識到，每個組織由名詞（實體定義）和動詞（操作定義）組成。FTE 的核心職能之一就是統一這些定義，讓各部門用相同的術語討論相同的概念。一旦使用者採用你的產品，他們也採用了你定義的語言系統。今天被認為理所當然的術語——如「技能」、「MCP」——一年前都毫不相關，現在卻成為整個經濟生態的基礎。誰定義了語言，誰就掌握了敘事權。

最後一個教訓是最具警示意義的：臨時方案永遠成為永久負債。 講者為數據保留問題快速寫了個 Groovy 腳本——完全不符合生產標準的應急之作。出人意料地，它成功了。12 個月後，這個腳本在擁有近 10 萬名客戶的大規模客戶基礎上廣泛使用。講者被迫支持這個「臨時」腳本多年。在軟體工程中，最危險的話語就是「這只是暫時的」。 如果它能解決問題、被人使用，它就會投入生產，而你將永久負責維護它。IBM 大型主機上仍在運行 40 年前的 COBOL 代碼，正是因為當年某人用臨時方案解決了問題。這意味著 FTE 的最重要技能是校準交付決策：六個月後我會否在凌晨 2 點接到關於它的求助電話？快速解決這個問題的代價是什麼？解決方案是該併入核心產品，還是應該直接廢棄？

講者最後總結，試圖開發 FTE 職能的組織常犯的錯誤是把它當作產品管理加客戶成功的混合工作——收集需求、進行調查、添加見解、運行流程。真正優秀的 FTE 做的是重新定義問題。他們持著客戶現場的通行證飛往世界各地，在端到端所有權下交付解決方案，然後將這些解決方案轉化為名詞和動詞，成為後續所有產品的基礎。產品優勢是贏得客戶的唯一方法。 對新創公司而言，不能像擁有無限時間和資金的自由工作者一樣工作，需要清楚辨別如何最大化運用現有資源，建構具有真正粘性的產品。