• 菜雞行為：把職場當成已經出好題目的考場
• STAR 階段：T (Task)
• 本篇定位：把真正該完成的任務、限制與成功條件定義清楚。

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

這篇在三日故事中的位置

Day 01 留下的問題是：一句「工單要能搜尋」，還不足以證明題目已經定義完成。這一篇只處理 Task：把表面要求拆成可討論、可限制、可驗收的工作定義。至於實際怎麼澄清、最後選哪個方案，以及產生了什麼結果，留給 Day 03。

我以前容易把 Task 理解成「接下來要做的功能」。於是要求加搜尋，我的任務就叫做做搜尋；要求加匯出，我的任務就叫做做匯出。名稱聽起來完全一致，交付時卻可能各自想像不同。這不是工作拆得不夠細，而是我根本還沒有說清楚：要改善誰的哪個情境，以及什麼變化才算完成。

「加搜尋」是候選答案，不是工作定義

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

如果我直接把這句話抄進待辦事項，它只保留了提出者目前想到的功能。Task 要補上的，是功能背後的工作情境。為了不讓合理推測偷偷升格成需求，我會替每一層標示目前狀態：

這張表不是正式的需求工程模型，只是我用來避免搶答的分類。它最重要的功能，是把「看起來很合理」與「已經確認」分開。若後來確認真正問題不是追蹤失敗工單，整個問題與任務欄都應改寫，而不是硬把搜尋方案保留下來。

先確認那些會改變題目的未知

未知不可能一次清空，也不需要每個細節都在第一輪問完。我要先確認的，是答案一變，任務就會跟著改變的資訊。

第一個是使用者與行動。誰要看這批工單？找到之後要判斷、聯絡、重試，還是轉交？如果結果沒有支援下一個行動，搜尋很可能只讓畫面多一個輸入框。

第二個是資料語意。「失敗」由哪個狀態或事件判斷？「未結案」是否等於沒有結案時間？現有資料若無法區分，任務就不只是查詢，還包含資料定義或來源缺口。這類未知不能靠我看欄位名稱猜答案。

第三個是權限與責任。哪些角色可以看哪些工單？系統負責列出候選項目到哪裡，後續處理又由誰負責？若責任人尚未確認，就應把它留在未知清單，不能因為表格需要填滿，順手指定給某個角色。

最後才是驗收時會觀察的條件：哪些資料必須被找出、哪些不得出現、條件如何重現，以及「可接受時間」到底是多少。沒有真實數據與約定前，我不會替案例補上一個看似專業的秒數或資料量。

相對地，搜尋框放在哪裡、採用哪個索引、使用哪套元件，可以等任務邊界穩定後再決定。延後不是忽略；它只是承認現在先回答這些問題，對工作範圍的影響比較大。

可驗收，不等於先把解法寫完

以這個虛構案例來說，一份仍待相關角色確認的工作定義可以寫成：

在授權範圍內，讓工單處理者依約定條件辨識失敗但未結案的工單，理解工單為何被列入或排除，並在約定的處理時限前取得後續判斷所需資訊；資料不足時，必須明確顯示缺口，不以猜測補齊。

這段話刻意沒有指定全文搜尋、篩選器或報表。它先把使用者、情境、期望行動與失敗邊界放進來，讓候選方案可以被比較，而不是先被需求原句綁死。

接著才能談驗收。至少要能確認：符合約定狀態的工單可以被重現地找出；不符合條件的工單不會混入；沒有權限的資料不會出現；狀態缺漏或矛盾時不會假裝判斷成功。系統負責正確篩選、套用權限並呈現判斷所需資訊，處理者負責後續業務決定；至於誰維護狀態定義，仍要在實際情境中確認。

非目標也要寫出來。本次不預設要重做整套工單系統、不保證自動修復失敗工單，也不因為資料品質可能有問題，就把所有歷史資料整頓一併塞進範圍。若那些工作後來成為驗收前提，再另行調整任務，而不是用一句「順便處理」藏起來。

需求澄清並不是把開工日往後拖，而是承認工程工作已經開始，只是此刻的產出不是程式碼，而是一個別人能檢查、反駁與驗收的工作邊界。對我來說，這比把模糊要求切成十張技術待辦更困難，也更接近真正的 Task。

粉鳥工程筆記：把推測留在推測欄

我替這一階段留下五個判斷：

• 要求保留原句，不先替提出者改寫成我熟悉的技術題。
• 問題描述受影響的人、情境與行動，不直接指定方案。
• 已知、假設與未知分開記錄；不知道不是缺格，假裝知道才是。
• 限制、責任與非目標會改變範圍，不能等實作快結束才補。
• 驗收寫可觀察條件；未確認的數字、角色與資料語意不自行補造。

這套整理不必套在每一個小修改上。變更很小、容易復原，而且雙方對問題與完成條件已有共同理解時，一句文字確認可能就夠了。當工作跨角色、碰到資料或權限、驗收容易各說各話，或重做成本較高時，才值得留下完整紀錄。

今天可以帶走的練習

找出 Day 01 記下的一句功能要求，花十五至四十五分鐘，完成一份[《問題陳述範本》]：

1. 原樣抄下要求，另外寫出第一個想到的方案。
2. 寫出受影響角色、使用情境、可觀察問題與希望支援的行動。
3. 將資料、權限、責任、時限與相依條件分成已知、假設與未知。
4. 寫出這次刻意不處理的非目標。
5. 用可觀察條件描述完成，不填入尚未確認的數字或角色。

明確產出是一頁以內的問題陳述與工作定義。請另一位讀者只看文件，重述「誰在什麼情況遇到什麼問題、這次要改善什麼、哪些仍未知、怎樣算完成」。若對方必須靠作者口頭補充，或把候選方案誤認成既定任務，就還不能通過。

練習內容不得包含公司名稱、可辨識人物、個資、內部網址、真實帳號、Token 或未公開資料。若只是低風險、可立即復原的小修改，可縮成幾句文字；表格能降低誤解、重做或交接成本時才值得使用。

# 問題陳述範本

## 用途

將問題寫成可討論、可修正的陳述，而不是直接鎖定方案。

## 使用時機

- 章節 OJT。
- 需求、設計、審查、交付或回顧需要留下可被他人理解的證據時。

## 不適用情況

- 問題極小且口頭確認已足夠。
- 填表成本高於實際風險。
- 只是為了證明有流程，而沒有實際決策用途。

## 範本

| 目前情況 | 受影響對象 | 可觀察問題 | 影響 | 期望改善 | 不先假設的方案 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## 使用提醒

- 只填寫會影響判斷、交付或驗收的資訊。
- 不放入密碼、Token、個資、公司機密或可辨識同事的內容。
- 不使用模糊百分比或「應該可以」取代證據。
- 表格不是目的；能降低誤解、風險或交接成本才有價值。

下一篇

現在已經有一份可被質疑、也可被驗收的工作定義。Day 03 再從這個邊界出發，處理下一步：我如何先澄清高影響未知、比較候選方案，並留下足以支持結果的證據。