產品需求寫什麼

『壹』 互聯網產品的需求文檔寫作，應該注意哪些事項和規范

1、寫前准備(信息結構圖)：產品需求文檔的寫作(一)在寫PRD文檔之前，我們需要先羅列出產品功能的信息內容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來規劃功能的輔助信息，同時也可以輔助服務端技術人員創建資料庫。因為這是第一步，所以我們不需要羅列的很詳細，在之後的步驟里，我們會逐步改進和完善信息內容。例如一篇文章的信息內容主要有：文章標題、文章正文、文章作者、發布時間、所屬分類。初始的功能需求只有這些信息內容，但是在之後的功能規劃中逐漸更加細致的考慮時，可能會增加或者刪減，因此第一步我們不用刻意的追求信息的全面。羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是思維導圖，因此我稱這一步為信息結構圖。2、梳理需求(產品結構圖和用戶流程圖)：產品需求文檔的寫作(二)當我們對產品的信息結構了解後，我們就需要規整腦海中的產品需求，讓想法更加結構化，因此這一步是梳理產品的需求。我們首先要羅列出產品的頻道及頁面(產品結構圖)，其次再基於產品結構圖梳理出頻道及頁面中的功能，並延伸構建出用戶的操作流程(用戶流程圖)。以上兩步是為了讓我們在撰寫產品需求文檔之前能夠對產品有一個全面的了解，類似鳥瞰式的一目瞭然，也方便調整完善。3、原型設計(手繪原型,灰模原型,交互原型)：產品需求文檔的寫作(三)當我們逐漸清晰了產品的需求後，並梳理了產品的各個頻道及頁面，那麼這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。首先我建議通過手繪的形式快速在草紙上繪制出產品的原型，推演和討論方案的可行性，當有一定的進展之後，我們再通過軟體工具進行更深入的設計。移動產品可以考慮灰模原型，網站產品可以考慮交互原型，對於這兩種原型方式，無論是移動產品還是網站產品都可以使用，具體取得於你的個人習慣和團隊要求。對於產品經理來說，原型設計是為了幫助我們細致的考慮方案，並論證方案的可行性，同時也是為了避免產品宣講時，抽象的語言描述導致聽眾理解困難和理解偏差。4、撰寫文檔(PRD文檔)：產品需求文檔的寫作(四)當我們通過以上三個大的步驟之後，我們就已經非常清晰產品的需求了，一般情況下，通過原型加描述的方式就已經完成了PRD文檔的目的(很多產品經理直接使用Axure製作PRD)。當然也會有一些個人或團隊的要求不一樣，對PRD文檔有特定的規范標准，這類情況可能是需要存檔歸類。無論什麼樣的規范標准，PRD文檔的目的都是相近的，因此功能描述的方式也是相似的，所以在這里我分享了三種撰寫PRD文檔的方式。5、用例文檔(UML用例圖、流程圖)：產品需求文檔的寫作(五)《產品需求文檔(PRD)的寫作方法》的補充文章，主要講解PRD文檔中的重要輔助文檔「用例文檔」。

『貳』 如何寫好產品需求

產品經理日常一項重要工作就是收集整理產品需求，轉化為產品需求文檔，將需求傳遞給項目團隊成員，完成需求功能開發測試上線。如何寫好產品需求屬於技術活，好的產品經理的需求有條理，由淺入深闡明問題及解決方案，而一般的方案會讓人看過後不知所雲，需要再次澄清需求。

如何寫好產品需求，有小竅門或理論可以參考，比如金字塔原理，在產品初期，我們往往會犯思路不清晰、無法明確表達自己的想法，或者提煉不出產品核心需求點的問題。這時，運用金字塔原理可以幫助我們構建清晰的邏輯思路，更好地表達產品觀點。

根據金字塔原理的指導，從分析需求產生的背景，到根據背景認清沖突點，分條列出沖突問題，歸納整理思路；最後根據已知問題，針對性地提出解決方案，尋求解決問題之道。以上步驟完成後，便可以將所有思路總結成文檔，具體實施。這種構建方式可以很明確地表述自己的思想，增強代入感。

歸納總結共三點：

1、分析背景，提煉關鍵需求點

關鍵需求點不用長篇大論，最好能一句話說明要做的事情，如果要深入細節，再詳細描述。

2、用歸納法理清你的思路

提煉關鍵需求點後，可以針對需求點提出相應解決方案，多個需求或解決方案之間可能存在邏輯關系或沖突，通過歸納法來總結梳理，幫助把握核心需求點、區分優先順序。

3、尋找問題解決知道

歸納總結問題後，剩下就是針對問題尋找解決方案了，解決方案的好壞取決於產品經理的經驗與學習能力。

『叄』 需求文檔怎麼寫最有效

能將功能需求寫清楚的就是好的需求文檔，因為現在的需求文檔一般都是給開發看，一般來說創業公司追求小步快跑快速迭代的開發模式的話，需求文檔不是一個很有必要的東西，直接在原型上表述效率會更好。如果公司追求規范管理的話，建議還是需求文檔，寫清楚項目名稱，迭代版本，及相關的日期規劃。

『肆』 如何寫一份易用的產品需求文檔

產品需求文檔分很多種，這里我只說一種讓程序員看起來舒服的需求文檔格式吧：

作為程序員，在需求文檔當中，最關注的內容是哪幾種呢？
1、流程：包括業務流程和基本流程；
2、數據：包括輸入數據和展示數據；
3、事件流：特別是分支事件流和例外事件流，感覺很多需求文檔中，缺少了這部分；

那麼，文檔的模板是怎麼樣的呢？
1、需求說明：主要闡述為什麼要做這個需求；
2、業務流程：最好使用VISIO來繪制，畫出整個業務的流程圖，特別是其中所要涉及的判定，分支等，都要畫出來，越詳細越好；
3、基本流程：繼續使用VISIO，畫出基本流程即可，一般來說都是業務流程中的最主要部分，但是可以加入更多的細節；
4、分支事件流：VISIO，各種分支事件的詳細流程，越詳細越好；
5、例外事件流：這里要使用表格，示例如下：主要是系統判定和對應的提示；6、輸入數據：用戶可以輸入數據的欄位，已經相應的定義，包括是否必填，欄位長度，錄入方式，對應規則等；
7、顯示數據：頁面顯示給用戶的數據，對應的欄位，取數規則，對應規則等;
8、補充說明；這個需求文檔模板，更傾向於傳統的軟體模板，而不是網路上比較流行的AXURE文檔。

『伍』 產品需求文檔應該包含哪些內容

我們先假如產品需求文檔（PRD）是一個產品，那麼該如何做出一個擁有良好用戶體驗的PRD？

首先先來考察下PRD的用戶群體（User Persona）：主要是開發人員，在繁忙的開發任務中最希望看到「簡潔易懂」的產品需求文檔。

梳理下PRD的功能：

傳達出產品需求；

管理記錄產品迭代過程；

各部門共享產品信息，以促進溝通；

因此一個好的PRD的原則是：

結構清晰

語言簡潔易懂

實時共享

具體我們該如何製作？

答案很簡單——一個PRD文檔即可

現在，越來越多的產品經理採用將文本說明和原型結合成一個PRD文檔的方式，因為之前的word+原型的方式管理起來繁瑣，而且還容易產生信息疏漏。

將原型和文本說明統一，直接分享一個鏈接，開發人員就能看到所有信息，是理想狀態。

多級導航結構展示PRD信息

通常來講，一個產品需求文檔里包含「產品概述」、「流程圖」、「功能詳情和原型」，「全局說明」，「非功能性需求」。

如何把這些內容清晰有條理地呈現在一個文檔里呢？使用一個網頁般的多級導航結構即可。

1、產品概述

產品概述部分用於展示文檔修訂歷史、版本說明、開發周期、和產品介紹。

「文檔修訂歷史」用來記錄產品經理對該PRD文檔的修改狀況，也方便成員能及時了解到PRD是否有改動；

「版本說明」展示上線產品各版本的核心功能；

「開發周期」用於梳理開發、測試、上線的預計開始和結束日期。

「產品介紹」用來記錄產品名稱、簡介、用戶畫像、使用場景、產品定位等等。

通過墨刀的分享鏈接還能直接讓公司內部人員在線實時同步PRD的更新，不用再擔心信息滯後或者文檔不兼容問題。

讓我們著手開始創建或者優化您的產品需求文檔吧～
希望採納！謝謝！

配圖來自 「運維派」以及墨刀官網截圖