讓「等待決定」看得見：不再追問「進度如何？」的狀態設定方法
關於本連載
「與 AI 協作的團隊任務管理」是寫給已經開始在工作中使用 ChatGPT 或 Gemini 的設計製作、客戶專案類小團隊的連載，共 6 篇。可以從任何一篇開始閱讀。
星期一的例會。大家把任務清單從上往下逐項看過。「首頁設計怎麼樣了？」「處理中。」「徵才頁面呢？」「也在處理中。」
清單裡幾乎全是「處理中」，看起來每一項都進行得很順利。可是，哪些任務是現在正在動手做的，哪些是在等某個人回覆的，光看清單是看不出來的。
「所以，現在到底是哪幾項卡住了？」
上一篇，我們從「做」的任務裡拆出了「決定」的任務。但即使拆開了，如果表示狀態的只有「處理中」這一個，還是看不出卡在哪裡。
這一篇以設計製作、客戶專案為例，介紹如何設定能看出「等待決定」的狀態，以及如何用它來開例會。
註：本文由 GeckoFlag 的開發者撰寫。
「處理中」裡混著 3 種狀態
把「處理中」的任務一項一項打開來看，內容大致可以分為以下 3 種：
- 自己正在動手做：在做設計、在寫文案、在用 AI 產生方案並比較。
- 在等公司內部某個人的判斷：請總監或主管看過，正在等回覆。
- 在等客戶的回覆：已經請客戶確認，正在等對方回覆。
如果 3 種都同樣是「處理中」，任務沒有進展時，就看不出原因。是工作進度落後了，還是在等回覆？如果在等，又該去找誰？光看清單看不出來，結果只好一個一個去問「進度如何？」。
正如第1篇所寫，有了 AI、工作變快之後，讓專案停下來的往往不是工作本身，而是「等待決定」。這些等待決定的事被藏在「處理中」裡，才是最大的問題。
例如，會有這樣的情況。最新消息頁面的設計，在例會上一直被回報為「進行得很順利」。負責人認為，把設計稿寄給客戶之後，自己的工作就算完成了。
然而，客戶那邊兩週都沒有回覆。發現時，已經是上線日的前夕。只好重新請客戶確認，並連同上線後的工作一起，重新安排時程。
因為任務的狀態一直是「處理中」，所以誰都沒有發現它在「等待」。
依「在等誰」來劃分狀態
因此，要把狀態分成能看出「下一步由誰來行動」的形式。例如，可以分成下面 6 種：
| 狀態 | 使用時機 |
|---|---|
| 未開始 | 還沒有著手 |
| 構思中 | 正在做方案、比較方案（用 AI 產生方案的階段也算在這裡） |
| 等待內部確認 | 在等公司內部某個人的判斷 |
| 等待客戶確認 | 已請客戶確認，正在等回覆 |
| 已決定・製作中 | 方向已定，正在做收尾工作 |
| 完成 | 已經結束 |
重點是把等待決定分成「內部」和「客戶」兩種。
為什麼要把等待分成兩種
因為等待的對象不同，要採取的行動也不同。如果在等公司內部的人，大多數情況下說一聲就能解決。如果座位離得近，也許當場就能決定。
如果在等客戶，就沒那麼簡單了。可能對方公司內部還在跑確認流程，也可能對方沒有理解需要決定什麼。在催促之前，有時需要先重新檢視確認請求的提出方式。
連載如何向客戶提出確認請求，在第5篇「不因客戶的『等待確認』而停擺的推進方式」中有詳細介紹
狀態不要設太多
分得越細，看起來越準確，但設太多是大忌。一旦選起來麻煩，狀態就沒有人更新了。沒有人更新的狀態，等於沒有。
大致以 5～7 個為宜。即使上面的 6 個不夠用，也建議先照這樣用一個月，只在真正遇到困難的地方再補充。
事先約定好變更狀態的時機
如果每個人變更狀態的時機各不相同，狀態很快就會和實際情況脫節。團隊裡可以事先做好下面這樣的約定：
- 一提出確認請求，就當場改為「等待內部確認」或「等待客戶確認」
- 收到回覆並做出決定後，把決定類任務改為「完成」，把進入收尾階段的製作類任務改為「已決定・製作中」
- 收到回覆後需要重做方案時，改回「構思中」
「一提出請求，馬上改。」只要守住這一條，清單上的狀態就幾乎和實際一致。
在一個地方看清所有等待決定的事
劃分好狀態後，下一步是讓「等待」有多少一目了然。
這時看板就很方便。任務卡片依狀態分開排列，「等待確認」那裡的卡片越積越多，一眼就能看出來。
比起正在製作的卡片，等待確認的卡片更多。這就是專案開始停擺的訊號。
知道了等待的數量，再對照到期日來看。處理的順序，從「還在等待、眼看要超過到期日的」開始。離到期日還很充裕的等待，不必急著去催。
還有一點很重要，就是「從什麼時候開始等的」。有些工具不會自動顯示等待的天數。這時，可以在請求確認時的留言裡寫上日期，例如「10月20日已請求確認」，日後再看也能知道。
改變例會的議程
透過狀態能看見等待之後，例會的進行方式也可以改變。不再從「進度如何？」開始，而是依下面的順序確認：
- 本週需要客戶決定的事，以及本週內公司內部必須決定的事：期限將近的等待決定。當場確認由誰、在什麼時候之前、決定什麼
- 正在請客戶確認的事：還沒有回覆的、需要催促的。決定由誰、用什麼方式去催
- 上週決定的事及其理由：讓做決定的人以外的人也知道方針已經改變
- 工作的進度：最後簡短地說。只談遇到困難的任務
可以想成是把例會從「回報進度的場合」，變成「決定由誰、在什麼時候之前、決定什麼的場合」。工作進度大多看狀態就能知道，口頭回報簡短即可。
例如，調整了議程順序之後
以前，例會要把任務從上往下逐項問「這個怎麼樣？」，要花將近 1 小時。改成從「本週要決定的事」開始之後，有時 30 分鐘左右就能結束。
不只是時間變短了，談話的內容也會改變。最先出現的不再是「進行得很順利」這樣的回報，而是「這件事需要客戶在本週五之前決定」。
等待決定越積越多時的檢查重點
即使劃分了狀態、改變了例會，等待決定的事有時還是遲遲沒有減少。這時，打開正在等待的任務，確認以下 4 點。
1決定的人是否明確
沒有寫明決定的人，或是像「團隊一起決定」這樣由多人決定的任務，很難定下來。決定的人只設一位。
連載為什麼決定的人只設一位，在第2篇「任務要依『要決定的事』來建立，而不只是『要做的東西』」中有介紹
2選項是否太多
是不是用 AI 產生了 10 個方案，就原封不動拿給對方看？選擇的一方負擔太大，判斷就會被往後拖。給別人看之前，先縮減到 2～3 個方案。
連載如何篩選用 AI 產生的方案，在第4篇「AI 給出的方案不是『成品』，而是『判斷素材』」中有詳細介紹
3是否寫明了期限
沒有期限的確認請求，難免會被往後放。要寫明「希望什麼時候之前得到回覆」，並附上理由。
4是否清楚傳達了希望對方決定什麼
是不是只寫了「請確認」？對方也許是因為不知道該看什麼、該回答什麼，才遲遲沒有回覆。要寫成能看出怎麼回答的形式，例如「A 和 B 要選哪一個？」。這一點在第5篇中也有詳細介紹。
在 GeckoFlag 中的實踐範例
以下是在 GeckoFlag 中實踐上述做法的範例。
為等待類狀態設定醒目的顏色
GeckoFlag 的狀態可由管理員在設定畫面中新增與編輯。可以設定名稱與顏色，最多可登錄 10 個。把上表的 6 個狀態登錄進去，只把「等待內部確認」和「等待客戶確認」設成醒目的顏色，在議題清單和看板上，等待中的議題就會馬上映入眼簾。
整理已經在使用的狀態時需要留意。刪除正在使用的狀態後，原本是該狀態的議題會顯示為「未設定」。請先把議題移到新的狀態，再刪除舊的狀態。操作步驟整理在手冊的「新增與編輯狀態」中。
在看板上查看等待的數量
在看板中選擇專案後，議題卡片會依狀態分開排列，並顯示各自的數量。看「等待確認」的數量，就能知道這個專案有多少事在等待決定。
在 PC 上，也可以拖曳卡片來變更狀態（v1.8.0 起）。變更後，會自動加上一則與在議題畫面中變更狀態時相同的留言，因此狀態是什麼時候改變的，會留在議題裡。
另外，看板是以專案為單位顯示的。無法把多個專案合併在一個看板上查看，需要逐一切換專案確認。
例會上先顯示「等待確認」的議題
議題清單可以依狀態篩選。例會開始時，先顯示「等待客戶確認」和「等待內部確認」的議題，一邊看到期日，一邊從本週內需要決定的開始確認。可以想成是一邊看著這個畫面，一邊進行上面議程的第 1 項和第 2 項。只要隨時更新狀態，就能一次看清所有正在等待的事項。「等待內部確認」的議題，可以從能當場決定的開始逐一處理。
請求確認時，在發表留言的同時變更狀態
發表議題留言時，可以同時變更狀態、負責人和日期。寫下「已寄出設計稿並請求確認（10月20日）」這樣的留言，直接把狀態改為「等待客戶確認」後發表。請求的內容、開始等待的日期和狀態的變化，就會一次記錄下來。
GeckoFlag 沒有自動顯示等待天數的功能。建議像這樣把開始等待的日期寫在留言裡。
看板和留言的使用方式，可以在 Demo 中試用。不妨親手試試看，劃分狀態後清單會是什麼樣子。
總結
- 「處理中」裡混著正在動手做的任務、等待公司內部判斷的任務和等待客戶回覆的任務
- 依「在等誰」來劃分狀態，就能看出卡在哪裡、該去找誰
- 狀態控制在 5～7 個左右，把「一提出請求，馬上改」作為團隊的約定
- 例會不從「進度如何？」開始，而是從「本週要決定的事」開始
能看見等待之後，到處問「進度如何？」的時間就會減少，省下的時間可以用在「請誰決定什麼」上。
下一篇將介紹如何把用 AI 產生的方案當作「判斷素材」來看待，並留下比較過的方案和選擇的理由。