互動文件，重要的是“互動”，作為文件溝通雙方要做到簡潔，清晰，明瞭首先需要雙方有一套“約定俗成”的規則，這也是很多網際網路企業的所謂“內部文件撰寫規則”，產品和技術溝通的時候能嚴格按照規則來撰寫互動文件，同時具備“同理心”，那寫出來的互動文件自然能夠成為雙方交流的絕佳工具

朋友你的問題，應該是如何寫“產品需求文件 PRD”吧？

我之前寫過這個主題的文章，可以看看。

產品需求文件（PRD, Product Requirements Document）的主要目的之一是提高團隊協作效率。如果PRD質量高，工程師與產品經理之間，以上兩過程可以做到接近零溝通，參考PRD就可以完成工作。相反，如果PRD質量不過關，需要來回溝通，降低合作效率。

如果理解了上面的邏輯，那“檢驗PRD是否合格，標準是什麼？” ryan的答案：研發過程是否接近零溝通。拿PRD給外包公司，能否實現出你想要的產品。

知道好的PRD標準是什麼，如何寫好PRD就很簡單，我只講一些基本原則。

在我們產品團隊內部（富途），我對PRD的要求有3點，可以說是三好原則：

1. 好結構；

2. 好內容；

3. 好排版；

下面展開說一下，都比較好懂。

一、好結構

任何文件，都應該有合理的結構，就像一本書，得有個好目錄。用ryan的這個通用結構，不會有大問題：

修改記錄：

1. xxxxx ---和robin溝通 2018-10-24 22:37

2. xxxxx ---和robin溝通 2018-10-24 22:37

-------------------------------------------------

一、背景

做什麼事都有背景，先說清楚。不然這個PRD交給外包公司的工程師，他們不知道這個需求想幹嘛，為什麼要這麼幹。

二、需求概述

在這部分，先附上完整的互動圖，複雜需求要把流程圖也附上。然後把當前需求拆解，拆成幾大塊，逐個列出來（不用展開細節，只列大模組）：

1. 我是模組A

2. 我是模組B

3. 我是模組C

三、需求詳述

把第二部分的幾個模組，分別展開：

3.1. 我是模組A

附上模組A的互動圖，有流程圖也附上。然後把模組A再拆解：

3.1.1 xxx

3.1.2 xxx

3.2. 我是模組B

同上

3.3. 我是模組C

同上

四、統計&其他

把需要統計上報等特殊內容列出來，哪怕沒有需要統計的，也保留這個章節，寫上“本需求不涉及統計需求”，因為如果不寫，看的人不知道是你忘記這回事兒，還是真的不需要，會來問你，給雙方增加不必要的溝通。

二、好內容

好內容是指，讓人看得懂，且各種疑問都能從PRD找到答案。上述模板的“需求詳述”部分，有特別多的細節需要描述，推薦圖文並茂（一圖勝千字），截一張圖，再從上往下用文字描述。

一般要描述清楚這些資訊：

1. 互動是怎樣

2. 文案是什麼（不能讓技術同學看截圖敲文案，道理自己想）

3. 資料從哪兒來

4. 格式有什麼限制

5. 邊界條件有哪些

6. 適當備註為什麼要這麼做

很多的細節，你在PRD中不說清楚，研發工程師開發過程中就會來問你，給雙方增加沒必要的溝通，降低合作效率。一篇PRD是否合格，最主要就是看內容是否到位，此部分是關鍵。

三、好排版

好排版是指，讓人更容易看懂你的文字，且讓人看得舒服。這點主要考驗同理心，站在研發同學和測試同學的角度，看一篇排版美觀的PRD，會有種賞心悅目的感受，更願意看，也更容易理解產品經理的想法。有些排版原則，簡單說一下：

1. 層級分明

就像我這篇文章一樣，用1234這種列表數字標記出來所屬層級；

2. 用不同縮排表示不同層級

方便閱讀，不多說，看下上文的“一、好結構”中的示例；

3. 慎用一大段文字

一大段文字很難消化，很難表達的東西儘量用圖，只用簡短的文字描述。如果實在需要很多文字，那麼就分段，用1234總結要點分段列出來。

4. 重要的內容特別標記。

比如本文中，重要的內容我會標記為橙色，方便閱讀者注意。

最後總結一下，上面說的觀點：

1. 好的PRD可以提高團隊協作效率；

2. 檢驗PRD是否合格的標準：把PRD交給外包團隊，能否實現出你想要的產品；

3. 如何撰寫好的PRD：三好原則（好結構、好內容、好排版）；

話說回來，PRD文件很難做到“研發過程零溝通”（ryan也沒把握每次自己的PRD都很完美），但我們作為產品經理，作為公司專案的發動機，我們應該儘量按這個標準去要求自己，提高PRD的質量，提升整個團隊的協作效率