系統規劃方法論：從需求到上線的完整流程
流程概覽
flowchart LR A[需求分析] --> B[架構設計] B --> C[技術選型] C --> D[容量規劃] D --> E[開發計劃] E --> F[驗收標準] F --> G[上線發布] style A fill:#4CAF50,color:#fff style B fill:#2196F3,color:#fff style C fill:#FF9800,color:#fff style D fill:#9C27B0,color:#fff style E fill:#F44336,color:#fff style F fill:#009688,color:#fff style G fill:#607D8B,color:#fff
文章概覽
在本篇文章中，您將學習到：
- 為什麼缺乏結構化規劃是專案失敗的主因
- 系統規劃的六大階段及其交付物
- 需求收集、技術選型、架構設計的實務方法
- 容量規劃的估算公式與思維模型
- 開發計畫的拆解方式與風險管理
- 上線計畫的檢查清單與回滾策略
- 可直接套用的文件範本（PRD、Technical Spec、ADR、上線清單）
引言：為什麼「隨便規劃」會導致專案失敗？
在軟體開發的實務中，許多團隊習慣「邊做邊想」——需求還沒釐清就開始寫程式，架構沒有共識就各自開發，容量沒有評估就直接上線。這種 ad-hoc（臨時起意）的開發方式，在小型專案中或許還能勉強運作，但隨著系統複雜度提升，問題會以指數級速度爆發：
- 需求不明確：開發到一半才發現需求理解有落差，大量重工
- 技術選型草率：選了不適合的框架或服務，中途被迫更換，造成技術債
- 架構缺乏設計：各模組之間耦合度過高，無法獨立部署與擴展
- 容量未經評估：上線後遭遇流量高峰，系統直接崩潰
- 時程嚴重失控：沒有明確的里程碑，無法追蹤進度，延期成為常態
- 上線沒有計畫：出問題時無法快速回滾，影響範圍不可控
結構化的系統規劃方法論，就是為了解決這些問題而存在。它不是繁瑣的官僚流程，而是一套經過驗證的框架，幫助團隊在正確的時間點做出正確的決策，將風險降到最低。
系統規劃生命週期
以下是系統規劃的六大階段，每個階段都有明確的輸入、活動與交付物：
flowchart LR A[需求收集<br/>Requirements] --> B[技術選型<br/>Tech Selection] B --> C[架構設計<br/>Architecture] C --> D[容量規劃<br/>Capacity Planning] D --> E[開發計畫<br/>Dev Plan] E --> F[上線計畫<br/>Launch Plan] style A fill:#4CAF50,color:#fff style B fill:#2196F3,color:#fff style C fill:#FF9800,color:#fff style D fill:#9C27B0,color:#fff style E fill:#F44336,color:#fff style F fill:#009688,color:#fff
每個階段都是下一個階段的輸入。跳過任何一個階段，都會在後續階段產生更大的風險與成本。這就是所謂的「前期多花一小時規劃，後期少花十小時救火」。
Phase 1 — 需求收集（Requirements Gathering）
需求收集是整個規劃流程的起點，也是最容易被忽視的階段。許多專案的失敗，追根究柢都是因為需求沒有收集完整或沒有取得共識。
1.1 利害關係人識別（Stakeholder Identification）
首先需要釐清：誰是這個系統的利害關係人？
| 角色 | 關注重點 | 參與方式 |
|---|---|---|
| 產品負責人（PO） | 業務需求、使用者體驗 | 需求定義、優先排序 |
| 技術主管（Tech Lead） | 技術可行性、架構品質 | 技術評估、架構決策 |
| 後端/前端工程師 | 實作細節、開發體驗 | 工作量評估、技術建議 |
| QA 工程師 | 測試策略、品質標準 | 測試計畫、驗收標準 |
| SRE / DevOps | 部署流程、系統穩定性 | 基礎設施、監控規劃 |
| 業務單位 | ROI、市場時程 | 需求提出、驗收確認 |
1.2 功能性需求（Functional Requirements）
功能性需求描述系統「應該做什麼」。常用的表達方式包括：
User Story 格式：
作為一個
<角色>，我想要<功能>，以便<價值>。
範例：
作為一個電商平台的買家，我想要在購物車中修改商品數量，以便我可以在結帳前調整訂單。
Use Case 格式：
- 主要場景（Happy Path）
- 替代場景（Alternative Path）
- 異常場景（Exception Path）
1.3 非功能性需求（Non-Functional Requirements）
非功能性需求描述系統「應該表現多好」，通常以量化指標呈現：
| 類別 | 指標 | 範例目標 |
|---|---|---|
| 效能（Performance） | 回應時間、吞吐量 | P99 回應時間 < 200ms |
| 可擴展性（Scalability） | 支援的併發用戶數 | 支援 10,000 併發用戶 |
| 可用性（Availability） | 系統運行時間比例 | 99.9% uptime（年停機 < 8.76 hr） |
| 安全性（Security） | 認證、授權、加密 | 所有 API 需 JWT 驗證 |
| 可觀測性（Observability） | 日誌、指標、追蹤 | 全鏈路追蹤覆蓋率 > 95% |
1.4 限制條件（Constraints）
每個專案都有其限制條件，必須在規劃階段就明確列出：
- 預算：基礎設施、第三方服務、人力成本的上限
- 時程：必須在何時上線？有無不可動搖的截止日期？
- 團隊規模：可投入多少工程師？是否有特定技術能力的缺口？
- 既有基礎設施：是否必須沿用既有的資料庫、雲端供應商、CI/CD 流程？
- 合規要求：是否有 GDPR、PCI-DSS 等法規需要遵守？
1.5 交付物：PRD（Product Requirements Document）
需求收集階段的最終產出就是 PRD。以下提供可直接套用的範本：
# PRD：[專案名稱]
## 1. 概述
- **專案名稱**：
- **文件版本**：v1.0
- **最後更新日期**：YYYY-MM-DD
- **文件擁有者**：[姓名 / 角色]
## 2. 背景與目標
- **問題陳述**：我們目前面臨什麼問題？
- **目標**：這個專案要達成什麼？
- **成功指標（KPI）**：如何衡量成功？
- **非目標（Non-Goals）**：這個專案明確不做什麼？
## 3. 利害關係人
| 角色 | 姓名 | 責任 |
|------|------|------|
| 產品負責人 | | 需求定義 |
| 技術主管 | | 技術決策 |
| 設計師 | | UI/UX 設計 |
## 4. 功能需求
### 4.1 Epic / Feature 名稱
- **User Story**：作為 ___，我想要 ___，以便 ___
- **驗收標準（Acceptance Criteria）**：
- [ ] 條件一
- [ ] 條件二
- **優先級**：P0 / P1 / P2
## 5. 非功能需求
- **效能**：
- **可用性**：
- **安全性**：
## 6. 限制條件
- **預算**：
- **時程**：
- **技術限制**：
## 7. 里程碑
| 階段 | 預計日期 | 交付物 |
|------|----------|--------|
| 需求確認 | | 本文件 |
| 技術設計 | | Tech Spec |
| MVP 完成 | | 可部署版本 |
| 正式上線 | | GA Release |
## 8. 開放議題
| # | 議題描述 | 負責人 | 狀態 |
|---|----------|--------|------|
| 1 | | | Open |
## 9. 附錄
- Wireframe / Mockup 連結
- 競品分析
- 相關技術文件Phase 2 — 技術選型（Tech Stack Selection）
技術選型決定了專案的技術基礎。錯誤的技術選型往往在開發中後期才暴露問題，此時更換的成本極高。
2.1 評估維度
進行技術選型時，應從以下維度進行系統化評估：
| 維度 | 說明 | 權重建議 |
|---|---|---|
| 團隊熟悉度 | 團隊是否有使用經驗？學習曲線多高？ | 高 |
| 社群與生態系 | 文件品質、第三方套件數量、活躍度 | 中高 |
| 效能表現 | Benchmark 數據、延遲、吞吐量 | 依需求 |
| 營運成本 | 授權費用、雲端資源消耗、維運人力 | 中 |
| 供應商鎖定 | 是否綁定特定平台？遷移難度？ | 中 |
| 成熟度與穩定性 | 是否已有足夠的生產環境驗證？ | 高 |
| 招募難度 | 市場上是否容易找到有經驗的工程師？ | 中 |
2.2 決策矩陣（Decision Matrix）
將候選方案以量化分數進行比較：
| 維度（權重） | 方案 A | 方案 B | 方案 C |
|---|---|---|---|
| 團隊熟悉度（30%） | 9 | 6 | 7 |
| 社群生態系（20%） | 8 | 9 | 7 |
| 效能表現（15%） | 7 | 8 | 9 |
| 營運成本（15%） | 8 | 6 | 7 |
| 供應商鎖定（10%） | 9 | 5 | 8 |
| 成熟度（10%） | 9 | 8 | 6 |
| 加權總分 | 8.35 | 7.00 | 7.30 |
2.3 ADR（Architecture Decision Record）
每一個重要的技術決策都應該用 ADR 記錄下來。ADR 的核心價值在於記錄決策的脈絡與理由，而不僅僅是結論。
# ADR-001：[決策標題]
## 狀態
Accepted | Proposed | Deprecated | Superseded by ADR-XXX
## 日期
YYYY-MM-DD
## 背景（Context）
描述促使這個決策的背景。我們面臨什麼問題或挑戰？
有哪些技術或業務上的驅動力（driving forces）？
## 考量的方案（Options Considered）
### 方案 A：[名稱]
- **優點**：
- **缺點**：
- **風險**：
### 方案 B：[名稱]
- **優點**：
- **缺點**：
- **風險**：
### 方案 C：[名稱]
- **優點**：
- **缺點**：
- **風險**：
## 決策（Decision）
我們決定採用 **方案 X**，因為：
1. 理由一
2. 理由二
3. 理由三
## 後果（Consequences）
- **正面**：這個決策帶來的好處
- **負面**：這個決策帶來的代價或風險
- **需要注意的事項**：後續需要監控或處理的事項
## 參與者
- [姓名 / 角色]Phase 3 — 架構設計（Architecture Design）
架構設計是將需求轉化為技術藍圖的過程。一份好的架構設計文件，應該讓任何一位工程師讀完後，都能理解系統的整體結構與設計決策。
3.1 高階架構圖（High-Level Architecture）
flowchart TB Client[Client<br/>Web / Mobile / API] -->|HTTPS| LB[Load Balancer<br/>Nginx / ALB] LB --> API[API Gateway] API --> AuthSvc[Auth Service] API --> BizSvc[Business Service] API --> NotifSvc[Notification Service] BizSvc --> DB[(PostgreSQL)] BizSvc --> Cache[(Redis)] BizSvc --> MQ[Message Queue<br/>RabbitMQ] MQ --> Worker[Background Worker] Worker --> DB NotifSvc --> Email[Email Provider] NotifSvc --> Push[Push Notification] style Client fill:#E3F2FD style LB fill:#FFF3E0 style API fill:#E8F5E9 style DB fill:#FCE4EC style Cache fill:#FCE4EC style MQ fill:#F3E5F5
3.2 元件拆分（Component Breakdown）
每個元件需要定義：
| 元件名稱 | 職責 | 技術棧 | 擁有者 | 依賴 |
|---|---|---|---|---|
| API Gateway | 路由、限流、認證 | Nginx / Kong | Infra Team | Auth Service |
| Auth Service | 身份驗證與授權 | Node.js + JWT | Backend Team | PostgreSQL |
| Business Service | 核心業務邏輯 | Node.js / Go | Backend Team | PostgreSQL, Redis |
| Notification Service | 通知發送 | Node.js | Backend Team | MQ, Email Provider |
| Background Worker | 非同步任務處理 | Node.js / Python | Backend Team | MQ, PostgreSQL |
3.3 API 設計
API 設計應該在開發之前就達成共識，避免前後端平行開發時產生介面不一致的問題：
- 端點清單（Endpoint List）：列出所有 API 的 HTTP method、path、request/response schema
- 資料流向圖（Data Flow）：描述核心場景中資料在各元件之間的流動
- 錯誤處理規範：統一的錯誤碼格式與分類
- 版本策略：URL versioning（
/v1/）或 Header versioning
3.4 資料庫設計原則
- 正規化（Normalization）：避免資料冗餘，但在效能需求下可適度反正規化
- 索引策略：根據查詢模式設計索引，避免過度索引
- 分區策略：大資料表考慮以時間或 ID 進行分區
- 備份與復原：定期備份、驗證復原流程
3.5 交付物：Technical Spec
# Technical Spec：[功能名稱]
## 1. 概述
- **對應的 PRD / User Story**：[連結]
- **作者**：[姓名]
- **審查者**：[姓名]
- **狀態**：Draft | In Review | Approved
## 2. 背景
簡述這個功能的業務背景與技術動機。
## 3. 架構設計
### 3.1 高階架構
（插入架構圖）
### 3.2 元件互動
描述各元件之間的呼叫關係與資料流向。
### 3.3 API 規格
| Method | Path | 描述 | Request Body | Response |
|--------|------|------|--------------|----------|
| POST | /api/v1/orders | 建立訂單 | `{ items, address }` | `{ orderId }` |
| GET | /api/v1/orders/:id | 查詢訂單 | - | `{ order }` |
### 3.4 資料模型
```sql
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id),
status VARCHAR(20) NOT NULL DEFAULT 'pending',
total DECIMAL(10,2) NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_orders_status ON orders(status);4. 設計決策
4.1 為什麼選擇 X 而不是 Y？
（記錄關鍵決策與理由，或連結到對應的 ADR）
5. 安全考量
- 認證與授權機制
- 資料加密策略
- 輸入驗證
6. 測試策略
- 單元測試覆蓋範圍
- 整合測試情境
- 效能測試計畫
7. 監控與告警
- 需要監控的關鍵指標
- 告警條件與通知管道
8. 部署計畫
- 部署方式（Blue-Green / Canary / Rolling）
- Feature flag 使用
- 資料庫 migration 策略
9. 時程估算
| 任務 | 預估工時 | 負責人 |
|---|---|---|
| API 開發 | 3d | |
| 前端串接 | 2d | |
| 測試 | 2d |
10. 開放議題
| # | 議題 | 狀態 |
|---|---|---|
| 1 | Open |
---
### Phase 4 — 容量規劃（Capacity Planning）
容量規劃是一門「用數字說話」的藝術。它的核心目標是：**在系統上線前，預估所需的運算資源，確保系統能承受預期的負載。**
#### 4.1 從用戶數推算 QPS
容量規劃的起點通常是**預期用戶數**，然後逐步推算到基礎設施需求：
DAU（日活躍用戶數）= 100,000 每位用戶每日平均請求數 = 20 每日總請求數 = 100,000 × 20 = 2,000,000
平均 QPS = 2,000,000 / 86,400 ≈ 23 QPS 峰值係數 = 3x（假設高峰期是平均值的 3 倍） 峰值 QPS = 23 × 3 ≈ 70 QPS
安全係數 = 2x（預留 buffer） 設計目標 QPS = 70 × 2 = 140 QPS
#### 4.2 資料庫容量估算
每筆訂單資料大小 ≈ 500 bytes 每日新增訂單數 = 10,000 每日新增資料量 = 10,000 × 500 bytes = 5 MB/day 每月新增資料量 = 5 MB × 30 = 150 MB/month 一年資料量 = 150 MB × 12 = 1.8 GB/year
加上索引開銷（約 1.5x）= 1.8 × 1.5 = 2.7 GB/year 保留 3 年資料 = 2.7 × 3 = 8.1 GB
#### 4.3 儲存容量估算
用戶上傳圖片：平均 200 KB/張 每日上傳量 = 5,000 張 每日儲存需求 = 5,000 × 200 KB = 1 GB/day 每月儲存需求 = 1 × 30 = 30 GB/month 一年儲存需求 = 30 × 12 = 360 GB/year
#### 4.4 頻寬估算
平均單頁大小 = 2 MB（含圖片、JS、CSS） 峰值 QPS = 140 峰值頻寬需求 = 140 × 2 MB = 280 MB/s ≈ 2.24 Gbps
考慮 CDN 快取命中率 80%： 實際源站頻寬需求 = 2.24 × (1 - 0.8) = 0.448 Gbps ≈ 450 Mbps
#### 4.5 資源對應表
根據上述估算，可以初步規劃基礎設施：
| 資源類型 | 規格 | 數量 | 備註 |
|----------|------|------|------|
| Application Server | 2 vCPU, 4GB RAM | 3 台 | 含 1 台 buffer |
| Database (Primary) | 4 vCPU, 16GB RAM, 50GB SSD | 1 台 | PostgreSQL |
| Database (Replica) | 4 vCPU, 16GB RAM, 50GB SSD | 1 台 | 讀取分流 |
| Redis Cache | 2 vCPU, 8GB RAM | 1 台 | Session + 快取 |
| Object Storage | - | - | S3 / MinIO，按用量計費 |
| Load Balancer | - | 1 台 | Nginx / ALB |
---
### Phase 5 — 開發計畫（Development Plan）
有了需求、架構和容量規劃，接下來需要將工作拆解成可執行的任務，並規劃時程。
#### 5.1 工作分解結構（WBS — Work Breakdown Structure）
WBS 的核心原則是**分到每個任務都可以被一個人在一個 sprint 內完成**：
-
基礎設施建置 1.1 開發環境配置 1.2 CI/CD Pipeline 建置 1.3 staging 環境部署 1.4 監控系統設定
-
核心功能開發 2.1 用戶認證模組 2.1.1 註冊 API 2.1.2 登入 API 2.1.3 JWT Token 管理 2.2 訂單模組 2.2.1 建立訂單 API 2.2.2 訂單查詢 API 2.2.3 訂單狀態更新
-
前端開發 3.1 登入/註冊頁面 3.2 訂單管理介面 3.3 後台管理頁面
-
測試 4.1 單元測試撰寫 4.2 整合測試撰寫 4.3 效能測試執行
-
上線準備 5.1 Production 環境部署 5.2 資料庫 Migration 5.3 上線驗證
#### 5.2 Sprint 規劃與里程碑
| Sprint | 時間 | 目標 | 交付物 |
|--------|------|------|--------|
| Sprint 1 | Week 1-2 | 基礎建設 + 認證模組 | 可登入的 staging 環境 |
| Sprint 2 | Week 3-4 | 核心業務邏輯 | 訂單 CRUD API |
| Sprint 3 | Week 5-6 | 前端整合 | 完整前後端串接 |
| Sprint 4 | Week 7-8 | 測試 + Bug 修復 | 通過 UAT 的版本 |
| Sprint 5 | Week 9 | 上線準備 + 正式上線 | Production Release |
#### 5.3 風險評估與緩解
風險管理不是「等問題發生再處理」，而是在規劃階段就預先識別並準備對策：
| 風險 | 可能性 | 影響程度 | 緩解策略 |
|------|--------|----------|----------|
| 關鍵工程師離職 | 中 | 高 | 確保每個模組至少 2 人熟悉；完善文件 |
| 第三方 API 延遲交付 | 中 | 中 | 準備 Mock Server；設計抽象層方便替換 |
| 需求範圍蔓延 | 高 | 高 | 嚴格的 Change Request 流程；PRD freeze 機制 |
| 效能未達標準 | 低 | 高 | 提前進行 Load Testing；預留效能優化時間 |
| 安全漏洞 | 中 | 高 | Code Review 必須含安全檢查；導入 SAST 工具 |
---
### Phase 6 — 上線計畫（Launch Plan）
上線是整個規劃流程的最後一哩路，也是風險最集中的階段。一份完善的上線計畫，能讓團隊在面對突發狀況時從容應對。
#### 6.1 上線前檢查清單（Pre-Launch Checklist）
```markdown
# 上線檢查清單
## 程式碼與品質
- [ ] 所有功能通過 Code Review
- [ ] 單元測試覆蓋率 > 80%
- [ ] 整合測試全數通過
- [ ] 效能測試結果符合 SLA
- [ ] 安全掃描（SAST/DAST）無 Critical / High 漏洞
- [ ] 所有技術債已記錄在 backlog
## 基礎設施
- [ ] Production 環境已部署並通過 smoke test
- [ ] Database Migration 已在 staging 驗證
- [ ] SSL 憑證已設定且有效
- [ ] DNS 設定正確
- [ ] CDN 配置完成並已 warm up
- [ ] 防火牆規則已設定
## 監控與告警
- [ ] Application 層監控已設定（回應時間、錯誤率、QPS）
- [ ] Infrastructure 層監控已設定（CPU、Memory、Disk）
- [ ] 日誌收集與集中管理已啟用
- [ ] 告警規則已設定且通知管道已驗證
- [ ] Dashboard 已建立（Grafana / Datadog）
## 資料
- [ ] 資料庫備份策略已啟用
- [ ] 備份復原流程已驗證
- [ ] 初始化資料已準備（Seed Data）
- [ ] 資料遷移腳本已測試
## 文件
- [ ] API 文件已更新（Swagger / OpenAPI）
- [ ] 運維手冊（Runbook）已撰寫
- [ ] 架構圖已更新
- [ ] On-call 輪值表已排定
## 溝通
- [ ] 上線時間已通知所有利害關係人
- [ ] 客服團隊已完成產品培訓
- [ ] 內部公告已準備
- [ ] 外部用戶公告已準備（如適用）
## 回滾計畫
- [ ] 回滾步驟已文件化
- [ ] 回滾已在 staging 環境演練
- [ ] 回滾的觸發條件已定義
- [ ] 回滾的負責人已指定
6.2 回滾計畫（Rollback Plan）
回滾計畫是上線計畫中最重要的安全網。它回答的核心問題是：如果上線出問題，我們怎麼在最短時間內恢復到上一個穩定版本？
關鍵要素：
- 觸發條件：定義什麼情況下需要回滾
- 錯誤率超過 5%
- P99 回應時間超過 2 秒
- 核心功能不可用
- 回滾步驟：逐步操作指引，讓任何 on-call 工程師都能執行
- 資料處理：如果有 schema 變更，回滾時資料如何處理？
- 驗證方式：回滾後如何確認系統已恢復正常？
- 時間預算：預估回滾需要多長時間？超過此時間需要升級處理。
6.3 監控設定（Monitoring Setup）
上線後的監控至少應涵蓋三個層次：
| 層次 | 監控項目 | 工具建議 |
|---|---|---|
| 基礎設施層 | CPU、Memory、Disk I/O、Network | Prometheus + Node Exporter |
| 應用層 | QPS、回應時間、錯誤率、業務指標 | Prometheus + Custom Metrics |
| 業務層 | 訂單數、轉換率、收入 | Grafana Dashboard |
6.4 溝通計畫（Communication Plan）
| 時間點 | 對象 | 內容 | 管道 |
|---|---|---|---|
| T-7 天 | 全體利害關係人 | 上線預告、功能說明 | Email + Slack |
| T-1 天 | 技術團隊 | 上線步驟 Dry Run | 會議 |
| T-0（上線中） | 技術團隊 | 即時狀態更新 | War Room / Slack Channel |
| T+1 小時 | 全體利害關係人 | 上線結果報告 | Email + Slack |
| T+1 天 | 全體利害關係人 | 穩定性報告 |
常見問題與風險
在實踐系統規劃方法論的過程中，團隊常會遇到以下挑戰：
問題一：過度規劃（Over-Engineering）
症狀：花了三個月做規劃，結果市場窗口已經關閉。
解法：根據專案規模調整規劃深度。MVP 階段不需要完美的架構，但需要明確的演進路線。Rule of thumb — 規劃時間不應超過總開發時間的 20%。
問題二：文件寫了沒人看
症狀：花大量時間撰寫的文件，在開發過程中沒有人參考，最後與實作完全脫節。
解法：
- 文件應該「剛好夠用」而非「鉅細靡遺」
- 將文件嵌入開發流程（例如 PR 模板中要求附上 Tech Spec 連結）
- 定期的文件審查與更新機制
問題三：需求持續變更
症狀：開發進行到一半，PO 不斷追加或修改需求，導致時程不斷延後。
解法：
- PRD 在進入開發階段後設定 freeze date
- 後續變更走正式的 Change Request 流程，評估影響後再決定是否納入
- 將變更分類為「必須」和「可延後」
問題四：技術選型由個人偏好決定
症狀：選技術的理由是「我覺得這個比較潮」或「我之前用過很順」，而非基於客觀評估。
解法：強制使用決策矩陣和 ADR。讓技術選型成為團隊的集體決策，而非個人偏好。
問題五：容量規劃憑直覺
症狀：「先開兩台 server 應該夠了吧」，上線後才發現不夠。
解法：任何容量規劃都必須基於數字推算。即使數字不精確，有數字依據的估算也遠比直覺可靠。上線後持續監控，用真實數據校正估算模型。
問題六：沒有回滾計畫
症狀：上線出問題後，團隊手忙腳亂，花了數小時才恢復服務。
解法：回滾計畫是上線的必要條件，不是可選項。上線前必須在 staging 環境演練過回滾流程。
小結
系統規劃方法論的六個階段——需求收集、技術選型、架構設計、容量規劃、開發計畫、上線計畫——構成了一個完整的閉環。每個階段都有其明確的目的與交付物：
| 階段 | 核心問題 | 交付物 |
|---|---|---|
| 需求收集 | 做什麼？為誰做？ | PRD |
| 技術選型 | 用什麼技術做？ | ADR |
| 架構設計 | 怎麼做？ | Technical Spec |
| 容量規劃 | 需要多少資源？ | 資源估算表 |
| 開發計畫 | 什麼時候做完？ | WBS + Sprint Plan |
| 上線計畫 | 怎麼安全上線？ | Launch Checklist |
最重要的不是嚴格遵守每一個步驟，而是建立**「在動手之前先想清楚」**的團隊文化。規劃的深度可以根據專案規模調整，但規劃的習慣不應缺席。
Proto 實踐對照
在 Proto 專案中，系統規劃的成果直接體現在每個 Track 的架構設計上。例如 Django Proto 的分層架構（Router → Service → Repository）就是系統規劃中「關注點分離」原則的實踐。詳見 Proto 規劃方法論。
延伸閱讀
- 環境分離策略：了解 DEV、SIT、UAT、PROD 各環境的配置與管理
- CD 持續整合與持續部署：將上線計畫自動化，降低人為錯誤風險
- 軟體架構概論：從更高的視角理解架構設計的全貌
- Git Workflow：版本控制流程與開發計畫的配合