你真的有在「規劃」嗎？
一句話總結：系統規劃不是官僚流程，是讓你少加班三個月的保險。
結論先講：跳過規劃直接寫 code，就像不看地圖就開車橫越沙漠——你可能會到，但更可能在半路拋錨，而且沒有人會來救你。
我見過太多團隊栽在「邊做邊想」這四個字上面。
不是能力不夠，是流程根本沒建起來。需求沒確認就開工，架構沒共識就各寫各的，容量沒估就直接上 production。小專案也許還能矇過去，但系統一複雜，問題就像滾雪球一樣指數成長。
你有沒有經歷過這些場景？
- 開發到一半才發現需求理解有落差，砍掉重練
- 選了某個很潮的框架，三個月後發現不合用，技術債直接爆表
- 上線當天流量一來，系統直接躺平
- PM 問「什麼時候做完？」你只能回「快了快了」
如果中了兩個以上，恭喜，你需要的不是更好的技術，是更好的規劃。
系統規劃到底在規劃什麼？
整個流程分六個階段，每個階段的產出都是下一個階段的輸入：
需求收集 → 技術選型 → 架構設計 → 容量規劃 → 開發計畫 → 上線計畫
聽起來很教科書？但關鍵在這句：前期多花一小時規劃，後期少花十小時救火。 我不是在講雞湯，這是踩過坑之後的算術題。
這篇先聊第一關——需求收集。這是最容易被跳過的階段，也是專案爆掉最常見的根源。
需求收集：最被低估的階段
很多工程師覺得需求收集是 PM 的事，跟自己無關。這個想法會害死你。
因為寫 code 的是你，到時候需求對不上、架構要重來的也是你。你不在需求階段就把事情問清楚，就等著在開發階段一直砍掉重練。
先搞清楚：誰在乎這個系統？
動手之前，先畫一張利害關係人地圖。不需要很正式，但你得知道：
- PO / PM：定義業務需求，決定優先順序
- Tech Lead：評估技術可行性，做架構決策
- 工程師們：估工時，提技術建議（對，你自己也算）
- QA：定測試策略跟驗收標準
- SRE / DevOps：管部署流程跟系統穩定性
- 業務單位：看 ROI，盯市場時程
漏掉任何一個角色，就是在製造驚喜。而專案裡的驚喜通常不是好事。
功能需求：「系統要做什麼」
User Story 大家都會寫，格式就是：
作為一個
<角色>，我想要<功能>，以便<價值>。
但問題不在格式，在你有沒有問完整。每個 story 都該想三種路：
- Happy Path：正常走完的流程
- Alternative Path：使用者走了另一條合理的路
- Exception Path：出錯了怎麼辦
只想 happy path 的需求文件，就像只有晴天計畫的旅行——一下雨就全毀了。
非功能需求：「系統要表現多好」
這塊更容易被忽略，但往往才是決定系統成敗的關鍵：
- 效能：P99 回應時間要壓在多少？200ms？500ms？
- 可擴展性：要撐多少併發用戶？
- 可用性：99.9% uptime 意味著一年只能停機 8.76 小時，你算過嗎？
- 安全性：認證機制、加密標準、合規要求
- 可觀測性：全鏈路追蹤的覆蓋率目標
沒有把這些數字寫下來，到時候 PM 說「怎麼這麼慢」，你連反駁的依據都沒有。
限制條件：先把地雷標出來
每個專案都有不能動的東西，趁早列出來：
- 預算天花板在哪？
- 有沒有不可動搖的上線日期？
- 團隊有幾個人？有沒有技術能力缺口？
- 必須沿用的既有系統或供應商？
- GDPR、PCI-DSS 這類合規要求？
這些限制條件不列出來，就是埋定時炸彈。等到開發中期才發現「啊原來不能用這個雲」，那個感覺，嗯，你懂的。
PRD 不是作文，是契約
需求收集的最終產出是 PRD（Product Requirements Document）。別把它當成寫給老闆看的作文，它是開發團隊跟業務單位之間的契約。
一份好的 PRD 至少要有：
- 背景與目標：我們為什麼要做這個？成功指標是什麼？
- 功能需求：每個 feature 的 User Story + 驗收標準
- 非功能需求：效能、可用性、安全性的量化目標
- 限制條件：預算、時程、技術限制
- 非目標（Non-Goals）：明確寫出「這個專案不做什麼」
Non-Goals 特別重要。沒有 Non-Goals 的 PRD，就是在邀請所有人無限制地加需求。然後你就會陷入永遠做不完的迴圈。
這篇的重點回顧
系統規劃六個階段，需求收集是地基。地基歪了，上面蓋再漂亮都會倒。
下一篇我們聊怎麼選技術、怎麼做架構設計——那是另一個充滿血淚的戰場。
系列文章：
- 你在這裡 → 系統規劃（一）：需求收集
- 系統規劃（二）：技術選型與架構設計
- 系統規劃（三）：容量規劃、開發計畫與上線
延伸閱讀：
「規劃就像刷牙，你不會因為做了而被表揚，但不做的話遲早會痛到不行。」