產品需求文檔模塊有哪些

A. 產品需求文檔模板

首先告訴你產品需求文檔肯定是有的！一個經過實際工作檢驗、經歷過「質疑」、「挑戰」和「斗爭」之後沉澱下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標准化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種「標准」的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。

不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，並在此過程中形成自己對於模板的理解，進而形成對於產品需求文檔的理解，在理解中使用，裁剪和優化。

要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：

一、描述-解釋-預測-監控

描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。

解釋，是回答 「為什麼」，是對於描述的理解、歸類、定義和解釋。其目標是將描述內容背後的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對於描述內容有更清晰、更細致、全面的了解。

預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，准確地表達內在聯系，從中推導出正確的預測。

監控，是對於預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而採取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的「響應」機制，並任其自然發生或者通過提供「系統」的自製能力來實現。

二、需求准備、編寫和檢查

回歸到產品經理的日常工作中，在時間佔比上較為集中的就是產品需求管理了，包括了需求的准備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，並可以幫助理解、形成並固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。

1. 描述

描述的過程是客觀的進行「需求向」描述的過程，是一個「背景」信息的補充，用來說明，這個需求文檔的源出是什麼，是針對什麼問題，這個問題是在具體什麼領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什麼，參與者是怎麼解決的，解決的情況怎麼樣，是好，還是不好，還是勉強可以，對於新的需求的緊迫性是什麼樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和「溝通字典」，避免在溝通中因為誤解而產生不必要的偏差。

需求准備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；

需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；

需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干係人角色和影響范圍；

需求檢查的過程：需求的背景、目標、過程、干係人、結果預測和預防的完整性檢查；

2. 解釋

解釋在需求來源的基礎上描述了 「為什麼」接下來這個需求可以解決遇到的問題，同時還加入了「是什麼」和「怎麼樣」的部分。就是這個需求是通過怎麼樣的方法解決了「描述」過程中提到的問題，這個新的解決方法需要要做什麼，對於原有的業務過程有哪些改變，會提升什麼，會降低什麼，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上佔比最大的一部分。

這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對於運營的影響，對於前端市場的影響，對於用戶的影響，對於財務、法務的影響；從技術開發、技術實現維度，比如對於前端開發的影響、對於服務端開發的影響、對於數據平台的影響，還可能涉及到對於運維資源的影響等；因此對應到實際的產品需求工作中：

需求准備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；

需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；

需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與後服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先順序；系統架構、干係人角色和影響范圍；

需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；

3. 預測與監控

預測與監控在產品需求文檔的管理上是聯動的，是對於預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對於設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 「非規劃」的使用，也就是我們通常說的「用戶並不總是按照產品設計的方式來使用產品，而且，往往相反。」因此，這部分內容很大的比例需要來對於用戶的行為進行預測和監控，並提供「預防」或者「解決」方案。其中：

預防在於，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最後操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多採用導航、提示等，不同的系統都有各自標准化的控價，我們在這里不做展開。

解決在於，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了「非標」、「超規」使用「掉出」原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來「回轉」用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過「導航」引導「跳轉」和「返回」、「回退」來實現。對應到實際的產品需求工作中：

需求准備的過程：了解用戶特徵和使用水平、評估、比較不同方式實現需求對於用戶行為的可控性和「非常規」操作的危害程度；

需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；

需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；

需求檢查的過程：需求「異常」流程和相應引導、控制地完整性檢查；

在需求管理的過程中，就可以按照這個 描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之後的檢查。

四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標准。所謂標准文檔，就可以按照這四個模塊作為框架、內容和格式。

寫在最後

產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，並最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。

B. 完整的PRD文檔包含哪些內容

完整的PRD文檔包含的內容如下：

1、文檔概述：文檔狀態、文檔修訂記錄、態簡舉名詞解釋。

2、產品概述：需求背景和需求目的、需求和功能拆分清單、產品架構圖和重要流程圖、原型交互。

3、需求詳細描述：拆分各個模塊詳細描述需求功能點，包括正常流程和異常流程。

4、帆碧非功能性需求：比如數據埋點需求和運營需求等。

PRD的主要使用對象

研發、測試、交互設計師及其他業務人員。

研發可以根據PRD獲知整個產品的邏輯，作為編碼的依據；測試可以根據PRD編寫測試用例，為正式測試做准備；交互設計師可以根據PRD設計交互細節；業務人員可以咐敏通過PRD提前了解產品，為運營和推廣做准備。

C. 產品需求文檔應該包含哪些內容

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

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

梳理下PRD的功能：

傳達出產品需求；

管理記錄產品迭代過程；

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

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

結構清晰

語言簡潔易懂

實時共享

具體我們該如何製作？

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

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

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

多級導航結構展示PRD信息

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

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

1、產品概述

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

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

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

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

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

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

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

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