10 個 sequential phase + 4 個平行 track。每個階段都有可勾選的 checklist、要參與的人、需要先看的文件、需要被誰確認。 勾選狀態自動存在本機，重新打開不會消失。
P0–P10.5 必須依序完成。每個 phase 結束需「上級確認」（approver 寫在每個 phase 的右側）後才能進下一階段。
不在主流程上，但與工程 phases 同時進行。這些是 BD / 內容 / 品牌 / 法務工作 — 工程做完但這些沒到位，平台 launch 時會空有外殼。
時程表不是「現在就能寫」的東西。在不同時間點交出來的時程表，誤差範圍是不一樣的。 對老闆承諾交付的「commit 版時程」必須等到夠多基礎條件達成 — 提前交承諾是埋雷。
用 BOM 工時表 + 三剖法（MAX / Realistic / MIN）的數字，告訴老闆「Y1 大概要這麼久」。 適合 stakeholder 報告、年度預算申請、投資人 pitch。
⚠ 不適合做合約承諾 — 還沒 schema、沒 tech stack，誤差太大。
這才是真正能交給老闆當 commit 用的時程表。 因為這時 schema 已凍結（不會大改）、tech stack 已選定（不會切換）、團隊與工具棧確認。 可以做 sprint 級別的 estimation。
✓ 適合對外簽合約、跟投資人定 milestone、跟老闆確認 launch date。
每個 sprint 的具體交付、每個 milestone 的精確日期。 這是工程內部使用的 detailed roadmap，會隨 sprint review 滾動更新。
→ 內部使用、每月跟老闆對齊一次。
從專案開工算起：P0 (2 週) + P1 (4 週) + P2 (6 週) + P3 (8 週) + P4 (6 週, 與 P5 平行) + P5 (3 週) = 最快約 23 週後（5.3 個月）才能交「±10% 的 commit 時程表」。
如果老闆現在就要時程表，最多只能給 V1 粗估版（±30%），且必須明確標示「等 P5 結束後會 refine」。 不要在 V1 階段就承諾 deadline — 那會在 Y1 中段炸開。
下表是 V1 粗估版 — ±25-30% 誤差。等 P5 結束後會 refine 成 V2 commit 版。
| 階段 | Phases | 時程 (週) | 里程碑 |
|---|---|---|---|
| 定焦期 | P0 + P1 | 4–6 週 | 北極星文件定稿 |
| 設計期 | P2 + P3 + P4 | 14–20 週 | Schema + Spec + 視覺定稿 |
| 準備期 | P5 + P6 | 5–7 週 | 技術架構 + 工程 plan |
| 開發期 | P7 | 20–30 週 | 代碼完成 |
| 驗證期 | P8 + P8.5 | 8–14 週 | Closed Beta 完成 |
| 上線期 | P9 + P10 | 8–12 週 | Y1 末對外公開 Launch |
| 總計 | P0 → P10 | 59–89 週 (14–21 月) | 對齊 Na 姐 Y1 12-18 個月計畫 — 緊但可達 |
最常見的 fatal mistake：P0–P1 拖到 3-4 個月不收斂（一直加新問題）→ Y1 整個 slip 到 Y1.5。
次常見：P5 技術架構決策草率（一個禮拜內決完）→ P7 開發到一半被迫換架構 → 砍掉重練。