• 菜雞行為：把職場當成已經出好題目的考場
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代我採取的澄清方法、得到的結果，以及仍然不能由表格代替的判斷。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 01｜我很會解題，卻還不會確認題目，讓我看見自己會把一句功能要求自動補成程式題。Day 02｜真正的任務，是把一句要求拆成能驗收的問題，則把要求、問題、任務與方案分開，留下了一份仍可被質疑的工作定義。

這一篇不再重講「工單要能搜尋」的完整情境，而是處理下一步：當我知道題目還沒出完，要怎麼先確認會改變範圍的資訊，再決定值不值得寫程式。這裡的結果不是一張表填得很漂亮，也不是從此不再重做；而是讓誤解有機會在變成程式碼之前，先變成可以被指出來的文字。

我先把鍵盤推遠，把五件事排出順序

以前的我只要沒有開始寫程式，就會懷疑自己是不是還沒開始工作。後來我替自己加了一個很不帥、卻很有用的動作：先原樣記下要求，不急著把它翻譯成欄位、API 或畫面。

接著，我依序確認五件事：誰要使用、事情發生在什麼情境、真正卡住的是什麼、有哪些限制，以及什麼現象算完成。這五項不是需求工程的唯一正式模型，也不保證一次問完所有問題；我選這個順序，只因為前面的答案一變，後面的工作範圍往往也會跟著變。

我還會把內容分成「已知、假設、未知」。已知可以拿來定義工作；假設必須標示，不能因為寫進文件就假裝已確認；未知則依影響排序。會改變使用者、資料語意、權限或驗收的未知先處理，搜尋框放哪裡、採用哪個索引或套件，等題目邊界穩定後再談。

[要求原句]
    |
    v
[標示已知、假設、未知]
    |
    v
[定義問題、限制、驗收]
    |
    v
[比較候選方案]

這張圖刻意只畫一條主線。它沒有表示每個需求都得走完正式流程，也沒有把確認寫成一次性活動；它只提醒我，候選方案應該接在工作定義之後，而不是從要求原句直接長出來。

搜尋不是唯一答案，反而讓工作變小了

以下延續虛構的「粉鳥工單服務」，不對應任何真實公司、人物或專案。要求原句仍是：「工單要能搜尋。」

如果先採用 Day 02 的待確認假設：處理者真正需要的是找出失敗、尚未結案，而且仍需追蹤的工單，那麼「搜尋」就只是候選方案之一。不同方案支援的行動與前提並不相同：

候選方案從一個變成四個，看起來像是事情變多；但若真正問題與驗收得到確認，工作範圍反而可以縮小。原本的「搜尋」可能暗示要處理所有欄位、各種關鍵字、索引、分頁與畫面；收斂後，這次也許只需要在授權範圍內，重現地列出符合約定條件的工單，並清楚呈現被列入、排除或無法判定的原因。

這不是在虛構案例裡宣布異常清單一定勝出。資料狀態不可靠時，狀態篩選與異常清單都可能站不住腳；責任歸屬未建立時，待辦清單也只是把未知換個欄位存起來。表格的作用是讓每個方案接受同一組問題與驗收條件，而不是替人做最後決定。

我留下的證據，不是「感覺有比較快」

標題裡的「比較快」，不是我量過節省多少時間，也不是一個可以套用到所有專案的績效結論。我能支持的質性觀察比較樸素：當要求原句、假設、未知、候選方案與驗收被分開記錄，工作範圍可以在實作前被另一個人閱讀、重述與反駁。

我因此留下的證據，不是「大家應該都懂了」，而是幾項可以檢查的差異：要求原句沒有被改寫成既定方案；高影響未知仍看得見；候選方案能用相同條件比較；另一位讀者只看文件，也能重述使用者、問題、範圍、非目標與完成條件。若重述結果和作者想的不一樣，這份落差本身就是證據，代表誤解還沒有消失，只是幸好尚未藏進程式碼。

至於重做與誤解是否真的變少，我不替這個概括性經驗補百分比。能確認的是，有些原本會在實作或驗收時才爆開的分歧，現在可以提早在工作定義上被指出。這不保證後面不會改需求，但至少修改的是可見的假設與邊界，不必先拆掉一個自問自答的完整功能。

表格不能代替判斷，也不能無限延後實作

需求澄清卡或一頁文件不會自動產生共識。若只有我一個人把空格填滿，沒有讓相關角色確認資料語意、權限與完成條件，它只是把猜測排版得更整齊。文件也有版本；情境、限制或驗收改變時，舊定義不能繼續冒充現在的題目。

反過來說，「先不寫程式」也不是無限分析的免死金牌。當高影響未知已經降到可接受範圍，下一步仍應用最小、可驗證的實作或探查取得新證據。很小、容易復原、雙方已有共同理解的修改，可能只需要一句文字確認；若填表成本已高於誤解與重做的風險，就不必為了演出專業而把小事做成公文旅行。

粉鳥工程筆記：先縮小題目，再開始解題

我替這一組三日故事留下五個判斷：

• 保留要求原句，避免候選方案偽裝成已確認任務。
• 先問會改變使用者、問題、資料、權限與驗收的未知。
• 將已知、假設與未知分開；文件不會讓假設自動變成事實。
• 用同一份工作定義比較方案，記錄選擇與不選擇的理由。
• 結果以可重述、可反駁、可驗收的證據呈現，不補造時程與績效。

今天可以帶走的練習

對應工具：《一頁式工作定義》

挑一項最近收到、但尚未完全定義的功能要求，花十五至四十五分鐘完成一張需求澄清卡；本篇用《一頁式工作定義》承載這張卡。先移除公司名稱、可辨識人物、個資、內部網址、帳號、Token 與未公開資料，再依序寫下要求原句、使用者與情境、可觀察問題、範圍、非目標、限制、假設、候選方案與驗收方式。

明確產出是一頁以內的工作定義，以及另一位讀者的重述紀錄。請對方只看文件，回答「誰在什麼情況遇到什麼問題、這次要處理與不處理什麼、哪些仍未知、怎樣算完成」。若對方必須靠作者口頭補充，或把某個候選方案當成唯一要求，就把差異標回文件，先不要急著實作。

變更很小、容易復原，而且雙方對問題與完成條件已有共同理解時，可以把工具縮成幾句文字，不必完整填表。以下版本可直接複製，也能離開本系列獨立使用：

# 一頁式工作定義

## 用途

在選擇方案前，將問題、範圍、限制、未知與驗收整理成可被閱讀、質疑與重述的一頁文件。

## 使用時機

- 工作跨角色、資料或權限邊界。
- 一句要求可能對應多種方案。
- 驗收容易各說各話，或重做與交接成本較高。

## 不適用情況

- 變更很小、容易復原，且雙方已有共同理解。
- 填寫與維護成本高於實際風險。
- 只是為了證明有流程，文件不會支援任何決策。

## 工作定義

- 要求原句：
- 使用者與情境：
- 可觀察問題：
- 目標：
- 範圍：
- 非目標：
- 限制：
- 已知：
- 假設：
- 未知與確認方式：
- 候選方案與取捨：
- 交付物：
- 驗收方式：
- 風險與未完成事項：

## 精簡示例（虛構工單系統）

- 要求原句：工單要能搜尋。
- 使用者與情境：待確認假設；處理者需要辨識仍待追蹤的工單。
- 可觀察問題：失敗、未結案與待追蹤的資料語意尚待確認。
- 候選方案與取捨：比較關鍵字搜尋、狀態篩選、異常清單與責任人待辦；尚未選定。
- 驗收方式：用約定樣本重現列入與排除結果；不得顯示未授權資料；資料不足時明確標示無法判定。
- 未完成事項：狀態定義、責任歸屬與可接受處理時限仍待確認。

## 使用提醒

- 已知、假設與未知分開記錄；不要為了填滿欄位而猜答案。
- 只保留會影響範圍、方案、風險、交付或驗收的資訊。
- 不放入密碼、Token、個資、公司機密或可辨識人物。
- 請另一位讀者只看文件重述問題與完成條件，將差異記回文件。
- 情境或限制改變時更新版本；舊文件不自動代表目前共識。

下一篇

把題目邊界釐清，不代表我從此不會搶答。下一組要處理的是另一種更細微的學生味：問題才剛露出輪廓，我又開始用最熟悉的框架替它決定形狀。Day 04｜需求才一句話，我已經開始選框架，會先停在這個選擇過早發生的情境。