完成的定義
一句話定義
「完成」是組織共識，不是技術事實——一個任務是否真的完成，由三個對外（用戶 / 交付 / 回饋）而非對內（程式寫完 / 上線 / demo 過）的條件共同判定；沒有共識，組織會在「80% 完成的殭屍專案」之間漂移。
核心要點
1. Roman Kudryashov 的三問判定
來源：2026-05-01-曼報-EP63-當每件事都很重要 第 6 步——
- 使用者的問題真的被解決了嗎？
- 解法真的被交付到使用者手上了嗎？
- 是否經過足夠時間收集到足夠的回饋？
三條件是 AND 關係——任一條件未滿足，專案就不是完成，而是進行中或失敗中的狀態。
2. 為什麼「完成」需要被定義
組織內常見的隱性「完成」標準（這些都不是真正完成）：
- 寫完 code 就算完成（工程視角）
- 上線了就算完成（運維視角）
- demo 過了就算完成（PM 視角）
- 客戶簽收了就算完成（甲方視角）
- 報表交了就算完成（管理視角）
這些都是對內事實，不是對用戶的價值交付。沒有對外標準，每個角色都會把自己這一棒當成終點。
3. 反 case：殭屍專案
「80% 完成的專案永遠占著資源」——沒有「完成的定義」，專案會永遠停在「幾乎完成」狀態，但從不真正關閉，吃掉組織持續注意力。
對位 優先順序矩陣 的「影響高 × 緊急低 = 殭屍專案」象限：兩種殭屍——
- 未啟動殭屍：影響高但不急 → 永遠不做
- 未關閉殭屍：技術完成但沒驗證 → 永遠不收尾
完成的定義是未關閉殭屍的解藥。
4. 與敏捷 / Scrum 的歷史背景
- 「Definition of Done」是 Scrum 的核心成熟度指標——每個團隊應該明確列出 DoD 清單（測試覆蓋、code review、文檔更新、A/B 測試結果等）
- Roman Kudryashov 的三問是 DoD 的用戶導向極簡版本——不關心內部清單細節，只問交付鏈條是否完成
4.1 增量是 DoD 的可見結果
2026-05-07-Jayden-Lin-Agile增量需求溝通 補上 Scrum 語境裡另一個相鄰概念：敏捷增量 是一段迭代後 integrated / running / tested 的可用軟體。
兩者的分工可以這樣看：
- DoD：每個 backlog item / user story 要滿足什麼條件，才算真的完成、可被納入本輪成果。
- Increment：多個已完成項目整合後，本輪產出的可運行、已測試、可釋出的軟體。
沒有 DoD，增量會混入半成品；沒有增量，DoD 會變成一串內部 checklist，卻未必形成使用者可接觸的 working software。
5. 「足夠時間 / 足夠回饋」的隱含 trade-off
第 3 條（足夠時間收集足夠回饋）是組織最容易忽略的：
- 太早關閉 → 看不到真實使用問題（像產品上線一週就宣布完成）
- 太晚關閉 → 組織注意力卡住，新事項無法啟動
- 沒有預設標準 → 每個專案都被個案處理
對位 Goal-Signal-Metric：「足夠回饋」需要先定義要收什麼指標 / 訊號 / 目標——否則「足夠」是空話。
6. AI agent 任務的完成定義
2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能 把 完成的定義 推到 long-running agent 場景。給 agent 的任務不能只寫「把專案改好一點」，而要在 Goal-Prompt 中交代五件事：
- Outcome：完成後應該達成什麼狀態。
- Verification：用什麼測試、metric、截圖或 rubric 證明完成。
- Constraints：哪些檔案、功能、成本或行為不能動。
- Iteration policy：每輪要記錄改了什麼、結果如何、下一步是什麼。
- Error handling：什麼狀況要停下來回報，而不是繼續空轉。
這讓 DoD 從團隊交付清單變成 agent 任務邊界：沒有 outcome，agent 會自己猜終點；沒有 verification，agent 會自我宣稱完成；沒有 error handling，長任務會變成無法治理的 token 消耗。
與其他概念的關係
- 對位 INVEST原則 之 T (Testable)：INVEST 是 user story 進入 sprint 前的驗收顆粒檢驗；本頁是專案結束時的整體收尾檢驗。前者守入口，後者守出口。
- 對位 Goal-Prompt：Goal-Prompt 是把完成定義寫進 AI agent 任務提示的操作格式。
- 對位 敏捷增量：DoD 守住每個項目的完成條件；增量守住一輪迭代後是否真的有 integrated / running / tested 的可用軟體。
- 對位 Goal-Signal-Metric：G-S-M 提供「該量什麼、怎麼量」；本頁提供「量到什麼程度才算完成」——前者是測量設計，後者是收尾判定。配合使用：先用 G-S-M 設計 signal/metric，再用本頁三問判定 done。
- 對位 檢核提案的-10-個問題 / 12個問題法則 / STAR原則 / INVEST原則 / SCQA架構 / MECE 構成 vault「結構化清單家族」第 8+ 條——本頁專責「收尾」場景，與其他清單的「入口 / 表達 / 拆分」場景區隔。
- 與 專案管理 互補：專案管理 「預防勝於治療」處理執行過程的危機預防；本頁處理執行結束的判定共識。沒有完成定義，預防做得再好也會卡在「永遠 80%」。
- 與 管理 / 執行力 連結：執行力 是把願景轉成成果的能力——但沒有「成果」的定義就沒有執行力。本頁是執行力的尾端錨點。
- 與 Empathize 同精神：第 1 問「用戶的問題真的被解決了嗎」需要回到用戶視角；對位設計思考第一階段——本頁把 Empathize 從專案啟動延伸到專案收尾。
- 與 Actionability 連結：「可被回饋驗證」是 Actionability 在收尾階段的具體要求——可被驗證的東西才算被完成。
相關來源
- 2026-05-01-曼報-EP63-當每件事都很重要 — Roman Kudryashov 原作 / 曼報 轉介；vault 中第一個系統處理「組織任務超載」場景的來源；本概念為其七步框架第 6 步
- 2026-05-07-Jayden-Lin-Agile增量需求溝通 — 補入敏捷增量與 DoD 的關係：增量要 integrated / running / tested，DoD 是可納入增量的完成條件。
- 2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能 — 補入 AI agent 任務的完成定義五要素：outcome / verification / constraints / iteration policy / error handling。
備註
本頁建立於 曼報 EP63 ingest。Definition of Done 是敏捷 / Scrum 的標準術語，但 Roman Kudryashov 的三問版本是用戶導向極簡版，比 Scrum 教科書版（測試覆蓋 / code review / 文檔等內部清單）更高層級。
未來累積方向：
- (a) Scrum 教科書版 DoD 清單：累積敏捷 / Scrum 主軸來源後可補入「內部清單版」與本頁「用戶導向版」對照
- (b) Definition of Ready（DoR）對位概念：「準備好可以開始」vs「完成可以結束」——累積 2+ 來源後可獨立建頁
- (c) 「足夠時間 / 足夠回饋」的具體量化：A/B 測試最小樣本數 / 統計顯著性 / 留存窗口等——對位 Goal-Signal-Metric 補位
- (d) Outcome vs Output 之分：本頁第 1 問已隱含「outcome（結果）優於 output（產出）」精神；累積 2+ 來源後可建 Outcome-vs-Output 獨立頁