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

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

這篇在三日故事中的位置

Day 01 留下的問題：一句「工單要能搜尋」不代表題目已定義完成。本篇只處理 Task：把要求拆成可討論、可驗收的工作定義；做法與結果留給 Day 03。

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

我以前把 Task 理解成「接下來要做的功能」：要求加搜尋，任務就叫搜尋，交付時各自想像。虛構的粉鳥工單服務繼續往下走，替每一層標示狀態，避免推測升格成需求：

這張表把看起來合理與已經確認分開；若真正問題不是追蹤失敗工單，問題與任務兩列都得重寫。

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

我先確認答案一變、任務就跟著變的三件事：使用者與行動——找到工單後要判斷、聯絡還是轉交，沒有下一步，搜尋只是多個輸入框；資料語意——「失敗」與「未結案」由哪個狀態判斷，資料分不出來，任務就含資料缺口；權限與責任——誰能看、誰負責，未確認就留在未知清單。索引與元件等邊界穩定再談。

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

一份仍待確認的工作定義可以是：

在授權範圍內，讓處理者依約定條件辨識失敗但未結案的工單，取得後續判斷所需資訊；資料不足時明確顯示缺口，不以猜測補齊。

它刻意不指定搜尋或篩選，讓候選方案能被比較。驗收寫可觀察條件：約定的工單能重現地找出、不符的不混入、無權限的不出現、狀態矛盾不假裝成功。非目標寫明：不重做整套系統、不保證自動修復。

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

• 要求保留原句，不先改寫成技術題。
• 已知、假設、未知分開；假裝知道最危險。
• 限制、責任與非目標會改變範圍，不能事後補。

小修改口頭確認就夠；跨角色或重做成本高時才值得完整記錄。

今天可以帶走的練習

拿 Day 01 記下的要求完成《問題陳述範本》：分開原句與方案，寫出角色、情境與可觀察問題，把資料與權限分成已知、假設、未知。產出一頁以內的陳述，請另一位讀者只看文件重述問題與完成條件。

對應工具：《問題陳述範本》。

# 問題陳述範本

用途：把問題寫成可討論、可修正的陳述，不直接鎖定方案。
使用時機：一句要求可能對應多種方案、驗收容易各說各話時。

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

提醒：已知、假設與未知分開；不放機密、個資與可辨識人物。

下一篇

從這份定義出發，下一篇要澄清高影響未知、比較候選方案，留下支持結果的證據——Day 03｜我先不寫程式，反而比較快找到該做的事。