1、需求文檔注定是給所有人看的，它就是產品的定義。· 文檔圍觀的人包括：你的老板（如果產品夠大，還會需要老板的老板），設計師，工程師，測試工程師。有時還應該包括產品前端：如運營，銷售，甚至市場部同事。· 在通過各方的評審和簽字后，一般來說，這個文檔就是一錘定音的事。若有更改，就是需求變更了。· 所以，在需求文檔撰寫前和撰寫中，對產品方向和用戶的把握要足夠強，從產品目的，到每個鏈接的含義，都需要準確地定義。基本上，當你開始寫文檔時，應該萬事俱備。一邊想一邊寫，那說明你還沒有想明白這個產品是怎么回事。· 在有些公司，需求文檔會包括產品的最終設計界面。即在文檔提交

2、給大家圍觀前，產品界面已經確定完畢。· 需求文檔寫作的一些建議格式無所謂。用WORD的多，HTML，在線文檔都成，我還見過PPT寫的！· 產品定義部分一定要詳細描述。按功能模塊寫，跨功能的定義用流程和關系來描述。多站在用戶的角度上，去定義用戶任務，用戶流程，頁面邏輯關系等。· 使用準確的用語，注意邊界情況。比如，一個文本框最多輸入多少個字符？是阿拉伯數字還是皆可？超過字數會怎么樣？· 多畫圖。把原型包括進去，或者把產品界面包括進去，不然就畫出來。否則除了你，沒多少看得懂。一個需求文檔，一些通用部分是必須要包括進去的，我總結了一個示例。當然， 很多時候有可

3、能是創業公司，或是小版本快速上線，要求會寬泛得多得多。比如現比較推崇的Agile敏捷開發，會更強短平快，削弱文檔的溝通而加強團隊的直接交流，簡化流程，快速反饋，快速迭代等等。這種情況下，需求文檔會極大簡化，咱就不在這探討了。· 文檔信息，版本記錄，責任人等· 項目背景，產品目的· 文檔約定（采用的標準，通用名詞等）· 可行性分析o 前期調研o 產品預期o 對其他產品的影響產品定義功能詳述（文檔主體部分）o 功能模塊o 用例o 用戶流程o 數據需求o 業務規則流程· 產品非功能需求o 對性能的需求o 安全性需求等· 產品風險或潛在問題做

4、好產品需求文檔的這十步，是經過長期的實踐經驗和反復驗證而得到的。可能這里描述的不是很全面，但他已經足夠讓你做一個成功的產品需求文檔。做好這幾步花費的時間要以項目的大小、復雜程度、個體學識、基本技能熟練度而定。第一步：做好準備工作你要做的是一個讓人無可爭議的產品，為了做好他，你必須做好前期的準備工作。你需要去了解你的顧客、競爭對手、產品團隊的實力和需要的技術。你需要從顧客、用戶、競爭對手、分析師、產品團隊、銷售隊伍、市場、公司職員等收集他們能發現的問題和可能的解決辦法。這里有很多的工作需要你去完成,在“成功的產品背后”這篇文章中有詳細的描述。建立良好的交流也非常重要，它會影響著產品團隊。如果你的

5、準備工作做的夠好，你也會變得越來越有信心和說服力。第二步：確定產品的目的任何一個好的產品都開始于一個需求。你必須清楚的了解這個需求，你的產品如何達到這個需求。產品經理需要提出一個清晰、簡明的價值主張，讓它很容易被接受，要讓產品團隊、管理人員、用戶、市場人員清楚的明白這個產品到底是什么意圖。雖然這聽起來很簡單，但是也只有少數產品才有這樣的價值主張。考慮“velevator pitch ”(電梯間演講、電梯行銷)測試。假設你在做電梯的時候遇到公司CEO，他問你產品的意圖是什么，你能在電梯到達之前回答這個問題嗎？如果不能，你就還有工作需要做。也許是你的說明沒有針對性，他可能表現出來和其他產品做的沒有

6、什么明顯區別；也許你提出的觀點不能和你的用戶產生共鳴；也許你解決的是一個非常規的問題，可能你想應用一種技術。這個價值主張可能需要滿足公司的產品戰略。注意你不需要闡述太多的細節，從某些方面來說，一個有價值的觀點應當是越簡越好。產品需求需要確切的指出這個產品發布的目標，同樣的這個目標也有優先之分。例如，你的目標可能是：1）易用，2）零售價不足$100，3）和前期產品很好的結合。然后你需要說明如何去測算。對于“易用”這類項目，你需要明確指出產品可用性達到某個水平。這是通常用目標用戶來定義。可用性工程師能測算出你的產品對目標用戶的可用性，也測算出可用性問題的嚴重程度，同樣你可以說明沒有重大的可用性問題

7、。這里的關鍵就是讓每個人都知道產品成功的時候是什么樣，還有給產品團隊在設計和實施中遇到問題如何進行取舍的指導。第三步：確定用戶原型、用戶目標和用戶任務現在你已經明白你想要解決什么問題，下接下來就要深入了解目標用戶和顧客，在這步中，和你的PD（產品設計）緊密聯系非常重要。用戶原型在這個階段，PM需要和很多用戶交流，需要花費大量的時間去直接觀察和討論。現在我們需要對用戶和顧客進行分類，然后決定那一類是我們的首要用戶。比如你正在做一個像eBay一樣的互聯網拍賣服務，你同時擁有買家和賣家，在這之中還有使用頻率少的用戶和經常使用的用戶，不難想象還有個別特殊的用戶，比如團體公司采購者。PM（產品經理）和P

8、D（產品設計）需要首先確定類型是最重要的，然后盡量對這個用戶群的特征進行詳細的描述，以便使用這個模型去指導產品的設計。這個模型通常稱其為“人物角色”。 雖然是想像的，但是應該是典型的、可行的和真實的，讓你能夠使用。這個想法來自與一個能代表這類用戶的本質的原型。舉個例子：“里昂是一個超級賣家，46歲，男性，居住在Fresno，經營小型摩托車配件。雖然他開著一個小店，但是他的生意大部分來自Ebay,每個月平均有400多次交易。他出售的東西品種非常多，但是他最受歡迎的商品還是哈雷戴維森的負重袋。他自己擁有兩個哈雷，還開著1993年的豐田皮卡。里昂已經結婚了還有兩個小孩。里昂買電腦僅僅是因為他需要使用

9、Ebay,除了ebay和電子郵件很少再使用其他東西。里昂已經在Ebay上銷售產品已經三年了，他學會了在ebay應該掌握的東西，他非常自豪的擁有超過5000的信用度。如果Ebay更改了網站，特別是銷售的過程方面，對于他來說改變習慣、學習這些變更是非常困難的。 里昂已經形成了自己的習慣，星期一列出銷售的商品，星期五拍賣結束，設法讓在收到貨款的幾個小時內出貨。”但愿這樣的描述能讓你了解里昂和知道他是怎么來的。當我們考慮新功能時，我就要問問自己里昂會是什么發應，為了讓他能順利的使用這個功能我們需要做什么。注意縮小范圍，讓他僅僅描繪必不可少的。滿足所有人是徒勞的，通常最后沒人會滿意，所以盡量提出幾個最重

10、要的和最流行的角色描述是非常重要的。同樣，如果你不去精確的定位你的目標用戶，你就只會存在模糊的概念，你會發現理解你用戶的反應非常困難。你要傾向于設想，讓你能更像你的用戶。用戶目標（用戶意愿）一旦我們確定并描繪了我們主要的用戶類型，我們就需要找出用戶在使用產品中的目標(想要干什么).這聽起來很簡單，但是解開根本問題是非常具有挑戰性的，特別當你周圍的人告訴你你已經解決了他們想要的。從CEO、銷售代表、工程師到客戶，每個人都太興奮而不能幫助你找到解決根本問題的辦法，他們會告訴你在某個地方添加一個快捷按鈕，或則添加一個功能僅僅是因為競爭對手有，或則是改變成他們喜歡的顏色。最好的解決辦法取決于清晰的了解

11、到底什么問題需要解決，每個用戶模型可能有不同的目的，需要在用戶原型涉及的方面中進行尋找。有可能將來某個功能解決的問題并不是主要用戶需要達到的目標之一。用戶任務（tasks，用戶為達到目標使用產品而需要做的任務）掌握了用戶原型與他們的目標愿望，我們就開始著手設計任務來滿足他們的目標意愿，這是產品制作進程中最核心的部分，也是創造力和創新力被激發的地方。許多優秀的產品僅是用更好更新的辦法解決一個已有的問題，有時候這種辦法僅僅是應用一個種新技術，但是大部分是來自深刻的見解而使一種新方法的產生。例如TiVo（美國市場占有率第一的數字錄像機）在電視節目錄制的老問題上面想出一個全新的辦法，讓顧客更加容易地實

12、現他們的目標并且建立了電子設備一個全新的類別。注意我們雖然談到了目標和任務但是還沒有談到具體的功能，這些功能都需要達到用戶目標而必須的。你以后會發現許多功能都是低優先級或則是完全多余的。以“必須功能”這個理由可以排除很多功能。諷刺的是，你用越少的功能，你的產品被發現得越來越強大。這是因為產品的功能越少，你的用戶就會發現并使用更多的功能，成功的使用越來越多的功能他們就認為你的產品非常強大。這些理由都是違反我們直覺的，我們大多數人都不能和我們的用戶一樣，我們在自己的行業中愿意比用戶花費更多的時間去探索功能和容忍復雜性。第四步：定義產品原則現在你需要開始把你的需求和用戶體驗定義成詳細的要求。同時你仍

13、然會面臨著許多的決定和權衡，為你的產品標準作出最佳的決定是非常重要的。在大多數的產品團隊中，每個成員都有做好產品的原則，但很少有兩個人有同樣的想法，這些差異都會導致不可思議的結果。嘗試和制訂一系列指導整個團隊的產品原則是非常有價值的，這些原則需要具體到域名和項目。用TiVo舉例，在產品團隊工作開始時，以下這些產品規范就被建立，并在團隊里傳達：1.它是娛樂的2.一個傻瓜式的電視3.一個該死的視頻設備4.平滑柔順的5.沒有模式和深層次6.尊重觀眾的隱私權7.像電視一樣強大這些規范很大的影響到產品的定義而且在很大程度上加大了難度，但是他們確實是成功產品的來源。比如易趣的口號就是：1、易于使用 2、安

14、全 3、有趣它將在該項目中，在面對眾多問題而作出決定的時候進行指南.第五步：產品原型和檢驗這是一個拿出你想法的階段，創造力和創新力拿出成就的地方.很多人都容易犯一個常見的錯誤，他們對產品設計規范太有信心，結果一旦得到beta的測試他們就必須調整產品。但是肯定beta測試版并不是進行重大改變的時候，所以才會有許多首次發布的產品離目標太遠。對于許多產品來說，這個時候你可以用大量的原型做很多的實驗。首先，下面的三個非常重要的測試你可能需要做可行性測試一個直接的問題就是產品是否可以開發，你的工程師和設計師應當介入技術的可行性調查和探索可用辦法。有些辦法是行不通的，但是有其他的辦法可行是非常有希望的。工

15、程師會發現在產品的某個階段不可能逾越，現在知道比以后知道要好。可用性測試產品設計師將要和你緊密工作共同提出產品功能，讓它能適應不同的用戶。可用性測試常常會找出遺漏的產品要求，同時確認產品最初的要求是否是必須的。在你拿出一個成功的用戶體驗之前需要多做一些測試工作。可用性的目的是在真正的用戶身上測試，從產品目標用戶得到質量反饋的測試是非常藝術和科學的。當然產品經理和產品設計將模仿使用，但是實際是沒有人能取代真實的目標用戶。概念測試（Product Concept Testing）光是可用和可行是不足的。真正的問題是你的用戶想要購買嗎你的用戶有多喜歡-你做的有什么價值。這測試可能與可用性測試聯系在一

16、起。對于一部份小產品，您的想法寫在紙就足夠了，但是對于多數產品，為了預計產品是否達到目標，復雜用戶互作用或新技術的使用、某種形式原型都是非常重要的。原型也許是一個物理設備，或者它也許是軟件產品的一個預覽版本。關鍵是它需要足夠現實，您能用原型在實際目標顧客身上測試，并且他們可以給您質量反饋。以前做原型主要有兩個障礙。第一是缺乏良好的原型工具，需要花費很多的時間制作原型；另一個是管理方不知道原型和真實產品的區別，在不可預計的情況下，按照最終產品來要求原型。今天有優秀的原型設計工具可以讓工程師或設計師快速的制作原型，可以有效的模擬未來的產品以達到必要的程度讓實際用戶進行測試。而且大多數管理者都知道模

17、仿和實際的區別 就如同縮小比例的房子模型和真實的家一樣。在實際去做產品之前去檢驗你的產品是非常重要的。一旦實際的工程開始，作出重要的變動會變得非常困難，花費也會變得很高。第六步：驗證和質疑當你認為你弄懂了你需要解決的問題，現在是時候開始驗證和質疑假設。假設甚至當作不知道是很容易的，但是切勿把不可知的結論當作指引，那會妨礙你獲得成功。天文學最初定義是研究太陽和其他行星如何圍繞自己轉，本身的定義就是一個臆斷，反而阻止人們獲得真相。第七步：寫當然你需要把這些都寫下來，大多數的PRD都是word文檔，但也有一些是幫助文檔，PowerPoint，或則寫在白紙上。當然用什么格式不是很重要，重要的是讓團隊成

18、功能輕松的看懂，不會遺漏，還有就是PRD可以隨著項目開發而更新。記住對話是兩個人之間的，但是PRD是要溝通整個小組。你也要記住獲得產品的銷售才是是重要的，所以不必擔心要有什么漂亮的外觀、PRD寫的有多厚，只要它是可讀的、可理解的、是需要的內容。PRD文檔主要有四個部份組成產品用途你的工作就是指出目標，團隊需要知道他們的目的是什么，目標說明要盡可能的明確，請確保你的內容包括：*那些問題你要解決，不是解決方案*誰是目標用戶*細節很多，但是大圖片必須清晰*情景描述多開展集思廣益的會議和臨時口頭的討論，從而更好的寫出來，更會讓團隊深入了解。產品功能特性產品需求文檔最主要的當然是需求。 具體的需求完全地

19、將取決于您的領域，但是不管你是什么行業，您的產品團隊將受益于陳述需求的清楚，毫不含糊的要求，而不是模糊的解決方案。描述每個功能的互動設計和使用案例。您必須非常清楚每個功能和用戶體驗，還需要給工程團隊留下足夠多的靈活自主空間。同樣重要的是確定那些要求滿足哪個目的。這里就需要提到“需求跟蹤”，對于關鍵的產品這是一個重要的流程。每種產品規范可能受益于清楚確定那些要求滿足哪個目的，如果某人決定削減要求，想要深入了解就會非常困難。 從要求到目的明確說明將會是文檔更加清晰。發布標準發布標準經常是不斷變化的，但是好的PRD應該考慮到為每種標準定一個最低要求。典型的如：性能，可測量性，可靠性，可用性，可控性。

20、時間進度其中很困難的一個問題就是描述產品需要的時間進度表。隨便列出一個時間是沒用的，你需要描述環境、動機、預計目標。你需要整個團隊都和你一樣達到預計目標，最終完成一個成功的產品。第八步 優先級除了明確的要求，對每一個您的要求給予優先和排列秩序是很重要的。多數產品經理，如果他們給予優先級，一般都是表明要求是否是“必須有， “重要”或“希望擁有” (或其他一些分類系統)。分類是很重要的，不可掉以輕心。產品經理對任何一個標記“必須擁有”都需要有高度的標準。如果還沒有找到必須擁有的功能意味著產品還不應該產生。所以小心標注“必須擁有”，這些標注“必須擁有”的功能直接反應出產品的核心價值。“重要”的分類也

21、很重要，在產品銷售前只要有機會就要滿足這些功能。“希望擁有”產品團隊也應該注意到，即使大多數也都沒有實現，在未來版本也適當的慢慢實現。這些有時候是不夠的，從1到n每一個分類優先排序都是很重要的。有幾個原因：首先，上市時間總是被關注，并且日程表經常下降，您說不定被迫使削減有些特點為了盡快進入市場。 你也不想產品團隊先開發簡單的功能而放松重要的功能，導致最后客戶使用的關鍵功能還沒完成。其次，在產品設計和開發階段，團隊將會發現更多的問題產生并解決這些問題，所以很有可能有更多關鍵功能出現。優先順序會可以幫助你如何平衡以容納更多的功能。這點就是說產品經理如何不給出優先級和重要等級，其他相關較少的因素也會

22、跟著無法確定。整個PRD是一個不斷完善和思維提高的過程，明朗銳利就是可以成功的產品的，模糊就是失敗的產品。在爭論最激烈的時候也能容易做決定，并且幫助工程師做出計劃。第九步 測試完整性現在你有一個PRD草稿，你需要測試它的完整性。工程師是否可以充分了解并達到目標？OA Team（質量管理團隊）是否有足夠的信息來做出測試計劃，是否可以開始做案例？當投資人或相關人審核了PRD，確定了各個需要說明的方面，所有的問題得到解決，現在你就可以按PRD進行產品開發。第十步 管理產品在產品實施期間，就算是最好PRD，也有不計其數的問題被解決。解決所有PRD中存在問題，如果不在PRD中就寫進去。你的任務就是迅速解

23、決問題并記錄在PRD。如果你做了你的工作并準備記錄在PRD，項目審查就會變得非常簡單，因為任何一個部份都歷歷在目。記住PRD是一個“活”的文件，在要跟蹤記錄在產品開發期間的所有功能過程。最后你會發現很多額外的東西，如果你認為是必要的就在PRD中寫進。產品需求文檔PRD模版首先大家一致確認了PRD的重要性，積極的Phoenix拋出了一個可供大家討論的模版。經過大家確認，一致認為效益成本分析是MRD中已經確認的內容，不應該在PRD中討論，所以去掉了效益成本分析這一塊。接下來按順序分析1概述關于概述大家都有不同的想法Phoenix提出概述應該包括名詞說明；產品概述及目標；產品roadmap；產品風險

24、，節奏提出既然是概述肯定要概括的說明產品的背景；產品的目標；產品的基本介紹等，基于經驗大家又發現需要對數據的進行部分說明增添了數據字典的模塊，需要對PRD的閱讀對象進行分工定義，增添了文檔閱讀對象。發散思維的各種討論后，講概述確定為1.1產品概述及目標-包括背景介紹和產品目的1.2名詞解釋-聲明文檔中出現的名詞含義1.3數據詞典-介紹本產品中數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等。1.4文檔閱讀對象-聲明本文檔輸出的閱讀對象和注意事項確認了概述時已經時間用去三分之一，各大神明顯覺得時間過得好快。所以接下來的討論加快了速度，快速的確認接下來主要討論的內容：產品描述和功能描述。 2產品描述討論