優化團隊（Optimize Team）：人員配置與技能運用的五種選擇

優化團隊（Optimize Team）透過人員配置與技能運用，處理交付中的等待與能力缺口。借調可以補上短期支援，調離成員可以在特定情境下降低帶領負擔，兩者都需要重新安排原有工作。

專注型解決方案團隊以長期穩定的跨功能配置減少交接與重新組隊的磨合。通才型專家以「深專長＋廣協作」承接相鄰任務。運用既有人才則讓未發揮的能力投入交付。

選擇做法時，需要確認缺口持續時間、可用技能、交接成本、學習成本與其他團隊的負擔，再約定投入期間與檢視日期，確認等待是否縮短、受影響的工作是否有人承接。

你是否常遇到開發已經完成，工作卻卡在測試、資安或維運等少數專家手上？

當這些專家同時支援多個團隊，功能就得排隊等待檢查或部署。從別的團隊借調人員能補上眼前缺口，相對的原團隊的工作也要重新安排。

如果每次交付都在等待同一批人，團隊就需要檢查技能配置，以及目前分工是否讓成員能承接的工作仍被轉交出去。

Disciplined Agile（DA）的優化團隊（Optimize Team）決策點，提供調整人員配置、團隊結構與技能運用的五種選擇。

本文從短期人力調整談到長期穩定配置與技能培養，說明各種做法能解決的問題，以及伴隨的交接、磨合與學習成本。

選擇前先確認缺口會持續多久、哪些工作會受到影響，再約定投入期間與檢視方式，確認等待是否縮短，以及其他成員是否多了無人承接的工作。

優化團隊（Optimize Team）的決策範圍

從加速價值交付聚焦到人員配置

在 Disciplined Agile（DA）中，加速價值交付（Accelerate Value Delivery）是一個流程目標，涵蓋工作如何組織、系統如何部署、程式與設定如何管理，以及品質如何確認。

優化團隊是其中一個決策點，聚焦於團隊成員如何配置、需要具備哪些能力，以及現有技能如何用在待完成的工作上。

例如，產品每次上線都要等待同一位資安工程師，團隊就需要了解這項支援要投入多少時間，以及哪些工作必須由他處理。

這次上線需要特殊檢查時，可以評估短期借調。每次交付都要經過相同檢查時，就需要考慮長期技能配置，或讓團隊成員學會承接其中能自行完成的工作。這些安排都屬於優化團隊的討論範圍。

DA 提供可依情境選擇的做法，團隊需要根據缺口持續時間、可用技能與交付需求判斷如何調整。

採用某個選項前，也要確認受影響的工作。例如，借入一名專家支援上線時，原團隊正在進行的任務就需要重新安排承接者或完成日期。

用一件卡住的工作辨認調整需求

第一步是挑一件正在等待的工作，沿著接手、開發、測試到上線的過程，找出實際停住的位置。

假設訂單功能已經完成開發，卻等了三天仍未進入測試，可以先確認測試人員手上有哪些任務、這次測試需要什麼能力，以及團隊內是否有人能協助。

把「缺人」拆成具體工作、所需技能與可投入時間，才有依據選擇調整方式。

如果測試人員同時處理幾項發布，這次等待與短期工作量集中有關，可以評估限期支援。若團隊無人具備這項功能所需的安全測試能力，就需要補上專業技能。也可能有工程師做過相關測試，只是目前分工讓他只接開發任務，此時可以討論重新分配工作，並確認他原先負責的事項如何安排。

討論時，可以直接在這件工作的紀錄中寫下等待開始時間、目前卡住的步驟、需要誰完成什麼，以及下一次交付是否還會遇到相同需求。接著與相關成員核對可投入的時間，確認這次需要短期支援，或應安排較長期的人員與技能調整。

應急方案：如何透過「借調」與「調離」解決短期人力瓶頸？

借調成員補上短期缺口

產品預計下週上線，團隊卻缺少執行安全檢查的能力，此時可以評估借調成員（Borrow team member）。

借調是讓其他團隊的成員在約定期間加入工作，時間可從數天到數週，完成支援後再回到原團隊。

例如，借調一名資安工程師，讓他與開發人員一起確認風險、檢查修改內容，並驗證修正結果，就能減少送出檢查申請後等待回覆、補件與再次排隊的往返。

借調者在這段期間以投入借入團隊為主要安排，同時保留原團隊歸屬，參與雙方必要的協調。他需要先掌握產品背景、目前進度與待處理問題，原團隊也需要知道哪些決定會影響自己的工作。

借調能把部分跨團隊交接改為直接合作，雙方仍需安排原有任務與後續支援責任。

如果借調者白天協助安全檢查，下午又被叫回原團隊處理其他問題，每次往返都得重新掌握任務背景，這就是上下文切換（Context switching）的成本。

原團隊也可能因熟悉決策細節的人暫時離開，出現脈絡遺失（Context loss）。例如，接手者只知道某項設定不能修改，卻不知道背後的相容性限制，討論到一半又得找借調者確認。這些追問會占用雙方原先安排好的工作時間。

評估借調時，可以把補上缺口的收益與兩邊需要承擔的成本放在一起看。

借調前，雙方應約定支援範圍、投入時間與返回日期，並把尚未完成的工作、重要決策及限制條件交接給指定成員。

借入團隊先備妥必要權限與工作資料，讓借調者到位後能開始處理問題。支援結束時，再交接檢查結果、未解決事項與後續負責人。

調離成員前評估帶領成本與後續安排

調離成員（Drop team member）是交付吃緊時可評估的人員調整方式，也可以透過改派到不直接影響交付日期的工作來實施。

當成員尚未熟悉角色或系統，資深同事就需要花時間解釋背景、示範做法與檢查成果。這些投入有助於成員成長，也會占用資深同事處理其他任務的時間。

例如，上線前仍有一項付款錯誤必須修正，負責的資深工程師同時帶領兩名剛接觸系統的同事。若他每天花大量時間回答環境設定與基本操作問題，可以討論讓其中一名同事暫時改做已有清楚操作步驟、完成日期較有彈性的任務，並由另一位有時間的成員協助。

這項調整能否讓付款修正提早完成，取決於省下的指導時間，以及交接和剩餘工作會增加多少負擔。

評估調離成員時，需要一併計算省下的帶領時間、留下的工作量與新的交接成本。如果被調整者原先已能獨立完成大量工作，這些任務改由其他人接手後，留下的成員可能更忙。

討論時也要向當事人說明調整原因與期間，避免讓一次任務調整成為對個人能力的籠統評價。

這個選項的短期收益與人員影響，需要在決定前一起確認。

調整前應與當事人確認新任務、協助者及重新檢視安排的日期，也要逐項確認原有工作的承接者。等這次交付壓力解除，再依成員的學習需求與工作安排，討論返回原任務或接續其他任務的時間。

專注型解決方案團隊：圍繞產品與價值流穩定配置

以長期穩定的跨功能配置承接交付責任

專注型解決方案團隊（Focused Solution Team，FST）是長期存續（Long-lived）、跨功能（Cross-functional）的團隊，圍繞產品、相關產品群或價值流（Value Stream）運作。

價值流可以理解為從需求出現，到客戶取得成果的一連串工作。以訂閱服務來說，從方案設計、功能開發、付款測試到正式上線，以及後續客服支援，都會影響客戶能否順利訂閱與使用服務。

專注型解決方案團隊會依約定成果配置所需能力，讓成員專責投入，並在一次交付結束後接續處理產品後續需求。

跨功能代表團隊具備完成成果所需的不同專業，可以依需要包含開發、測試、維運、行銷與客服等能力。長期穩定配置讓同一個團隊能接續承擔產品工作，專責投入則讓成員有時間完成這些責任。

成立專注型解決方案團隊前，需要確認各項能力能投入多少時間。例如，訂閱服務每次調整付款流程都需要安全檢查，相關能力就需要有穩定的配置安排。

若稀缺專家只能偶爾支援，檢查工作仍得配合他的時間排程。成員頻繁被調去其他任務時，也要重新確認原先承諾的交付日期。

減少重新組隊造成的磨合成本

如果每次改版都拆散原班人馬，再從不同部門重新指派成員，新的組合就需要時間熟悉彼此的專長、協商分工，並確認遇到問題時找誰處理。

即使每個人都熟悉自己的技術，團隊仍得重新討論測試由誰安排、上線前如何確認結果，以及意見不同時如何做決定。

團隊發展可以用形成期（Forming）、風暴期（Storming）、規範期（Norming）與表現期（Performing）來理解。

成員先認識任務與彼此，再協調做法上的分歧，建立工作約定，並在合作中熟練地完成任務。各團隊的發展速度與經歷會有差異，成員異動也可能讓部分分工重新進入協商。頻繁重新組隊，會讓這些適應工作反覆占用交付時間。

專注型解決方案團隊的長期穩定配置能保留產品知識與合作默契，減少反覆重新組隊所需的適應時間。

例如，同一批成員接續處理訂閱服務的上線回饋時，已經知道付款失敗由誰追查、哪些情況需要客服協助，以及哪些修改必須重新驗證。下一次改版可以沿用這些分工，再針對新需求調整測試與上線安排。

以價值增量與創新增量安排工作焦點

專注型解決方案團隊以一次專注一個價值增量（Value Increment，VI）或創新增量（Innovation Increment，II）作為主要工作安排。

價值增量是能為內部或外部客戶提供可衡量價值的可交付工作單位，包含實現這份價值所需的工作。例如，讓訂閱客戶自行變更方案，需要完成畫面、付款計算、測試與部署，也要準備客服說明，客戶才能實際使用這項服務。

創新增量著重探索新的市場、技術或服務方式。假設團隊想了解按使用量計費是否適合新的客群，可以設計小規模試用，讓受邀客戶體驗計費方式，並觀察使用情況與回饋。這次工作的交付範圍就包含可供試用的服務、計費說明，以及供後續判斷使用的實驗結果。

專注於一個增量時，團隊需要先確認這次要完成的成果，再安排實現成果所需的人員與工作。

以自行變更方案為例，若功能已開發完成，客服仍無法回答費用如何計算，就需要把說明與培訓工作納入這次交付，並指定負責人和完成日期。

專責團隊仍需顧及企業共用系統

企業感知（Enterprise Awareness）在這裡代表團隊做決定時，會考慮其他團隊與企業整體的需要。

專注型解決方案團隊即使具備完整的交付能力，也會使用共用帳號、付款或資料服務。產品內部的設計決定，可能改變其他系統的使用方式與維護工作。

例如，訂閱服務為了方便開發，自行建立一套與企業既有系統不相容的帳號機制，客戶日後使用其他產品時就可能需要重複註冊。當企業希望整合帳號，相關團隊還得處理身分對應、權限轉換與資料搬移。

先前未處理、後續需要補做的整合工作，會形成組織層級的技術債（Technical Debt）。

團隊可以在設計前，先與共用系統的負責人確認使用限制、必要檢查與變更程序，並記錄需要共同決定的事項。

例如，新增訂閱方案時是否要調整共用權限資料，以及這項修改需要哪些產品一起驗證，都應有明確的聯絡窗口。

評估專注型解決方案團隊時，可以同時檢查穩定配置帶來的收益，以及組織需要承擔的人力與整合成本。

成立團隊前，先確認稀缺技能的投入安排，再與共用系統的負責人約定需要共同檢查的變更。若某項能力暫時無法配置到位，就把外部支援的負責人與可提供支援的時間寫進交付安排。

團隊技能運用：發揮既有專長與培養通才型專家

運用既有人才時一併調整原有任務

運用既有人才（Utilize existing talents），可以從成員已具備、卻尚未充分使用的能力著手。

例如，一位成員主要負責測試，也擅長把操作步驟寫得清楚。當產品準備上線，使用說明文件還沒有人處理時，團隊就可以與他討論是否願意運用這項專長，協助完成文件。

要找出這類能力，可以用技能矩陣（Skills Matrix）記錄成員熟悉的工作，以及完成這些工作時需要多少協助。盤點時可以請成員分享做過的任務、能獨立處理的範圍與希望參與的工作。

例如，除了記下「擅長寫作」，也確認他是否寫過操作指南、能否依使用者的情境安排說明，以及是否需要其他人檢查技術細節。

以下是三位成員對前端、測試與資安的技能矩陣範例，可依團隊目前的任務範圍填寫。

「主導」表示能在約定範圍內獨立處理工作並協助他人，「可支援」表示能承接部分任務，必要時需要確認，「學習中」則需要示範、練習與成果檢查。

例如，A 修改前端功能時，可請 B 協助確認測試範圍，涉及資安判斷時再由 C 參與。分派前仍需確認各自可投入的時間，並在完成實際任務後一起更新掌握程度。

運用既有專長時，需要一併重新安排成員原先負責的工作。如果這位成員需要兩天撰寫文件，就要確認這兩天的測試由誰接手，或哪些任務可以延後。

若文件與測試都必須在上線前完成，就需要安排支援，或重新討論交付範圍與日期。

重新分配任務能讓既有能力派上用場，也會改變原有工作的安排。

確認分工後，應同時更新文件與測試工作的負責人、完成日期及檢查方式。以文件為例，可以安排熟悉產品的同事核對操作步驟，再由預定使用者試讀，確認他能依說明完成操作。

通才型專家以深專長與廣協作減少交接等待

通才型專家（Generalizing Specialist）同時具備深度技術或業務領域技能（Deep technical/domain skills），以及支援跨領域協作的廣泛技能（Broad skills）。

前者讓他能在擅長的領域處理複雜問題，後者讓他理解其他角色的工作、業務規則與交付需求，並在能力範圍內協助完成相鄰任務。

這種能力組合可以用 T 型或 M 型人才來理解。T 型的直向代表一個領域的深度專長，橫向代表能與其他領域合作的廣度。M 型則用多個直向表示在數個領域具備深度。

以後端工程師為例，他可以精通程式設計與資料處理，同時理解訂單規則，也能設計基本測試，與測試人員共同判斷哪些情況需要驗證。

深專長讓成員能處理所擅長領域的複雜問題，廣協作則讓他能承接相鄰工作，減少跨團隊交接（Hand-off）的等待。

假設這位工程師正在修改訂單取消功能，他可以在開發時一併驗證可取消與不可取消的條件，發現錯誤後直接修正。這樣能減少把基本驗證全部交給測試團隊後，排隊、補充背景與退回修正的往返。涉及他尚未掌握的安全風險或複雜測試時，仍需邀請相應專家參與。

培養這類能力，可以從目前工作會用到的相鄰技能開始。例如，安排工程師與熟悉自動化測試的同事進行結對編程（Pair Programming），一起寫出訂單取消的測試，說明測試資料如何準備、結果如何判讀，再讓學習者練習修改其他案例。

學習者與指導者都需要預留時間，團隊也應與成員討論希望發展的方向，再安排適合的練習任務。

通才型專家能擴大團隊內可承接的工作範圍，培養過程中的時間與能力界線也需要納入安排。

完成一輪練習後，可以由學習者與指導者一起檢查成果，確認哪些任務已能獨立完成、哪些仍需共同檢查，並更新技能矩陣。

例如，成員已能自行撰寫訂單狀態的基本測試，遇到付款與退款交互影響的情況時，則安排熟悉該領域的同事一起確認測試範圍。

依缺口期間與受影響範圍選擇做法

根據需求持續時間安排選項

同樣是等待資安檢查，一次性的特殊需求與每次交付都會出現的需求，需要不同的人員安排。

若這次產品導入新的付款服務，需要專家協助檢查特定風險，可以評估限期借調，並約定檢查範圍與結束條件。若每次修改付款流程都得等待外部支援，就需要檢查團隊長期需要哪些能力，以及哪些工作可以由既有成員承接。

缺口持續多久、多久出現一次，會影響人員投入期間與技能培養的安排。需求反覆出現時，可以先盤點成員是否已有相關專長，再決定如何重新分配工作。

需要培養新技能時，則要考慮學習所需的時間。若產品後續都有穩定的跨功能交付需求，也具備長期配置人員的條件，就可以評估專注型解決方案團隊。調離成員適合針對特定任務的帶領負擔評估，並確認調整後留下的工作有人承接。

這些選項可以搭配使用。例如，團隊先借調資安工程師完成近期的上線檢查，再安排成員共同參與，學習後續會重複用到的基本檢查方法。

短期支援需要明確的完成日期，技能培養則需要預留練習與成果檢查的時間。借調結束前，雙方應確認哪些檢查已能由團隊自行完成、哪些仍需專家支援，以及下次需要支援時如何安排。

將原團隊與成員負擔納入決策

當兩個團隊同時需要同一名資安工程師，借調就牽涉兩邊的工作承諾。假設甲團隊希望他投入三天檢查新功能，乙團隊原先也安排他在這三天處理既有產品的安全問題，雙方就需要一起確認工作的急迫性、延後的影響與可替代的支援人選。

把兩件事都交給同一個人，再要求原定日期照常完成，會讓借調者自行承擔排程衝突。

團隊引導者（Team Lead）可以協助整理卡住的工作與所需支援，主管協調跨團隊的人員安排，成員則補充實際投入時間、目前進度與交接限制。

討論時要把必要會議、熟悉產品及交接所需的時間算進去。例如，借調三天之中若有半天需要取得權限與了解系統，就要依剩餘時間確認這次能完成哪些檢查。

人員調整方案需要交代哪些工作會延後、由誰承接，以及當事人能投入多少時間。同樣的檢查也適用於其他選項。改派成員撰寫文件時，要安排原有測試工作的承接者。培養新技能時，要預留指導者的時間。調離成員時，也要確認接手指導的人有餘裕。

若某項工作找不到承接者，就需要由有權決定的人確認延後、縮小範圍或另找支援，並將新的安排告知受影響的成員。

結語：從一項可檢視的調整開始優化團隊（Optimize Team）

為選定方案寫下試行約定

優化團隊可以從眼前一項卡住的工作開始。選定做法後，先把這次要解決的問題、參與成員、投入期間與檢視日期寫下來，讓受影響的人確認安排。

若要建立長期穩定的團隊，也可以先針對一段交付工作檢查所需能力與人員配置，並將長期投入的承諾納入討論。

例如，團隊每次發布都在等待部署支援，可以約定由一名熟悉部署的工程師，在下次發布前投入三天，與團隊一起完成部署準備、執行與結果確認。

原團隊同時指定這三天內的問題由誰接手，並記錄哪些任務需要延後。發布完成後，由借調者交接操作步驟與未解決事項，再依約定返回原團隊。

試行約定需要同時寫清楚要完成的工作，以及這次調整會占用誰的時間。在開始前指定一位成員記錄等待支援的時間，並約定發布後的檢視日期，邀請借調者與雙方團隊一起確認結果。

以等待時間與承接負擔決定下一步

檢視時，先確認原先卡住的工作是否完成，再比較等待支援的時間與成員實際投入的時間。如果這次發布的範圍或難度與前次差異很大，也要一起記錄，避免將所有變化都歸因於人員調整。

接著檢查原團隊是否出現新的延誤，以及借調者是否因往返處理兩邊的工作而增加負擔。

假設部署等待時間縮短了，原團隊卻因此延後一項重要修正，下次就需要重新安排支援期間或承接人選。

若團隊已學會處理基本部署工作，可以確認後續自行負責的範圍，將專家支援保留給尚無法獨立處理的問題。若同一個缺口在每次發布時都出現，就應重新評估長期配置與技能培養的安排。

把檢視結果寫回工作紀錄，明確決定這次安排要延續、調整或結束。下一次交付前，確認未完成事項的承接者、需要支援的工作，以及相關成員的投入期間，讓每個人知道接下來由誰處理什麼。

• 團隊不是組好就結束：Disciplined Agile 團隊演化策略解析
• 極限編程的「全隊」（Whole Team）：XP 全隊實踐與跨職能團隊的協作方式
• Accelerate Value Delivery