概念地圖・特徵驅動開發
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
特徵驅動開發：功能清單切成會重複的兩段
品牌客戶寄來的規格表列著一百一十二項功能，第一次會議上，對方想先把整年的時程排出來。你翻到第三頁就知道排不出來——那份清單裡有一大半的條目，其實是同一件事的不同說法。特徵驅動開發（Feature-Driven Development）處理的正是這個場面：先把清單歸整成一張特徵表，再讓五段流程走上去。前面幾段整批走完就收工，後面幾段每個特徵各走一次，走完一個就交出一塊看得到的東西。
五個流程，哪三個只做一次
五個名字聽起來很像，差別在「走幾次」這一欄。
| 五段 | 走幾次 | 這一段交出什麼 |
|---|---|---|
| 建立整體模型 | 整批一次 | 一張大家都認得的領域圖，名詞跟名詞之間的關係先講定 |
| 建立特徵清單 | 整批一次 | 一張分好主題群的特徵表——這張表歪了，後面兩段會一路歪下去 |
| 依特徵計畫 | 整批一次 | 誰負責哪一群特徵、先後順序怎麼排、哪一群先開工 |
| 依特徵設計 | 每個特徵各一次 | 這一塊要動到哪些類別、介面長什麼樣、誰要簽 |
| 依特徵建造 | 每個特徵各一次 | 寫完、測完、併回主線，客戶當天就看得到差別 |
把「走幾次」那一欄遮起來，這張表就退化成一般的瀑布式流程。它真正的重量在後兩段被圈成一個迴圈：整批的力氣只花在前三段，之後每一個特徵都從設計走到建造，各走各的一輪。要提醒的是，不同來源對「哪幾段只走一次」的整理略有出入，也有把前兩段算成一次性、後三段算成反覆的版本；多數整理採用前三後二，本文照這一版走。
切不切得出特徵，看規格表上三個訊號
一、每一條都唸得成一個動作。特徵的定義很窄：一個對客戶有意義的小功能，寫出來通常是「動作＋結果＋對象」。血壓計那張規格表上寫著「支援藍牙」，這四個字唸不成動作——它得再往下拆到「量完一次之後，把這一筆讀數傳到手機 App 並回報成功」，才站得住。唸得成動作的條目才進特徵表，唸不成的先留在主題群當標題。自問：這件工作切得出對客戶有意義的小塊嗎？
二、兩週是那條天花板。血壓計的韌體團隊有一條土法煉鋼的驗算：把那一條特徵交給組裡最資淺的人估，估出來超過十個工作天就當它太肥。太肥的條目通常藏著兩件事——「把讀數傳出去」跟「連不上時要重試幾次」硬綁在一起，拆開之後各自都做得完。這個上限管的是可視性：超過兩週，進度就只剩口頭回報。自問：切出來的每一塊，兩週內做得完嗎？
三、做完之後，有人指得出差別。這是最容易被跳過的一條。血壓計的專案裡有二十幾條像「重構通訊層」「補上單元測試」這種條目，做完之後品牌端的窗口在畫面上看不到任何變化。它們該做，只是位置擺錯了——得掛在某個特徵底下當作實作細節，否則特徵表會被工程任務灌到看不出交付節奏。自問：做完之後客戶看得出差別嗎？
一張血壓計代工的規格表，五段排一次
底下這家台灣中部的血壓計代工廠，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。
- 建立整體模型：三位小組長把「量測」「使用者」「傳輸」三塊名詞攤上白板，先把「一次量測」到底包含哪幾筆資料吵完。吵了兩天半，但後面所有的介面命名都從這張圖抄。名詞講定了，後面的爭執少一半
- 建立特徵清單：規格表上一百一十二項條目歸整之後，剩下三十八個特徵；其中九個都落在「藍牙傳輸」這一個主題群底下，將近四分之一。品牌端看到這個分佈才鬆口，承認自己最在意的其實是連線穩不穩。主題群把客戶真正的重心攤出來了
- 依特徵計畫：三十八個特徵排出順序，藍牙那九個排最前面。前三段加起來，整批一共花了十五個工作天——而且只走這一次。十五天買到一張後面不再重畫的底圖
- 依特徵設計：從這一段開始，每一個特徵各走一輪。第一批藍牙特徵設計得很順，第七個開始卡住——因為「重試策略」在整體模型裡根本沒有對應的名詞。回頭補模型花了三天。第四段卡住，卡的多半是第一段沒講完的事
- 依特徵建造：設計加建造，每一個特徵平均六個工作天。三十八個特徵合計兩百二十八個工作天的工，分給三個小組同時進行，一組大約七十六個工作天。品牌端每兩週就收到一台可以按的樣機
把數字疊起來看：前三段十五個工作天，後兩段每組七十六個工作天，一條線走下來大約九十一個工作天，四個多月。客戶第一次會議想排的是整年時程，而這五段給他的是另一種東西——第三週就有第一批藍牙特徵可以拿在手上按。真正的接縫在第四段那一次卡住：重試策略沒有名字，代表整體模型當初漏了一整塊。前三段只走一次的代價就在這裡，它假設你第一次就把領域講對了；一旦漏掉，補回去的成本會落在最忙的那一段身上。這也是為什麼第一段那兩天半的白板爭執，是整條線上最便宜的兩天半。以上為說明結構用的示意情境，僅供理解框架之用。
五段階梯什麼時候會騙你
- 特徵切太細，這張表會退化成一份任務清單。兩週上限逼著人往下拆，拆過頭之後，特徵表上會出現「新增藍牙裝置列表的排序欄位」這種條目。它符合格式、也估得出工時，但品牌端的窗口翻完整份清單，說不出這一個月到底交付了什麼。判斷方法很土：把特徵名唸給不懂技術的人聽，他接不下去的那幾條，就是已經掉進實作層了。特徵表的第一位讀者是客戶（排程軟體排第二）。
- 前三段只走一次，前提是這個領域夠穩定。血壓計的量測邏輯十年沒變，所以整體模型畫一次可以撐到專案結束。換成一個法規還在修、規格每季調整的產品，第一段畫的圖三個月後就作廢，而這條階梯沒有替「回頭重來」留位置——它只在圖上畫了往右上走的那一個方向。真的碰上這種領域，得自己約定一個回頭修模型的節奏，並且把修模型的成本明講在報價裡。
- 「每個特徵兩週內完成」是經驗值，會隨團隊與領域跑掉。這個數字來自原始定義成形時的專案體質，它假設團隊對領域夠熟、程式碼基底夠乾淨。一個剛接手陌生舊系統的團隊，同樣一條特徵可能要三週，硬把它壓進兩週的結果是三分之二做完就宣告完成，把剩下的塞進下一條。守著兩週那個字面沒什麼用——先量自己團隊最近十條特徵的實際天數，用中位數當上限，過幾個月再量一次。
痛點視角看那張規格表
這道階梯排得出誰先誰後。
一百多項功能排成一條線的時候，客戶的耐心是按月結算的——他不會等你把整張圖畫完才開始判斷這案子有沒有在動。這張圖畫得出五段的順序、也畫得出哪兩段要重複，畫不出品牌端的窗口在第幾週開始覺得「怎麼都沒東西可以看」。《痛點》那把尺的第一格問的是誰在痛：在這個專案裡，痛的人是那位要回去跟老闆報進度的窗口，他的痛點單位是「這個月我手上有什麼可以拿出去講」。特徵驅動開發之所以在這種代工場景好用，是因為它剛好讓那個窗口每兩週有一台可以按的樣機——結構順便解決了關係。反過來說，如果你把兩百二十八個工作天全部排成一條漂亮的甘特圖，卻讓第一次交付落在第十週，那五段走得再標準也救不了他。今晚可以做的一件小事：打開最近那份需求文件，挑五條出來，各補一句「做完之後，客戶會在哪一個畫面上看到差別」。那五句寫完，明天的會議就有東西可以排順序了。
常見問題
特徵驅動開發跟 Scrum 差在哪？
兩者管的是不同層的東西。Scrum 給的是節奏與角色：固定長度的時間盒、每日站會、誰負責待辦清單。特徵驅動開發給的是「工作怎麼切」與「切完之後走哪五段」，它對開會頻率幾乎沒有意見。實務上兩套常常疊著用——用特徵表當待辦清單的內容，用時間盒當推進的節奏。會打架的地方只有一處：特徵的兩週上限跟衝刺長度要對齊，不然會出現一條特徵橫跨兩個衝刺、每次都報「快好了」的狀況。
「特徵」到底要切多細？
抓兩個邊界就好。上界是兩週，超過就往下拆；下界是「唸給客戶聽，他點得了頭」，唸完對方一臉茫然就代表拆過頭了。實作上最好用的形狀是「動作＋結果＋對象」，例如「量完一次血壓後，把讀數傳到手機並回報成功」。這個形狀有個副作用：它逼你在切的時候就想清楚驗收條件，因為結果那一段本身就是驗收條件。切不出這個形狀的條目，通常代表需求還停在名詞階段。
前三段真的只走一次嗎？
多數整理是這樣分的——前三段（整體模型、特徵清單、依特徵計畫）屬於整批的前置作業，後兩段依每個特徵反覆。不過這個切法在不同來源略有出入，也看得到把前兩段算成一次性、後三段算成反覆的版本。更實際的理解是：前面那幾段的產出是「全案共用的底圖」，後面那幾段的產出是「一塊一塊的交付物」。真正該記住的是這條分界線的位置，而底圖在領域變動時當然可以回頭修，只是修的成本會落在專案最忙的時候。
十個人以下的小團隊值得用嗎？
值不值得，看你的清單有多長。五個人做一個二十項功能的內部系統，整體模型畫在白板上、拍張照就夠了，第三段的分工也不用排——這時候整套流程的儀式感是負擔。但只要功能清單超過三、四十條、而且要對外部客戶交代進度，前三段那十來天就會開始回本，因為它把「客戶問進度」這件事從口頭爭辯換成一張可以指的表。小團隊常見的折衷是：前三段壓縮成一週，後兩段照走。
把五段換成你自己那張規格表，第四段會卡在哪裡——那一格通常就是第一段還沒講完的地方。想補上時間盒與角色那一層，可以看 Scrum 框架；想從使用者旅程反推出功能清單，另一張是 使用者故事地圖。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。