一句「可不可以順便…」，變成 40 個工時
前年一個電商後台專案，客戶在週會最後兩分鐘說：「可不可以順便讓優惠券疊加？」聽起來像十分鐘的事，實際上牽動購物車計算、退款拆分與報表，吃掉 40 個工時、延後 11 天。代價不是那 40 小時，是它沒被寫下來、沒被報價、沒人確認過；上線日一過，雙方對「答應過什麼」的記憶完全不同。之後我們訂死一條規矩：不在原始規格裡的需求一律走變更單（Change Request）。
我們的做法：一句話變成一張有編號的單
超出原始規格的需求都要走八個關卡，沒有口頭版本，也沒有例外；那句話從說出口起就有編號可查：
客戶一句話（週會 / LINE / Email）
↓
Slack #cr-inbox 開單（24h 內）
↓
Notion 變更單 CR-2026-041（13 欄位）
↓
分級 A / B / C（人時 + 風險面）
↓
影響評估（模組 / 資料 / 測試 / 文件）
↓
報價 + 排程（B、C 級必經）
↓
客戶書面確認（Email 回「同意」）
↓
GitHub Projects 排入 Sprint → PR → 驗收
↓
回寫規格 + CHANGELOG → 關單為什麼設計成這樣：三個取捨
速度 vs 可追溯。小改動全走流程會被拖死，所以留了 A 級快速通道：直接做，單照開但不擋路。
免費額度 vs 界線。不給免費額度，客戶會覺得每講一句都在被收錢，久了乾脆不講，需求變成上線後才爆；A 級因此附帶每月 8 人時額度。
用人時分級，不用「重要性」。重要性主觀，人時可討論：
| 等級 | 判準 | 處理方式 |
|---|---|---|
| A 級 | ≤ 2 人時，不動資料表與金流權限 | 當週 Sprint 吸收，不計費（月上限 8 人時） |
| B 級 | 2–16 人時，或跨 2 個以上模組 | 出評估與報價，排入下一個 Sprint |
| C 級 | > 16 人時，或動到資料模型、金流、權限 | 視同新階段，重估時程並簽合約附件 |
具體執行：工具與變更單
四個工具串起這條線：Slack Connect 開共用的 #cr-inbox 頻道，客戶端行銷、營運都能直接丟需求；Notion 存單、自動編號 CR-YYYY-NNN；GitHub Projects 接手排程，PR 必須引用 CR 編號，看板就是客戶看得懂的進度；Figma 做視覺對照，上線後 Sentry 觀察 48 小時。
# CR-2026-041｜優惠券可疊加
- 提出人：客戶端 / 王經理
- 管道：週會（2026-09-02）
- 原始描述：「可不可以順便讓優惠券疊加？」
- 釐清範圍：一張訂單最多 2 張券
- 明確不包含：會員加成、跨店券、歷史回溯
- 影響模組：Cart / Order / Refund / Report
- 資料異動：orders 新增 coupon_stack_meta
- 測試影響：6 個 feature test + 退款回歸
- 文件回寫：spec/checkout.md、CHANGELOG.md
- 分級：B
- 估時：14 人時
- 排程：Sprint 2026-W38
- 客戶確認：2026-09-05 Email 回「同意」
「明確不包含」是最值錢的欄位：爭議多半來自客戶以為順便會做的那塊。寫評估時跑這份清單：
- ☐ 改到資料表結構嗎？要不要 migration 與回滾腳本？
- ☐ 影響已驗收功能嗎？補哪些回歸測試？
- ☐ 碰到金流、權限、個資嗎？
- ☐ 有沒有更便宜的替代做法給客戶選？
這個做法的代價
- 慢。B 級單從一句話到動工平均 2–3 個工作天，一半耗在客戶內部決策。
- 行政成本自吸。每張評估 40–60 分鐘不計費，月十張就是 8 小時。
- 容易過度分級。工程師保守，會把 A 級丟去 B 級，我們每季抽查校正。
不適合什麼情境
- 探索型 MVP／PoC。規格本來就邊做邊長，一天三張單會讓人窒息，改成兩週一次重議。
- 長期維運月約。維運是連續的小需求流，改用工單池加月人時上限。
客戶為什麼該關心
時程：延期多半不是技術難度，是沒人記得範圍被加了多少。有變更單就有出處：「W36 加了 3 張 B 級單共 31 人時，上線從 10/1 移到 10/9」。
費用：你在點頭前就看得到價格，不會有做完才冒出來的追加帳單。
品質：每張單都要回答「補哪些測試、回寫哪份文件」，半年後接手的人看到的規格才跟程式一致。
如果你也想這樣做
- 先談分級，再做表單。很多團隊先設計 20 欄的表單，結果沒人填。
- 書面確認越輕越好。只要客戶回一句「同意」；簽核系統只會卡在對方行政。
- 回寫文件納入 Definition of Done。沒回寫不能關單，這是唯一能長期複利的部分。
我們用在哪些客戶身上
一個 B2B 工業零件報價系統，六個月累積 47 張單：31 張 A（全在免費額度內）、14 張 B、2 張 C。其中一張 C 級要加多階經銷商價格，評估顯示得重寫定價資料模型、估 62 人時，客戶決定延到第二期。
另一個連鎖餐飲訂位 App，第三個月客戶的營運主管自己會說「這應該是 B 級吧？」——制度那時才算活了。
常見問題 FAQ
客戶說「這個很急」也要走完流程嗎？
急件走壓縮版：當天出評估與報價，口頭同意即可開工，24 小時內補單並回信確認。流程可壓縮，紀錄不能省。
A 級免費額度用完怎麼辦？
當月剩下的小需求轉 B 級報價，或延到下月額度；額度不累積、不退還。
如果是我們自己估錯導致工時暴增？
估時是我們的責任。報 14 人時、實做 22 人時，超出部分由我們吸收，不回頭追加。
客戶端很多人提需求，怎麼避免灌爆？
啟動時請客戶指定一位「決策代理人」：任何人都能丟需求進 #cr-inbox，但只有他能對 B／C 級單說「同意」。
合作或加入我們
如果你正在評估把 Laravel 或 Flutter 專案交給外部團隊，而過去的經驗是「範圍一直長、帳單一直來、沒人說得清為什麼」，歡迎把專案拿來聊，我們可以示範一張變更單在你的情境裡長什麼樣。喜歡把模糊需求拆成可估時、可驗收的工程師或 PM，我們也在找。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p