From 311ce53116d2e819a7a4a76bc2fcd8b41fcdb862 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Thu, 17 Sep 2026 13:07:49 +0800 Subject: [PATCH] =?UTF-8?q?feat(=E5=8F=AF=E8=A1=8C=E6=80=A7=E6=AA=A2?= =?UTF-8?q?=E6=9F=A5):=20=E6=96=B0=E5=A2=9E=E6=9E=B6=E6=A7=8B=E3=80=81?= =?UTF-8?q?=E9=82=8F=E8=BC=AF=E3=80=81=E8=B3=87=E6=96=99=E3=80=81=E6=99=82?= =?UTF-8?q?=E7=A8=8B=E5=9B=9B=E4=BB=BD=E6=AA=A2=E6=9F=A5=E6=B8=85=E5=96=AE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問 使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把 它變成一句能收斂的提問，那才是實際卡住的地方。 四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經 做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡）， 時程問未知數最大的一項（它決定整體估算的可信度）。 Co-Authored-By: Claude Opus 5 (1M context) --- references/feasibility-architecture.md | 22 ++++++++++++++++++++++ references/feasibility-data.md | 19 +++++++++++++++++++ references/feasibility-logic.md | 20 ++++++++++++++++++++ references/feasibility-schedule.md | 21 +++++++++++++++++++++ 4 files changed, 82 insertions(+) create mode 100644 references/feasibility-architecture.md create mode 100644 references/feasibility-data.md create mode 100644 references/feasibility-logic.md create mode 100644 references/feasibility-schedule.md diff --git a/references/feasibility-architecture.md b/references/feasibility-architecture.md new file mode 100644 index 0000000..5090f34 --- /dev/null +++ b/references/feasibility-architecture.md @@ -0,0 +1,22 @@ +# 架構可行性檢查 + +問的是「這件事該不該在這裡做、做了會不會把結構弄壞」。 + +每一條都要對著需求議題的內容回答，回答不出來就是一個要問使用者的問題。 + +## 檢查項 + +1. **落點** — 這個需求該由哪一個 repo 承接？若需求議題的「影響範圍」列了多個 repo， + 哪一個是主要落點、其餘各自要改什麼？ +2. **放錯地方的徵兆** — 若照目前的落點做，是否需要把原本屬於別處的知識搬進來？ + 需不需要讀別的 repo 的資料表或內部模組？ +3. **相依方向** — 新增的相依是誰依賴誰？會不會造成循環相依（A 依賴 B，B 又回頭依賴 A）？ +4. **既有邊界** — 這次改動會不會穿過既有的分層或模組邊界？若會，是邊界本來就畫錯， + 還是這次該繞過？ +5. **對外介面** — 會不會改變既有的對外介面？既有呼叫端有誰、要不要同時改？ +6. **可回復性** — 做錯了要怎麼退回？是可以直接 revert，還是會留下已遷移的資料或已發布的介面？ + +## 問題怎麼問 + +每一條檢查若在議題裡找不到答案，就轉成一個問題。問題要具體到能用一句話回答， +不要問「架構上有什麼考量嗎」這種無法收斂的問法。 diff --git a/references/feasibility-data.md b/references/feasibility-data.md new file mode 100644 index 0000000..0a77b70 --- /dev/null +++ b/references/feasibility-data.md @@ -0,0 +1,19 @@ +# 資料可行性檢查 + +問的是「資料層面會不會出事，以及出事有多難救」。 + +## 檢查項 + +1. **schema 變更** — 要不要動資料表？新增欄位、改型別、改索引，各自影響哪些既有查詢？ +2. **遷移** — 既有資料怎麼辦？需不需要回填？回填期間新舊邏輯會不會同時在跑？ +3. **可逆性** — 遷移能不能退回？若不能，上線前要準備什麼（備份、灰度、開關）？ +4. **交易邊界** — 一次操作要寫幾個地方？其中一個失敗會不會留下不一致的狀態？ + 哪些必須在同一個交易內？ +5. **資料量與成長** — 現在的量級是多少、一年後呢？查詢會不會隨資料成長而變慢？ +6. **敏感資料** — 會不會經手個資或憑證？誰能讀到？日誌裡會不會留下不該留的東西？ +7. **資料來源** — 資料從哪裡來、由誰維護？來源不可用時這個功能該怎麼表現？ + +## 問題怎麼問 + +schema 與遷移的答案通常不在需求議題裡，而在資料負責人腦子裡——這一組問題幾乎一定要問。 +把「不動 schema」也當成一個明確的答案記下來，不要當成沒問。 diff --git a/references/feasibility-logic.md b/references/feasibility-logic.md new file mode 100644 index 0000000..98fc5fc --- /dev/null +++ b/references/feasibility-logic.md @@ -0,0 +1,20 @@ +# 邏輯可行性檢查 + +問的是「這件事是不是已經有人做過、或者根本不必做」。 + +## 檢查項 + +1. **重複** — 既有功能裡有沒有已經在做同一件事的？若有，是要沿用、擴充，還是取代？ +2. **相近但不同** — 有沒有看起來很像但語意不同的既有功能？兩者的差別是什麼、 + 會不會讓使用者混淆？ +3. **真正的需求** — 使用者描述的是解法還是問題？若是解法，背後要解的問題是什麼？ + 有沒有更直接的做法？ +4. **邊界情境** — 空值、極大量、並行操作、重複執行，各自該怎麼表現？ + 需求議題的驗收標準有沒有把這些寫進去？ +5. **失敗時的行為** — 這件事做到一半失敗會怎樣？要回滾、要留下半成品，還是要能續跑？ +6. **誰會消費** — 產出的東西給誰用？那個消費者現在是怎麼取得同樣資訊的？ + +## 問題怎麼問 + +「既有功能已經做過同一件事」是最值得先問的一條——它能整個取消這次工作。 +先查再問：能在程式碼裡查證的就不要拿去問使用者。 diff --git a/references/feasibility-schedule.md b/references/feasibility-schedule.md new file mode 100644 index 0000000..38d4a94 --- /dev/null +++ b/references/feasibility-schedule.md @@ -0,0 +1,21 @@ +# 時程可行性檢查 + +問的是「要多久、哪一段最可能爆炸」。 + +## 檢查項 + +1. **相依鏈最長路徑** — 把工作依相依關係排開，最長的那一條有多長？ + 那條路徑上的每一項都非做不可嗎？ +2. **未知數最大的一項** — 哪一項的估算最沒把握？它為什麼沒把握——是不熟的技術、 + 不明的既有程式碼，還是等別人回覆？ +3. **可平行的部分** — 哪些工作彼此沒有相依、可以同時進行？ +4. **外部相依** — 有沒有卡在別的團隊、別的服務、或需要權限開通的事？ + 那些事的前置時間是多久？ +5. **可切分性** — 這個需求能不能先交付一部分就對使用者有價值？ + 若能，第一刀切在哪裡？ +6. **驗證成本** — 做完要怎麼驗？驗證本身要花多少時間（需要造資料、需要別人配合）？ + +## 問題怎麼問 + +先問「未知數最大的一項」，因為它決定整體估算的可信度。 +把每一項的人天估算記下來，之後 sdlc-report 會拿它跟實際工時比對。