「以終為始」是一種反直覺的思維方式。我們習慣的思維模式是線性而順序的，第一步做完做第二步。
但高效工作需要我們先想清楚結果是什麼樣子，再倒推該做什麼。

為什麼大多數人不這麼做#

幾十萬年的演化留給我們短視的行為和思考習慣，因為這樣最節省能量。
把目光放長遠需要額外消耗能量，所以「以終為始」對大多數人來說並不自然。

許多人聽到別人要做的功能，就開始腦補接下來的一切，導致付出努力毫無意義。

兩次創造#

任何事物都要經過兩次創造：

1. 第一次創造（Mental/First Creation）：在頭腦中的創造，智力上的構想
2. 第二次創造（Physical/Second Creation）：付諸實踐，實際的構建

第二次創造的成本很高。我們應該在第一次創造上多下功夫，將相關各方的「集體想象」統一起來。

DoD：完成的定義#

DoD（Definition of Done）是行業最佳實踐，用來解決軟體開發中常見的「完成」理解偏差問題。

什麼是 DoD#

在開始工作前，團隊先制定「完成」的標準。例如：

特性開發完成：

• 經過需求澄清、功能設計、編寫程式碼、單元測試
• 通過測試人員驗收
• 程式碼處於可部署狀態
• 相關文件編寫完畢

開發完成：

• 編寫好功能程式碼
• 編寫好單元測試程式碼
• 編寫好整合測試程式碼
• 測試通過
• 程式碼通過風格檢查、覆蓋率檢查

DoD 的特點#

1. 可檢查的清單：檢查項應該是實際可檢查的
2. 只有兩種狀態：做完或沒做完，沒有「80%完成」
3. 彙報機制：團隊成員間彼此確認的方式

實戰指南#

產品經理給你需求時該問什麼#

當產品經理交代一個功能特性時，運用「以終為始」的原則提問：

1. 為什麼要做這個特性？ 它會給使用者帶來怎樣的價值？
2. 什麼樣的使用者會用到？ 他們在什麼情境下使用？怎樣使用？
3. 是否有其他手段達成目的？ 是不是一定要開發一個系統？
4. 上線後怎麼衡量有效性？

預設所有需求都不做，直到弄清楚為什麼要做這件事。擴大自己工作的上下文，別把自己局限在「程式設計師」的角色上。

亞馬遜的向後工作法#

亞馬遜開發產品的順序：

flowchart LR
    A[📰 寫新聞稿] --> B[❓ 寫 FAQ]
    B --> C[📖 寫使用者文件]
    C --> D[💻 寫程式碼]

    style A fill:#fff3e0,stroke:#ef6c00
    style B fill:#fff3e0,stroke:#ef6c00
    style C fill:#e3f2fd,stroke:#1565c0
    style D fill:#e8f5e9,stroke:#2e7d32

這就是「以終為始」的體現——先讓所有人看到結果的樣子，統一集體想象，再動手實現。