需求坑 | The Pragmatic Programmer 20週年紀念版

Perfection is achieved, not when there is nothing left to add but when there is nothing left to take away…
— Antoine de St. Exupery, Wind, Sand, and Stars, 1939

核心概念#

許多書籍和教程將「需求蒐集（requirements gathering）」稱為專案的早期階段。但「蒐集」這個詞暗示需求已經存在某處，你只需要找到它們、放進籃子裡即可。事實並非如此。需求很少浮在表面——它們通常深埋在假設、誤解和政治的層層之下。更糟的是，它們往往根本不存在。

Tip 75 - No One Knows Exactly What They Want（沒有人確切知道他們想要什麼）

需求的迷思#

在軟體早期，電腦比使用它的人還昂貴。我們會先取得需求規格、轉成設計文件、再轉成流程圖和虛擬碼，最終寫成程式碼。但現實世界是混亂的、矛盾的、未知的。精確的規格極其罕見，甚至不可能。

程式設計師的工作是幫助人們理解他們想要什麼。事實上，這可能是我們最有價值的能力。

Tip 76 - Programmers Help People Understand What They Want（程式設計師幫助人們理解他們想要什麼）

程式設計即治療#

稱呼請求我們寫軟體的人為「客戶」。典型客戶帶著需求來找我們，但初始的需求陳述不是絕對的需求——它是一個探索的邀請。

新手開發者常犯的錯誤是拿到需求陳述就直接實作。好的開發者會像治療師一樣，探索邊界案例、提出問題。以書店免運費為例：「$50 以上免運費」看似簡單，但你會開始問：

$50 包含稅嗎？
包含目前的運費嗎？
紙本和電子書都算嗎？
國際訂單呢？
$50 的門檻多久會變一次？

你的角色是解讀客戶的話，並將其含義回饋給他們。這既是智識的過程，也是創造性的過程。

需求是一個過程#

Tip 77 - Requirements Are Learned in a Feedback Loop（需求是在回饋循環中學習的）

你的工作是幫助客戶理解其需求的後果。你透過產生回饋來做到這一點，讓客戶用這些回饋來精煉他們的想法。務實的程式設計師使用「這是你的意思嗎？」的回饋方式——製作模型和原型，讓客戶操作。

整個專案都是一個需求蒐集的練習。這就是為什麼我們偏好短迭代——直接獲取客戶回饋，確保方向正確。

站在客戶的鞋子裡#

有一個簡單的技巧可以深入了解客戶的想法：成為客戶。如果你正在寫客服系統，去客服部門待幾天。如果你在自動化倉庫管控系統，去倉庫工作一週。

Tip 78 - Work with a User to Think Like a User（與使用者一起工作，像使用者一樣思考）

需求 vs. 政策#

區分需求和政策非常重要。例如，「只有員工的主管和人事部門可以查看員工記錄」——這是需求還是政策？如果寫成「只有授權使用者可以存取員工記錄」，開發者就會設計存取控制系統。當政策改變時，只需更新元資料即可。

Tip 79 - Policy Is Metadata（政策是元資料）

實作一般性的情況，將政策資訊作為系統需要支援的範例。

需求 vs. 現實#

成功的需求蒐集考慮到工具必須適應使用者的手。早期回饋——使用原型或曳光彈——能讓客戶說出「是的，它做了我想要的，但不是我想要的方式。」

記錄需求#

最好的需求文件也許就是可運行的程式碼。但這不表示你不需要記錄對客戶需求的理解——只是這些文件不是交給客戶簽核的交付物，而是幫助引導實作過程的里程碑。

需求文件不是給客戶的#

客戶請程式設計師來是因為客戶在解決高層次的模糊問題，而程式設計師對所有細節和細微差異感興趣。把 200 頁的需求文件交給客戶，他們多半只會翻翻前幾段。

需求文件是給規劃用的#

我們偏好能放在索引卡上的簡短描述——通常稱為使用者故事（user stories）。透過保持簡短，鼓勵開發者在每段程式碼的創建之前和期間提出問題，增強客戶和程式設計師之間的回饋過程。

過度規格化#

另一個大危險是需求文件寫得太具體。好的需求是抽象的。需求是需要，不是架構、不是設計、也不是使用者介面。

再多一個功能…#

許多專案失敗歸咎於範圍膨脹（feature bloat）。答案還是回饋——如果你和客戶在迭代中持續回饋，客戶會親身體驗「再多一個功能」的影響。

維護詞彙表#

Tip 80 - Use a Project Glossary（使用專案詞彙表）

建立並維護專案詞彙表——定義專案中使用的所有特定術語和詞彙的地方。如果使用者和開發者用不同的名稱稱呼同一件事，專案就很難成功。