開發流程：需求到上線
你提了一個需求給工程師，結果過了兩週還沒上線。不是工程師在偷懶——是因為從「需求」到「上線」之間，有很多你沒看到的步驟。
情境：「加一個按鈕而已，要做那麼久？」
行銷部門想在首頁加一個「新會員 9 折」的活動 banner。聽起來很簡單，但工程師說要兩週。為什麼？
因為「加一個 banner」背後可能包含：
- 設計稿（UI/UX 設計師要畫）
- 前端切版（HTML/CSS）
- 後端判斷邏輯（是不是新會員？折扣怎麼算？）
- 活動開始和結束時間的控制
- 測試（各種瀏覽器、手機都要測）
- 上線部署
軟體開發的六個階段
| 階段 | 誰負責 | 做什麼 |
|---|---|---|
| 1. 需求 | PM / 業務 | 確認要做什麼、為什麼要做 |
| 2. 設計 | 設計師 / 架構師 | UI 設計稿、技術架構 |
| 3. 開發 | 工程師 | 寫程式碼 |
| 4. 測試 | QA / 工程師 | 找 bug、確認功能正確 |
| 5. 部署 | DevOps / 工程師 | 把程式放到正式環境 |
| 6. 維護 | 全員 | 監控、修 bug、持續優化 |
環境的概念：Dev → Staging → Production
工程師不會直接在「正式網站」上改東西。就像你不會直接在客戶的報價單上亂改——你會先在草稿上改好，確認沒問題再給客戶。
| 環境 | 用途 | 誰會用 |
|---|---|---|
| Dev（開發環境） | 工程師自己測試 | 工程師 |
| Staging（預備環境） | 模擬正式環境做最後測試 | PM、QA、利害關係人 |
| Production（正式環境） | 真正的使用者在用的 | 所有人 |
Bug 的嚴重程度
測試時發現的問題叫「Bug」。不是每個 Bug 都一樣急，工程師會用嚴重程度分類：
本課重點
- 軟體開發六階段：需求 → 設計 → 開發 → 測試 → 部署 → 維護
- 三個環境：Dev（開發）→ Staging（預備）→ Production（正式）
- Bug 有嚴重程度之分，Critical 優先修、Low 排後面
- 一個「看起來很簡單」的功能，背後可能涉及多個階段和角色
AI 協作：學了這個，跟 AI 怎麼配合？
了解開發流程後，你能更準確地評估時程，也能讓 AI 幫你拆解需求和寫驗收條件。
你的人類優勢：
- 你知道這個功能的商業目標和優先順序
- 你能協調不同部門的時間和資源
可以這樣跟 AI 說：
我想在電商網站加一個「商品比較」功能，請幫我拆解成開發任務清單，列出每個任務需要的角色（前端/後端/設計）和預估天數。
練習題
互動示範
挑戰任務
模擬開發工期計算：建立 tasks 陣列，包含 {name: "設計", days: 3}、{name: "開發", days: 5}、{name: "測試", days: 2}。用 for 迴圈算出總天數，印出 "總工期：10 天"。
模擬環境判斷：宣告 env = "staging"，用 if/else if/else 判斷——"production" 印出 "正式環境，小心操作"，"staging" 印出 "測試環境，可以放心測"，其他印出 "開發環境"。
模擬 Bug 篩選：建立 bugs 陣列包含 {id: 1, severity: "Low"}、{id: 2, severity: "Critical"}、{id: 3, severity: "Critical"}。用 for 迴圈找出所有 severity 為 "Critical" 的 bug，印出 "Bug {id} 需要立即處理"（每行一筆）。