寫好MRD的10種技巧

       以下是寫好MRD的10種技巧-第二部分(6-10)

6、說明"是什么"和"為什么"，但不要"如何"

       產品經理為理解客戶的需求負責，然后基于這些理解定義什么和為什么需要開發.
有一件比任何事情讓開發者發瘋就像在幾英里外都能聽到的汽笛在他們耳邊尖叫一樣的是一個令人痛苦的詳細描述了怎樣實現每一個需求細節的MRD。

       考慮你們公司正在開發的以下兩種描述CRM“Login”功能的方法。

       推薦-描述“是什么”
       Mike是一個銷售經理，當他打開我們的CRM軟件，他會看到一個登陸界面...登陸界面建議提供“記住我”復選框。如果Mike在點擊登陸按鈕之前選擇了該復選框，我們的軟件將記住并且在他下次來到登陸界面時自動填寫他的名字。

       不推薦-描述“怎么樣”
       Mike是一個銷售經理，當他打開我們的CRM軟件，他會看到一個登陸界面...登陸界面建議提供“記住我”復選框。如果Mike在點擊登陸按鈕之前選擇了該復選框-將通過Javascript 保存他的名字以cookie的方式寫到他的硬盤。當cookie寫到硬盤后，用戶名和密碼將被發送到服務器。下一次Mike來到登陸界面時，Javascript 將讀取他的cookie，成功讀取后，Javascript 將是適當的DOM命令填充登陸頁面上的用戶名。好的產品經理擅長理解用戶的需求和描述什么需要實現，好的工程師擅長決定怎么樣實現它。好的工程師希望能自由的決定怎么樣最好的實現用戶希望得到的東西。

       我注意到有技術背景的產品經理尤其喜歡描述“如何實現”。如果這些描述的就是你，應該從現在開始不要再做這樣的事了。工程師們將會感謝你。

       附：這里有一些例外的情況-當在描述“是什么”中描述“怎么樣”是必要的，當描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么樣”的情況。

7、覆蓋非功能性需求

      盡管功能性需求描述產品的功能，非功能性需求描述系統特性，如：
       a)性能
       b)可伸縮性
       c)可用性
       d)國際化
       e)等等...

       我注意到因為許多產品經理和產品市場人員認為這些是“技術細節”，而在MRD中被忽略。我發現這些是我的MRD中非常重要的一部分，工程師們會非常感激在MRD中定義這些需求。

       要點：當寫非功能性需求的時候，盡可能的是使他們可度量（可測試）。否則，QA不能測試它們，你將沒有辦法知道完成的產品是否已經實現了這些非功能性需求。