Day 24 調整團隊協作節奏：讓討論與決策對準 AI 的建造速度

本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。

昨天談到，團隊需要為探索保留時間，也要讓學習結果影響後續開發。接下來還有一個實際問題：新的資訊出現之後，團隊什麼時候一起討論，並據此調整工作？

假設 PM 已經用 AI 整理需求，工程師也很快做出初版功能，但大家仍要等到下週的會議，才確認某個影響範圍的重要問題。這時候，開發速度雖然提升了，整體工作卻未必能更早完成。

當 AI 加快部分工作，團隊也需要回頭檢視 Planning、Refinement 與迭代節奏，看看哪些準備可以提早完成，哪些討論需要更早發生。

用 AI 準備初稿，也把待討論的問題留下來

《產品領導人之道》第 22 章談到增量與迭代時，提醒讀者：安排 Sprint 工作需要 PM 與團隊合作，而事先準備初稿，可以幫助大家建立基本共識。

把這個做法延伸到 AI 協作，PM 可以先整理使用者問題、相關證據與已知限制，再請 AI 協助草擬工作項目，列出可能遺漏的情境。準備資料時，也應留下尚未確認的問題，讓參與者知道哪裡需要一起判斷。

Atlassian 的 Rovo 官方應用示範提供了一個具體例子：AI 從會議逐字稿整理需求、描述與驗收條件，經使用者確認後建立 Jira 工作項目，再與技術團隊進一步細化。這是一個功能與流程示範，值得參考的是它把資料整理和後續討論接在一起。

如果只請 AI 把需求「補完整」，原本沒有答案的地方，也可能被寫成看似確定的條件。因此，會前資料可以明確區分已確認內容、AI 提出的建議，以及仍待團隊回答的問題。讀的人才有機會辨認，哪些文字已經有依據，哪些只是草案。

Refinement 要讓不同理解浮現

產品待辦清單細化（Refinement）會持續拆解與釐清工作項目。實際安排時，可以先讓成員閱讀資料、留下問題，再把需要共同判斷的部分帶進討論。

延續昨天的報表情境，假設團隊準備提供資料核對功能。AI 產出的需求寫著：「發現金額不一致時，提醒使用者。」這句話看起來很清楚，但 PM 想的是讓使用者繼續處理其他資料，工程師理解的可能是先阻止整批匯入，設計師則需要知道，使用者能否直接修正差異。

這些理解會影響流程、錯誤處理與開發範圍。即使文件已經寫好，團隊仍需要拿一筆具體資料走過操作情境，確認出現差異時，使用者接下來可以做什麼。

AI 可以協助列出例外情境，讓大家有討論的起點。但在這個假設案例中，哪些差異必須阻擋、哪些可以稍後處理，仍要依使用者的工作需求與系統限制決定。

討論結束後，也要把決定更新回工作項目。否則會議上已經改變的理解，可能沒有進入後續開發使用的資料，AI 和團隊成員便繼續依舊版本工作。

Planning 要談清楚這次能交付什麼

到了 Sprint Planning，團隊需要共同確認這次的目標、選擇投入的項目，以及完成工作的方式。Scrum Guide也將這些列為 Planning 要處理的核心內容。

AI 可以協助草擬拆分方式與工作順序，但選擇範圍時，仍需要回到使用者能完成的事情。

以前面的資料核對功能為例，「完成上傳介面」與「完成比對程式」都代表工作有所進展，但使用者可能還無法走完核對流程。團隊可以考慮先支援一種固定格式，讓使用者從上傳、查看差異到確認結果，都能完成一次操作，再逐步擴充其他格式。

這也呼應原書第 22 章的提醒：早期版本要兼顧精簡與完整，保留足以讓使用者獲得價值、讓團隊取得學習的內容。

如果 AI 讓程式初稿更快完成，規劃時仍要把整合、測試與必要的修正算進去。團隊可以參考近期相似工作的實際完成情況，調整這次的預估，不宜直接把產生程式碼的速度當成整體交付能力。

也可以在規劃時一併確認：這個版本完成後，誰能試用、希望觀察什麼，以及何時根據結果決定下一步。如此一來，回饋才有機會趕上後續投入。

發布與回饋可以提早，Sprint 長度另外判斷

如果團隊原本採用兩週的 Sprint，AI 加快開發後，是否就該縮短成一週？

可以先檢查，現在有哪些工作只是因為習慣而等到週期結束。Scrum Guides明確說明，Sprint 內可以產生多個增量，也可以在 Sprint 結束前交付；Sprint Review 不應成為發布價值的關卡。Product Backlog Refinement 同樣是持續活動，不必把所有釐清都留到固定會議。
因此，團隊可以維持原有的 Sprint 節奏，同時更早交付已符合完成定義、具備發布條件的功能，並及早取得回饋。遇到會影響當前工作的疑問，也可以先找相關成員討論，將結果同步給其他人。

調整時仍要保護團隊的專注。如果每出現一個 AI 產生的新點子，就插入工作或改變範圍，團隊反而難以完成原定目標。新的資訊是否需要立即處理，可以看它會不會影響目前的目標、造成返工，或讓其他工作無法繼續。

至於 Sprint 長度，則可以根據團隊取得回饋與調整方向的需要來檢視。如果每次都要等很久才能修正已知問題，值得嘗試更短的週期；若主要困難是顧客尚未試用，或重要決定一直無人處理，單純縮短行事曆上的週期，幫助可能有限。

對產品領導人而言，可以先和 PM、團隊回顧最近一次開發：哪些資料能在討論前備妥？哪個問題太晚釐清？有沒有已完成的功能，因為等待固定會議而延後交付？

從其中一項開始調整，例如會前先提供 AI 協助整理的草案，會議集中處理分歧，並約定重要問題出現時的討論方式。下一輪再看，反覆釐清與等待是否減少，團隊是否更早取得有用的回饋。這些變化比單看會議縮短幾分鐘，更能幫助我們判斷調整有沒有作用。

下一篇將接著討論，當 AI 讓 PM、設計與工程的工作能力出現更多重疊，團隊如何安排分工與責任。