Files
tea-sdlc/references/feasibility-data.md
T
jiantw83andClaude Opus 5 311ce53116 feat(可行性檢查): 新增架構、邏輯、資料、時程四份檢查清單
四份規則正本,各自列出要對著需求議題回答的檢查項,回答不出來的就是一個要問
使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼,不說怎麼把
它變成一句能收斂的提問,那才是實際卡住的地方。

四份各自點出一個最該先問的:架構問落點與循環相依,邏輯問既有功能是不是已經
做過同一件事(這條能整個取消工作),資料問 schema 與遷移(答案通常不在議題裡),
時程問未知數最大的一項(它決定整體估算的可信度)。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 13:07:49 +08:00

1.2 KiB

資料可行性檢查

問的是「資料層面會不會出事,以及出事有多難救」。

檢查項

  1. schema 變更 — 要不要動資料表?新增欄位、改型別、改索引,各自影響哪些既有查詢?
  2. 遷移 — 既有資料怎麼辦?需不需要回填?回填期間新舊邏輯會不會同時在跑?
  3. 可逆性 — 遷移能不能退回?若不能,上線前要準備什麼(備份、灰度、開關)?
  4. 交易邊界 — 一次操作要寫幾個地方?其中一個失敗會不會留下不一致的狀態? 哪些必須在同一個交易內?
  5. 資料量與成長 — 現在的量級是多少、一年後呢?查詢會不會隨資料成長而變慢?
  6. 敏感資料 — 會不會經手個資或憑證?誰能讀到?日誌裡會不會留下不該留的東西?
  7. 資料來源 — 資料從哪裡來、由誰維護?來源不可用時這個功能該怎麼表現?

問題怎麼問

schema 與遷移的答案通常不在需求議題裡,而在資料負責人腦子裡——這一組問題幾乎一定要問。 把「不動 schema」也當成一個明確的答案記下來,不要當成沒問。