Linear 導入計劃總覽（統整版V2）
本文件為統整初稿 V1 的升級版本，融合 Integration Expert 整合決策報告的所有架構裁決。核心差異：新增 Hotfix 緊急通道設計、QA 批次視窗機制、成熟度路徑 Level 3.5 過渡，以及所有 Automation 的技術可行性誠實標注。適用對象：Forest App 15 人團隊全體成員與決策者。
執行摘要
Forest App 是訂閱制消費者行動應用，有 iOS、Android、Android CN 三個版本。功能更新透過四個 Channel 發布（iOS / Android / Server / Web），不同職能的工程師以 Label 區分；其中 Server 與 Web 是各平台 App 共用的後端，不是獨立平台。現有版本管理以 Notion Release Tracker 為核心，輔以 n8n 自動化與 Slack 通知。
V2 導入 Linear 的核心目的，按優先序排列：
- 將 Issue 追蹤遷移到更適合工程團隊的工具，降低手動更新成本，並透過 GitHub 原生整合讓 PR 狀態自動同步 Issue 狀態
- 建立真正的 Release Train 節奏——Feature Freeze 讓版本按時發車，Hotfix 超車道讓緊急情況有序處理
- 以「文件化優先」取代 Slack 口頭溝通，測試注意事項、掉車決策、Crash 監控全部留存在 Issue 中
- 建立可量測的品質指標（DORA 4 個 + 消費者 App 3 個），以數據驅動流程改善
- 保留 Notion 的文件與知識庫功能，兩個工具明確分工各司其職
V2 vs V1 的核心升級：V1 奠定了基本架構，V2 在三個方向進行實質升級——（1）補完三個版本共同缺少的 Hotfix SOP，（2）將 QA 批次視窗機制從隱含假設提升為顯性設計，（3）對所有 Automation 進行技術可行性誠實標注，告別「工具會強制」的錯誤期待，轉為「設計層明確，工具補充，人工紀律支撐」的現實設計。
導入策略：漸進式平行運行。Month 1 建立基礎、驗證機制、String Freeze 試水；Month 2 建立文化、掉車 SOP 演練、QA 批次視窗上線；Month 3 全員整合、DORA 與消費者 App 指標達標。
消費者 App 成熟度定位（V2 版：加入 Level 3.5）
Forest App 在 Release 流程成熟度上，目前約等同於 2019 年的 Todoist：有自動化、有多平台管理，實際運作上沒有因等人而延遲發車的情況，但尚未建立正式的 Feature Freeze 截止文化與掉車 SOP，缺乏明確的截止點機制使版本節奏仍依賴功能完成的默契而非制度保障。V2 的三個月目標是達到 Level 5（Duolingo 水準）——有明確的 Feature Freeze、掉車 SOP、Crash Gate 與 DORA 追蹤。
V2 新增 Level 3.5：這是 V1 路徑中缺少的過渡步驟。Level 3（自動化基礎）到 Level 5（完整 Feature Freeze 文化）的跨度太大，直接跳躍往往引發文化抗拒。Level 3.5（String Freeze 先行）讓團隊先習慣「截止點是死的」這個最基本認知，再引入掉車 SOP（Level 4）和完整 Feature Freeze（Level 5）。
| 成熟度等級 | 代表公司（同類） | 特徵 | Forest 現況 / 目標 |
|---|---|---|---|
| Level 1 | 早期 Streaks | 手動發布，無流程 | — |
| Level 2 | 小型習慣 App | 有 Notion 追蹤，無節奏 | — |
| Level 3 | 2019 年 Todoist | 有自動化 | 目前位置 |
| Level 3.5 | String Freeze 試行 | 有截止點，翻譯字串凍結，Low-Conflict 文化試水 | Month 1 末目標（V2 新增） |
| Level 4 | Headspace/Calm | Feature Freeze 試行，掉車 SOP 演練，DORA 雛形 | Month 2 目標 |
| Level 5 | Duolingo | Crash Gate + 掉車 SOP 自動化 + DORA 全追蹤 | Month 3 目標 |
| Level 6 | Notion/大型 App | Feature Flag + A/B Testing | 未來路線圖 |
為什麼 String Freeze 先行：String Freeze（文字內容截止）是所有 Freeze 機制中情緒阻力最低的——它只影響翻譯字串的修改，不影響功能開發。但它能建立「有一個日期，過了就不能改」的文化印象，讓整個團隊第一次體驗截止點的真實感。這個經驗為 Month 2 的掉車 SOP 演練做好心理準備。
8 大導入原則（V2 版）
以下 8 條原則在 V1 基礎上強化了原則六（新增 Hotfix 超車道）和原則八（Testing Notes 三方確認），並對每條原則加入「為什麼這樣設計」的說明。
原則一：平行運行，降低風險
在 Linear 環境完全驗證前，團隊繼續使用 Notion。不強迫切換，讓信心自然建立。Linear 的價值要先在局部展示（從 RD 的 GitHub 整合開始），不靠行政命令推動。
為什麼：強制切換的心理成本是技術成本的 3-5 倍。當 RD 第一次看到 PR 合併後 Issue 狀態自動更新，那個「這個工具真的有用」的瞬間，比任何培訓文件都有效。
業界案例：Atlassian 推動 Jira 全面採用時，允許各 Squad 自行選擇導入時間點，最終 18 個月內完成全員遷移，比強制推行快 40%。
原則二：從開發端切入
RD 是最自然的起點。GitHub 整合讓 Linear 的價值立竿見影——PR 自動連結 Issue，幾乎不需要額外學習成本。從工具使用者最有感的地方開始，比從管理層要求開始更有效。
為什麼：工具導入的最大阻力來自「為什麼要多一個步驟」。GitHub 整合把「步驟」變成了「減少步驟」——RD 不再需要手動更新 Issue 狀態，PR 合併就自動完成了。這讓第一批使用者成為內部推廣者，而非被動接受者。
原則三：保留 Notion 的優勢（V2 工具分工表）
兩個工具明確分工，V2 新增 Hotfix 相關欄位：
| 工具 | 負責內容 | 不負責的內容 |
|---|---|---|
| Linear | Issue 追蹤、狀態管理、Cycle 管理、Feature Freeze Milestone、掉車記錄、Hotfix 流程追蹤（[Hotfix] Label + Hotfix Cycle）、MTTR 計時記錄 | 設計文件、知識庫、Epic 規格書、測試報告精美格式 |
| Notion | 設計文件、測試報告文件、Epic 規格、知識庫、長期文件化、Hotfix 根因分析記錄（Retrospective 後） | Issue 狀態追蹤、開發工作流程 |
| Slack | 即時通知（自動觸發）、緊急討論、Hotfix 緊急廣播（Firebase Alert → release-monitor） | 決策記錄、Testing Notes（必須在 Linear Issue 內） |
| n8n / Calendar | Feature Freeze 48 小時提醒（Linear 原生不支援 Milestone 日期觸發）、DORA Webhook 接收、Release Notes 自動草稿生成 | Issue 狀態管理（由 Linear 負責） |
重要技術說明：Feature Freeze 提醒無法由 Linear 原生 Automation 實現（Linear 沒有「距 Milestone 日期 N 天」的 Trigger）。V2 採用外部工具補充：若 n8n 已有，使用 n8n Cron Job 每天查詢 Linear Milestone 日期；若尚未配置，由 RM 在建立 Milestone 時同步設定 Google Calendar 提醒（Freeze 前 48 小時）。
原則四：尊重現有自動化邏輯（含 Android ALPHA 機制）
現有自動化規則是多年積累的流程智慧。不能一次性廢棄，須逐一用 Linear Automation 重建，確保邏輯等效。特別重要的是 Android ALPHA 機制：PR 合併到 staging/android-* 分支時，CI/CD 自動建置版本號含 -ALPHA，並觸發 Linear Automation 將 Issue 狀態改為 Ready for Test，同步通知 Slack android-test。此機制不可因導入而中斷。
為什麼：現有 Automation 的技術細節背後都有對應的業務需求。每條規則在廢棄前，都要確認「這條規則在解決什麼問題」，而不是「這條規則有沒有在 Linear 中對應的設定」。
原則五：統一跨平台流程（iOS 通知可靠性差異顯性化）
V2 明確標注 iOS vs Android 的通知可靠性差異，而非假裝已統一：
- Android：-ALPHA 版本號機制全自動，通知可靠性高
- iOS：過渡期（M1-M2）由 RD 使用 Linear Issue Comment 標準模板發通知，不靠記憶
- 中期目標（M3）：評估 TestFlight Webhook 可行性，讓 iOS 可靠性追上 Android
短期補償機制：iOS RD 合併 PR 後，在 Linear Issue 新增 Comment（使用固定模板），不依賴 Slack 手動訊息。這讓通知有可追溯的記錄，即使遺漏也能事後追查。
原則六：列車不等人（V2 新增：Hotfix 緊急超車道）
Cycle 是真正的時間箱。功能未完成則進入下一個 Cycle，不延誤整個版本。掉車不是失敗，讓列車延誤才是問題。
V2 新增核心設計：「列車不等人」需要一個配套的緊急超車道設計。沒有設計好 Hotfix 流程的 Release Train 系統，在第一次緊急事故時必然失控——因為 Hotfix 需要打破「列車不等人」的常規，而沒有設計好的超車道，每次 Hotfix 都會變成特例討論。
Hotfix 超車道不是「列車等人」的例外，而是有嚴格觸發條件的緊急通道。使用頻率過高（月 > 2 次）是需要改善測試流程的信號，而非調整 Hotfix SOP。
Hotfix 觸發條件：PO 判定為 P0 Bug（David 或 Ezou，兩人其一即可）
PO 的 P0 判定依據包含：Crash-free rate < 99.0%、付費功能中斷、影響 > 10% 用戶的核心功能失效等。
詳細 Hotfix SOP 見本文件「Hotfix 緊急通道設計」章節，完整操作步驟見 02-Linear功能對應分析（統整版V2）。
原則七：度量驅動改善
每個 Cycle 結束後用 DORA 指標加上消費者 App 特有指標回顧，讓流程改善有數據基礎。沒有度量的改善只是感覺，有度量的改善才能識別真正的瓶頸。
V2 更新：MTTR（平均恢復時間）的計算起點明確為「Firebase Alert 自動觸發時」，而非「人工發現時」。Firebase Alert 有精確時間戳可追蹤，確保 MTTR 數字可信且可量測。
原則八：文件化優先（V2 升級：Testing Notes 三方確認機制）
測試注意事項、掌車決策、Crash 監控記錄——所有流程節點的重要資訊都要寫進 Issue，不依賴 Slack 口頭溝通。
V2 升級：從「雙向強制（PO + QA）」升級為「三方確認機制（PO + RD + QA）」。原設計遺漏了最脆弱的環節——RD 在開發中補充技術邊界。V2 在 PR Template 加入確認欄位，讓 RD 補充 Testing Notes 的動作嵌入 PR Review 流程，而非獨立習慣。
重要澄清：三方確認機制依賴人工紀律，而非工具強制。Linear 無法阻止 QA 跳過 Comment 直接改狀態，也無法判斷 Description 是否已填寫。機制的執行靠人工紀律 + RM 每週 Review 抽查 + PR Template 的流程嵌入。
7 大成功指標（V2 版）
統整版採用 DORA 4 個核心指標 + 消費者 App 3 個特有指標，共 7 個。V2 更新了 MTTR 計算起點，並新增 QA 批次視窗相關指標。
DORA 4 個核心指標
| 指標 | 定義 | 3 個月目標 | 消費者 App 業界水準 |
|---|---|---|---|
| Lead Time for Changes | Issue 建立（Planning）→ 版本 Released 的天數 | ≤ 4 週（28 天） | 2-4 週（含 App Store 審核） |
| Deployment Frequency | iOS / Android 版本發布頻率 | 每 2 週一個版本 | Duolingo 每 1-2 週 |
| Change Failure Rate | 緊急修復（Hotfix）次數 / 總發布次數 | < 15% | 業界平均 10%，Duolingo < 5% |
| MTTR（平均恢復時間） | 從 Firebase Alert 自動觸發時（而非人工發現時）計算，到 Hotfix 版本 Released 的時間 | < 3 天 | 消費者 App 同業 < 2 天 |
MTTR 計算起點裁決（V2）：採用「Firebase Alert 觸發時」為計算起點。人工發現時間不可測量也難標準化（「我今天早上看到」不是可量測的事件）；Firebase Alert 有精確的毫秒級時間戳，且在 Slack release-monitor 有公開記錄，確保 MTTR 數字可信、可比較、可改善。
消費者 App 3 個特有指標
| 指標 | 定義 | 開始追蹤時機 | 3 個月目標 |
|---|---|---|---|
| Crash-free Session Rate | Firebase Crashlytics 的 Crash-free session 比例，iOS 和 Android 分別追蹤 | Month 2 起（Phased Release 監控啟動後） | > 99.5%（對標 Duolingo Crash Gate 閾值） |
| Testing Notes 填寫率 | 新建 Issue 中，「測試注意事項 - 重點觀測項目」欄位非空的比例，以及 RD PR Template 確認欄位填寫率 | Month 2 起追蹤（Month 1 為建立 Template 期） | Month 2 目標 > 80%；Month 3 目標 > 90% |
| 版本準時發車率 | 版本在預定 Cycle 結束日（±3 天容差）內提交 App Store / Google Play 的比例 | Month 3 起（第一次完整 Release Train 後） | 第一次成功即達標（文化建立里程碑） |
V2 新增補充指標（非 KPI，但需追蹤）：
- QA context switching 次數（目標：實施批次視窗後 < 3 次非計劃中斷/天）
- Hotfix 使用頻率（目標：月 ≤ 2 次；超過即觸發測試流程改善討論）
Hotfix 緊急通道設計（V2 全新章節）
這是 V1 統整初稿的最大盲點。三個版本（V1 / V2 / V3）均未設計 Hotfix 流程。V2 將 Hotfix SOP 作為 Release Train 文化的必要安全閥，首次完整設計。
為什麼 Hotfix SOP 是必要的
沒有 Hotfix 超車道的 Release Train 系統，在第一次緊急事故時必然失控：
- 每次 Hotfix 都需要重新討論「要打破 Cycle 嗎？」，消耗 RM 的信任資本
- 沒有明確授權人，David 和 Ezou 可能意見分歧
- 沒有標準流程，每次 Hotfix 都是即興處理，品質無保障
- MTTR 無法計算（因為流程不標準，每次計時起點不同）
Hotfix SOP 解決的是「知道要做什麼」的問題，而不是「技術能力夠不夠」的問題。
Hotfix 觸發條件
觸發條件：PO 判定為 P0 Bug
授權人：PO（David 或 Ezou，兩人其一即可，不需要兩人都同意，確保緊急時決策速度）
PO 在判斷是否為 P0 Bug 時，主要參考以下指標：
| 參考指標 | 具體數值 / 定義 | 資料來源 |
|---|---|---|
| Crash 率異常 | Crash-free rate < 99.0%（iOS 或 Android） | Firebase Crashlytics Alert 自動推送 |
| 付費功能中斷 | 訂閱購買、Forest 幣功能出現任何中斷回報 | Slack user-feedback 或 App Store 評論 |
| 核心功能失效 | 影響 > 10% 用戶的核心功能失效（例：計時器不啟動、通知完全失效） | 人工判斷 |
最終是否啟動 Hotfix，由 PO（David 或 Ezou）判定。RM 負責協調後續執行流程。
Hotfix 執行摘要（5 步驟）
Step 1：Firebase Alert 觸發 → MTTR 計時開始
→ 自動推送到 Slack <span class="tag">release-monitor</span>
→ RM 識別觸發條件類型
Step 2：PO 判定並授權 Hotfix
→ PO（David 或 Ezou）確認觸發情況，判定是否為 P0 Bug
→ PO 在 Slack 發出 Hotfix 啟動通知（文字記錄，作為授權依據）
→ RM 接收通知，在 Linear 建立 Hotfix Issue（Label: [Hotfix] + 版本標記如 v5.8.1）
→ RM 開始協調後續執行流程
Step 3：RD 在 Hotfix 分支修復
→ 分支命名：hotfix/vX.X.X
→ 精簡 Review：不需要 PO Review，RD Lead（Ezou）代碼審查即可
Step 4：QA 快速回歸測試
→ 不走批次視窗，立即插單（[Hotfix] Issue 是 [Critical] 等級例外）
→ 重點測試：修復的 Bug 場景 + 相關核心功能回歸
Step 5：發版
→ iOS：Shawn 申請 App Store Expedited Review（在送審說明填寫緊急原因）
→ Android：緊急發布，同時申請 Fast Track Review
→ Hotfix Released → MTTR 計時結束
→ 下次 Sprint Retrospective 討論根因，納入測試覆蓋
Hotfix 在 Linear 中的操作
- [Hotfix] Label：在 Label 系統中建立（若尚未存在，列入 Month 1 Week 1 設定清單）
- Hotfix Cycle：建立獨立 Cycle（命名：Hotfix v5.8.1），不合併進正常版本 Cycle
- MTTR 記錄：Hotfix Released 時，在 Issue Comment 記錄「MTTR：X 小時 Y 分鐘（從 Firebase Alert 到 Released）」
- Retrospective 記錄：在 Hotfix Cycle Description 記錄根因分析和學習點
完整 Hotfix 操作步驟與 Android / iOS 流程差異，詳見 02-Linear功能對應分析（統整版V2）。
QA 批次視窗機制（V2 全新章節）
統整初稿 V1 採用個別 Issue 觸發 Ready for Test（正確設計），但沒有配套 QA 的工作安排機制。Fei Chen 和 Jimmy 兩人在純粹個別觸發模式下，會面臨頻繁的 context switching，每次切換成本約 15-20 分鐘。V2 補充「QA 批次視窗」設計，解決這個被低估的問題。
設計原則
批次視窗不是取消「個別 Issue 觸發」——Issue 狀態仍然是個別觸發的（功能開發完就進入 Ready for Test，不等其他功能）。批次視窗改變的是 QA 的工作節奏：Issue 進入 Ready for Test 後，進入「QA 等待池」，在固定批次時間集中處理。
這個設計保護了兩樣東西：
- QA 的認知資源：深度測試需要連續時間，零散中斷讓測試覆蓋率下降
- RD 的合理期待：RD 知道「Ready for Test 後，下個批次視窗（最遲 X 天）會被測到」，不會因等待而不確定
批次視窗設計
- QA 等待池：Issues 進入 Ready for Test 後，自動出現在 QA 的「待測 Queue」Linear 視圖（Filter：Status = Ready for Test）
- 批次視窗時間：每週 2 個固定 QA 時段（建議週二下午 + 週四下午，由 Fei Chen 和 Jimmy 根據實際工作節奏確認）
- 等待池處理原則：時段外收到的 Ready for Test 通知加入等待池，下個視窗集中處理
緊急插單機制
批次視窗有一個明確的例外：緊急 Issue 可以打破批次規定，立即處理。
- 觸發條件：RM 在 Linear Issue 加 [Priority: Urgent] 標記（或 [Hotfix] Issue 自動為緊急等級）
- 授權流程：RM 通知 Fei Chen / Jimmy（Slack 直接訊息），說明緊急原因
- QA 處理：看到 [Priority: Urgent] 或 [Hotfix] 後，可優先插入當前工作，不需等下個視窗
Linear 視圖設定
QA Dashboard（Team 層級 View）：
- Filter：Assignee = Fei Chen 或 Jimmy，Status = Ready for Test 或 Testing
- 排序：Priority（高到低）→ Due Date（近到遠）
詳細 QA Dashboard 設定步驟見 02-Linear功能對應分析（統整版V2）。
主要風險表（V2 版）
以下風險表在 V1 基礎上新增 Hotfix SOP 相關風險，並更新 Testing Notes 機制的描述。
| 風險 | 可能性 | 影響 | 因應策略 |
|---|---|---|---|
| 團隊抗拒改變 | 中 | 高 | 先展示 GitHub 整合立即價值；用業界案例說明；不強制切換，平行運行 |
| 自動化規則重建耗時 | 高 | 中 | 分批重建（P0 → P1 → P2），優先處理最常觸發的 Automation；Android ALPHA 機制列為 P0 保護 |
| Feature Flag 引入複雜度 | 低（短期） | 中（長期） | V2 不在 3 個月內強制引入 Feature Flag；留在未來路線圖評估 |
| DORA 度量失真 | 中 | 中 | 避免單獨追求 Deployment Frequency；7 個指標並行，防止局部優化 |
| Hotfix SOP 缺失 → 緊急事件無標準程序 | 低 | 高 | V2 已設計 Hotfix SOP（見本文件 Hotfix 章節）；Month 1 Week 1 完成 [Hotfix] Label 設定；Shawn 學習 Expedited Review 申請方式 |
| PO 不填 + RD 不補 + QA 不看（Testing Notes 三方失效） | 高 | 高 | PO 填寫是 Issue 建立流程的一部分；RD PR Template 加入確認欄位；QA Ready for Test 時有 Automation Comment 提醒；RM 每週追蹤填寫率 |
| iOS 通知可靠性低於 Android | 中 | 中 | iOS RD 使用 Linear Issue Comment 標準模板（不靠記憶）；M3 評估 TestFlight Webhook |
| Automation 5「智慧偵測」期待落空 | 低（V2 已更正） | 中 | V2 已修正為「無條件提醒」，不依賴 Linear 讀取 Description 內容；全文件統一描述 |
| RD 防禦性承諾（為免掉車而過度保證） | 中 | 高 | Feature Freeze 前進行掉車風險掃描；心理安全聲明讓 RD 知道誠實評估優於過度承諾；掉車預演在 M2 先進行 |
| Shawn 單點監控風險 | 中 | 高 | Firebase Alert 自動推送到 Slack release-monitor；David 為備援觀察者；Shawn 缺席時 David 授權備援機制 |
| 「列車不等人」文化衝突 | 高 | 高 | String Freeze 先行（Level 3.5，低衝突）；M2 掉車預演；第一次掉車刻意選影響最小的功能；去污名化 Retrospective |
| QA 批次視窗 → RD 等待不確定感 | 中 | 中 | 明確告知 RD「批次視窗時間」；[Priority: Urgent] 插單機制確保緊急需求不受影響 |
關鍵角色與導入責任（V2 版）
| 角色 | 姓名 | V2 新增核心責任 | 主要進入時間 |
|---|---|---|---|
| 專案負責人 | David | Linear 環境建置、Hotfix P0 判定與授權（與 Ezou 任一即可）、Testing Notes 填寫率追蹤 | Month 1 起（全程） |
| RM（版本節奏守護者） | Sherridy | Feature Freeze 設定、掉車決策、Hotfix 流程協調執行（授權判定由 PO 負責）、QA 批次視窗緊急插單審批、DORA + 消費者指標回顧 | Month 1 起（全程） |
| CTO | Ezou | Hotfix P0 判定與授權（與 David 任一即可）、PR Template 修改確認、Feature Freeze 日期評估 | Month 2 起（諮詢） |
| iOS RD | Richard, Eric | GitHub 整合、iOS 標準 Comment 模板執行（取代 Slack 手動通知）、PR Template Testing Notes 確認 | Month 2 起 |
| Android RD | Tolyn, Kenneth | Android ALPHA 機制配合、Testing Notes 技術邊界補充、Hotfix 分支命名規範（hotfix/vX.X.X） | Month 2 起 |
| Server RD | Xiang, Keith, Tommy | Server 端 Deployment Frequency 指標、Testing Notes 補充 | Month 2 起 |
| Web RD | Matt | 同 Server RD | Month 2 起 |
| QA E2E | Fei Chen | QA 等待池視圖使用、批次視窗工作節奏設計、雙重讀取機制、iOS/Android 版本確認 | Month 2 起（批次視窗 M2 上線） |
| QA 自動化 | Jimmy | Integration Test 覆蓋率、批次視窗配合、反向補充 Testing Notes | Month 2 起 |
| PO + 送審 | Shawn | Testing Notes 初始填寫、Phased Release 監控、App Store Expedited Review 申請（Hotfix 時）、Phased Release 啟用確認（M1 W1） | Month 1 起（Shawn 角色） |
| PD | Tiffany, Zi | Figma 連結維護、Release Notes 審閱（M3） | Month 2-3 |
Notion / Linear 工具分工與 Hotfix 使用說明（V2 版）
正常 Release 流程的工具使用
Notion（規格 + 知識庫）
↓ PO 建立功能規格
Linear（Issue 追蹤 + 狀態管理）
↓ RD / QA 執行，狀態自動同步
GitHub（PR + Code Review）
↓ 合併觸發狀態更新
Slack（即時通知）
← Linear Automation 自動推送
Hotfix 流程的工具使用
Firebase Crashlytics Alert
↓ 自動推送到 Slack <span class="tag">release-monitor</span>
Linear（建立 Hotfix Issue + Hotfix Cycle）
↓ [Hotfix] Label，獨立 Cycle
GitHub（hotfix/vX.X.X 分支）
↓ 精簡 Review（RD Lead 即可）
App Store Connect（Expedited Review）+ Google Play
↓ 緊急上架
Firebase Crashlytics（確認 Crash rate 恢復）
↓ MTTR 計時結束
Notion（根因分析 + Retrospective 記錄）
三個月時程快覽（V2 版）
Month 1（建立基礎 + String Freeze 試水）
├── Week 1：[Hotfix] Label 設定；Phased Release 啟用狀態確認（Shawn）
├── Week 1：Android ALPHA 機制驗證（P0）
├── Week 1-2：Testing Notes Template 建立（含 PR Template 確認欄位）
├── Week 2：DORA 基線數據測量（含消費者 App 3 指標）
├── Week 2：Firebase Crashlytics Alert 設定（閾值 < 99.0%，推送到 <span class="tag">release-monitor</span>）
├── Week 3：Feature Freeze 概念宣告（向全員說明）+ 心理安全聲明
├── Week 4：第一次 String Freeze 試水（Level 3.5 起點）
└── Week 4：Hotfix SOP 初稿確認（David + Ezou + Sherridy 三人對齊）
Month 2（文化轉變 + QA 批次視窗 + 掉車 SOP 演練）
├── Week 1：QA 批次視窗機制啟動（Fei Chen + Jimmy 設定工作節奏）
├── Week 1：QA Dashboard 視圖設定（Linear Team View）
├── Week 2：第一次 Feature Freeze 設定與執行
├── Week 2：Feature Freeze 48 小時提醒機制上線（n8n 或 Calendar Alert）
├── Week 2-3：掉車預演會議（角色演練）+ 去污名化說明
├── Week 3：掉車 SOP 首次實際演練（刻意選影響最小的功能）
├── Week 4：第一次掉車 Retrospective（去污名化格式）
└── Week 4：Sprint Review — 確認保守模式退出條件（前 2 次掉車後，文化是否已接受）
Month 3（指標達標 + 完整 Feature Freeze 文化）
├── Week 1：QA / Shawn 全面接入
├── Week 1：從第 3 次掉車起，自動掉車（無需 RM + PO 逐次確認）
├── Week 2：Release Notes SOP 首次完整執行（Shawn + PD 協作）
├── Week 2：Beta 用戶群建立（MKT + Shawn 協作）
├── Week 3-4：DORA 4 個 + 消費者 App 3 個指標首次完整評估
└── Week 4：評估 TestFlight Webhook 可行性（iOS 通知自動化）
成熟度路徑一覽：
- Month 1 末：Level 3.5（String Freeze 試行，截止點文化建立）
- Month 2：Level 4（掉車 SOP 演練，DORA 雛形）
- Month 3：Level 5（完整 Feature Freeze 文化，Crash Gate 初步版本）
文件導覽（V2 版）
| 文件 | 內容 | 適合對象 |
|---|---|---|
| 00-導入計劃總覽（統整版V2） | 本文件：原則、指標、風險、角色、Hotfix 摘要 | 全體成員 |
| 01-現有流程深度分析（統整版V2） | 14 個節點深度分析（含 Hotfix 緊急通道節點） | 專案負責人 / RM / QA |
| 02-Linear功能對應分析（統整版V2） | Workflow States、Automation（含降級說明）、Hotfix SOP 完整操作、QA 批次視窗 | 專案負責人 / RD / QA |
相關文件：01-現有流程深度分析（統整版V2） | 02-Linear功能對應分析（統整版V2）
linear 導入計劃 統整版v2 Forest 消費者App DORA ReleaseTrain HotfixSOP QA批次視窗 統整初稿-v2