最近的一系列事情開始教育我，如果不能做好需求管理的工作，產品人員疲於應付不斷變化的需求，導致無法正常開展產品的設計和管理工作。結果就是交付給開發人員的需求文檔不斷變動，開發人員也不知道自己究竟該做什麼，項目進度越拖越慢。最後到了規定好的交付時間，因為拿不出需要的產出物，部門之間開始互相推诿、埋怨。
思考良久，需求的變動固然是造成這種結果的主要原因，另一個不能忽視的因素則是需求沒有表述清楚，開發人員面對表述模糊的需求文檔，更加無法完成既定的開發工作。
如何表述清楚需求？我們需要盡可能做好兩件事情：1.完整建立產品的user case；2.在需求文檔中力爭做到明確、完整、一致和可測試四點。那麼對於產品、開發的工作影響就能降到最小，你的項目也越能在規定的時間內完成。
如何建立產品的User Case Diagram
User Case Diagram也叫用例圖，基於面向對象的思想和用戶視角來設計。如下圖就是一種非常簡單的用例圖，它有點類似創建產品的用戶角色，你需要能從使用的角度描述出用戶是如何一步步操作這個產品的。
用例這種通過講故事來把需求描述清楚的辦法很有點黑盒的概念，很容易被用戶和開發者理解；但缺陷在於無法描述清楚該如何實現，也很少涉及內部的信息。一旦我們遇到無法理解產品實現機制或者內部流程架構的情況時，就必須借助其他的方法來理解需求，這個過程可以理解為打開黑盒。這樣通過不斷地觀察黑盒，打開黑盒、分析黑盒，然後再打開黑盒的過程，我們就能做到對整個產品的需求有比較准確的把握。
用例圖就是這樣一種能幫助我們了解需求的方式，當然如果指望讓程序員看完了用例圖就能把程序做出來，那是相當地扯淡……
因為用例圖本身只是用來闡述用戶的需求，很難准確對產品的功能、架構賦予嚴謹的描述和定義。因此，我們還需要另外一份交付物，來清楚表達產品的功能、流程和架構，比如說產品需求文檔。
產品需求文檔應有的幾個基本要素：
對應的產品不同，需求的標准也不盡相同，不過有一些通用的要素，仍然是可以借鑒的：
明確：很多撰寫需求文檔的人並沒有學習過形式化語言，因此我們看到的需求文檔很多都是采用自然語言寫出來的。這對需求分析帶來的最大弊病就是它的二義性。因此需要我們對文檔的表述進行一些限制，例如盡可能只用主謂賓的基本表達方式，避免修飾句，避免容易令人產生誤解的表達方式。
比如我們是做一個社保卡系統，你可以這樣描述需求：每張公交IC卡只能屬於一個用戶，社保卡有卡號和金額數。社保卡可以在醫院使用，可以用來支付醫藥費。
完整：既不要在提需求時說還有一些需求沒有確認，也不要開發接近完成了提出來有一些需求遺漏了。需求的不完整是導致開發返工的最直接因素，也是令人發指的行為。
需求的完整需要產品人員有很好的產品管理技能，也需要對已有產品的架構有清晰的了解，很多時候產品人員面對的都是拍腦袋或者臨時決定提出來的需求，很難第一時間提煉出完整的需求，怎麼辦？問！問自己，問客戶，問開發。在你無法確認出完整需求或者起碼的核心需求之前，任何交付給開發的行為注定是不負責任的。
一致：需求簡單來說可以分成業務需求、用戶需求和開發需求三個方面。用戶需求需要能和業務需求一致，開發需求需要能和用戶需求一致，這並不是在說廢話，而是三種需求之間的繼承關系。否則，辛苦開發出來的東西很可能會偏離當初的實現目標。在具象的實現過程中，這種一致性也必須細化。往往用戶需求在整個過程中不斷變化，產生所謂的”需求變動”，這種變化不應該超出先前既定的范圍，至少不應該超出最初的業務目標。
可測試：很多人認為項目、產品的測試應該從寫完代碼輸出測試產品時開始算起或者說開發們在寫代碼的時候就該開始履行測試的職責了，這樣理解有它的道理。但實際上，和完整性的要求一樣，測試的過程應該從需求一開始分析的時候就要開始。
作為測試的輸入輸入和參照物，需求分析應該是可測試的。比如我們說“設計一個網站，能讓用戶第一時間了解車票的行情”。這個需求是可測試的麼？當然不是！車票是指的火車票、汽車票抑或二者都是？了解車票的行情包括哪些方面？這些在需求中都沒有做出說明，也意味著它是無法測試的，不具備可測試性。
因此包括前幾項的需求因素在內，我們的目的都是要保證需求的可測試性。當且只有當所有的需求是可以被測試的，才有可能保證產品從需求分析到設計開發再到最後的交付都是真的在圍繞業務目標和用戶需要的。產品才能更接近成功。
究竟該如何解決“需求的變動”帶來的問題呢，對於這個“世界難題”我只能說見招拆招了，畢竟這屬於項目開發中不可抗的外因，很多時候並不是產品經理或者項目經理能左右的。在面向對象的開發模式下，管理者能做的就是盡可能避免變動可能造成的計劃延遲，而對於產品經理來說，不僅要控制好進度，更要能把握好變動可能帶來的對核心功能的影響，因為你是掌舵者，你是“總設計師”。
但是，有句說句：忽略需求過程或者需求的變動造成項目返工是項目失敗的最大因素，大量項目的失敗往往都是在需求階段就注定了的。正在做產品經理的諸位不妨審視一下自己的工作，發現情況不妙的趕緊處理掉吧。
舉兩個典型的需求變動的例子：
1.需求人員口頭上把自己的想法和開發人員溝通以後，又扔下一句話：這些地方暫時沒有討論清楚，不用去管，你先做吧，然後過了一段時間又提出來一個新需求，完全不管不同需求之間對開發工作的影響。
2.告訴開發人員需要做一個xx產品，但是現在自己很忙，要開發人員先照著其他類似的產品做一個出來。
上述的兩種情況都會造成項目的不成功，特別當某些外行冒充內行的時候……