如何寫好MRD文檔及相關注意事項

14 評論 53415 瀏覽 325 收藏 15 分鐘

MRD定義與分類

MRD指Market Requirements Document,簡稱市場需求文檔。

市場需求文檔的主要功能是描述什么樣的功能和特點的產品(包含產品版本)可以在市場上取得成功。

產品進入實施,需要先出MRD,具體來說要有更細致的市場與競爭對手分析,通過哪些功能來實現商業目的,功能/非功能需求分哪幾塊,功能的優先級等等。

產品市場經理(PMM,Product Marketing Manager)負責分析市場變化,通過對市場的分析,MRD指出什么樣的新產品、方案和服務可以更好的開拓市場。

通常情況下,產品經理或者技術產品經理會將在MRD的基礎上完成PRD(Product Requiremnets Document),技術團隊應用PRD開發產品。

在百度的ECOM PM部門,MRD要分為給RD/QA看和給業務部門看的兩種。

給工程、測試、設計看的MRD是他們的輸入信息和測試對象。給業務部門看的MRD,最主要是因為MRD里面的功能實現后,會對客戶產生影響,所以必須確認業務部門知曉。

MRD基本寫法

一般來說,MRD包含“項目背景”“名詞解釋”“可行性分析”“綜合描述”“功能詳述”等部分。這里結合不同版本的MRD談談MRD的基本寫法。

目前看到的幾個MRD比較重視功能需求這塊。功能需求主要包括功能點類型和優先級/流程圖/頁面布局/功能點描述等要素。其中優先級和功能描述比較重要,流程圖??墒÷?。

要素1:項目背景要讓RD理解。

“具體開發的背景是什么,解決什么問題得寫清楚,否則開發人員在不清楚背景的情況下去做,很容易出問題,而且也缺乏參與感?!?/p>

事實證明,誰將買和使用戶你的產品和與競爭對手的產品比你的產品定位怎么樣的對工程師很有價值,許多工程師想知道為什么一個產品或特性要開發,誰將使用他們,什么是他們可以另外選擇辦法。這些信息幫助他們和產品組的其他成員想象最終用戶并從而更好的為創造成功的產品工作。要盡可能的(在MRD中)包含這些信息。不一定要很詳細,只要包含幾個段落就足夠了。

要素2:名詞解釋要確保RD看得明白。

在名詞解釋這塊,“描述的準確性很重要,沒有二意性,否則,等RD開發好了以后,才會發現和自己想要的不一樣,追溯mrd才發現有歧義?!?/p>

要素3:要考慮系統的兼容性等不確定因素,把控風險。

我們應該提前把控風險,不確定性降到最低,并具有良好的溝通和通報意識。例如,當MRD要求的是原來系統的更新,而不是一個全新的,與其他系統沒有關聯的產品時,應考慮到更新的內容與原來的系統其他部件的接口,以及其他外部系統的兼容。eg:2006年8月3日MRD)

要素4:對于要實現的系統功能要詳細分解。

每一步出現什么界面,進行什么操作,下一步又怎么進入什么界面,進行什么操作,都要介紹清楚,這樣比較容易讓RD明白,也易于實現。(eg:2006年9月4日MRD )

要素5:在涉及數量關系時,要利用好公式。

要用公式明白地表明變量的關系。對公式里面變量的定義必須清晰無疑義。在列舉公式時,需要窮盡所有可能的情況,此外,還需要列舉注意事項,澄清可能存在的誤區。在增加QA時,要把提問的問題寫清楚。(eg:2006年8月3日寫MRD)MRD里面的數據來源最好有附表,這樣比較清楚明白。(eg:2006年9月4日MRD)

要素6:要區分功能需求的優先級。

通常來說,工程師團隊不一定能全部實現MRD里包括的所有特性的沒有刪減的項目。當出現需要決定取舍的時候,應該提供一個辦幫助讓他們決定那些特性要實現那些可以推遲。最好的決定一個已經明確的需求的優先級方法這個需求實現后的好處-包括客戶和公司。在實際實踐中,最好是和其他多種因素一起綜合決定。在學習材料里面的幾個MRD里面一個突出的問題是優先級寫的都是很高,沒有根據第一等級,第二等級這樣的區分。(eg:2006年9月4日MRD)

要素7:要積極參加評審鼓勵修正。

要讓產品經理伙伴和工程師團隊評審MRD然后提出反饋意見。保持一個敞開的思想然后在評審反饋的基礎上更新MRD。(eg:2006年9月4日MRD)

要素8: 要覆蓋非功能性需求

要用功能性需求描述產品的功能,然后用非功能性需求描述系統特性,當寫非功能性需求的時候,盡可能的是使他們可度量(可測試)。否則,QA不能測試它們,PM將沒有辦法知道完成的產品是否已經實現了這些非功能性需求。

要素9:要包含一個術語表

如果MRD使用了新術語或在非通用的地方是使用了常用術語-確保在MRD后面包含一 個術語表。術語表將確保所有讀者(有些可能不是技術人員)理解PM的意思是什么 。

要素10:深入分析目標用戶群需求,市場發展趨勢,競品,結合自身優勢找出制勝點

在學習的歷史MRD中,沒有包含市場分析和定位,而針對市場做好分析其實是很重 要的一塊,因為“寫MRD一定就和畫像一樣,得現有輪廓,然后才有具體里面的眉毛、眼睛?!碧貏e是對目標用戶群需求,市場發展趨勢,競品等深入分析,然后結合公司自身優勢找出制勝點。MRD必須在覆蓋了市場目標(誰將買和使用戶你的產品)和定位(與競爭對手的產品比你的產品定位怎么樣的)的方面做好。

那么,如何分析好市場目標和定位?

首先,在寫MRD之前,得有細致的研究和溝通階段。其中比較重要的是要知道幾個為什么:“用戶需要的是什么?/ 我們為用戶提供的是不是用戶真正想要的?/ 憑什么能代表用戶?”其他考慮的因素還有很多,例如人力,時間,成本,價值等。綜合衡量很多因素,最后決定是否需要做這件事情。

在這方面,我們也可以通過以下方法去實現:

1、對于某產品可以進行調查問卷的形式發放出去(搞一些活動之類的)

2、對于有針對性的產品,可以去專訪一些資深的用戶去調查體驗

3、找一些資源,設計一些腳本程序,用這個腳本程序,計算需要的數值,用數字說明用戶想要。多個維度的思考會比較有力,所以最好綜合參考幾個維度。

撰寫MRD的常見陷阱和對策

陷進1:如何不斷提高可讀性?

為了確保MRD可以執行,最重要的是提高MRD的可讀性。其中可讀性一般包含準確性和易讀性兩個方面。

不準確指表達模棱兩可,容易讓人誤解;不易讀指邏輯關系太復雜,表述太長,不容易理解。那么如何盡量避免這兩個問題呢?

1 插入屏幕截圖或者流程圖,同時保持文本和圖片描述一致。

一般來說,圖片直觀,容易理解。與此同時,因為MRD經常會改動很多次。當文字發生改動時,圖片也應做相應的改動,以免帶來不必要的混淆和誤解。

Eg1: 圖片中寫了付款方式,但是文字中提到相應概念時,卻說是“繳費方式”,那么就容易讓人產生誤解。

Eg2: 圖片里面畫了簡略的圖表,但是文字里面有了詳細的分支的展開。那么讀者在圖表里面找不到文字里面描述的分支,就會產生困惑。

2 正文批注分開,省略功能實現等方面的細節

有時候MRD里面描述非常清楚,但是RD和QA希望提供更多的細節幫助理解。于是MRD越寫越長,造成易讀性變差,怎么辦呢?

MRD里面應該省略細節,主要講產品設計的思路。在排版時,應該把正文和批注分開。細節寫在批注里面。這樣一方面條理清楚,容易閱讀。另一方面,講清楚為什么這么設計的原因,而不窮舉功能該如何實現,可以發揮RD的主觀能動性,讓他們更有參與感,從而主動去想如何做得更好。應該說明的是”是什么”和”為什么”,但不要”如何” 和“怎么樣”。

3 通過版式來提高MRD易讀性

MRD最好控制在5-6頁之內。如果MRD比較長,最好使用1.5倍行間距,以便RD讀起來比較舒服。如果使用模板,確信相關人員可以靈活的跳過模板某些部分和創建新的內容。

另外,應避免大段的文字。如果使用宋體5號字,文字超過兩行半,就應該利用良好的邏輯結構來使文章易讀,例如使用分段,序列符號,并列符號等等。

在語句組織上,應保持簡短的語句,把長的語句分解成多個小的語句?;蛘甙汛髩K文本做成表格都是很好的辦法。

4 通過詳細解釋項目背景和名詞解釋簡化MRD

項目背景和名詞解釋對于某一個具體的MRD都是通用的知識。在項目背景和名詞解釋方面解釋得越詳細清楚,越有助于RD和QA理解下文中功能點設計和實施目標。預先的解釋可以大量減少MRD后續解釋的篇幅。

5 功能點和功能點之間合理分配篇幅并注意銜接

對于比較復雜需要長篇敘述的功能點應該進行進一步的細分。例如一個5頁的MRD如果包含5個功能點,那么就不應該讓一個獨立的功能點占據2頁的篇幅。

如果兩個功能點A和B提到了同一個背景知識。為了節省篇幅,我們只需要在A展開背景知識,而在B的相應部分寫上“相關介紹請見A”。

如果多個功能點共享同樣的背景知識,造成嵌套的情況,容易讓人對功能點之間的邏輯結構產生混淆。這時候應該畫功能點邏輯圖,以便于讀者理解。

陷阱2:如何抓住關鍵,又不錯過關鍵細節?

在MRD的纂寫過程中,必須抓住關鍵,不能太糾纏于細節。與此同時,有些細節也是很關鍵的,需要辨別出來,那么,哪些是關鍵的細節呢?

1 當一個流程出現分支/異常的時候,臨界的判斷條件是關鍵細節

Eg?假設一個點擊3毛錢,一個客戶的廣告該不該出現?那就需要考慮用戶的預算/帳戶余額等多種情況,然后確定廣告是否出現,以及廣告被點擊后的后續操作

2 涉及用戶體驗的細節是關鍵細節

Eg 當客戶點擊一個操作按鈕時,應該在新窗口打開,還是新標簽頁打開?

3 當一個過程操作結束后無法恢復時,處理方式是關鍵細節

Eg 當客戶刪除一個關鍵字時,操作是不可重復的,那么是不是應該有一個二次提醒的框?

陷阱3:多模塊的合作模式下,MRD需要注意哪些方面?

有時候產品的更新不是一個獨立進行的操作,而是涉及到多個模塊的合作。應該注意推舉一個總負責人,確保MRD與MRD之間,設計與設計之間不重合,也沒有三不管地帶。既減少別的產品更新給自己的產品變化帶來不利影響,也認真考慮自己的MRD對別人的影響。

陷阱4:處于和RD/QA磨合期時,MRD需要注意哪些方面?

處于和RD/QA磨合期時,應該注意預判RD/QA可能出現的易錯點和盲區,做好PPA/POA分析,及早預防可能存在的意外。尤其是當MRD推的產品非常重要時,需要特別注意這一方面。

另一方面,如果RD和QA在新人培訓方面的確做得不到位,也應考慮暴露問題,推進問題的徹底解決。

 

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 已閱

    來自貴州 回復
  2. Requirements 拼寫錯誤

    來自廣東 回復
  3. 在百度的ECOM PM部門,MRD要分為給RD/QA看和給業務部門看的兩種。你這句話拆解的意思是指給PD,QA看的是PRD,給業務及BOSS看的是mrd吧

    來自上海 回復
  4. 這是PRD吧

    來自上海 回復
  5. BRD、MRD和PRD是需要的,在所謂敏捷開發特別是小團隊初創階段其實是可以在文檔上簡化的,甚至可以以涂鴉式的流程圖、會議紀等形式存在,前提條件是這個團隊核心成員磨合已過,很多東西有了共識,但不意味著BRD和MRD,包括PRD的一部分內容或步驟沒有經過深思熟慮和團隊內充分溝通,只不過沒落到紙面而已。如果團隊部分核心人員為新人、系統復雜、或在資金充足情況下產品在可見未來會快速更新等情況下,我建議還是盡可能將核心復雜構架形成文檔,避免在未來運營階段的溝通成本和失誤。

    回復
  6. 產品經理 已經被市場和模式所束縛, prd、 mrd 文檔在敏捷開發和要求效率開發的時候 沒見過誰用過,誰會去看一個20幾頁的word文檔 項目背景 ,設計和技術管你什么項目背景,知道項目背景有什么用?可以不設計嗎?可以不敲代碼嗎?如果一個流程圖和axure原型做的到位,根本不需要這種東西,這種東西只存在于外包存檔公司存檔,或者是糊弄老板才會用。大大降低了效率,產品經理不拘一格才對 不然你將創造 不出來好的產品!

    來自天津 回復
    1. 然后你做了一個市場根本不需要東西嗎?市場文檔可以做得很簡單,例如精益看板。

      來自四川 回復
    2. 讀小學有什么用,天天起來就知道寫漢字,讀大學有什么用,你大學的函數出來社會有幾個人能用得到。那幫讀書的啥子為啥不五六歲開始直接闖蕩社會,浪費什么時間 在讀書上面

      來自陜西 回復
    3. 敏捷開發的時候,是沒人用這些。你見過大學生拿出草稿紙算十以內加減法嗎?但是你不能說小學拿草稿算十以內加減法是無用的

      來自陜西 回復
    4. 喜歡你的一些看法,但這些東西怎么說,在一些公司可能沒太大用,在一些大公司我相信還是會用到的,真正想把產品做好就要讓每個人都有參與感,而mrd就是讓他們知道自己在做什么?在干著一件什么樣的偉大的事

      回復
  7. 呵呵,越往下看越糊涂,這是寫MRD還是PRD呢?寫文章的人自己混淆了吧。

    來自上海 回復
  8. 誤人子弟,完全沒有搞明白MRD和PRD的關系

    來自浙江 回復
    1. 同感

      回復
  9. 發這文章的人不復審自己發的東西嗎?

    來自廣東 回復