系統開發流程六階段：需求訪談到上線維運，常見雷區一次講清楚

想導入一套客製化系統或App，卻不知道整個過程會經過哪些關卡？多數人第一次接觸系統開發，最大的困惑不是「要花多少錢」，而是「這中間到底發生了什麼事，為什麼會花這麼久」。

系統開發流程其實有一套國際上通用的骨架，從需求訪談一路走到上線維運，共六個階段。這套骨架不是哪一家廠商發明的秘方，而是軟體工程界行之有年的共識，甚至有一份國際標準——ISO/IEC/IEEE 12207——把它系統化整理成完整的流程框架。看懂這六個階段，你才有辦法在跟開發團隊溝通時聽懂對方在講什麼，也才知道哪個階段最容易出狀況、該在哪裡多花心思把關。

這篇文章會把六個階段一步步拆開講，也會談到瀑布式跟敏捷式這兩種開發方法怎麼選、自聘、委外還是用現成方案怎麼判斷、報價通常怎麼分期，以及一個很多系統開發文章都沒提到的重點：需求訪談階段如果沒有把行銷追蹤跟未來擴充性一起考慮進去，上線後常常要多花一筆改版費用。

作者｜晨星行銷　陳俊鳴執行長（網路流量操盤手・企業行銷顧問）

系統開發流程到底在做什麼，先把「客製化系統」講清楚

先講白話版本。系統開發流程，講的就是「把一個企業的需求，變成一套能實際運作的軟體」這整段過程。不管是內部用的進銷存系統、對外的會員App，還是串接多個平台的後台管理工具，走的都是同一套骨架，差別只在規模大小跟複雜程度。

跟買現成軟體（例如直接訂閱一套雲端記帳工具）不一樣的地方在於，客製化系統是「照著你公司實際的作業方式去量身打造」，所以中間需要一段「把你腦中的流程，轉換成工程師聽得懂的規格」的過程——這段轉換，就是系統開發流程存在的原因。

如果把系統開發比喻成蓋房子，需求訪談就是跟建築師討論「這間房子要住幾個人、需要幾間房、預算多少」；系統設計是畫藍圖；程式開發是實際動工蓋房子；測試是完工前的驗屋；部署上線是交屋入住；維運優化則是入住後房子有狀況要修、家庭成員變多要加蓋。少了前面的討論跟藍圖，直接叫工人動工，蓋出來的房子十之八九不會是你要的樣子——這正是系統開發最常出問題的地方。

系統開發流程六階段，一次看懂每一步在做什麼

國際標準 ISO/IEC/IEEE 12207 把軟體生命週期的流程分成「協議流程」「組織專案賦能流程」「技術管理流程」「技術流程」四大類，涵蓋從取得、供應、規劃、風險管理到需求、設計、測試、維運與系統除役的完整範圍（ISO/IEC/IEEE 12207:2017）。這幾個分類名稱不用背，你只要知道一件事：這不是廠商自己發明的說法，而是一套經過國際認證、完整覆蓋全流程的正式規範，講這套流程有憑有據，不是憑感覺喊價。這套框架比較適合大型組織拿來做流程治理，對中小企業來說，簡化成下面這六個階段就足夠理解整個流程：

階段	主要工作	產出物
① 需求訪談與分析	訪談各部門、釐清業務流程、確認範圍	需求規格書、功能清單、優先順序
② 系統設計	規劃系統架構、資料庫結構、操作介面	架構圖、資料庫設計文件、介面原型
③ 程式開發	依設計文件實際撰寫程式，通常分模組進行	可運作的功能模組
④ 測試除錯	單元測試、整合測試、使用者驗收測試（UAT）	測試報告、問題清單
⑤ 部署上線	正式環境佈署、資料遷移、教育訓練	上線的系統、操作手冊
⑥ 維運優化	除錯維護、功能迭代、效能與安全性優化	維護紀錄、優化版本

這六個階段不是各自獨立，而是前一階段的品質會直接影響後面所有階段。需求訪談沒做好，設計就會照著錯的方向走；設計有漏洞，開發就會做出用不到或做錯的功能；功能做錯了，測試階段才會發現，這時候要改的成本已經比一開始就講清楚高出許多。

需求訪談與分析：整個專案成敗的起點

這是六個階段裡最常被低估的一步。很多企業主會覺得「我知道我要什麼」，但知道自己要什麼，跟能把它寫成一份工程師看得懂、不會誤解的規格書，是兩件完全不同的事。

需求訪談要做的事情包括：訪談實際會使用這套系統的員工（不只是老闆自己的想法）、畫出現有的業務流程、確認哪些功能是「一定要有」、哪些是「有更好但可以之後再加」、以及這套系統未來會跟哪些其他系統或平台串接。

系統設計、程式開發、測試除錯：把想法變成能用的系統

需求確認之後，接下來是系統設計——把「要做什麼」轉換成「怎麼做」。這個階段會決定系統的架構（例如資料要怎麼儲存、各功能模組怎麼互相溝通）、畫出操作介面的雛型，讓業主在真正動工前就能先看到系統大概長什麼樣子。

程式開發則是把設計文件變成實際可以運作的程式碼，這也是外界印象中「系統開發」最直觀的部分，但其實只佔整個流程裡的一段而已。程式開發通常會拆成多個模組分批進行，方便階段性驗收與調整。

測試除錯這一步常被壓縮，卻是決定系統穩不穩定的關鍵。完整的測試至少要包含：單元測試（確認每個小功能本身沒問題）、整合測試（確認各功能模組串起來運作正常）、以及使用者驗收測試（UAT，讓實際會用這套系統的人試用，抓出「功能對，但不好用」這類問題）。

部署上線與維運優化：上線不是結束，是另一階段的開始

系統正式上線，代表要把它從測試環境搬到正式環境，過程中可能牽涉舊資料的遷移、跟既有系統的串接，以及讓實際使用者知道怎麼操作（教育訓練）。這個階段容易低估的成本，是「員工適應新系統」所需要的時間——再好用的系統，剛換上去的頭幾週生產力通常都會先下滑一段，這是正常現象，不代表系統做壞了。

上線之後，維運優化才真正開始：系統會需要持續除錯、隨著業務成長加新功能、也要因應資安風險做更新。把上線當成終點，是很多企業對系統開發流程最大的誤解——實際上，上線只是這套系統開始被真正使用的第一天，後續的維運才是決定它能不能長期發揮價值的關鍵。

瀑布式還是敏捷式？兩種開發方法怎麼選

系統開發流程要照哪一種「節奏」走，主要有兩種方法論：瀑布式（Waterfall）跟敏捷式（Agile）。

瀑布式是照著上面六個階段依序完成，一個階段做完才進到下一個，中間文件齊全、里程碑清楚。敏捷式則是把整個開發拆成一次次短週期（常見是兩到八週一輪），每一輪都交付一部分可以實際使用的成果，再根據回饋調整下一輪要做什麼。敏捷式的精神源自2001年由17位軟體工程師共同發表的《敏捷宣言》，其中一項核心原則是「及早並持續交付有價值的軟體，以滿足客戶需求」，並且「就算開發後期，也歡迎改變需求」（Agile Manifesto 官方網站）。

比較項目	瀑布式	敏捷式
開發節奏	六階段依序完成一次	短週期反覆交付（通常2-8週一輪）
適合情況	規格明確、變動風險低、法規要求嚴謹	需求可能隨市場調整、想快速驗證
文件與里程碑	完整、清楚	較輕量，重視可用成果
中途改需求的成本	較高，越晚改成本越高	較低，本來就預期會調整
常見適用專案	內部固定流程的行政系統、法規遵循系統	對外服務型App、新創產品、需要快速驗證市場的系統

多數企業實務上不會死守單一方法，而是混用——整體規劃走瀑布式的階段管理（清楚知道每個階段要花多久、預算多少），實際開發執行則採敏捷式的短週期交付（每隔幾週就能看到進度、及早發現方向錯了）。這種混合做法能兼顧「老闆想要有清楚時程」跟「開發團隊需要彈性調整」這兩種需求。

為什麼「需求沒講清楚」是系統開發最常見的失敗原因

很多人以為系統開發會失敗，是因為工程師技術不夠好、或是選錯了開發語言。實際上，國際專案管理協會（PMI）針對全球專案管理現況的調查發現，將近半數（47%）的失敗專案，主要敗因是需求管理不準確——不是技術做不出來，而是一開始就沒有把「要做什麼」講清楚（PMI – Poor Requirements Management: The Source of Failed Projects）。

這個數字之所以重要，是因為它打破了一個常見誤解：「只要找到夠厲害的工程師，系統就會做得好」。事實上，工程師再厲害，也只能照著給他的規格去做；規格本身是模糊的、有遺漏的，做出來的東西自然就會跟預期有落差。

需求異動的成本，會隨著專案進度往後拖延而越墊越高——這件事在大型專案上格外明顯。麥肯錫與牛津大學major programme management中心針對超過5,400個大型IT專案的研究發現，這類專案平均會超支45%、超時7%，而且實際交付的價值比原本預期的少了56%（McKinsey – Delivering large-scale IT projects on time, on budget, and on value）。

「越晚發現問題、修正成本越高」這件事，軟體工程界其實有超過四十年的實證研究支持，不是憑感覺說說而已。軟體工程學者Barry Boehm與Victor Basili在學術期刊《IEEE Computer》發表的研究指出，軟體問題如果拖到交付後才修正，成本可能是在需求與設計階段就修正的100倍（Boehm & Basili, Software Defect Reduction Top 10 List, IEEE Computer）。

這也是為什麼經驗豐富的開發團隊，反而會在需求訪談階段花更多時間，而不是急著跳進去寫程式——不是他們動作慢，而是他們知道這個階段的每一分投入，換算成後面少走的冤枉路，通常是划算的。

系統開發流程裡最常被漏掉的一步：把行銷跟未來擴充性一起放進規格書

這一段講的是多數系統開發文章不會提到的角度。純技術背景的開發團隊，規劃系統時很自然會從「功能能不能用」「資料結構合不合理」去想，但常常漏掉一件事：這套系統上線之後，還要不要被用來做行銷、追蹤轉換、串接廣告後台、或者未來要不要做SEO優化？

實際有做過系統開發也同時做行銷代操的團隊會觀察到一個反覆出現的情況：企業先花錢做了一套官網或會員系統，上線半年後才發現沒辦法追蹤「使用者從哪個廣告點進來、最後有沒有下單」，或是網站結構天生就不利SEO（例如頁面網址是一長串亂碼、內容全部塞在需要登入才看得到的地方），這時候要補這些功能，往往比一開始就放進規格書要多花一筆改版費用。

換句話說，系統開發流程不該只是工程團隊自己關起門來想的事，行銷或業務部門的人也該在需求訪談階段就參與進去——這不是要把系統開發變複雜，而是避免「先做完系統，之後才發現行銷用不上」這種常見的落差。這也是為什麼委外開發時特別建議業主端指派固定窗口密集參與（詳見下一段）：這個窗口如果同時懂一點行銷需求、又能代表公司拍板決策，規格書漏掉行銷考量的機率會明顯降低。如果對「SEO友善的網站結構」具體該長什麼樣還不熟悉，可以先看SEO是什麼？中小企業主必看的搜尋引擎優化入門指南打好基礎概念。

自己找工程師、委外開發，還是用現成方案？三條路怎麼選

決定要導入系統之後，接下來的問題其實有三條路可以走，不是只有「自己找人」跟「委外」二選一：自聘團隊、委外客製化開發，或是採用現成軟體／低代碼平台（不用工程師寫大量程式碼、用拖拉元件的方式就能快速組出系統的開發工具，優點是快，缺點是能客製化的空間比較小）。如果只是要架設一個官網、還沒到整套客製化系統的規模，判斷邏輯其實很類似，可以參考網站架設自己來還是委外？從網域主機、平台選擇到上線前檢查清單。

比較項目	現成軟體／低代碼平台	委外客製化開發	自聘團隊開發
前期成本	最低，訂閱制為主	中等，依專案付費	最高（招募、培訓、設備）
符合業務流程的程度	較低，要遷就系統既有邏輯	高，照業主流程量身打造	高，且能隨時調整
上線速度	最快	中等	最慢
團隊完整度	不需要組建團隊	通常能一次取得完整團隊	需要自己湊齊PM、設計、工程、QA
長期彈性	受限於平台功能	需要另外提出需求變更	系統會持續迭代時較有優勢
適合情況	業務流程標準、不需要深度客製化	需求相對明確、預算有限的中小企業	系統會長期持續開發、跟著business一起長大

如果公司的業務流程跟多數同類型企業差不多、沒有特殊到需要量身訂做，現成軟體或低代碼平台通常是最划算的選項——不用經過完整的六階段開發流程，上線速度也最快。真正需要走客製化系統開發流程的，是業務邏輯有明顯特殊性、或現成方案無法滿足關鍵需求的情況。評估現成方案是不是夠用時，可以先看一個具體例子：CRM 是什麼？中小企業導入前，先搞懂「該不該用」比「用哪套」更重要，判斷邏輯跟這裡講的「業務流程夠不夠標準」是同一套。

在客製化開發的前提下，自聘團隊的優勢在於系統會長期持續開發、迭代的情況——當一套系統會一直加新功能、跟著business一起長大，養一支內部團隊的長期效益通常比較高。委外開發則適合預算有限、系統需求相對明確、或是內部沒有能力管理技術團隊的中小企業，能用較低的前期成本快速取得完整的開發能力。委外開發的判斷邏輯其實跟評估要不要找行銷顧問代操很像，都可以先把網路行銷顧問、代操、自己請人：先把請一個人的真實成本算出來這種真實成本算清楚，再決定要走哪條路。

不過委外不代表「甩手不管」。委外開發能不能順利，關鍵不在廠商技術強不強，而在業主端有沒有一個人能代表公司，密集跟開發團隊溝通、做決策、驗收成果——資策會（台灣官方支持的資訊產業推動機構）在探討軟體委外管理時也指出，委外承辦人若無法即時掌控開發進度，容易在交付後才發現落差（iThome – 資策會揭軟體委外開發管理關鍵）。這也呼應了一個更廣義的道理：把專業的事交給專業的人做沒有問題，但業主自己還是得看得懂需求規格、報表跟驗收標準，才不會被牽著走——你不需要自己會寫程式，但基本的判斷力不能少。

系統開發報價怎麼看懂，付款通常怎麼分期

系統開發的報價，通常不是單一數字，而是一連串成本的加總。開發費本身只是其中一部分，常見容易被忽略的還有：介面設計費、測試費、資料遷移費、員工教育訓練所需要的時間成本，以及上線之後生產力短暫下滑的磨合期。

台灣市場常見的付款方式是分階段的里程碑付款，例如簽約時付一部分、設計確認後再付一部分、開發完成再付一部分、最後驗收通過付尾款；上線後的年度維護費，市場行情通常落在開發費用的一到兩成半左右，多數廠商會先提供幾個月的免費保固期，之後才進入年約維護。這些數字是市場行情的觀察，不是固定標準——實際費用仍會因專案規模、複雜度跟廠商的報價方式而有落差，拿到報價單時，最好請對方把每一筆費用對應到哪個階段講清楚，而不是只看總價。

評估預算時，台灣中小企業也可以留意經濟部中小及新創企業署目前推動的中小微企業數位轉型相關補助方案，針對規模較小的企業提供人才培訓與軟體導入的部分費用補助（經濟部中小及新創企業署 – 中小企業數位轉型）。補助方案的申請對象、額度與受理期間每年可能調整，實際是否符合資格、能補助到哪個項目，建議直接向主管機關或申請窗口確認，不要只憑網路上的舊資訊就假設一定適用。

挑系統開發夥伴前，這幾個問題一定要先問

不管是找廠商還是招聘團隊，挑選開發夥伴時，有幾件事值得在合作前先確認：

• 這個團隊的組成是否完整？一個健全的開發團隊通常要有專案經理（PM）、介面設計（UI/UX）、前後端工程師，以及負責測試的QA，缺少其中任何一角，都可能讓某個階段的品質失衡。
• 對方能不能提供實際做過的類似案例，讓你去了解實際的合作經驗（不只是看作品截圖）。
• 對方在需求訪談階段，是主動來問你的業務流程，還是只等你自己講？一個有經驗的團隊，通常會反過來引導你把需求講清楚，而不是被動接受一份模糊的需求就開始動工。
• 驗收標準有沒有白紙黑字寫清楚？包含哪些測試項目要通過、UAT要由誰簽核。
• 合約裡有沒有講清楚原始碼與資料的歸屬——這件事常被忽略，但攸關系統未來要不要換團隊維護的自由度。

系統開發流程中最容易讓專案失控的幾種情況

除了需求不清楚，系統開發流程中還有幾種情況特別容易讓專案失控：

業主端沒有固定窗口，每次溝通對象都不一樣，導致需求反覆被重新解釋；開發到一半頻繁更改核心需求，卻沒有意識到這會連動影響已經做完的部分；驗收階段沒有明確標準，導致「到底算不算完成」變成各說各話；只看報價高低決定廠商，卻沒確認團隊組成跟過往經驗——這幾種情況單獨看都不算嚴重，但只要同時出現兩三項，專案延誤跟超支的機率就會明顯提高。

把這些常見雷區提前納入考量，比出事後才回頭補救，成本通常低很多——這也是為什麼系統開發流程要花時間走完前面幾個階段，而不是急著跳過規劃直接動工的原因。

系統開發從來不是「花錢買一套系統」這麼單純的事，而是一段需要業主與開發團隊一起投入時間釐清需求、階段性確認方向的過程。把六個階段跟中間的關鍵決策點都想清楚，才比較有機會讓做出來的系統真正符合企業成長的需要——如果評估過程中需要有人同時從系統架構跟行銷佈局的角度幫忙把關，晨星行銷這類同時經營系統開發與SEO代操的團隊，會是一個可以考慮諮詢的方向。

FAQ