星期一早上的 Planning 很順。

螢幕上的工作看板只剩最後六張卡。

主持人逐張問：

「Ready？」

需求窗口點頭。

系統負責人點頭。

執行的人也沒有反對。

AI 會議助手把結果整理成：

Ready for this week: 6 / 6
Open blocker: 0
看起來沒什麼好討論的。

第一張卡當天下午就被拉進執行。

五分鐘後，負責的人在群組裡問：

「核准信在哪裡？」

沒有人回得出來。

需求窗口愣了一下。

「我說 Ready，是資料都補齊了，可以送核准。」

系統負責人回：

「我以為 Ready 是已經核准，可以開始改。」

另一個人補了一句：

「我理解的是排進本週就算 Ready，環境可以後面再準備。」

看板沒有壞。

AI 也沒有記錯。

四個人真的都說了 Ready。

只是他們說的不是同一個狀態。

一個字，讓流程看起來比實際簡單
很多團隊會刻意控制 Status 數量。

理由很合理。

如果每一個細節都變成一個狀態，看板很快就會長成：

Waiting for Data
Data Ready
Waiting for Approval
Approved
Environment Ready
Waiting for Execution
Ready to Execute
最後沒有人想維護。

所以大家收斂成幾個簡單標籤：

Open
Ready
In Progress
Done
問題不在標籤少。

問題在於大家開始把自己的前置條件，默默塞進同一個 Ready 裡。

需求窗口看到的是：

Input 已經完整。

系統負責人看到的是：

可以正式執行。

執行者看到的是：

我現在拿起來，不應該再遇到前置阻塞。

AI 如果只看到 Status 欄位，也只會得到一件事：

這張卡現在叫 Ready。

它不會因為讀到同一個 Label，就自動知道每個角色腦中的完成條件。

Shared Label 不等於 Shared State
真正影響工作的不是那個字長什麼樣。

而是這個 State 會讓下一個人做什麼。

如果 Ready 對某個人代表「可以送審」，對另一個人代表「可以執行」，那它就不只是語言差異。

它會改變下一步。

同一張卡，在不同人的理解裡其實是：

A：Ready → Send for approval
B：Ready → Execute change
C：Ready → Put into weekly queue
這也是為什麼單純要求大家「統一用詞」通常不夠。

大家本來就已經統一用詞了。

真正沒有統一的是那個詞背後的 operational meaning。

換句話說，看到 Ready 時，至少應該能回答兩件事：

進入這個 State 前，什麼必須已經成立？

以及：

進入之後，下一個人被允許做什麼？

如果這兩題的答案不同，畫面上再整齊的 Status 也只是把差異藏起來。

他們沒有把看板改成十五個狀態
事件發生後，有人第一個建議是重新設計整套 Workflow。

把核准、環境、資料完整度全部拆成獨立 Status。

最後沒有這樣做。

因為當下真正造成誤判的只有 Ready。

團隊先在它下面補了兩行：

Ready

Entry condition:

• Required information complete
• Approval completed

Allowed next action:

• Start execution
  其他細節仍然留在原本的 Checklist 和系統裡。

不是每個工作詞都需要被寫成規格書。

但只要一個 State 會驅動後續 Action，它就不能只剩一個大家各自解讀的名字。

下一次 Planning，主持人多問了一句
隔週又有一張卡被說成 Ready。

主持人沒有增加新的表格。

也沒有重新介紹流程。

他只問：

「這裡的 Ready，是已經可以開始執行了嗎？」

需求窗口打開附件。

核准完成。

執行者也確認需要的資料都在。

看板上的字還是同一個：

Ready
只是下面多了兩個很小的條件。

這一次，第一個拿起工作的人沒有再問：

「為什麼明明 Ready，我卻還不能開始？」