在 Ray 加入專案之後，每隔一段時間我都會發揮一下同學愛，進行一些溫暖的問候：

「目前開發還好嗎？有沒有遇到什麼問題？」
「需求有沒有哪裡不清楚？不清楚可以問喔！」

通常得到的答案都是酷酷的：「沒有。」

很好，世界和平，歲月靜好。

直到某個功能開發完成，Ray 告訴我可以開始測試，我也摩拳擦掌，打開測試案例時，他突然冷不防冒出一句：

「你知道 asdf 是什麼嗎？」（此處專案內名詞使用代稱）
我愣了一下，「……你是說 asdf 嗎？」
「喔對，asdf。這是什麼？」

當然，不知道肯定是沒有問題的，畢竟承接新的專案，有很多的 know-how 不熟悉也是理所應當，而且專案裡本來就充滿各式各樣的縮寫、欄位和商業邏輯，一切都能理解。但就是說呢，有個小小的問題－－

這次改的功能，就是 asdf。

並且這個功能，Ray 在上星期就告訴我開發完成了，只是在微調一些細節，這週才會交測。
……OwO？

PM 問「需求有沒有問題？」真的有用嗎？

什麼叫做需求澄清？

印象非常深刻，在 PMP 第一堂課，老師就告訴我們，專案中百分之八十的問題，都來自於**「需求」**。需求不明確，認知不同，範圍想法不同，指涉的東西不同，都可能影響專案的進行與交付，而後面千千萬萬的問題，幾乎都源自於「需求」，對內對外皆同。

Requirement Clarification（需求澄清），就是確認專案團隊對需求的理解是否一致。

PM 把需求文件交給 RD，不代表需求澄清就完成了。因為同一句需求，PM、SA、RD 可能會有不同的理解。如果沒有及早發現這些認知落差，就可能一路帶到開發、測試，甚至上線前才發現「做出來的東西跟原本想的不一樣」。

因此，需求澄清不只是確認「需求有沒有說明」，而是要確認幾件事情：為什麼要做、要做什麼、什麼情境下會發生、預期結果是什麼，以及怎樣才算完成。

PM 可以怎麼做需求澄清？

1. 與其問「有沒有問題」，不如改成確認對方的理解

「有沒有問題？」很容易得到「沒有」，畢竟沒有細部確認前，很少有人會馬上發現問題。可以改成用具體問題確認，請他將他的認知說一次給你聽，然後隨時補充與糾正。

寧願事前花多點時間確認，也不要在最後一刻欲哭無淚。事前確認就可以提早發現，他可能連規格中的重要名詞都不確定意思。

2. 用實際 Scenario 對需求

與其只討論規格文字，也可以直接拿幾個 Case 來確認：

**Case A：**符合條件 → 預期結果是什麼？
**Case B：**不符合條件 → 預期結果是什麼？

如果大家對同一個 Case 得到不同答案，就代表需求還需要繼續確認。相信我，這真的非常容易發生。

3. 定義清楚 Acceptance Criteria

最後要確認**「怎樣才叫做完成？」**

Acceptance Criteria（驗收條件）可以把模糊的「功能完成」變成具體、可驗證的結果。這不只能讓 RD 知道開發目標，也能讓 PM 後續確認或測試時有明確的判斷依據。可以避免掉很多「我以為」的狀況出現。

以及，請記住

情緒無法解決問題，想處理事情時，絕對不要帶著情緒。
情緒無法解決問題，想處理事情時，絕對不要帶著情緒。
情緒無法解決問題，想處理事情時，絕對不要帶著情緒。

無論發生什麼，都要平和對待，不可酸言酸語，因為對事情毫無幫助。需動心忍性，增進修行。

事後平和反省了一下，雖然這個功能的規格， SA 說過，前任 RD 交接時也再說過，PM 本人我自然更是再三強調過。但畢竟是新同學，需要多一點的關照，無論從互動上，乃至於規格上，都需要再多點關心。而經過簡單的溝通後， Ray 也開始會發問問題，實在是可喜可賀，值得掬一把清淚。