一、 MRD簡介
MRD-“市場需求文檔”，是產品經理或者產品市場經理編寫的一個產品的說明需求的文檔。這些文檔用於計劃一個新產品或修正一個已有的產品，是被工程師團隊開發產品時使用。
在硅谷的一些軟件公司，MRD僅僅覆蓋high-level的功能。在這種情況下，產品經理通過創建了另一個文檔-通常指的是PRD（產品需求文檔）來定義更加詳細的產品需求。
在本文中，我用術語“MRD”泛指所有那些由產品管理和/或產品市場團隊創建的，爲工程師團隊傳達產品需求爲目的的文檔。
MRD-“市場需求文檔”，是產品經理或者產品市場經理編寫的一個產品的說明需求的文檔。這些文檔用於計劃一個新產品或修正一個已有的產品，是被工程師團隊開發產品時使用。
在硅谷的一些軟件公司，MRD僅僅覆蓋high-level的功能。在這種情況下，產品經理通過創建了另一個文檔-通常指的是PRD（產品需求文檔）來定義更加詳細的產品需求。
在本文中，我用術語“MRD”泛指所有那些由產品管理和/或產品市場團隊創建的，爲工程師團隊傳達產品需求爲目的的文檔。
二、 寫好MRD的10種技巧（第一部分）
1、從用戶角度的編寫
從用戶角度編寫需求內容。使用“用例（Use Case）”和“用戶角色（User Personas）”來達到這個。考慮用以下兩種方法來詳細說明你們公司正在開發的SFA（sales force automation）軟件的“Login”的功能性。
方法A：用戶通過一個要求用戶提供證書的登陸界面，然後軟件允許用戶帶着特定的權限進入系統。軟件鑑別這些證書，在鑑定通過的基礎上允許用戶訪問那些他們有權限訪問軟件的功能部件。
方法B：Mike是一個銷售經理，Cathy是一個銷售代表。當他們打開軟件，他們看到登陸界面。他們通過用戶名和密碼進入系統。如果用戶名和密碼是正確的，他們能登進系統。一旦登陸進系統，Mike能訪問軟件所有的功能部件。Cathy只能訪問那些對銷售代表有有效的功能部件。
哪個方法更加容易閱讀和理解？就我的看法，毫無疑問，"方法B".還有，它同時減少了令人煩惱的閱讀！
2、使用Screen Shots
使用Screen Shots或者mockup來你的想法。我們中很多人都聽說過“一張圖片好比一千個文字”。當提到寫MRD的時候，一個screen shot好比一千個文字！
舉個例子，看看下面這個screen shot，你需要多少字來描述？我想可能不只一千個字。
3、用簡單的語言編寫
在我超過11年的行業中，我通常注意到的（更多是令我懊惱）一件事是用很做作的語言來寫的MRD.我想這個主要是因爲MRD聽起來是正式的和專業的原因吧。
相反，想象你寫的MRD是寫給你的在工程師團隊工作的朋友。你的目標是幫助他理解你需要什麼，以便於他能開發產品實現這些需要。這個將有助於你避開陷入那些令讀者人厭煩（有時他們會把MRD撕碎然後再碎片餵給碎紙機）的用做作的語言的陷阱。
還有：a）保持簡短的語句，把長的語句分解成多個小的語句。
b）避免大篇幅的連續文本，把他們分解成多個小的章節。
c）把大塊文本內容分解成，screen shots，表格、重點列表等等。
4、小心的使用模板
我發現MRD模板非常有用。他們的幾個好處包括：a） 模板提供了一個標準的格式，使那些不得不閱讀大量MRD的讀者更加容易閱讀。
b） 模板讓新的產品經理快速的寫MRD變得容易，因爲公司與公司之間的MRD內容是不同的。
c） 模板確保你不會忘記所有需要在MRD中覆蓋描述的部分；
然而，一些公司過分的使用模板。一個硅谷最大的公司之一有一個所有部分被強制使用的近60頁的模板。我覺得這個讓人覺得非常難以忍受並且有幾個負面的作用：a） 產品經理害怕但又不得不寫MRD - 幾乎和不得不和Dick Cheney去南德克薩斯打獵一樣（譯者按：美國副總統Dick Cheney在南德克薩斯打獵時意外的打傷了和自己一起去的打獵夥伴）。
b） 工程師團隊害怕但又不得不閱讀MRD. c） 寫MRD和讀MRD都需要花大量的時間。
我推薦你使用MRD模板，但確保他們不要過分的長。還有如果需要，確信產品經理可以靈活的跳過模板某些部分和創建新的內容。
5、區分需求的優先級
在這些年裏，我從來沒有碰到一個工程師團隊實現了MRD裏包括的所有特性的沒有刪減的項目-通常由於那些我們控制之外因素！
這就是說作爲MRD作者的產品經理，當出現需要決定取捨的時候，應該提供一個辦幫助讓他們決定那些特性要實現那些可以推遲。
區分需求的優先級是一個最好的能幫助完成這個事情的辦法。我發現把需求分等級就像P1，P2，P3……這樣工作的剛剛好。在這個分類中-P1是最高優先級，P2是第二高優先級等等。
最好的決定一個已經明確的需求的優先級方
歡迎進入軟件測試社區論壇，與200萬技術人員互動交流 >>進入
法這個需求實現後的好處-包括你的客戶和你的公司。在實際實踐中，最好是和其他多種因素一起綜合決定。
我推薦你只要包括P1，P2，P3的需求在你的MRD中，在多數的項目中更低的優先級可能未必會實現。還有這樣也讓MRD變得更加容易讀。
簡介
MRD-“市場需求文檔”，是產品經理或者產品市場經理編寫的一個產品的說明需求的文檔。這些文檔用於計劃一個新產品或修正一個已有的產品，是被工程師團隊開發產品時使用。
在硅谷的一些軟件公司，MRD僅僅覆蓋high-level的功能。在這種情況下，產品經理通過創建了另一個文檔-通常指的是PRD（產品需求文檔）來定義更加詳細的產品需求。
在本文中，我用術語“MRD”泛指所有那些由產品管理和/或產品市場團隊創建的，爲工程師團隊傳達產品需求爲目的的文檔。
在我前面名爲“寫好MRD的10種技巧-第一部分”Blog文章中，我描述了寫好MRD的5種技巧。我知道你一定迫切的想看到其他5種技巧，不用再等了，下面我就描述它們！
在本文中，我用術語“MRD”泛指所有那些由產品管理和/或產品市場團隊創建的，爲工程師團隊傳達產品需求爲目的的文檔。如果你還沒有閱讀前面的5個技巧，請先閱讀它們，我會等在這裏，好了，你準備好了嗎？
以下是寫好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不能測試它們，你將沒有辦法知道完成的產品是否已經實現了這些非功能性需求。
8、評審&修正
我有一個朋友-我們叫他Matt（他的真名叫Steve）。Matt在硅谷一家成功的公司做產品經理工作。最近我在午餐的時候碰到他是告訴我一個非常有趣的故事。
他們僱用了一個有三年經驗的產品經理。在他被僱用的幾個月裏，不知何故他讓他的產品經理同事和工程師一樣疏遠他。
他是罪犯？他基本上認爲他的MRD就像一個法令。他寫了它，但不想和任何人評審或在反饋的基礎上修改它。他僅僅想工程師團隊沒有問任何問題的拿着它並實現它們！
不要像Matt的同事那樣。確信做到和你的產品經理夥伴和工程師團隊評審你的MRD.保持一個敞開的思想然後在評審反饋的基礎上更新MRD.這將幫助你寫出更好的MRD，工程師將喜歡你（或者至少少恨你一些），你的團隊也將創造更好的產品。
9、定義市場目標和定位
大部分我看到過MRD在覆蓋了市場目標（誰將買和使用戶你的產品）和定位（與競爭對手的產品比你的產品定位怎麼樣的）的方面做的很好。
我還看到過一些沒有描述市場目標和定位的MRD，他們通常會這樣爭辯：“爲什麼工程師們需要知道這些？拿到定義了什麼是需要的還不夠嗎？”
這些問題（誰將買和使用戶你的產品和與競爭對手的產品比你的產品定位怎麼樣的）的確有一些正面價值，我發現許多工程師想知道爲什麼一個產品或特性要開發，誰將使用他們，什麼是他們可以另外選擇辦法。
這些信息幫助他們和產品組的其他成員想象最終用戶並從而更好的爲創造成功的產品工作。我的建議的儘可能的（在MRD中）包含這些信息。- 它們不一定要很詳細，只要包含幾個段落就足夠了。
10、包含一個術語表
如果你的MRD使用了新術語或在非通用的地方是使用了常用術語-確保在MRD後面包含一個術語表。
當你像這樣說“我們的軟件將提供SME用戶通過選擇WAP或PSMS開MRC帳單”時，術語表將確保你的所有讀者（有些可能不是技術人員）理解你的意思是什麼。