• 菜雞行為：把本機或 Demo 能跑當成已經交付
• STAR 階段：T (Task)
• 本篇定位：定義從展示品走到可驗收成果所需的責任、條件與非目標。

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

這篇在三日故事中的位置

Day 07｜本機能跑，我就以為事情差不多了，停在成功證據只涵蓋本機與展示。本篇把「所以還欠什麼」整理成可驗收的任務；行動與結果留給 Day 09。

「讓匯入上線」是一句要求，不是一個任務

粉鳥工單服務仍是虛構案例。我原本把接下來的工作理解成「把 Demo 搬到正式環境」，只差一個部署動作。但把「上線」攤開，底下藏著一排沒定義的事：資料從哪來、跑在誰的環境、用什麼權限、壞掉誰知道、做到哪算交付。任務不是搬運展示品，而是把這些條件一件件變成可檢查的事。

完成有四層，我手上的證據只蓋到前兩層

我把「完成」拆成四層，各自要求不同證據：

本機與展示的成功，只涵蓋第一層與第二層的一角；Day 07 的錯覺正是四層共用同一個畫面，證據卻完全不同。

正式資料不是放大版的測試資料

最容易被低估的是資料。正式資料不是放大版測試資料：它有缺值、髒欄位、重複與歷史格式，量大到手動重跑救不回來。必須先確認的未知有兩個：真實資料樣本長什麼樣、受限帳號權限怎麼申請，這兩件會推翻設計；監控告警可以延後。

非目標與責任邊界，跟完成條件一樣重要

任務也要寫不做什麼：不做自動修復、不重寫工單流程、尖峰量另案處理；來源資料品質由來源系統負責，匯入端負責驗證、記錄與拒收。少了非目標，小功能會膨脹到交不了；少了責任邊界，每個壞資料都是我的急件。

說完成之前，先指明是哪一層

「完成」兩個字要接得上層級，否則對方只能猜；正式資料用真實樣本確認，不靠想像；非目標與責任邊界跟完成條件一起寫，任務才有形狀。

今天可以帶走的練習

挑一項手上的功能，用《完成定義表》寫下程式完成、功能完成、整合完成與交付完成的條件與證據，補一句本次非目標。產出是一頁定義表，另一位讀者能說出功能目前停在哪一層即通過。一次性腳本或純個人工具不必填表。

對應工具：《完成定義表》。

# 完成定義表

用途：區分程式完成、功能完成、整合完成與交付完成。
使用時機：要回報進度、約定交付範圍或驗收時。
不必使用：一次性腳本或純個人工具。

| 層次 | 完成條件 | 證據 | 未完成事項 |
| --- | --- | --- | --- |
| 程式完成 | 本機以測試資料跑通 | 測試紀錄 |  |
| 交付完成 | 部署、權限與失敗處理就緒 | 驗收清單 |  |

提醒：說完成前先指明層級；不放機密、個資與可辨識人物。

下一篇

任務有了層級、條件與邊界，差距還在原地。Day 09｜我用差距表把展示品推到可驗收成果，會交代我怎麼逐項關閉它們。