團隊導入策略（統整版V2）

工具導入的失敗，90% 是人的問題，不是工具的問題。本文件聚焦在「如何讓 Forest 團隊自然地接受 Linear」，以及如何建立配套的成熟度文化——從 String Freeze（低衝突試水）到掉車 SOP（中等衝突）到完整 Feature Freeze（高衝突），並在緊急情況下有 Hotfix 的有序應對。

V2 與 V1 的最大差異在於：新增三個設計精細的文化機制（去污名化 Workshop、QA 批次視窗、Hotfix 文化），以及「三方確認機制」取代「雙向強制」的誠實命名。

相關文件：03-三個月導入路線圖（統整版V2） | 04-環境建置指南（統整版V2）

導入哲學

核心理念：展示價值，而非強迫遵從

「如果 Linear 真的更好，讓人們自己發現它更好。如果需要強迫，那是工具沒有設定好，不是人的問題。」

統整版 V2 導入策略基於三個前提：

1. 先解決現有痛點：每一個 Linear 功能的引入，都要對應一個現有痛點的解決
2. 不增加工作量：特別是過渡期，不讓任何人的工作量因為「雙寫」而增加超過 30 分鐘/天
3. 失敗安全：每個導入步驟都可以獨立回退，不影響整體流程

成熟度路徑（V2 版，含 Level 3.5）

三個月導入期採用分層衝擊設計，每個月有一個主要的文化升級點：

為什麼分層衝擊很重要

V1 在 Month 2 同時引入 Feature Freeze 設定和掉車 SOP 演練，文化衝擊過度集中。當一個文化同時面臨「截止點存在」和「功能要掉車」兩個新概念，往往導致其中一個概念被虛設化（RM 在壓力下放棄其中一個）。

V2 的分層設計讓每個月只有一個主要的文化升級挑戰：

• Month 1 末的 String Freeze 只影響文字，幾乎不涉及情緒衝突，但建立了「截止點存在且嚴肅對待」的基礎
• Month 2 的掉車 SOP 在 String Freeze 文化已建立的基礎上推進，衝擊已有緩衝
• Month 3 的 Hotfix SOP 是例外通道的建立，讓 Release Train 在緊急時也能有序運作

文化轉變五關鍵時刻（V2 版）

V1 有三個關鍵時刻。V2 新增兩個：第一次 String Freeze 和第一次 Hotfix。

關鍵時刻 1：第一次 String Freeze（Level 3.5 首次試水）

為什麼關鍵：String Freeze 是整個 Release Train 文化的「最低成本試水」。它讓全員在幾乎沒有代價的情況下，體驗「有截止點且截止點不可以任意延伸」。第一次 String Freeze 執行的品質，決定了後續 Feature Freeze 的文化基礎。

String Freeze 的違反成本說明（讓全員理解為什麼這個截止點是認真的）：

• 對 MKT：String Freeze 後文字修改意味著翻譯工作需要重做，直接增加 MKT 的工作量和版本風險
• 對用戶：翻譯品質下降（因時間不足）直接影響非中文用戶的 App 體驗
• 對文化：如果第一次 String Freeze 沒有被嚴肅對待，它就會變成「可以協商的日期」，而不是「截止點」

如何讓第一次 String Freeze 是「認真的」：

RM 的行動清單：
  1. 公開設定 Milestone 日期（在 Linear 和 Slack 都可見）
  2. 截止日前確認 MKT 是否有任何文案未確認
  3. 如有 Exception 申請：必須走正式申請流程，不接受 Slack 訊息通知
  4. 截止日當天：在 <span class="tag">forest-release</span> 確認「String Freeze 已生效」
  5. 任何違反（即使是小改動）：要求走 Exception 申請並在 Issue Comment 記錄

如果有人說「只是改一個字，可以嗎？」：
  RM 的回應腳本：
  「我理解這看起來是小改動，但 String Freeze 的意義在於
   MKT 的翻譯工作已基於這個版本的文字開始進行。
   即使是一個字的修改，也需要翻譯確認才能保持一致性。
   請提交 Exception 申請，說明修改原因和緊急程度，
   我來決定是否適合做 Exception。」

第一次 String Freeze 後的處理：在當週的週會中，Sherridy 說明「這次 String Freeze 的執行情況」——不管是完全沒有 Exception，還是有幾個 Exception 申請，都要說明。讓全員知道 String Freeze 不是空文，而是真實執行的機制。

關鍵時刻 2：第一次掉車

為什麼關鍵：Feature Freeze 的文化現實落地試金石。細節設計見原版（V1 繼承）。

V2 新增：掉車決定的自動化確認路徑：

第 1-2 次掉車：保守模式（RM + PO 確認）
  Sherridy 必須在 Issue Comment 記錄決策過程
  並在 <span class="tag">forest-release</span> 發心理安全公告

第 3 次起：自動掉車（Duolingo 模式）
  RM 識別 → 執行 → 事後通知（不再需要每次 PO 確認）
  退出保守模式的確認：Month 2 Sprint Review 中，David 確認文化已接受

如果第 1-2 次掉車後文化仍未接受（在 Sprint Review 中判斷）：
  延長保守模式 1-2 次，Month 3 Week 2 重新評估

第一次掉車後的公告格式（V1 繼承，V2 精確化掉車 Label）：

v5.x.x Feature Freeze 執行：

[功能名稱] 移至 v5.x+1.x
原因：在 Freeze 截止前未完成開發，為保護版本品質與測試時間。
下一班版本：v5.x+1.x（預計 [日期]）
版本發布計劃不變，感謝大家的理解。

這是 Forest App 第一次嚴格執行 Feature Freeze，
列車準時出發是給所有準時完成的人的尊重。

注意：掉車 Issue 加上 [Dropped] 通用 Label（V2 修正），不建版本特定 Label。在 Issue Comment 中記錄版本資訊：「掉車自 v5.x.x，預計列入 v5.x+1.x」。

關鍵時刻 3：第一次拒絕填 Testing Notes

為什麼關鍵：測試文化的邊界試探（V1 繼承）。

V2 更新：三方確認機制說明：

V1 稱「雙向強制（PO + QA）」，V2 改為「三方確認機制（PO + RD + QA）」。

這個更名反映了兩個現實：

1. 工具層面無法強制（Linear 不能阻擋狀態轉換）
2. 機制包含三方（PO 初始填寫 + RD 開發中補充 + QA 雙重讀取），V1 版本遺漏了 RD 這個最脆弱的環節

三方確認機制的三個環節：
  PO（Planning 時）：填寫「重點觀測項目」初始版本
  RD（In Development 時）：補充「技術邊界」和「平台差異」
  QA（展測項 + Testing 時）：雙重讀取並確認 Testing Notes 已更新

最脆弱的環節：RD 補充這一步
  工具支撐：PR Template 確認欄位（「已更新 Linear Issue 的測試注意事項：Y/N/無更新」）
  Automation 支撐：Automation 5 無條件提醒（Issue 進入 In Development 時觸發）
  人工紀律：RM 在 Weekly Review 時手動標注 [Testing-Notes-Missing] Label

關鍵時刻 4：第一次 Crash Alert（V1 繼承）

為什麼關鍵：Crash Rate 監控文化的首次實戰（V1 設計繼承，MTTR 計算起點說明同 V1）。

V2 新增：如果第一次 Crash Alert 觸發了 Hotfix SOP：

第一次 Crash Alert 可能觸發兩種場景：

場景 A：Crash Rate 異常但未達 Hotfix 觸發條件
  → 走正常監控流程（Shawn 確認 + Linear Comment 記錄）
  → 繼續觀察，可能無需 Hotfix

場景 B：Crash Rate 異常且達到 Hotfix 觸發條件（< 98.5%）
  → 啟動 Hotfix SOP
  → MTTR 從 Firebase Alert 時間戳開始計算
  → 走完整 5 步驟 Hotfix 流程（見 [03-三個月導入路線圖（統整版V2）](/linear-roadmap)）

第一次 Hotfix 的處理：
  在 Month 3 Sprint Retrospective 中討論 Hotfix 根因
  記錄根因 + 預防措施（納入測試覆蓋範圍）
  判斷是否需要調整測試流程（不是調整 Hotfix SOP）

關鍵時刻 5：第一次 Hotfix（緊急應對第一次實戰）

為什麼關鍵：Hotfix 是 Release Train 的「緊急超車道」。第一次真實 Hotfix 是整個緊急應對系統的壓力測試——每個人知不知道自己在 Hotfix 情境下要做什麼，決定了 Hotfix SOP 有沒有真正運作。

設計原則：

• 第一次 Hotfix 不管問題大小，都要完整走 SOP 的 5 個步驟
• 每個步驟都要有 Linear 記錄（特別是 MTTR 計時）
• Hotfix 完成後，在下次 Sprint Retrospective 中討論：「這次 Hotfix 的 SOP 執行是否順暢？」

如果 Month 3 以前發生緊急情況（Hotfix SOP 尚未培訓）：

臨時應對方案（Month 1-2 期間）：
  1. 在 <span class="tag">release-hotfix</span> 發通知（Channel 和 Label 在 Month 1 已建立）
  2. 照 [04-環境建置指南（統整版V2）](/linear-setup-guide) Step 15 描述的 5 步驟執行
  3. PO（David 或 Ezou，兩人其一即可）判定 P0 Bug 並授權，RM 協調執行
  4. 事後在 Month 3 Hotfix SOP 培訓時回顧此次經驗

注意：緊急情況不等 SOP 培訓完成，用已有的 5 步驟執行。
培訓的目的是讓全員熟悉 SOP，不是讓 SOP 等培訓完成才能用。

去污名化 Workshop 設計（V2 新增）

時機：Month 2 Week 1，第一次真實掉車之前

形式：60 分鐘 Workshop（建議結合 Planning 會議進行，避免佔用額外時間）

參與者：David（主持）+ Sherridy + Ezou（RD Lead）+ 所有 RD + Fei Chen

設計目的：讓所有人在真實掉車之前，已經在安全的環境中體驗過掉車的決策流程——理解對方的壓力，知道自己的角色，並聽到 RM 的公開承諾。

完整 60 分鐘議程

[0-10 分鐘] 角色互換演練——理解對方的壓力點

  形式：RM（Sherridy）扮演 RD，RD（Ezou）扮演 RM

  劇本（David 旁白）：
    「v5.x.x 的 Feature Freeze 在 3 天後。
     FOR-XXX（翻譯功能更新）仍在 In Development。
     RD 評估在 Freeze 前完成的可能性：低。」

  演練對話：
    「RD」（Sherridy 扮演）：「我只差 2 天了，可以等我嗎？」
    「RM」（Ezou 扮演）：「這個版本已有 4 個功能準時完成了 QA，
                          如果等你，他們的測試時間就被壓縮。
                          我需要做一個決定。」

  討論（5 分鐘）：
    「扮演對方角色時，你感受到了什麼壓力？」
    讓所有人說出來，不評判

[10-30 分鐘] 掉車情境完整模擬

  從 SOP 的第 1 步走到第 5 步，讓所有人知道自己的動作：

  Step 1：David 展示 Feature Freeze 前 3 天的 Linear 查詢結果
          「現在是 Freeze 前 3 天，In Development 的 Issue 有：FOR-XXX」

  Step 2：Sherridy 模擬詢問 Ezou：「FOR-XXX 能在 Freeze 前完成嗎？」
          Ezou 模擬回答並在 Issue Comment 記錄

  Step 3：Sherridy 宣布掉車決定 + 在 Comment 記錄
          David 模擬在 Linear 執行 Issue 移動 + 加 [Dropped] Label

  Step 4：Sherridy 念出 <span class="tag">forest-release</span> 公告（心理安全聲明）

  Step 5：David 說明掉車後的回顧議程

  全員確認：「我知道在這個流程中我要做什麼」

[30-40 分鐘] 心理安全宣言

  Sherridy 公開承諾（在 Slack <span class="tag">forest-release</span> 同步記錄）：

  「從今天起，我承諾：
   1. 掉車不計入個人績效，只計入版本學習
   2. 第一次掉車的原因永遠是流程問題，不是個人問題
   3. 掉車後被掉車 RD 的下一班時程會在 24 小時內確認
   4. 如果掉車決定讓你感到委屈，你可以直接找我討論
   5. 每次掉車都會有公開的說明，不只是發結果

   我希望從今天開始，掉車不是一件讓人緊張的事，
   而是一個正常的流程決定。」

  David 補充：「這份承諾是記錄在案的。如果我們沒有做到，
              可以在 Retrospective 中提出來。」

[40-60 分鐘] 掉車記錄格式預覽 + Q&A

  讓所有人看到「掉車記錄長什麼樣」：
    - Linear Issue Comment 的記錄格式
    - [Dropped] Label + Comment 格式（「掉車自 vX.X.X，預計列入 vX.X+1.X」）
    - Slack 公告的格式
    - 掉車功能在下一班 Project 中的狀態（轉移，不是消失）

  Q&A（David 記錄所有顧慮，承諾在 Freeze 前回應）：
    「我們這個月的第一次 Feature Freeze，大家有什麼顧慮？」
    收集的顧慮會在 Freeze 前回應，不是放著不管

去污名化 Workshop 的設計邏輯

去污名化（Destigmatization）的核心是「讓人在安全環境中預先體驗」。

心理研究顯示，當人第一次遇到一個有負面情緒風險的情境時，如果沒有預先準備，往往會採取防禦反應（否認問題、保護自我）。Workshop 的作用是讓這個「第一次」發生在安全的演練環境中，而不是在高壓的真實情境中。

當 Workshop 完成後，真實掉車發生時，所有人都已經走過了這個情境，已經知道：

1. 這個流程是什麼樣的
2. 自己的角色是什麼
3. RM 的態度是什麼
4. 掉車後會怎樣

QA 批次視窗文化建立（V2 新增）

為什麼需要批次視窗機制

個別 Issue 觸發（Issue 完成 → 立即通知 QA）是正確的設計——它確保 QA 不需要等整個 Milestone 完成才開始測試，縮短了每個 Issue 的 Lead Time。

但純粹的個別觸發模式下，QA 面臨的挑戰是：每收到一個 Ready for Test 通知，都需要停下手上的工作，評估要不要立刻開始測這個新 Issue。這個高頻 context switching 是 Fei Chen 和 Jimmy 的隱性成本——不是工作量增加，而是認知資源耗盡。

批次視窗機制的設計原則：保護 QA 的認知資源，而非限制工作彈性。

批次視窗設計

固定批次視窗（建議，可依實際節奏調整）：
  週二 PM 14:00-18:00
  週四 PM 14:00-18:00

批次視窗機制的運作邏輯：
  1. Issue 完成 → 自動通知（Automation 1/2/3 繼續運作）
  2. Issue 進入 QA 待測 Queue（Linear 視圖）
  3. 批次視窗開始 → Fei Chen/Jimmy 打開 Queue → 按優先順序處理
  4. 批次視窗結束 → Queue 剩餘 Issue 等待下個視窗

例外處理（QA 可以在批次視窗外立即測試的條件）：
  - Issue 有 [Priority: Urgent] Label（需 RM 手動加）
  - 接近 Feature Freeze 的 Issue（RM 評估後加 Urgent Label）
  - Hotfix 相關 Issue（Hotfix SOP 啟動時，QA 立即切換）

如何向 RD 建立正確期待（培訓素材）

RD 的常見困惑：「我的功能 Ready for Test 了，為什麼 QA 沒有立刻開始測？」

培訓說明：

「QA 使用批次視窗機制來保護他們的工作節奏和認知資源。當你的 Issue 變成 Ready for Test，它會立刻進入 QA 的待測 Queue（可以在 Linear 看到）。QA 會在下個批次視窗（週二或週四下午）開始測試，不是忘記了你的功能。

這個設計對你有什麼好處？當 QA 在批次視窗中專注測試你的功能時，他們的認知資源是充足的，而不是在多個功能之間頻繁切換後的疲憊狀態。測試品質更好。

如果你的 Issue 接近 Feature Freeze 或有特殊緊急需求，請通知 Sherridy，她可以加上 Urgent Label 讓 QA 插隊優先處理。」

QA 批次視窗的工作節奏設計

批次視窗開始（Fei Chen 或 Jimmy）：
  1. 打開「QA 待測 Queue」Linear 視圖
  2. 掃描 Queue 中的 Issue 清單和優先順序
  3. 確認是否有 [Priority: Urgent] 的 Issue（優先處理）
  4. 按優先順序開始測試

測試中的工作方式：
  - 每個 Issue 測試完成後，更新 Issue 狀態（QA Passed 或 Ready for Fix）
  - Bug 記錄在 Issue Comment（不散落 Slack Thread）
  - 回測計數格式：「[回測 N] [問題描述]」（統一格式，方便統計）
  - 如果發現 Testing Notes 有遺漏：在 Issue Comment 補充
    「[Jimmy/Fei Chen 補充] Integration Test 發現：[描述]」

批次視窗結束：
  - 在 <span class="tag">forest-release</span> 簡短說明本次批次的測試進度
    「本次批次視窗完成 N 個 Issue 測試，剩餘 M 個在 Queue 中待下次處理」
  - 如有 Issue 需要 RD 立即確認，在 Slack 通知對應 RD

如果 QA 待測 Queue 積壓過多

積壓的觸發條件：待測 Queue 超過 10 個 Issue，且距離 Feature Freeze 不到 5 天。

積壓應對流程：
  1. Fei Chen / Jimmy 通知 Sherridy：「Queue 積壓 N 個，Freeze 在 X 天後」
  2. Sherridy 評估：
     - 是否需要增加批次頻率（暫時每天都有批次視窗）？
     - 是否有 Issue 可以掉車，減少 QA 壓力？
     - 是否需要加急某些 Issue（Urgent Label）？
  3. 記錄評估結果在 <span class="tag">forest-release</span>
  4. 下次 Sprint Retrospective 討論：積壓的根因是什麼？
     （通常是 RD 開發完成時間集中在 Freeze 前幾天）

Hotfix 文化設計（V2 新增）

Hotfix 的文化定位

Hotfix 是 Release Train 的「緊急超車道」。它的存在是讓 Release Train 文化在緊急情況下仍能有序運作，而不是因為一次緊急事件就讓整個「列車不等人」的文化崩潰。

最重要的文化認知：Hotfix 是例外通道，不是常規流程。

Hotfix 使用頻率的健康指標：
  健康：每季 0-1 次（系統穩定，測試覆蓋充足）
  可接受：每月 1 次（偶爾的緊急問題）
  需要關注：每月 2+ 次（測試流程有系統性問題）

當 Hotfix 頻率高時，正確的應對是：
  改善測試流程（增加回歸測試覆蓋、改善 Testing Notes 填寫率）
  而不是：讓 Hotfix SOP 更快、更容易觸發

Hotfix 情境下的角色分工

Hotfix 的「緊急切換」文化設計

Release Train 的正常節奏需要穩定的工作環境。當 Hotfix 發生時，全員需要在「正常列車模式」和「緊急應對模式」之間切換。這個切換需要有清晰的信號。

進入緊急模式的信號：
  在 <span class="tag">release-hotfix</span> 發布「Hotfix 啟動」通知（Automation 13 自動觸發）
  通知格式：「🚨 Hotfix 啟動：[觸發條件] | [版本號] | MTTR 計時開始：[時間戳]」

進入緊急模式後的行為期望：
  所有人確認 <span class="tag">release-hotfix</span> 的訊息
  相關人員（RD、QA、Shawn）立即回應，確認自己的角色
  正在進行的 Cycle 任務暫時停下，Hotfix 優先

回歸正常模式的信號：
  在 <span class="tag">release-hotfix</span> 發布「Hotfix 發版完成」通知
  MTTR 時間戳記錄
  恢復正常 Cycle 進度

Hotfix 後的 Retrospective 設計

每次 Hotfix 完成後，在下次 Sprint Retrospective 中加入 15 分鐘的 Hotfix 回顧：

Hotfix 回顧議程（15 分鐘）：
  1. MTTR 報告（5 分鐘）：
     - 這次 Hotfix 的 MTTR 是多少？
     - 哪個步驟最耗時？

  2. 根因分析（5 分鐘）：
     - 這個問題為什麼沒有在測試中發現？
     - 是 Testing Notes 沒有覆蓋到這個 Edge Case？
     - 還是 QA 沒有時間測試這個場景？

  3. 預防措施（5 分鐘）：
     - 下次版本如何避免類似問題？
     - 是否需要增加回歸測試覆蓋範圍？
     - 是否需要調整 Testing Notes 模板？

記錄：將根因分析和預防措施記錄在 Hotfix Issue Comment 中
目標：每次 Hotfix 都讓測試覆蓋更好，而不只是修復問題

全體成員名單與角色定位（V2 版）

角色導入策略（V2 版）

David（專案負責人）

V2 新增職責：

職責 5：Hotfix 協調與 MTTR 記錄（V2 新增）

Hotfix 啟動時（收到 <span class="tag">release-hotfix</span> 通知後）：
  1. 確認觸發條件是否達到（或協助 Sherridy 確認）
  2. 在 Hotfix Issue Comment 記錄 MTTR 起始時間戳
  3. 協調 RD、QA、Shawn 三方的工作優先順序
  4. Hotfix 發版後，計算 MTTR 並記錄在 Issue Comment

David Hotfix 授權備援：
  若 Ezou 無法聯繫，David 可提供 Hotfix 授權（Sherridy 確認後執行）
  確認記錄在 <span class="tag">release-hotfix</span> 留存

David 三個月優先行動（V2 版）：

M1（P0）：
  - [ ] branchPattern 設定並通過驗收測試（最優先）
  - [ ] Issue Templates V3 上線（含 Testing Notes + Hotfix Template）
  - [ ] 第一個 Project 建立（含 String Freeze + Feature Freeze Milestones）
  - [ ] [Hotfix] Label + <span class="tag">release-hotfix</span> Channel 建立
  - [ ] 邀請全員加入 Release Tracker Team

M1（P1）：
  - [ ] Automation 5 降級版（無條件提醒）+ Automation 13（Hotfix 通知）設定
  - [ ] Firebase Crashlytics Alert 設定（方案 C 起步）
  - [ ] DORA 基線測量
  - [ ] String Freeze 試水準備 + 第一次執行

M2（P2）：
  - [ ] QA 待測 Queue 視圖設定（Fei Chen + Jimmy 確認）
  - [ ] 去污名化 Workshop 主持
  - [ ] Feature Freeze 警告機制（Google Calendar 提醒確認）
  - [ ] DORA Webhook → n8n Pipeline
  - [ ] PR Template 確認（Ezou 可行性評估後設定）

M3（P3）：
  - [ ] Hotfix SOP 培訓主持
  - [ ] n8n Feature Freeze 提醒升級評估
  - [ ] V3 完整指標對比報告
  - [ ] 所有 Automation 全面驗收

Sherridy（PO + RM — 版本節奏的守護者）

V2 新增職責：

職責 5：String Freeze 執行者（V2 新增）

每個版本：
  1. 決定 String Freeze 日期（Feature Freeze 前 7-10 天）
  2. 在 Linear 設定 String Freeze Milestone
  3. 在 <span class="tag">forest-release</span> 發布 String Freeze 公告
  4. Exception 申請審核（收到申請後判斷是否允許修改）
  5. 截止日當天確認並記錄

String Freeze 執行原則：
  例外申請需說明原因和緊急程度
  RM 有最終決定權，但不應輕易批准
  連續 2 個版本都有大量 Exception，召開流程回顧

職責 6：Hotfix 觸發確認（V2 新增）

收到 Firebase Alert 或緊急通報後：
  1. 確認觸發條件（< 98.5% / 核心功能無法使用 / 安全漏洞 / 差評突增）
  2. 聯繫 David 或 Ezou 確認授權
  3. 在 <span class="tag">release-hotfix</span> 發布 Hotfix 啟動通知
  4. 決定 Hotfix 的發版策略（Patch Release 或 Minor Release）
  5. Hotfix 完成後，在 <span class="tag">release-hotfix</span> 確認關閉

RM 的 Hotfix 文化溝通腳本：
  「這次 Hotfix 是因為 [觸發條件]，我們需要打斷正常 Cycle 進行緊急修復。
   這是一個設計好的例外通道，不是流程失控。
   請 [RD] 優先處理 Hotfix，其他 Issue 暫時等待。
   預計 MTTR 目標：[時間]。」

Sherridy 的掉車文化腳本（V2 精確化）：

對「我只差一點，等我一下」的回應：

「我理解這個功能很重要，也知道你很努力。但有兩個問題：第一，『差一點點』在 Release 管理中是最危險的說法——它可能是 1 天，也可能是 1 週。第二，如果這個版本等這個功能，下次會有另一個『差一點點』的功能，列車就永遠不準時。掉車不是失敗，讓列車延誤才是問題。這個功能在下一班會更完整地完成。」

QA（Fei Chen）— 品質文化建立者 + 批次視窗主責

V2 核心升級：從「接收 Ready for Test 才開始」→ 「Planning 就開始建立測項，批次視窗中集中執行，Hotfix 時可立即切換」。

V2 日常操作（加入批次視窗）：

每天早上：
  打開 Linear → QA 待測 Queue 視圖
  確認 Queue 中的 Issue 數量和優先順序
  評估今天是否有批次視窗，或是否有 Urgent Issue 需要立刻處理

批次視窗中（週二 + 週四 PM）：
  按優先順序處理 Queue 中的 Issue
  每個 Issue 測試完成後立即更新狀態
  Bug 記錄格式：在 Issue Comment，使用「[回測 N] 問題描述」格式

Hotfix 啟動時：
  收到 <span class="tag">release-hotfix</span> 通知 → 立即切換到 Hotfix 模式
  停下正在進行的 Cycle 測試（記錄當前進度）
  執行 Hotfix 快速回歸測試（核心功能 + Hotfix 相關功能，目標 2 小時內）
  Hotfix 完成後恢復正常 Cycle 測試

QA（Jimmy）— 整合測試 + 批次視窗協同

V2 新增職責：批次視窗協同（與 Fei Chen 共同維護 QA 待測 Queue）。

批次視窗協同規則：
  週二視窗：主責 Fei Chen（Jimmy 協助）
  週四視窗：主責 Jimmy（Fei Chen 協助）
  （可依實際工作安排調整，不硬性規定）

Hotfix 備援：
  Fei Chen 無法執行時，Jimmy 作為 Hotfix QA 備援
  兩人都需要熟悉 Hotfix 快速回歸測試的範圍界定

Shawn（PO + 送審人）

V2 新增職責：App Store Expedited Review 申請 + Hotfix 送審流程。

App Store Expedited Review 申請流程：
  觸發條件：Hotfix 需要快速通過 iOS App Store 審核

  申請步驟：
    1. App Store Connect → 選擇 Hotfix 版本
    2. 送審說明中加入緊急說明：
       「此版本修復了影響 [X]% 用戶的 [功能名稱] 崩潰問題。
        Firebase Crashlytics 顯示 Crash-free rate 已降至 [X]%，
        遠低於正常水準（>98.5%）。
        請加急審核，感謝。」
    3. 在 App Store Connect 的「Resolution Center」申請加急審核
    4. 在 <span class="tag">release-hotfix</span> 記錄申請時間和預期審核完成時間

Android Hotfix 流程：
  Google Play Console → 版本管理 → 選擇 Hotfix 版本 → 分級發布（1%-10%-100%）
  通常 2-4 小時審核通過

培訓計劃（V2 版）

培訓時程

Resistance 管理策略（V2 版）

V1 繼承的阻力類型（保留）

類型 1-6（工具阻力、DORA 阻力、掉車阻力）：見 V1 版本，策略相同。

V2 新增阻力類型

類型 11：「String Freeze 是什麼？文字有那麼重要嗎？」

「String Freeze 保護的是多語言用戶的 App 體驗。MKT 的翻譯工作需要 7-14 天，如果文字在翻譯開始後修改，翻譯就需要重做。這不只是時間成本——匆忙翻譯的文字品質會直接影響 Forest App 在非中文市場的用戶體驗。而且，String Freeze 的另一個作用是讓全員習慣『截止點是認真的』——這個習慣是 Feature Freeze 文化的基礎。」

類型 12：「批次視窗太慢了，我的功能要等到週四才被測試？」

「我理解你希望功能盡快被測試。批次視窗的設計是為了保護 QA 的工作品質，而不是拖慢進度。如果你的 Issue 接近 Feature Freeze 或有特殊緊急需求，可以告訴 Sherridy，她可以加上 Urgent Label 讓 QA 優先處理。一般情況下，等到下個批次視窗（最多 3 天）的 Lead Time 影響是可以接受的，換來的是更高品質的測試。」

類型 13：「Hotfix SOP 那麼多步驟，緊急時根本記不住」

「這就是為什麼 Hotfix SOP 培訓在 Month 3 做，而且要演練一遍的原因。Hotfix 在緊急時確實需要快速執行，但『快速』不等於『跳過步驟』。每個步驟都有它的意義：觸發條件確認防止假警報浪費資源，MTTR 計時讓我們知道應對速度，QA 快速回歸確保修復沒有引入新問題。你不需要背住所有步驟，#release-hotfix 通知發出後，每個人按自己的角色去做就好。」

類型 14：「Testing Notes 是 PO 的工作，我 RD 只要做功能就好了」

「Testing Notes 中有兩個部分：PO 填重點觀測項目（他的責任），RD 填技術邊界和平台差異（你的責任）。這不是 PO 在要求 RD 做額外工作——是 RD 把自己在開發中發現的技術知識傳遞給 QA，讓測試更有效率。PR Template 中的確認欄位就是這個傳遞的機制，你在 PR Review 時順手填一下就好了，不需要額外打開 Linear。Duolingo 工程師透過這個習慣讓 Bug 率降低了 30%，原因是 QA 知道 RD 在意哪些邊界情況。」

工具遷移 Buffer 期設計（V2 新增）

三個月的工具遷移節奏

Month 1-2：Slack 和 Linear 雙軌並行
  - Slack 仍可討論 Bug、進度、掉車決定
  - Linear 用於正式記錄
  - 規則：Slack 討論的結論需要在 Linear Comment 中留存
  - 目的：讓團隊有心理準備期，不是一次性強制切換

Month 3 起：所有重要決定的正式記錄只在 Linear
  明確截止點：從 Month 3 第 1 週起
  可接受的：Slack 繼續用於即時溝通和討論
  不可接受的：重要決定（掉車、Hotfix 啟動、Crash Rate 異常）只存在 Slack 中

為什麼要有明確的「截止點」：Buffer 期沒有退出條件，就會變成永久狀態。Month 3 Week 1 是明確的截止點，讓團隊知道「這是過渡期，有終點」，而不是「雙軌是永遠的設計」。

情感層面的阻力（V2 新增分析）：

工具遷移的情感阻力往往比技術阻力更難克服。當人們已經熟悉 Slack 中找東西的方式（搜索 / Pinned 訊息 / Thread 整理），切換到 Linear 意味著「我不再知道怎麼快速找到我需要的資訊」。這個「能力損失感」是真實的，不應該被輕視。

應對策略：

1. 提前展示 Linear 的搜索功能（比 Slack 更好的 Issue 搜索體驗）
2. 在培訓中讓每個人自己找一個他們關心的資訊（證明他們能在 Linear 找到）
3. 承認過渡期確實需要時間，但過渡期是有終點的

採用率追蹤（V2 版）

每週觀察指標

成功加速策略（V2 版）

快速勝利（Quick Wins）

Quick Win 1（保留）：iOS Ready for Test 自動通知（解決 iOS 手動發 Slack 的痛點）

Quick Win 2（V2 新增）：QA 批次視窗的第一次成功

• 第一個批次視窗後，Fei Chen 在 forest-release 分享使用心得
• 展示：「我在這 4 小時測了 N 個 Issue，而且不需要頻繁切換」
• 這比管理層說「批次視窗很好」更有說服力

Quick Win 3（V2 新增）：String Freeze 的第一次無 Exception 完成

• 在 forest-release 公告：「這是第一次 String Freeze 沒有任何 Exception 申請」
• 簡單慶祝，強調這代表 MKT 翻譯工作有充足的時間

慶祝里程碑（V2 版）

Level 3.5 達成（String Freeze 第一次成功）：
  Sherridy 在 <span class="tag">forest-release</span> 發布：
  「Forest App 第一次成功執行 String Freeze。
   這意味著我們的翻譯品質有了保障，
   也意味著截止點在我們的文化中開始有了意義。
   感謝所有人的配合。」

Level 4 達成（去污名化 Workshop + 第一次掉車）：
  Workshop 後，David 在 Notion 記錄關鍵承諾
  第一次掉車後，Sherridy 發心理安全公告

Level 5 達成（第一次列車準時發車）：
  公告格式（見 [03-三個月導入路線圖（統整版V2）](/linear-roadmap) M3-04）
  特別感謝 QA 的批次視窗工作
  說明 Hotfix SOP 已就緒（即使這次沒有用到）

導入完成後的維護

持續優化機制

1. 每季一次 Linear 設定檢討：Review Workflow States 是否仍符合流程需求
2. 每季 Architecture Review（Ezou 主持）：技術負債、Feature Flag 評估、測試覆蓋率
3. Automation 日誌定期審查：確保所有 Automation 仍然正常運作
4. Hotfix 頻率追蹤：若 Hotfix 頻率高，討論測試流程改善

三個月後的評估點

相關文件：03-三個月導入路線圖（統整版V2） | 04-環境建置指南（統整版V2）

linear 團隊策略 統整版V2 消費者App dora ReleaseTrain 掉車SOP 測試注意事項 MTTR StringFreeze HotfixSOP QA批次視窗 去污名化