jiantw83andClaude Opus 5
549bd29313
四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問 使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把 它變成一句能收斂的提問，那才是實際卡住的地方。 四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經 做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡）， 時程問未知數最大的一項（它決定整體估算的可信度）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 lines
1.1 KiB
Markdown
21 lines
1.1 KiB
Markdown
# 邏輯可行性檢查
|
|
|
|
問的是「這件事是不是已經有人做過、或者根本不必做」。
|
|
|
|
## 檢查項
|
|
|
|
1. **重複** — 既有功能裡有沒有已經在做同一件事的？若有，是要沿用、擴充，還是取代？
|
|
2. **相近但不同** — 有沒有看起來很像但語意不同的既有功能？兩者的差別是什麼、
|
|
會不會讓使用者混淆？
|
|
3. **真正的需求** — 使用者描述的是解法還是問題？若是解法，背後要解的問題是什麼？
|
|
有沒有更直接的做法？
|
|
4. **邊界情境** — 空值、極大量、並行操作、重複執行，各自該怎麼表現？
|
|
需求議題的驗收標準有沒有把這些寫進去？
|
|
5. **失敗時的行為** — 這件事做到一半失敗會怎樣？要回滾、要留下半成品，還是要能續跑？
|
|
6. **誰會消費** — 產出的東西給誰用？那個消費者現在是怎麼取得同樣資訊的？
|
|
|
|
## 問題怎麼問
|
|
|
|
「既有功能已經做過同一件事」是最值得先問的一條——它能整個取消這次工作。
|
|
先查再問：能在程式碼裡查證的就不要拿去問使用者。
|