Leader 說要改善流程，但我不知道怎麼配合

Leader 說要改善流程，但我不知道怎麼配合 目錄 1. 上下認知落差 2. 改善沒有落地 3. 各做各的優化 4. 測試資源不足 5. 心態與做法 某個 sprint 開始前，Leader 在 Slack 發了一則訊息：「這個 sprint 我們要試行新的 test plan review 流程，每個功能測試前要先提交 test plan 給我看。」 我看到的時候，心裡的第一個反應不是「好主意」，而是「我今天下午三點 build 要出，後天 release，我要怎麼同時做這件事？」 那個 test plan review 流程試行了兩週，然後在沒有人討論的情況下消失了。 Leader 和 QA 工程師之間的流程改善失敗，通常不是因為想法不好。是因為有幾個斷點，雙方都感覺到，但沒有一個地方說清楚。 上下認知落差 Leader 看流程的視角是系統性的：「我們的回歸測試每次都要花兩天，要改善。」 工程師感受到的是今天的 deadline：「今天下午三點 build 要出，明天 PM 要看 demo，我根本沒有思考系統的餘裕。」 這不是誰的問題。Leader 的工作就是要往上看，找出系統的瓶頸；工程師的工作就是在現有資源下把今天的任務做完。但這個視角差，讓 Leader 推的改善常常對工程師來說像是「再加一件事」，而不是「這會讓你更輕鬆」。 結果： Leader 覺得工程師沒有改善意識；工程師覺得 Leader 不了解現場壓力。兩邊都沒有錯，但溝通沒有對上。 雙向機制：流程健診 每月一次，30 分鐘，Leader 問工程師三個問題： 1. 這個月有沒有什麼事情讓你覺得在浪費時間？ 2. 有沒有哪個流程你覺得有問題，但一直沒有說？ 3. 如果只能改一件事，你想改什麼？ Leader 的角色是聽，不是立刻回答「那我們來改」或「這個改不了」。先把工程師的地端觀察記下來。 工程師的責任是說真話，不是抱怨，而是描述具體的障礙：「每次 build 好了我不知道，要自己去問 RD，這個每次浪費我二十分鐘。」 這個機制把工程師的地端訊號，轉化成 Leader 可以操作的改善方向。沒有這個機制，Leader 只能靠自己觀察和假設，通常都會猜錯優先順序。 改善沒有落地 我們開過一次會，決定要在 Confluence 建立測試知識庫，把每個模組的邊界條件和歷史 bug 記進去。大家都覺得這是好事。 六週之後，那個頁面還是空的。 不是因為沒人想做，是因為沒有人知道「這件事現在的狀態是什麼」，也沒有人主動推進。每個人都以為別人會先開始。 會議決定的改善方案，要落地需要兩個條件： 明確的 owner 和 定期的有效性確認 。兩個缺一不可。 雙向機制：owner + 有效性確認 每個改善項目在決定時就要指定 owner，不能是「我們大家」。可以是 Leader，可以是工程師，但要有一個具體的人名。 Owner 的責任不是把所有事情做完，而是「確保這件事繼續前進」——可以是自己做，也可以是推別人做，但要有人負責不讓它消失。 兩週後，Leader 問一句：「這個改善對你的工作有沒有幫助？有的話哪裡有幫助，沒有的話卡在哪裡？」 這句話很重要。改善方案設計的時候是 Leader 覺得對工程師有幫助，但實際執行之後工程師才知道有沒有用。不問，就不知道。問了，才能調整。 有一次我們試了一個新的 bug report 格式，我覺得某個欄位完全沒用，每次填都在浪費時間。但因為沒有人問，我就一直填，最後那個欄位在沉默中消失，沒有人知道它為什麼沒用。 各做各的優化 某個 sprint，Leader 在推動 CI/CD 自動部署到測試環境。同一個 sprint，我在優化 bug report template，把環境資訊的欄位整理得更清楚。 兩件事都是好事，但我們不知道彼此在做什麼。 CI/CD 上線之後，測試環境的部署方式改了，有些環境資訊的取得方式也跟之前不一樣。我的 template 裡有幾個欄位突然不再適用，我花了一個下午才弄清楚什麼地方對不上。 如果我知道 Leader 在做 CI/CD，我在設計 template 的時候就會先問「部署之後環境資訊怎麼看」，這個問題早三週問，可以省掉一個下午的混亂。 雙向機制：共用優化地圖 不需要複雜的工具，一個 Notion 頁面或 Google Sheet 就夠。欄位： | 項目 | 負責人 | 狀態 | 預計完成 | 說明 | | | | | | | | CI/CD 自動部署 | Leader | 進行中 | Sprint 5 | 部署到 staging，merge 觸發 | | Bug report template v2 | 我 | 進行中 | Sprint 5 | 增加環境資訊欄位 | 每週各自更新一次自己的項目狀態。不需要額外的會議，只是讓彼此知道「對方在動哪些東西」。 這張地圖最大的價值不是追蹤進度，而是讓人在做自己的工作之前，先看一眼有沒有跟對方的工作有交集。 測試資源不足 Leader 說：「我有跟 PM 反應了，測試時間不夠。」 工程師想的是：「你說不夠是指哪裡不夠？我這個 sprint 跳過了三個 edge case，你知道嗎？」 問題有兩層。 第一，Leader 往上爭資源的時候，講的通常是「時間不夠」這個概念；但 PM 想知道的是「如果資源不足，具體放棄了什麼，風險是什麼」。概念說不動人，具體風險才說得動人。 第二，工程師每天在做取捨——「這個 case 我跳過，那個 case 我快跑」——但這些決策通常不透明，Leader 不知道，PM 更不知道。結果是：上面覺得測試跑完了，下面知道其實有洞，但沒有地方說。 雙向機制：Risk Based 排序 + 可視化工作量 工程師每個 sprint 把要測的項目標上風險等級（H/M/L），在 sprint 開始時跟 Leader 對齊一件事：「如果這個 sprint 時間只夠跑 H 和 M，我們接受 L 的風險。」 這個對話讓取捨變得明確，不再是工程師默默決定、Leader 不知情。 每個 sprint 結束，工程師記錄一句話：「這個 sprint 我跳過了什麼，為什麼。」 例：Sprint 12 跳過了離線模式的 edge case（時間不足），已知風險：在弱網下偶爾會有 race condition。 Leader 把這些記錄累積下來，拿去跟 PM 談：「過去三個 sprint，我們平均每個 sprint 跳過 2–3 個 edge case，原因是時間不夠。這些跳過的地方，有兩個在上線後被用戶回報了 bug。」 這是數據，不是感覺。數據說得動資源。 心態與做法 四個機制都不複雜，工具也不貴。但如果心態沒到位，這些做法就只是更多需要維護的文件。 Leader 的轉換： 流程改善不是管理任務，是創造安全空間。 最有效的 Leader 不是推出最多改善方案的人，而是讓工程師願意說「這個流程有問題」的人。工程師如果覺得說出問題會被視為抱怨、不夠積極，就會選擇沉默。沉默的團隊看起來沒有問題，但問題在累積。 工程師的轉換： 地端觀察是資產，不是抱怨。 工程師每天在現場，知道哪個流程在浪費時間、哪個邊界條件過去出過事、哪個改善方案在現實中行不通。這些觀察，Leader 看不到。工程師的責任不只是執行，也包括把這些訊號帶出來，讓 Leader 能做出更好的決策。 可以立即帶走的做法：每 sprint 10 分鐘雙向 check in 不需要開會，不需要議程，兩個問題： 1. 工程師問 Leader： 「你這個 sprint 在推什麼改善？我需要配合什麼嗎？」 2. Leader 問工程師： 「這個 sprint 有沒有什麼流程在拖你？」 10 分鐘，在 sprint 開始的時候做。 這個 check in 不解決所有問題，但它持續地打開兩個對話的頻道：工程師知道 Leader 在做什麼、Leader 知道工程師遇到什麼。其他機制——流程健診、優化地圖、風險排序——都能更容易在這個基礎上運作。 流程改善不是 Leader 的工作，也不是工程師的工作，是兩個人一起的工作。Leader 有系統視角和向上推動的籌碼；工程師有地端觀察和具體風險的數據。兩邊的資訊合在一起，改善方案才會落地，不然就只是一個消失在 Confluence 的空頁面。 參考資料 Tuckman's Stages of Group Development — 團隊發展四階段模型（Forming / Storming / Norming / Performing） Lisa Crispin & Janet Gregory — Agile Testing — 敏捷測試中 QA 與團隊角色的完整討論 Google Re:Work — Guide: Understand Team Effectiveness — Google 研究：高效團隊的關鍵因素 Ministry of Testing — Test Leadership — QA 在流程改善中的領導力 Lisi Hocke — Whole Team Quality — 全團隊品質文化實踐者的個人部落格