系統開發流程完整拆解：需求訪談到驗收的七個節點，各要交什麼

恆遠自己每年要跑十幾條系統開發流程，客戶端的、自有產品的都有。累積下來我們發現一件事：專案真正出事的節點，幾乎沒有一次是「程式寫不出來」。出事的地方都很無聊，前一週有人講了一句「這個應該可以吧」，沒有人寫下來，三個月後兩邊對著同一份畫面各自認定對方要負責。

所以這篇不打算教你判斷技術好壞。你是付錢的一方，真正需要知道的是：這七個節點各自要交出什麼、什麼時候該把錢押住、哪一句話沒寫進文件會在三個月後變成加價單。

台灣的中小企業在這件事上吃虧特別多。Standish Group 的 CHAOS Report 長年統計顯示，軟體專案完全照原訂範圍與預算交付的比例只有三成上下，而失敗案例裡最常見的根因是需求不明與範圍變更，兩者加起來壓過技術問題。這個數字幾十年沒有明顯改善，代表它是流程問題，不是技術進步能解決的問題。

系統開發流程真正卡住的地方，八成不在寫程式

先講結論：專案延遲的成本，八成產生在需求訪談跟驗收這兩端，中間的開發期反而是最可控的。

原因很單純。開發期有程式碼、有 commit、有測試，進度是看得見的；需求訪談跟驗收沒有產出物可以量，全靠雙方對「講清楚了沒」的主觀認知。認知落差累積到上線前才引爆，那時候改一個欄位的代價已經是需求期的十倍。

業界有個很老但一直成立的經驗值：缺陷在需求階段被抓到的修正成本設為 1，到了設計階段大約 5，寫進程式碼大約 10，上線之後可以到 100 以上。IBM Systems Sciences Institute 的早期研究提出這組比例後，後續各家統計的絕對數字有出入，倍率關係倒是很一致。你在需求訪談多花的兩個下午，換的是後面兩個月不用重做。

這也是為什麼下面這張表要放在最前面。你可以只看這張，剩下的內文是給想知道「為什麼」的人看的。

七個節點速覽：你要交什麼、廠商要交什麼、通常卡在哪

接下來逐節點拆。每一節都會給你一句可以直接複製進信裡問廠商的話。

需求訪談：你講得越具體，後面改得越少

這個節點你的發言權最大，之後只會越來越小。廠商在這個階段能改的東西成本趨近於零，等程式寫下去，同一句話的價碼就變了。

常見的失誤是派錯人。老闆覺得這是技術會議，派了 IT 或行政去開，但真正每天在跑這條流程的是業務跟倉管。訪談紀錄回來全是二手轉述，細節都對不上。真正該到場的是那個每天被這件事煩到的人。

第二個失誤是講功能不講痛點。你說「我要一個報表功能」，廠商就做一個報表功能給你，做完你才發現你要的是「每天早上八點自動把昨天的數字寄給三個主管」。前者是介面，後者是流程，價差可以到兩倍。

好需求跟壞需求的白話對照

把這張表拿去對照你手上的需求文件。如果左欄那種句子超過三句，你的需求訪談還沒做完。

需求整理完該產出的是一份文件，不是一場會議的記憶。這份文件業界叫需求書或 BRD，我們另外寫過完整的欄位範本，可以直接照著填：老闆找外包前必備的客製化系統需求書寫法。

規格與報價：把「做什麼」寫成可以驗收的句子

規格書的唯一任務，是讓三個月後的你能拿著它逐條打勾。做不到這件事的規格書，寫得再厚都只是簡報。

判斷方法很簡單：每一條規格後面加一句「怎麼證明它做到了」。答得出來的是規格，答不出來的是形容詞。

報價的部分，你要的是分項，不是總價。只給一個數字的報價單，代表你談判時只能砍總價，砍完廠商會自己決定從哪裡省，通常省掉的是測試跟文件。分項報價才能讓你說「這個功能先不做，第二期再說」。

同一份需求給三家報，價差三到五倍是常態，這件事本身不代表有人在騙你。落差來源、以及當場能驗證的問句，我們整理在這篇：三家報價差五倍完整解碼框架；想知道系統開發費用各段實際包含什麼，看系統開發費用完整拆解。

規格談定之後，要把它掛進合約。合約層面的規格紅線、驗收里程碑與罰則寫法，另外一篇有完整模板：SOW + 規格書 + 合約完整指南。

UI/UX 設計：改稿次數要寫進合約，不是靠默契

設計期最該先談定的一件事是改稿次數上限，而且要寫進合約。這句話對雙方都是保護。

沒寫上限的專案通常這樣走：第一版出來，老闆看了說可以；第三天業務主管看到，說配色不行；第十天老闆娘路過，說按鈕太小。每一輪都很合理，加起來設計期從三週變成三個月，開發只能停在那裡等。廠商吃了成本，你吃了時間，沒有人是贏家。

務實的做法是：合約寫「線框圖兩輪、視覺稿三輪，超出部分依人天計價」，然後你這邊承諾一次把所有部門的意見收齊再回。內部意見沒收齊就回饋，等於用廠商的工時當你的內部會議室。

互動原型確認那一刻，是你最後一次能低成本改變主意的時機。過了這條線，同樣的修改要動程式，價碼跟工期都不一樣了。

開發期：看不到進度，就是你這個專案最大的風險

開發期你唯一該堅持的事情：每週要有一個你點得進去的網址，不是一份寫著「進度 60%」的報告。

進度百分比是這個行業最沒有資訊量的數字。它可以連續四週都停在 80%，而你完全無從查證。可以點的測試環境不會說謊，功能在就是在，不在就是不在。

這裡要講一個我們的判斷，可能跟不少同業的說法不一樣：我們認為固定總價、瀑布式一路做到底的合約，對中小企業客戶是比較差的選項，即使它看起來風險比較低。固定總價會逼廠商把所有不確定性都灌進報價，也會讓雙方在任何一個小變更上進入談判狀態，最後大家把力氣花在攻防而不是產品上。分階段驗收、每階段獨立計價，帳面上麻煩一點，實際上兩邊都不用把對方當敵人。

週報該長什麼樣，有一個很低的及格標準：這週完成什麼、下週要做什麼、卡住什麼需要你決定。第三項最重要。廠商的週報如果從來沒有第三項，通常代表他在自己猜你的意思。

進度真的跑不出來時，不要等到上線前才處理。止血條款、換廠觸發訊號與決策順序，這篇寫得比較完整：客製化系統開發專案延遲完整指南。另外「PM 是誰」這件事值得在合約階段就釘死，軟體外包 PM 配置完整指南 有三種配置模式的對照。

恆遠自己是這樣跑的。我們接案累積到現在有 40+ 企業客製案落地，同時也在做自家產品，兩邊用同一套節奏：每週一個可點的環境、每週一份帶「待你決定」欄位的週報。做自有產品時我們是自己的甲方，被自己的模糊需求坑過幾次之後才把這套流程收緊，例如影視器材租賃與檔期系統那個案子，檔期衝突的判斷規則就是在需求訪談來回三輪才定案的，那三輪省下的是上線後整套排程邏輯重寫。

測試：廠商測完不等於你驗完，這是兩件事

廠商的測試在確認「功能有照規格做出來」，你的測試在確認「這套東西放進我公司真的跑得動」。兩者不能互相取代。

最常見的錯誤是老闆自己點一點覺得沒問題就簽了。老闆點的是理想路徑，真實世界是業務會在收訊不良的工地用手機建單、會計會把三千筆資料一次貼進去、有人會按兩次送出。這些情境只有每天做這件事的人想得到。

測試階段該做的事情有三件：找三到五個真的會用的員工、給他們一份平常會遇到的真實資料、讓他們用平常的裝置跑一遍完整流程。發現的問題寫進缺陷清單，標上嚴重度，跟廠商約定哪些等級必須在上線前修完。

上線前如果這套系統會碰到客戶個資或金流，值得多花一筆做第三方程式碼審計。該查哪六項、報價區間大概落在哪，這篇有整理：客製化系統程式碼審計完整指南。

驗收：先定義什麼叫完成，再來談尾款

驗收糾紛百分之九十來自同一件事：合約簽的時候沒有人寫下「完成」的定義，等到要付尾款才開始吵。

這一節是整條系統開發流程裡最值得你花時間的地方。前面六節做得再好，驗收標準寫得含糊，你還是會在最後一哩路卡住。

可用的驗收標準只有一種寫法：可觀察、可重複、有數字。「系統運作正常」不是標準，「以三十筆真實訂單完整走完建單到出貨，全部成功且資料無誤」才是標準。

付款節奏要跟驗收節點綁在一起。常見且合理的分法是簽約三成、設計確認兩成、開發完成三成、驗收通過兩成。最後一筆保留款不要低於兩成，那是你唯一還握著的籌碼。

驗收當天該交接的東西，除了系統本身還有原始碼、資料庫結構、部署文件與第三方服務帳號。這幾樣沒拿到，你等於租了一套系統。完整的交接檢查項目在客製化系統開發交付驗收完整 SOP；如果案子金額大、廠商規模小，可以考慮加一層源碼託管當保險。

上線與保固：這裡是維運的起點，不是流程的終點

上線那天最該備好的東西是回滾方案。慶功可以延後，切換正式環境前手上沒有回滾計畫，等於拿公司當天的營運下注。

多數中小企業的第一次上線都會選在週五晚上或連假前一天，理由是「出事還有時間處理」。實務上這個時間點最糟：出事的當下人最少，隔天要找人支援也找不到。比較安全的做法是選在平日的營運低峰，例如週二上午，全公司都在、廠商也在線上。

回滾方案要具體到「誰在什麼情況下有權喊停、切回舊流程需要幾分鐘、切回去之後新系統那幾筆資料怎麼補」。這三題答得出來，上線就不可怕。

保固期最容易起爭執的是「這算 bug 還是新需求」。界線可以先寫在合約裡：規格書上有寫但沒做到、或做了但不符合驗收標準，算 bug，廠商免費修；規格書上沒有的，算新需求，另外報價。有這一句，保固期就不會變成雙方互相消耗。

保固期結束前一個月，就該把維運合約談完。三種維運模式的費用結構、十二條必看條款與換廠商決策樹在這篇：軟體外包驗收後的維運合約怎麼簽。

整條流程走一次，你真正需要準備的東西

回頭看這七個節點，你要準備的東西其實只有三樣：一份寫得夠具體的需求、一份可以逐條打勾的驗收清單、一個能替你在會議上做決定的窗口。這三樣到位，剩下的都是廠商的事。

如果你正在評估要不要發包、或已經收到報價但看不懂裡面在寫什麼，可以把你現在的情況丟過來聊聊，我們陪你看這條流程從哪一段開始最划算、哪些功能可以留到第二期。系統裡如果有想接 AI 的部分，AI 系統開發 那邊也可以一起看。