MANAGEMENT / JUDGMENT & SUPPORT
功能進度與跨團隊資源，Manager 如何取捨？
依我的團隊分工與版本選擇經驗整理，並說明目前的管理做法；版本更新的問題為回顧延伸。
其他產品已經有了新功能，我們卻決定先不跟。當時的選擇，是繼續跟進其他 team 的 develop，還是從穩定版本建立自己的分支。
跟進 develop，新功能可以較快進來。建立穩定分支，功能就會暫時落後。
如果只看功能表，跟進似乎更合理。但我還要看：更新進來之後，哪些團隊會停下原本的工作，替這次整合處理問題？
TL 先有初步判斷，需要協調就提早提出
我直接管理 System、WiFi、5G 三個 team，負責成員發展與工作交付。他們各自負責，也共同協助。
本文的 TL 指 Technical Lead，負責各自技術領域的判斷與帶領。
在自己的技術領域內，我期待 TL 先有初步判斷，說明目前怎麼看、卡在哪裡，以及需要什麼支援。有初步判斷就可以討論，不必先準備多個答案。
涉及跨團隊、外部協作或資源需求時，我期待 TL 提早提出，讓我一起協調；不必等所有資訊齊全或自己無法決定才開口。
在那次版本選擇裡，需要比較的，是新功能、相依性與共同開發的進度。
新功能進來，成本可能跨過團隊邊界
跟進 develop，可以較快取得新功能，但更新不一定同時進到所有相關 repo。
部分 repo 更新、其他相依部分還沒接上，可能造成編譯問題。更難處理的是編譯沒有報錯，執行行為卻異常，甚至 crash。
這些風險可能牽動多個 team。除了自己的除錯，還需要協助處理其他 team 的編譯問題。原本安排的開發，也可能因此等待。
一個團隊取得新功能，可能讓幾個團隊付出整合時間。這也是我不能只看自己進度的原因。
先建立穩定分支，也有明確代價。
新功能不會即時帶進來，我們的 device 在功能面上，會落後某些已進入 EA、RC 或 GA 的產品。這個落差不能只用「穩定比較重要」帶過。
這次功能延後，主要影響內部開發與功能排程，沒有更改當時的對外承諾。
得到什麼
- 跟進 develop
- 較快取得新功能。
- 從 stable 建立分支
- 保留目前穩定基準。
承擔什麼代價
- 跟進 develop
- 承擔更新相依性與整合負擔。
- 從 stable 建立分支
- 接受功能暫時落後；後續仍需整合。
影響哪些團隊
- 跟進 develop
- 整合與除錯可能占用其他團隊的開發時間。
- 從 stable 建立分支
- 當時希望保留其他團隊的開發空間。
依本文經驗與回顧整理；是當時的選項比較，不是量化結果或通用答案。
我的決定：先穩定，再判斷跟進時機
當時，我決定先從穩定版本建立分支，接受功能暫時落後。
我把整合與除錯可能占用的資源，以及對其他 team 開發的影響，一起放進這個取捨。
後續仍然保留兩條路：從 develop 選取有用的 commits，或等對方下一版進入 EA、RC 或 GA，再評估跟進。
EA、RC、GA 在這裡是版本階段的標記。判斷是否跟進，仍要確認對方已驗證的範圍，以及帶到我們設備上的相依性與整合風險。
Cherry-pick 縮小了變更範圍，也可能漏掉必要的相依變更。編譯通過，還要看執行行為。
接下來幾次整合與測試中，系統逐漸進入穩定期。其他 team 的編譯與整合能正常進行，也不再需要為我們的相依性問題頻繁提供支援；跨團隊追蹤中，他們的工作能繼續推進。TL 也曾肯定當時的決定。
這些是我從整合、測試、跨團隊追蹤與回饋得到的後續觀察，並非量化比較的結果，也不代表所有問題都已排除。
這個結果支持當時的選擇。但換一個階段，功能需求與整合條件改變，判斷也可能不同。
選了 stable，後續更新仍有人要管
在後續的版本與技術方案評估中，我逐漸看到分工的變化。以前，方案比較常需要我補齊；後來，TL 能先說清楚選項、相依風險與代價，再帶著需要的支援來討論。
我主要處理跨團隊的取捨，重要判斷仍由我們共同完成。TL 持續追蹤，這種分工也延續到多次更新。
對我而言，這是團隊開始承接更多判斷的具體訊號。這些是我在工作中的觀察，並非量化成效，也不能單憑這段經驗判定變化來自某一種管理方法。
回頭看，穩定分支留下了持續的工作：追蹤功能差距、確認選取 commits 的相依性，以及為下一次整合保留資源。
從這次經驗延伸，我會把三個問題帶回討論：
- 哪些功能已經不能再延後？繼續等待會影響什麼承諾？
- 維護目前分支的投入，是否已經比跟進候選版本更難承受？
- 候選版本目前有哪些相依性與設備驗證依據？這些證據是否已改變風險，值得重新比較選項？
這些是回顧後的討論方向，並非當時採用的固定門檻。它們讓團隊重新檢查：原來的理由，現在是否仍然成立。
目前的做法：排優先順序，也保留重新判斷的空間
這是我目前一般的管理做法。TL 負責自己的技術領域；我把各團隊的進度放在一起，分析取捨、調整資源，必要時協調外部。
執行前，我會先看影響範圍、出問題後能否恢復、已有證據與未知，再衡量交付承諾、客戶與營運影響、跨團隊依賴，以及投入與替代方案。
超出團隊可承擔範圍的取捨，要和相關負責人共同決定。若風險可能讓交付本身失去意義，我會先處理風險，重新協商承諾。
交付承諾優先，但我也會保留必要的維護、平台與能力改善資源。若長期問題已威脅交付，就需要重新協商範圍或時程，讓改善有空間進行。
TL 持續追蹤領域內的風險，透過固定檢視一起確認狀況；檢視頻率隨風險調整，重大變化則立即回報。執行中有新風險或證據、影響擴大，或原先條件改變時，就重新檢視決定。
改變做法，要依實際證據和 TL 討論。
- 持續投入仍沒有進展時，換分析方式或方法。
- 若新風險可能因繼續執行而造成更大影響，就先暫停受影響的工作，查證風險。
- 若缺少關鍵驗證、資源或相依條件，就調整計畫。
- 需求或價值改變時，則視情況停止或重訂範圍。
選定方向後，說清楚接受的代價、先等待的工作與支援需求。
文章脈絡
依我的團隊分工、版本選擇經驗與目前的管理做法整理，省略產品與內部細節。一般做法不表示當時已採用相同流程。文中的相依性故障是評估時考慮的風險，不表示每一種故障都發生於該次事件；後續結果為我的觀察，未提供量化驗證紀錄。
— 修訂說明：補充這次功能延後的影響範圍為內部開發與功能排程，未更改當時的對外承諾。
— 修訂說明：補充三個團隊的直接管理責任，以及 TL 方案比較與 Manager 跨團隊取捨的分工變化；保留質性觀察與因果界線。