FDE的一週｜從第一天交出程式碼，到星期五回流產品的實作流程

大家好，我是株式會社TIMEWELL的濱本。

這是FDE實務系列的第七篇。前六篇寫了問、看、待在、變成結構、拍下來計數、把辭典交給機器的技術。這次寫的是，這些技術在一週之內怎麼配置。

我們說以FDE的風格能做到最快的實作。坦白說，這種說法有引起誤解的餘地。不是指工程師手快，而是指問、做、取得反應、回流產品的來回收在一週之內。這篇文章把那一週從星期一寫到星期五，說明與委外開發的工序有何不同，以及一週內無法上線的東西是什麼，不隱瞞地寫出來。想先了解讓自家團隊轉動這個來回的方案，可以先看WARP的頁面。

前提。速度的真面目，不是手快而是來回短

先寫速度的真面目。

在Palantir擔任FDE八年的人寫道，當一群二十幾歲的小團隊出現在客戶現場、在一到兩週內做出人能用的真正軟體時，客戶那一方很驚訝，因為他們平常打交道的既有系統導入業者，是以年為單位的瀑布式在運作¹。AWS在2026年6月成立的FDE組織，揭示要把部署從月單位壓縮到日單位²。OpenAI在5月成立的實作專門公司，把典型做法說明為：診斷價值所在、與經營層及現場共同選出少數優先工作流程、在組織內設計、建構與部署³。共通的是順序：不等需求確定，先把能運作的東西放下，放下之後再學習。

我們的速度還有一個理由：小公司。大型FDE組織裡，在現場問的人、做的人、回流產品的人是分開的。我們是同一個人。星期五在現場找到的例外，同一個人下週一做出來，那週的星期五判斷要不要變成產品的標準功能。人分開的話要靠會議傳達的內容，在同一個人腦中就完成。

再來是程式碼代理的存在。以前，第一天能交出程式碼的只有身手好的工程師。現在，給它名詞與動詞，幾小時就有暫時的畫面。不過這裡有陷阱。如抽象化與具體化的文章所寫，有調查顯示寫程式的速度提高後，價值的提升幅度比它小。寫得快和寫得對是兩回事。FDE的一週是為了找出對的東西而縮短來回的設計，不是為了寫得快的設計。

星期一。問三層、找出資料的持有者、傍晚放下初版

星期一上午是問的時間。經營層、事業部主管、現場，分別問。聚在同一間會議室只會留下經營層的聲音。問經營層想在業界改變什麼，問事業部主管本期的數字，問現場昨天下午開了哪個畫面。找出同時滿足三者的那一點，是這一週的目標。OpenAI說的「少數優先工作流程」，我們稱之為這一點。

上午還要決定一件事：資料的持有者。「那個數字來自哪個系統」「管理者是誰」。如Palantir前FDE所寫，8到12週的試行案可能全部消耗在資料存取的交涉上¹。我們在第一次會議就決定匿名化的步驟，資安審查並行進行，審查期間用匿名化資料運作。星期一上午能找出持有者，下午手邊就有匿名化的真實資料。

下午是看的時間。坐在當事人的斜後方，用跟隨觀察看一天的流程。不插話。記錄移動與等待。五欄的記錄從這裡開始。

傍晚放下初版。在我們產品的標準元件上，放上上午聽到的名詞與動詞，照下午看到的畫面流程，用匿名化的真實資料運作。讓程式碼代理寫，人讀，放到當事人面前。做法的細節寫在即時模型的文章。放下之後只問一句：「哪裡不一樣？」這裡冒出來的差異，就是星期二要做的東西。

初版不放寫入，只到讀取與建議為止。寫回正式系統的處理，要先決定權限、事前模擬、重大判斷時人的介入、可稽核的記錄四點才會放。這是比速度更前面的條件。

星期二到星期四。用觀察蒐集例外，每天累積一個版本

星期二到星期四是邊看邊做的日子。上午是脈絡訪查，坐在工作現場，一邊看工作一邊問「剛才為什麼那樣做」。例外筆記越來越多。「急件的時候股長蓋章」「只有月底用這張表單」「這個確認課長休假就會停」。下午把上午的例外放進版本。

版本的做法是規格驅動。把例外筆記的一行寫成短規格，讓程式碼代理實作，人讀，放到當事人面前。先寫規格的理由，是為了事後能追溯讓代理做了什麼，寫法整理在規格驅動開發的文章。一天一個版本。即使有餘裕做兩個，也只做一個，因為當事人一天能回應的次數以一次為限。

星期四下午做效果的暫定測量。請當事人用可運作之物做同一項作業，計算時間與畫面切換次數。取得拍攝同意的話就用影片計數。「等待核准從47分鐘變成12分鐘」這樣的差異，是星期五判斷的材料。暫定測量是給當事人的成果，同時也是給自家的「這個型值不值得回流產品」的依據。

這三天，我們的工程師留意的一件事是不要做過頭。例外筆記有10項，就會想全部做。但10項之中有7項是那家公司獨有的分枝，而且一個月只發生一次。星期四之前做的，只有每天發生的例外。其餘的等星期五分完型與分枝再決定。

星期五。做群、更新辭典、把型回流產品

星期五是離開現場思考的日子。上午把星期一到四的片段、逐字稿、五欄記錄、例外筆記、星期四的計數，用KJ法的思考方式做成卡片、做群、命名。步驟寫在KJ法的文章。

下午從群的名稱抽出五項更新辭典：名詞、動詞、關係、狀態、例外。「核准」的定義本週變成「股長判斷、課長蓋章」，版本往上加一。如本體論的文章所寫，辭典以下週一讓代理讀取為前提來寫。

然後把群的名稱分成型與分枝。「核准是兩階段」是在其他公司也看過的型。讓產品端能設定核准的階段數與判斷者的工作，進入產品的待辦清單。「那張紙由會計的田中先生保管」是分枝，記錄下來，不放進產品。a16z在2026年1月整理的壓力測試之一「能否對客製化說不」⁴，我們答得出來，是因為有這個星期五。

星期五的最後寫兩段文字。給當事人：「下週會在畫面上建立急件的核准路徑。理由是現在的紙張路徑是以股長判斷為前提。」給自家：「急件的另一條路徑是型，保管處是分枝」的判斷。寫完這兩段，一週結束。

累積週次。45到90天，我們不再被需要

一週就是這樣反覆，但週次累積之後內容會變。a16z在2026年1月的文章把真正的FDE型態整理為時間區隔的部署，並以90天上線的衝刺為例⁴。AWS把結束時客戶能自行運作的狀態，也就是留下可運作之物、文件與受過訓練的內部人員，放在設計的核心²。我們也在一開始就決定在現場的期間，大約45到90天。

第一週到第二週是上面寫的來回，放下讀取與建議。第三週到第四週分階段放上寫入：決定四項條件，先只寫回一個處理，在正式環境看一週。第四週左右，開始請當事人碰辭典。「急件類別的判斷者換人了」由當事人而不是我們修改。第六週到第八週，安排我們的工程師不在現場的日子。不在的日子來回還在轉，就準備好離開了。

離開的條件有三個。當事人能自己更新辭典。可運作之物的效果，以業務指標讓當事人自己看得見。以及型已回流產品，下一位客戶不再需要同樣的學習。曾領導Palantir商用部門的人把FDE稱為客戶事業的「沒有權限的CEO」，要求對成果負責⁵。對我們而言，成果就是我們不再被需要。

與委外開發工序的差異

把一週的結構和委外開發的工序並排。

觀點	委外開發	FDE的一週
工序的排列	需求定義、設計、實作、測試、驗收，串列	問、做、取得反應、回流，每週並行
第一天的產出	會議記錄與需求草稿	用匿名化真實資料運作的初版
變更的處理	需求變更就追加費用與重新報價	變更放進星期二的版本，星期五分型與分枝
成果的測量	驗收（是否照規格運作）	業務指標（47分鐘有沒有變成12分鐘）
學習的去向	客戶的資產	型回流產品，分枝作為客戶的擴充
結束方式	驗收後撤離	當事人能碰辭典，我們不再被需要

最大的差異是不把工序排成串列。委外開發在需求確定前不寫程式，確定後設計、實作、測試、驗收。需求正確的話，這個順序最沒有浪費。FDE放棄串列，是因為需求從一開始就不會正確。當事人寫不出「股長蓋章」的例外到空白規格書上，看到能運作的東西才說得出來。所以把問和做放在同一週，把取得反應放在每一天。

另一個差異是成果的測量方式。委外開發以驗收測量，照規格運作就完成。FDE以業務指標測量，即使照規格運作，當事人的等待核准沒有減少就不算完成。所以星期四做暫定測量，下週再重拍。這個測量方式的差異，改變了「快」的意思。委外的快是到驗收為止的天數，FDE的快是到當事人的一天改變為止的天數。

我們的實務與限制。一週內無法上線的東西

坦白說，有些東西一週內上不了線。

對核心系統的寫入整合一週內上不了。要決定權限、事前模擬、人的介入、稽核記錄，從一個處理開始分階段放上去，所以會到第三週以後。需要資安審查的連線，取決於審查期間。我們讓審查並行、審查期間用匿名化資料運作，但無法讓審查本身變快。只在月底或旺季出現的處理，時期沒到就看不到，所以當成事件來問、暫時做出來，時期到了再修。

也寫速度的條件：當事人的時間與資料的存取。當事人一直說「很忙之後再說」的現場，來回轉不動。星期一找不出資料持有者的現場，星期二就沒有東西可做。我們在第一次會議就把這兩點作為案件的條件取得共識。無法取得共識的現場，不承諾一週的來回。

最後寫「第一天交出程式碼」這種說法的危險。第一天出來的是不完整的初版，是為了引出「哪裡不一樣」的回答的提問裝置。被當成完成品接收的話，第二天就會失望。所以我們放下初版時一定會說「這是為了請你告訴我們哪裡不對而做的」。速度的價值不在第一天的完成度，而在到星期五為止接近正確答案的速度。

總結

我們說能最快實作的依據，是問、做、取得反應、回流產品的來回收在一週之內。星期一問三層、找出資料持有者、傍晚放下用匿名化真實資料運作的初版。星期二到四用脈絡訪查蒐集例外，用規格驅動一天累積一個版本，星期四暫定測量效果。星期五用KJ法做群、更新辭典、把型回流產品、記錄分枝。

累積週次，在45到90天內當事人能自己更新辭典，我們不再被需要。與委外開發的差異是不把工序排成串列、成果不以驗收而以業務指標測量、學習回流產品。有些東西一週內無法上線，速度的條件是當事人的時間與資料的存取。

想用自家的工程師團隊轉動這個來回，或想找把這個來回帶進自家現場的夥伴，歡迎參考WARP的方案，或透過個別諮詢和我們聊聊。下一篇會用職缺、投資與收購的數字，解讀FDE這個職種為什麼在2025到2026年急速擴大。

Footnotes

1. Reflections on Palantir（Nabeel S. Qureshi，2024年10月15日）。一到兩週交出可用之物的敘述、與既有導入業者的對比、試行案消耗於資料存取交涉的軼事依該文（筆者譯） ↩ ↩²

2. AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon，2026年6月30日）。從月單位壓縮到日單位、結束時的自行運作依該發布 ↩ ↩²

3. OpenAI launches the OpenAI Deployment Company（OpenAI，2026年5月11日）。典型合作流程依該發布 ↩

4. The Palantirization of everything（Marc Andrusko，a16z，2026年1月16日）。時間區隔的部署、90天衝刺、壓力測試依該文 ↩ ↩²

5. Sorry, that isn't an FDE（Ted Mabrey，2024年9月21日） ↩