概念地圖・瀑布模型
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
瀑布模型：七個階段一路往下，那道不准回頭的門
新的預約系統上線第一天，監理站櫃檯前排的隊比上線前更長。系統照著十四個月前那份需求規格，一格一格做出來了——每一階都簽核、每一階都驗收，沒有人偷工。瀑布模型把一個專案切成七個往下的階段，上一階交出文件，下一階才動工，像水流過落差之後不回頭。這張圖真正在管的只有一件事：階與階之間，准不准往回走。而這件事會直接決定，一個發現要花多少錢才修得掉。
七個階段，每一階要交出什麼
這個模型的骨架是「文件接力」：每一階把自己的結論寫成一份文件，簽核之後往下傳，下一階拿這份文件當事實。
| 階段 | 這一階要定下來的事 | 交出的文件 | 錯誤在這一階才被抓到的代價 |
|---|---|---|---|
| 需求分析 | 這件事要解決誰的什麼問題、什麼叫做完 | 需求規格 | 改一份文件，動的是紙 |
| 系統設計 | 整套東西拆成哪幾塊、彼此怎麼接 | 系統架構 | 後面五階的工期全部要重估 |
| 細部設計 | 每一塊裡的欄位、流程、例外怎麼走 | 模組設計 | 實作與測試整段重來 |
| 實作 | 把設計寫成會動的東西 | 程式 | 改完要把測試全部重跑一次 |
| 測試 | 用前面幾階寫好的標準逐條驗 | 測試報告 | 它對得上的是文件，文件本身寫錯時照樣全綠 |
| 部署 | 換到真實環境、真實資料、真實流量 | 上線手冊 | 環境層級的問題到這裡才第一次現形 |
| 維運 | 讓它繼續活著，並收下真實使用者的反應 | 維護紀錄 | 要改的話得退回前面某一階，重跑一整段 |
把右邊那一欄由上往下讀一次，會看到一條很單純的規律：同一個誤解，被抓到的位置每往下一階，要重做的東西就多一層。這條規律就是模型的本體——七個往下的箭頭，本質上是在告訴你「發現得晚，你要自己吞」。
你這件事適不適合一路往下走，先問三個問題
一、改一次規格，你實際要付什麼。監理站的預約系統，需求規格上「一個時段三十分鐘」這一行字，往下會長成資料表的欄位、排班演算法的參數、簡訊通知的樣板、櫃檯叫號機的畫面。上線後想把它拆成兩種長度，要動的是這四個地方，還得把已經預約的民眾重新排一次。而在需求分析那一階多花兩週，把汽機車的驗車動線各走一遍，付的是兩個人的兩週。兩張帳單擺在一起看，答案通常很明顯。自問：規格改一次的代價，跟事前多想兩週的代價，哪一邊大？
二、驗收標準現在寫得出來嗎。監理業務有一個難得的好處：它有法規當底。驗車項目、資格條件、規費金額、應備文件，全部白紙黑字。所以「什麼叫做完」在第一階就寫得成條文，這正是瀑布模型能站得住的前提。換一種需求試試看——「讓民眾覺得比較好用」。這句話在需求分析那一階寫不成驗收標準，往下六階就沒有一把對照的尺，測試那一階自然也驗不出東西。自問：這件事的驗收標準，現在就寫得出來嗎？
三、方向換掉，這個案子撐得住嗎。公務標案把交付項目、期程、金額都綁在合約上，中途要換方向得走變更設計、重新議價、送監造單位簽核。一個十四個月的案子，光是跑完變更流程就可能吃掉一個月，而這一個月不會產出任何一行程式。撐得住這種折騰的案子，才適合把賭注全押在第一階；撐不住的，一路往下走等於把所有風險累積起來，留到最後一天才引爆。自問：做到一半才發現方向要換，這個案子承受得住嗎？
一套監理站預約系統的十四個月，把七階走一遍
底下這座台灣中部的監理站與它的系統承包商，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實機關或公司。
- 需求分析．3 個月：訪談櫃檯人員、調三個月的臨櫃紀錄、把換照與驗車的流程寫成需求規格，其中一行寫著「預約時段以三十分鐘為單位」。有法規當底，驗收標準逐條寫得出來
- 系統設計．2 個月：整套切成預約、排班、通知、報表四個模組，介面規格談定。模組邊界清楚，之後分工不打架
- 細部設計．2 個月：「三十分鐘」被寫死進排班參數與資料表欄位。機車與汽車在這裡被折疊成同一種時段，往後四階沒有人再問一次
- 實作．4 個月：四個模組同時開工，最長的一段，也是報表看起來最漂亮的一段。
- 測試．1.5 個月：照需求規格逐條驗，兩百多項全數通過，測試報告乾淨到可以直接附進結案文件。它驗的是「跟文件一不一致」，文件錯了它看不見
- 部署．0.5 個月：切換上線、資料轉檔、教育訓練，一切照表操課。
- 維運．1 個月：上線第一天，機車驗車的隊伍把汽車的時段一路卡住，櫃檯只好回頭手工插隊。十四個月裡第一次有真實使用者碰到這套系統
3 加 2 加 2 加 4 加 1.5 加 0.5 加 1，十四個月，每一階都準時、每一階都簽核，而那個誤解從第一階一路活到第十四個月。機車與汽車的驗車流程不一樣，預約時段該有的長度也不一樣，需求文件卻從頭到尾把兩者當成同一件事。這個誤解若在需求分析那三個月裡被問出來，要改的是一份文件，約兩週；上線之後才發現，得退回細部設計，把細部設計、實作、測試、部署重跑一輪，追加 5 個月。同一個發現，被抓到的階不同，付的是兩種厚度完全不同的帳單——而那道不准回頭的規則，正是讓帳單愈往後愈厚的機制。以上為說明結構用的示意情境，僅供理解框架之用。
瀑布模型什麼時候會騙你
- 它掛的那個名字，出自一篇主張別這樣做的論文。Royce 一九七〇年那篇談大型軟體開發管理的論文裡，確實畫了一張七階往下的圖；圖的旁邊他寫著，這種做法會失敗。同一篇論文接著主張：這套流程至少要跑兩次，而且相鄰的每一階之間都要有往回上一階的回饋線。後來被大量引用、寫進教科書、抄進標案規格的，是前面那張圖。招牌圖上那兩條金色虛線，畫的就是被留在原地的另一半。
- 七階裡有一階叫測試，很多人因此以為品質已經有人守。測試的對照物是前面幾階交出的文件——程式對不對得上模組設計，模組設計對不對得上需求規格。當需求規格本身把兩種車折疊成同一件事，測試會全數通過，報告會漂亮到足以當作驗收證據。這個模型能保證的是「做出來的東西跟文件一致」；文件跟真實世界一不一致，七個階段裡沒有任何一階在管。
- 七個階段名很好抄，成立它的前提抄不進去。很多規格書把這七階直接抄成里程碑與付款節點，抄進去的是階段名與時間點，留在門外的是這個模型的前提：需求在動工前就穩得住。前提不成立的時候，七個里程碑照樣一格一格勾完——勾掉的是進度條，而這件事到底做對了沒有，七格裡沒有一格在問。這也是為什麼同一套流程，在法規明確的案子上很好用，換到需求會邊做邊長的案子上就變成一台加價機。
痛點視角看那道不准回頭的門檻
那六個往下的小三角形，各自是一次不能反悔的簽名。
不准回頭這條規則做的事情，是把代價往後推。同一個誤解，在需求分析那一階被抓到，代價是改一份文件；拖到維運才被抓到，代價是退回細部設計、重跑一整段。所以整條路上還能大幅省錢的動作只剩一個——把發現的時間點往前搬。而《痛點》裡 P.A.I.N. 的第一個字母問的正是這件事：誰在痛。監理站櫃檯的人一直都知道機車和汽車的驗車動線不一樣。那個資訊在第一天就存在。它只是沒有走進那份需求規格。這張圖畫得出每一階該交出哪份文件，畫不出那份文件裡有沒有裝著真實使用者的難處。今晚可以做的一件小事：把手上那份規格印出來，用紅筆圈出三句「使用者會⋯⋯」，然後逐句查一下，那三句話是誰講的、什麼時候講的、有沒有人真的當面問過對方。
常見問題
瀑布模型是誰提出的？
最常被引用的出處是 Winston W. Royce 一九七〇年那篇談大型軟體開發管理的論文。不過他在文中把那張七階往下的圖當成會失敗的示範，同一篇接著主張至少跑兩次、並在相鄰各階之間加上回饋線。「瀑布」這個名字出自後來的引用者，論文原文並沒有用這個詞。圖上那七個階段名同樣是後世教科書整理出來的版本，各家的切法略有出入。
瀑布模型和敏捷開發差在哪裡？
差別落在「回頭的價錢」。瀑布把一次交付切成七個往下的階段，中途要回頭得走變更流程；敏捷把交付切成很多次小的，每一次都自帶一個回頭的機會。所以選哪一種，看的是你的需求會不會在中途長出新樣子，以及那個改變的代價由誰吸收。法規明確、驗收標準寫得成條文的案子——監理、報稅、健保申報這一類——瀑布仍然很順手。
什麼樣的專案到今天還適合用瀑布模型？
三個條件同時成立的時候：需求在動工前就穩得住、驗收標準寫得出具體條文、中途變更的代價高到不值得冒險。由法規定義「完成」長什麼樣的系統多半吃這三條，因為那份需求規格背後有法條在撐，它不會因為誰換了主管就變一個樣。反過來，只要「什麼叫做完」還要靠做出來才知道，這七階就會把你的學習全部擠到最後一格。
為什麼標案規格書還是很愛寫這七個階段？
因為它把付款切得非常乾淨。七個階段對應七份文件，文件簽核就撥款，發包方看得到進度、承包方領得到錢，稽核起來也一目瞭然。這是採購與驗收上的方便；至於這樣長出來的系統合不合用，七個付款節點裡沒有一格在問。想在這種合約下自保，實務上的做法是在需求分析那一階多塞使用者訪談，把發現往前搬到還改得動的位置。
回頭看你手上正在跑的那個案子，最後一次能改規格是哪一天。把那個日期寫在白板上，你大概會突然很想在那之前多問幾個人。想知道每一階交出的文件該由誰、在什麼時候驗回來，可以看V 模型的驗證與確認那一張，它把右邊每一次測試對回左邊每一層文件；想把風險一圈一圈提前打掉，螺旋模型那一張走的是另一條路線。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。