同時開太多工作怎麼辦？用完成能力設定在製品上限

用任務狀態、完成速度與滿載接單規則，估算團隊可承受的在製品上限，並透過每週回看調整工作節奏。

團隊同時開著許多工作，常見原因不是大家不夠努力，而是開始新任務很容易，完成並交接卻被等待、切換與臨時插單拖慢。要減少塞車，可以先為「正在做」定義共同邊界，盤點實際完成速度，再用小幅試行找出團隊能穩定承接的在製品上限。以下用可觀察的狀態和明確接單規則，讓上限成為調整工作流的工具，而不是催促個人的數字。若只要求每個人加快速度，常會讓更多工作同時停在半途；明確限制名額，則讓團隊先完成手邊工作，再騰出空間接新需求。這套方法適合多人協作、且能辨認開始與完成狀態的任務；重點在共同約定和回看，不是讓每種工作都照同一節奏前進。

界定進行中狀態

先把「進行中」寫成可觀察的狀態，而不是看板上被移到某欄的印象。任務進入進行中，應以團隊真的開始投入時間為準：有人已接手，並在本工作時段內做了推進工作的動作，例如訪談、整理資料、製作初稿或檢查結果。只有被指派、排進行事曆、等客戶回覆或等內部核准，都不代表正在處理；這些各有原因，應另標「待開始」或「等待中」，才不會把尚未能動的工作算進執行容量。可以把每件工作設成未開始、進行中、等待、完成四個狀態，再替「等待」填上等待誰、何時追蹤。像「整理網站改版需求」如果負責人已完成訪談並開始歸納，才算進行中；若只是收到需求，尚未排出訪談，就留在未開始。已開始卻因素材缺漏停下來，則轉成等待，並註明要向誰拿資料。若同一任務有多個可獨立交付成果，拆成不同卡片；若只是同一成果的幾個步驟，留在一張卡並標示下一步，避免用拆卡把同一工作藏成多件。這個界線要簡單到不同人看同一件事會填出相近狀態。試行前先寫出開始與停止條件，遇到模糊案例由負責人當天確認，日後才有可信的數量可比較。也可替每種工作寫一句判斷題：「現在有誰正在做哪個具體步驟？」若回答只有「等某人回覆」或「排在本週」，便不算正在執行。每天更新狀態時，順手記下最後推進日；連續多日沒有下一步，就請負責人確認要續做、轉等待或重新排序。狀態不必記精確工時，重點是是否真的占用當下的處理能力。若判斷不同，先確認能否實際推進，再校正欄位。

觀察同時工作數

定義狀態後，先觀察團隊平常同時開著多少件，不急著立刻限縮。選一個固定時點，例如每天收工前，連續記錄看板上進行中的件數，也記下其中等待、被退回或跨人交接的件數；若不同工作差異很大，再按工作類型或主要負責角色分組。不要把整週新接到的總量當成同時進行數，也不要只看某次會議截圖，因為兩者都會漏掉日常起伏。記錄時只需日期、進行中數、等待數、當日完成數及一行備註，不必另造複雜表格。舉例來說，假設週一記到八件、週三十件、週五仍有九件，這組數字只說明那幾個觀察點的狀態，不能單憑最高值就判定團隊容量。再看哪些工作持續留在清單、哪些由等待轉回執行，以及新開的任務是否增加。若同一時段每人都各自開卡，整體數字也可能掩蓋稀缺角色被多件工作共用；因此可另記「需要同一位專家處理」的件數。若記錄成本讓團隊無法持續，先減少欄位而保留固定時點與狀態定義。觀察目的是找出流動和停滯的位置，並非替個人排名。若工作會在多人間往返，快照仍以任務件數計一次，但補記卡在哪個角色，否則總數會低估等待。每次觀察要用同一時段並保留背景，例如當週是否集中交付或有人休假。可以由一人讀看板、一人核對實際工作；發現狀態不一致時，先修正定義再累計。若記錄期只碰到低峰或特殊活動週，就延長觀察，避免拿單一週次當作容量常態。若交接頻繁，另記目前停在哪個角色，別把同一工作誤算成新件。

對照實際完成速度

在製品數要和完成速度一起看，否則只知道工作很多，卻不知道上限應落在哪裡。先選範圍相近的工作，統一「完成」的定義，例如成果已交付、必要檢查完成，且下一位接手者知道如何使用；只把已完成的件數算入，不把開始數、估計進度或工時當作完成。以週為單位記錄一段可比較的期間，並註明假期、臨時支援或工作類型改變，避免把偶然的一週當成常態。假設某小組四週共完成八件同類工作，平均是每週兩件；這是該組在這段觀察內的平均，不代表每週必定能交付兩件，也不能直接套用到其他類型。若同時新增的工作平均每週五件，而完成約兩件，待辦自然會累積；應先討論需求排序、拆小交付或承接節奏，不能只把更多任務壓進進行中。可把完成件數按小型與大型工作分開，或將範圍相近的任務放在同一組比較。看速度時也檢查從開始到完成經過多久，以及卡住多久；相同件數若長期等待，可能需要釐清交接或決策流程。這些數字用於安排系統容量，不是個人績效配額。若任務尺寸差異大，不要把「做完三件」直接和另一週的三件比較；先分組，或挑範圍與交付條件相近的工作。未完成的工作不折算成半件，也不因已投入很多時間就算完成。每週同時記下新進件數與完成件數，能看出待辦增加是需求流入較快，還是執行中的卡點使交付放慢。若完成數忽高忽低，查看工作組成和阻塞紀錄，再選擇可比的區間，不必用單一數字做承諾。

設定試行上限

有了基準後，先設定一個團隊共同遵守、期限短且容易回看的試行上限。可從目前常見在製品數往下調一小步，而不是一次壓到理想值；若工作大小差距明顯，先按類型設上限，避免一件大型任務和一件簡單任務被當作同等負荷。另一種估算方式是把近期每週完成速度，乘上團隊希望工作在手上停留的週數，得到初始參考值，再依等待與實際變異修正。舉例，假設同類工作平均每週完成四件，團隊先希望在製工作約一週半，四乘一點五得到六件，可把六件當作試行起點；這是根據假設資料的估算，不是承諾或通用標準。把限制說清楚：算哪些工作、誰共用名額、等待中的卡片如何計算、拆分後如何避免重複計數。若某角色是共同瓶頸，也為該角色的待處理工作另設較小上限，免得全隊總數看似合理，工作卻都排在同一個人前面。試行期間不應因數字滿了就隱藏任務；新任務先排隊，並記下來源與期待時間。每週檢視完成量、等待時間和未完成原因，再決定維持、微調或撤回；若交付品質或安全檢查被犧牲，立即修正規則。也要檢查名額是全隊共用，還是由不同專業角色分別承擔。若一位設計者同時支援多個案子，即使每案各只開一件，他仍可能被多頭打斷；可為這項稀缺角色設定子上限，並由排序者協調需求先後。訂出上限後，先公告試行起訖、負責更新的人與例外核准者，讓每個人遇到滿載都照同一流程處理。沒有明確例外負責人時，先暫停新增並交由指定主管排序，不要靠個人自行判斷誰的工作較重要。

定義滿載接單方式

上限真正有用的時候，是新需求到來而名額已滿時，團隊知道接下來怎麼做。先設一個看得見的待排隊清單，記下需求、提出者、期望時間、影響範圍與目前仍缺的資訊；有人提出工作不等於團隊已答應開工。負責排序的人應先判斷截止時間是否有外部依據、延後會造成什麼影響、能否縮小交付範圍，以及目前哪件工作可先完成或暫停。不要把每個口頭上的「急」都變成例外；可預先約定少數明確條件，例如營運中斷、既定承諾面臨失守，並由指定角色確認。若新工作確實優先，採用「一件進、一件出」：先決定暫停或移後哪件舊工作，更新負責人與下一步，再讓新工作進入進行中。假設三個名額都已使用，主管又提出今天要處理的需求，團隊先查明今天是硬性期限還是偏好，再由排序者和需求方選定被延後的項目；不得默默讓第四件也開工。若資訊不足，就先安排短暫釐清，而非把整個大型需求當成已啟動。接單後回覆何時重排、需要什麼資料，讓提出者知道目前狀態。滿載時也要讓需求方看得到取捨：預估可開始的時點只是依現有隊列推算，遇到範圍或優先順序變動就重新確認。若交付日期是團隊已確認的外部承諾，排序時要把受影響工作與溝通責任一併列出；不能只把新需求插入而不通知原需求方。對可先做的部分，確認它有獨立用途且不會帶來重工，再拆成小範圍納入排程。若沒有任何工作可停或延後，就明確回覆需先重新排期或增加可用處理能力，不要用加班作為預設解法。

每週回看阻塞原因

每週回看時，不只問「為什麼還沒做完」，而要找出工作在哪個環節停住、誰能推動下一步，以及現行限制是否貼合實際。逐件檢視仍在進行或等待的工作，記錄阻塞類型，例如等資料、等決策、跨人交接、需求變更、工作範圍過大或共用資源不足；同時寫下解除阻塞的下一個動作、負責人和回看時間。比較幾週後重複出現的原因，再挑一項可由團隊控制的改變試做，例如提早檢查輸入資料是否齊全、把交付拆成可先確認的小段，或固定安排決策時間。假設一週盤點十件未完成工作，其中四件都在等同一份資料，這是值得查明的共同卡點；先確認資料由誰提供、何時提出需求，以及缺件時是否能先做別的部分，而不是直接把上限從十件改成六件。若阻塞來自客戶或其他部門，記下已發出的請求和下次跟進時間，將工作轉為等待，讓在製數據反映團隊當下能做的事。下一週再比較相同類型的等待是否減少、完成數是否改變。若上限造成更多閒置而沒有改善交付，檢查規則是否過緊或工作分組不當；若名額常滿且等待仍長，則先處理共用瓶頸或調整接單次序。回顧以流程改善為目的，避免把單週波動歸咎於個人。回顧時可把「團隊可處理」與「需外部回覆」分開，前者安排改善，後者保留催辦節點；兩者混在一起，容易讓上限看似失效。每次只改一項規則並留下起始數字，例如等待件數或週完成數，下一週才看得出改動是否帶來差異。若沒有改善，撤回或換一個原因處理，不要堆疊更多規定。也邀請執行者補充看板看不到的切換與返工原因，讓決策依據完整。下一步，挑一種工作類型，用固定時點連續記兩週，帶著完成數、等待原因與滿載時的決策方式，和團隊一起訂出試行上限。延伸資訊可從 ZhenheAI 官網 開始。