現況評估與下一步（統整版V2）

本文件繼承 V1 統整版的痛點評估框架（13 節點診斷、Gap 分析、文化轉變關鍵時刻），並加入三版演化後新識別的問題和更新的下一步建議。資料取得時間：2026-02-18；統整 V2 時間：2026-02-19。

Workspace 基本資訊

第一部分：問題識別框架（13 節點診斷，含 V2 解法更新）

V1 透過 Linear API 直接調閱 workspace，對照 13 個流程節點，識別出已完成與尚未完成的配置。V2 在此基礎上更新「V2 解法」欄位，反映三版演化後的技術修正和新增機制。

已完成項目（截至 V1 評估時間）

Workflow States（11 個，已設定）

V2 State 命名更新說明：V1 的 4 個「Ready for」前綴 State 在選擇器中視覺相似，容易選錯。V2 建議更名為動詞描述（Test Requested / Fix Required / Build Requested / Release Scheduled），語意更清晰，視覺區別性更高。如果評估更名溝通成本過高，可保留原名，改用顏色和分組提高區別性。

V2 新增說明：Waiting for Translation 從 State 降級為 Label 組合（QA Passed + [Needs Translation] Label），State 總數從 12 降至 11。理由：Waiting for Translation 只對有翻譯需求的功能有意義，在全體 Issue 的選擇器中出現造成噪音。

Labels（31 個，已設定）

現有 31 個 Labels，已設定的平台標籤、流程輔助標籤、人員標籤均可繼續使用。

V2 新增 Labels：

• [Hotfix]：用於 Hotfix Issue（已有或需新增）
• [Dropped]：通用掉車標籤（取代版本特定的 [Dropped from vX.X.X]）
• [Priority: Urgent]：用於 QA 批次視窗緊急插單

V2 Label 管理建議（43 個 Label 的前綴規範）：

• [Platform]：iOS / Android / Server / Web / CN
• [Status]：At Risk / Dropped / Hotfix
• [QA]：E2E / Integration / Re-test-1/2/3
• [Translation]：Needs Translation / Translation Confirmed
• [Priority]：Urgent

整合（Integrations）

尚未完成項目（6 大缺口）+ V2 解法

缺口 1：Projects（版本管理）

缺口 2：Branch-Specific GitHub Automation Rules

缺口 3：Issue Templates

缺口 4：Workflow States 缺漏

缺口 5：Automation Rules

缺口 6：成員邀請

第二部分：三版演化後新識別的問題（V2 新增）

在 V1 統整版（基於 V1/V2/V3 三版辯論）完成後，三位分析 Agent（Release Tracker Expert、Linear Expert、Industry RM Expert）識別出以下統整初稿 V1 遺漏的問題。這些問題在三版中均未被解決，是 V2 的主要差異性。

新問題一：Hotfix 缺口（最高風險）

問題描述：三個版本均未設計 Hotfix 流程。Forest App 的 Release Train 系統有完整的正常發布流程，但沒有「緊急超車道」。

風險等級：高

影響：

• 第一次發生 P0 Bug 時，必然失控——因為 Hotfix 需要打破「列車不等人」的常規，沒有設計好的超車道，每次 Hotfix 都會變成特例討論
• Hotfix 的觸發條件、授權人、執行步驟不明確，緊急時需要臨時決策，消耗 RM 的信任資本
• MTTR（平均修復時間）的計算起點不明確，無法作為 DORA 指標的基準

V2 解法：新增完整 Hotfix SOP（見 06-角色視角指南（統整版V2））

下一步：Month 1 前完成 Hotfix SOP 培訓（見第四部分優先行動 #1）

新問題二：QA 批次視窗缺口

問題描述：統整初稿 V1 採用「個別 Issue 觸發 QA」（不等 Milestone）是正確的方向，但沒有配套 QA 的工作安排機制。在純粹個別觸發模式下，Fei Chen 和 Jimmy 面臨頻繁的 context switching——每收到一個 Test Requested 通知就要切換，高峰期一天可能收到 5-8 個通知。

風險等級：中

影響：

• QA 的認知資源被過度消耗，測試品質下降
• RD 不理解「為什麼我的功能 Ready for Test 後不立刻被測試」，產生工具信任問題
• 沒有結構的 QA 工作節奏，容易在 Feature Freeze 前出現積壓

V2 解法：個別觸發進入等待池 + 批次視窗集中處理

下一步：Month 2 第一週試行（見第四部分優先行動 #2）

新問題三：成熟度路徑過陡

問題描述：統整初稿 V1 的三個月路線圖，Month 2 同時引入 Feature Freeze 設定和掉車 SOP，文化衝擊集中。三版辯論後識別到，Level 2 到 Level 5 之間有必要的文化試水期，統整初稿 V1 跳過了這個步驟。

風險等級：中

影響：

• 「截止點是真的」這個最基本的文化認知，在第一次 Feature Freeze 時才面對，可能引發強烈抵抗
• 沒有過渡期的「列車不等人」文化，第一次掉車的情緒衝擊更大
• 業界案例（Duolingo）顯示，強制截止文化在第一次執行時通常會引發文化衝突

V2 解法：Level 3.5 過渡——String Freeze 先行

設計邏輯：String Freeze 的情緒阻力最低（沒有功能被掉車），但它讓所有人習慣「有截止點且截止後不能改」，這個認知轉移到 Feature Freeze 時，衝擊會低很多。

第三部分：差距觀察更新（V2 新增觀察）

在 V1 統整版的差距分析基礎上，V2 新增以下差距觀察：

差距觀察一：Automation 5 技術限制的替代方案已落地

V1 設計意圖：Issue 進入 In Development 且 Testing Notes 為空時，加 Label + 發 Comment 提醒。

技術現實：Linear Automation 無法讀取 Description 內容，條件「Testing Notes 為空」不可判斷。

V2 替代方案（已在文件中落地）：

• Trigger：Issue 狀態改為 In Development（無條件，不判斷 Description）
• Action：發 Comment 提醒（「請確認 Testing Notes 是否已填寫，若已填寫請忽略此提醒」）
• 補充措施：PR Template 加入 Testing Notes 確認欄位（RD 在 PR Review 這個唯一工具強制節點插入確認）
• 手動追蹤：RM 在 Weekly Review 時人工抽查 5 個 Issue，標注未填寫的 Issue

誠實評估：Testing Notes 機制依賴人工紀律，不是工具強制。文件中所有提到「Automation 5 智慧偵測」的描述，已更新為「無條件提醒」。

差距觀察二：Feature Freeze 提醒需要外部工具補充（已規劃 Calendar 方案）

V1 設計意圖：距 Feature Freeze Milestone 日期 ≤ 2 天時，Linear Automation 觸發 Slack 警告。

技術現實：Linear Automation 沒有「距 Milestone 日期 N 天」的 Trigger，技術上不可行。

V2 已規劃的方案：

目前採用：方案 B（Calendar 提醒）作為過渡，已在06-角色視角指南（統整版V2）的 RM 操作中說明。

差距觀察三：iOS 通知可靠性仍是中期挑戰

現況：Android 有自動版本號通知（CI 生成 -ALPHA 後自動 Slack 通知），iOS 目前依賴 RD 手動在 Issue Comment 和 Slack 發送確認。

風險：手動通知依賴記憶，RD 在高壓期間容易遺漏。V1 將此標注為「Month 2 需要統一的地方」，但沒有具體方案。

V2 設計：

• 短期（Month 1-2）：iOS RD 使用標準 Comment 模板（見06-角色視角指南（統整版V2）），降低遺漏可能性
• 中期（Month 3 評估）：若 iOS 有 Fastlane 或 GitHub Actions，CI 完成後發 Webhook → Linear 狀態更新，達到 Android 同等自動化；若手動上傳，考慮 API 輪詢方案
• 長期目標：iOS 和 Android 的通知可靠性達到同等水準

第四部分：Month 1 完成度評估（V2 更新）

Month 1 整體完成度：約 50%（基礎設施就緒，關鍵機制待建）

V2 對此評估的補充：50% 的完成度反映的是配置層面，但關鍵性缺口（Hotfix SOP、QA 批次視窗、String Freeze）是 V2 識別的新增項目。這些新增項目的存在，讓「加速進入 Month 2」的建議需要同時附帶「先完成 Hotfix SOP 設計」這個前提條件。

第五部分：文化轉變關鍵時刻（V2 更新）

關鍵時刻一：第一次 String Freeze（Month 1 末）

為什麼重要：Forest App 目前沒有任何「截止點」的文化。String Freeze 是第一個有明確截止點且不可輕易延展的機制。它的情緒阻力低（沒有功能被延誤或掉車），但它建立的文化認知是 Feature Freeze 的前提。

成功的標誌：String Freeze 後確實沒有文字被改動（或只有有充分理由的緊急申請被批准），MKT 在截止日期後開始翻譯，翻譯完成時版本 UI 文字與翻譯一致。

失敗的信號：String Freeze 後仍有人在沒有申請的情況下修改 UI 文字。如果發生，這是「截止點不是真的」的文化訊號，需要在下個版本更嚴格地執行。

關鍵時刻二：第一次掉車（Month 2）

為什麼重要：第一次掉車是文化轉換的關鍵考驗。設計上應該是被刻意選擇的——選一個影響最小的功能，走完完整的掉車 SOP，包括去污名化聲明和 Retrospective 議程。

成功的標誌：掉車後版本準時發出，掉車功能在下一班順利完成，RD 感覺掉車是正常操作而非失敗。

RM 的心理設計：第一次掉車時，RM 的第一個動作是私訊 RD（不是在公開 Channel 宣布），讓 RD 有心理準備。去污名化聲明在 forest-release 公開，但語氣是「決策說明」而非「失敗公告」。

V2 設計的退出保守模式條件：

• 前 2 次掉車：RM + PO 確認（保守模式，逐次確認）
• 第 3 次起：自動掉車，事後通知（接近 Duolingo 模式）
• 退出確認時間點：Month 2 的 Sprint Review 中，確認前 2 次執行後文化是否接受

關鍵時刻三：第一次 Hotfix（任何時間可能發生）

為什麼重要：Hotfix 是最難預測的緊急情況。前兩個關鍵時刻可以計劃，但 Hotfix 可能在 Month 1 就發生。

準備工作（Month 1 前）：

• David + Sherridy + Shawn 走一遍 Hotfix SOP 的流程確認
• 確認 release-hotfix Slack Channel 已建立，Alert 通知對象已設定
• 確認 Firebase Crashlytics Alert 設定完成（閾值 98.5%）
• Shawn 確認 App Store Expedited Review 申請方式已知悉

成功的標誌：第一次 Hotfix 啟動後，在 release-hotfix 有清楚的流程推進，所有角色知道自己的下一個動作，MTTR 被記錄。

V2 特別說明：Hotfix 使用頻率本身是個指標。月超過 2 次 Hotfix，是測試流程需要改善的信號，而非調整 Hotfix SOP 的理由。Hotfix 是安全閥，不是常規通道。

第六部分：下一步行動（執行路線，V2 更新版）

優先行動 #1：Hotfix SOP 培訓（Month 1 前必須完成）

執行步驟：

Step 1：David + Sherridy + Shawn 走一遍 Hotfix SOP 確認（1 小時）
  確認項目：
  □ 觸發條件清楚（特別是 Crash-free rate 閾值：98.5%）
  □ <span class="tag">release-hotfix</span> Slack Channel 已建立
  □ Firebase Crashlytics Alert 設定（閾值、通知對象）已完成
  □ Shawn 確認 App Store Expedited Review 申請方式

Step 2：RD Lead（Ezou）確認 PR Template Testing Notes 欄位設計可行性
  確認 PR Template 修改不影響現有 PR 流程

Step 3：在 Linear 確認 [Hotfix] Label 已存在或新增

Step 4：在 Slack 建立 <span class="tag">release-hotfix</span> Channel（如尚未建立）

完成定義：
  ✅ 所有核心成員（Sherridy、David、Shawn、Ezou）確認了解 Hotfix SOP
  ✅ Firebase Alert 已設定
  ✅ Hotfix Issue 模板或 Label 已就緒

負責人：Sherridy（主導）+ David（授權） 目標時間：Month 1（v5.0.0 上線前完成，不等 Month 3）

優先行動 #2：QA 批次視窗試行（Month 2 第一週）

執行步驟：

Step 1：Fei Chen 和 Jimmy 建立 Linear QA 待測 Queue 視圖
  操作：Linear → Team → Views → Add View
  Filter：Status = Test Requested，Assignee = Fei Chen / Jimmy

Step 2：Fei Chen + Jimmy 確定每週 2 個批次視窗時段
  建議：週二 PM + 週四 PM（14:00-18:00）
  調整原則：依實際工作節奏，不硬性規定

Step 3：向 RD 說明批次視窗機制
  重點說明：「功能 Test Requested 後為什麼不立刻被測試」
  （保護 QA 的認知資源，是質量保護，不是拖延）

Step 4：試行 2 週後在 Sprint Review 評估
  評估問題：
    批次視窗的工作量是否合理？
    是否有 Issue 在批次視窗間等待太久？
    RD 對等待時間的接受度如何？

完成定義：
  ✅ QA Queue 視圖已建立
  ✅ 兩個固定批次時段已確認
  ✅ 完成 2 次批次視窗試行

負責人：Fei Chen + Jimmy（執行）+ Sherridy（溝通 RD） 目標時間：Month 2 Week 1 開始試行

優先行動 #3：String Freeze 第一次試行（Month 1 末）

執行步驟：

Step 1：Sherridy 在 Linear 建立 String Freeze Milestone
  日期：Feature Freeze 前 5-7 天
  說明：String Freeze 規則（文字截止，緊急申請流程）

Step 2：Sherridy 在 <span class="tag">forest-release</span> 發全團隊通知
  通知對象：PO、設計師、RD、MKT

Step 3：Shawn 確認所有 v5.0.0 Issue 的 UI 文字已定稿
  完成後在 <span class="tag">forest-release</span> 回覆確認

Step 4：String Freeze 後追蹤是否有例外申請
  批准原則：只批准功能正確性問題，不批准「文字更好看」

Step 5：在 v5.0.0 Retrospective 中記錄 String Freeze 執行情況
  記錄：「String Freeze 執行情況：有/無例外申請，
         文化觀察：截止點被接受了嗎？」

完成定義：
  ✅ String Freeze Milestone 已建立
  ✅ 全團隊通知已發布
  ✅ Freeze 後無未批准的文字修改（或例外申請有記錄）

負責人：Sherridy（執行）+ Shawn（文字確認） 目標時間：Month 1 末（v5.0.0 版本的最後 2 週開始）

優先行動 #4：PR Template 加入 Testing Notes 確認欄位（Month 1 第 2 週）

執行步驟：

Step 1：Ezou 確認 PR Template 修改可行性
  確認：團隊使用的 GitHub PR Template 位置和修改流程

Step 2：Ezou 修改 PR Template，加入：
  ## Testing Notes 確認
  - [ ] Y / N / 無更新（已更新 Linear Issue 的技術邊界說明）

  ## Impact Scope
  - 本 PR 影響範圍：[簡述]
  - 是否影響現有已通過測試的功能？Y / N
    若是，建議 QA 回歸測試的範圍：[說明]

Step 3：David 在 <span class="tag">forest-dev</span> 說明 PR Template 變更
  重點：Testing Notes 確認欄位的填寫說明和目的

Step 4：在 Month 2 的 Sprint Review 檢視 Testing Notes 填寫率
  方式：RM 抽查 10 個已完成 Issue 的 Testing Notes 狀態

完成定義：
  ✅ PR Template 已更新
  ✅ 所有 RD 確認了解填寫說明
  ✅ Month 2 Sprint Review 確認填寫率 > 70%（試行目標）

負責人：Ezou（技術執行）+ Sherridy（過程追蹤） 目標時間：Month 1 Week 2

立即執行（本週內）— 繼承 V1

P0 — 邀請團隊成員加入

Settings → Members → Invite
邀請：Sherridy、Keith、Ezou、Fei Chen、Jimmy、Shawn
目標：本週五前完成

P0 — 設定 Branch-Specific GitHub Automation

Branch: staging/ios-*  → State: Test Requested
Branch: staging/android-* → State: Test Requested
Branch: main/*         → State: Release
執行驗收測試：測試 PR → 確認 Issue 狀態自動改變（必須通過才繼續後續設定）

P0 — 建立 Issue Template（含 Testing Notes 欄位）

1. 功能規劃 Template（含 Testing Notes 欄位與三方確認說明；Acceptance Criteria 欄位已移除，改以 Issue Description 說明功能定義）
2. QA 測項 Template（Sub-issue 用）
3. Bug 回報 Template

P0 — Feature Freeze 概念宣告

David 在 <span class="tag">forest-release</span> Slack 發布 Feature Freeze 說明訊息
重點：解釋「列車不等人」文化，並預告 String Freeze 試行
目標：本週三前完成

P0 — Phased Release 啟用確認（V2 新增）

Shawn 確認：
  □ iOS App Store Phased Release 是否已啟用？（App Store Connect 確認）
  □ Android Google Play Staged Rollout 是否已啟用？（Google Play Console 確認）
在 Linear 對應設定 Issue 中記錄確認結果
如未啟用，在 Month 1 Week 2 前完成設定

本月完成（Month 2）

P0 — QA 批次視窗機制啟動（見優先行動 #2）

P0 — 掉車 SOP 第一次演練

David + Sherridy 選擇一個適合的功能走掉車 SOP
  選擇標準：非核心功能、非承諾給用戶、非緊急
整個過程記錄在 Linear Cycle Description
在 <span class="tag">forest-release</span> 發布「第一次掉車記錄」公告（去污名化格式）
Sprint Review 確認掉車文化接受度

P0 — Automation Rules 建立

基礎 5 條 + V2 修正：
1. Issue → Test Requested → Slack 通知 QA + Testing Notes 讀取提醒
2. Issue → Fix Required → Slack 通知 RD + RM
3. Issue → Build Requested → Slack 通知 RD
4. Issue 加入 Project → Slack 通知 QA
5. Issue → Released → 自動記錄時間戳
6. Issue → In Development → 無條件 Testing Notes 提醒（Automation 5 降級版本）

P1 — Feature Freeze 前 2 天提醒機制上線

若 n8n 已有運作：配置 Cron Job（方案 A）
若 n8n 尚未導入：確認 RM 在 Milestone 建立時同步設定 Calendar 提醒（方案 B）

P2 — Labels 策略清理

與 RM 討論，移除重複的 QA Status 類型 Labels
（這些已由 Workflow State 承載，不需要用 Label 複製）

下個月完成（Month 3）

掉車退出保守模式確認

Month 2 Sprint Review 中，確認：
  前 2 次掉車執行後，文化是否已接受？
  是否可以進入第 3 次起自動執行？
David 主持確認，記錄在 Cycle Description

Release Notes SOP 首次完整執行

責任人：Shawn（技術摘要）+ PD（用戶語氣審閱）
時機：Feature Freeze 後開始撰寫（不是送審前才寫）
格式：按功能分類（新功能 / Bug 修復 / 改善），語氣對用戶友好
Linear 整合：Release Notes 草稿存在 Milestone Description

工具遷移評估

評估三個問題：
  1. PO 是否已習慣在 Linear 建 Feature Issue？
  2. RM 是否已習慣用 Linear Project 管理版本？
  3. Release Tracker Notion 表格是否還在被主動維護？

建議路線（V2）：
  Linear 負責 Issue + Release 流程追蹤
  Notion 負責文件、知識庫、設計文件
  兩者功能不重疊，不需要選一個消滅另一個

第一次完整「列車準時發車」

成功定義（V2 版本）：
  ✅ Feature Freeze 日期按時執行
  ✅ 至少有 1 個 Issue 掉車，掉車決定在 Freeze 前完成
  ✅ String Freeze 已執行（版本 UI 文字與翻譯一致）
  ✅ 版本在預定日期提交 App Store / Google Play
  ✅ Crash Rate 在 Phased Release 期間正常（未觸發 Hotfix）
  ✅ QA 批次視窗機制已正常運作（無積壓）
  ✅ 掉車的功能順利進入下一班

第七部分：DORA + 消費者 App 指標總覽（V2 更新）

DORA 四大指標

消費者 App 特有指標（V2 版本）

時間軸視覺化（V2 更新版）

Week:   1    2    3    4    5    6    7    8    9   10   11   12
        |────|────|────|────|────|────|────|────|────|────|────|
Month 1: ████████████████████████
          ↑    ↑         ↑         ↑
       邀請  PR         Hotfix   String
       成員  Template   SOP      Freeze
       Branch Firebase  培訓     試水
       Auto  Alert             （Level 3.5）
       設定  設定

Month 2:               ████████████████████████
                         ↑         ↑         ↑
                    QA 批次      掉車SOP   保守模式
                    視窗啟動     第一次     退出評估
                    Feature      演練      Sprint
                    Freeze                 Review
                    提醒上線

Month 3:                              ████████████████████████
                                       ↑         ↑         ↑
                                   Release    工具遷移  列車準時
                                   Notes      評估     發車
                                   SOP        掉車自動
                                              化確認

設計決策記錄（V2 版本）

決策 1：Hotfix SOP 是 V2 的最高優先新增項目

三個版本均未設計 Hotfix 流程。V2 識別這是最大的未識別風險——沒有 Hotfix SOP 的 Release Train，在第一次真實緊急情況下必然失控。Hotfix SOP 不是可選項，是 Release Train 文化的必要安全閥。

決策 2：Testing Notes「雙向強制」改稱「三方確認機制」

工具現實的誠實描述：Linear 沒辦法強制 QA 在讀 Testing Notes 之前才能改 Issue 狀態，也沒辦法阻止 RD 在 Testing Notes 空白時就合併 PR。所有 V2 文件中「雙向強制」一律改為「三方確認機制（PO 初始填寫 + RD 開發中補充 + QA 雙重讀取），機制靠人工紀律支撐」。

決策 3：掉車退出保守模式條件明確化

V1 的「第 3-5 次後評估自動化」是模糊的。V2 明確：前 2 次保守模式（RM + PO 確認），第 3 次起自動執行，退出確認在 Month 2 Sprint Review。「評估」改為有明確時間點和確認人的「確認」。

決策 4：Dropped Label 從版本特定改為通用

[Dropped from v5.8.0] 等版本特定 Label 長期會累積大量只用一次的 Label。V2 改為通用 [Dropped] Label + Issue Comment 記錄版本號（「掉車自 v5.8.0，預計列入 v5.8.1」）。Label 管理的可持續性是設計原則之一。

決策 5：State 精簡——Waiting for Translation 改為 Label

Waiting for Translation 只對有翻譯需求的功能有意義，在全體 Issue 的 State 選擇器中出現造成噪音。V2 改為 Label 組合（QA Passed + [Needs Translation] Label），Automation 8/9 的觸發邏輯對應調整。State 總數從 12 降至 11。

相關文件：06-角色視角指南（統整版V2） | 07-功能案例走查（統整版V2） | 03-三個月導入路線圖（統整版V2）

linear 導入計劃 現況評估 Forest release-management 統整版-v2 Hotfix QA批次視窗 StringFreeze 三方確認