起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求文檔撰寫與合格交付原則
文檔的撰寫與合格交付一直是困擾在許多產品經理心中的一個難題。為了解決這個難題，筆者收集了開發、測試、設計人員多方意見，總結出這一份文檔交付原則。
眾所周知，需求文檔的撰寫與交付是每位產品經理工作中必備的技能，而在筆者寫下這套文檔交付原則之前，筆者所在的產品團隊正面臨著需求文檔混亂、格式不統一、不具備參考性等眾多問題。
筆者在收集了多位開發、測試、設計人員的意見后，綜合了一些較為優秀的PRD需求文檔，最終寫下了這篇文檔交付原則。目前也已經成功投入使用，它不僅僅能告訴你如何寫一份需求文檔，也能告訴你文檔在進入設計、開發流程前你需要做哪些準備工作，衷心的希望這篇原則能給讀者們以啟迪！
一、文檔交付流程
文檔從最開始的需求分析到真正以文本格式投入使用往往需要經歷以下幾個階段——即：需求分析→原型設計→文檔撰寫→內部評審→外部評審。
這也是當今主流互聯網公司大多采用的流程，筆者在本文中會主要介紹：原型設計、文檔撰寫、內部評審三個方面。
二、原型設計
原型繪畫是產品經理的基礎技能，但現在許多產品經理都認為繪畫原型沒那么重要，所以草草了事。
但實際上，一份好的原型不僅能幫助設計和后端開發較好的理解你的意圖，也能增進團隊之間的和諧。在筆者的產品工作中，設計人員不止一次因為拿到一些不規范的原型設計向筆者抱怨。那么，一份讓大家都滿意的原型應該滿足哪些要求呢？
筆者認為主要是以下四點：
- 可點擊的頁面跳轉或頁面流程圖
- 清晰且與文檔對應的框架結構
- 美觀且較易于理解的設計草圖
- 簡單、規范、統一的必要文字說明
“可點擊的頁面跳轉或頁面流程圖”：能夠幫開發更好的理解功能流程，也更利于產品經理在內審時對自己做的功能進行介紹，而且這通過Axure的“屏幕快照”功能可以非常輕松的實現。
“清晰且與文檔對應的框架結構”：要求PRD需求文檔功能模塊的名稱要與原型文檔里的名稱對應。
“美觀且較易于理解的設計草圖”：要求產品經理繪畫的原型要至少保證可用性——即有原型且原型交互符合規范。筆者曾遇到過有產品經理在原型設計中將Web端交互放到了移動端，甚至直接給設計人員Web端原型，讓設計人員做一份移動端設計稿的情況。
(移動端原型錯誤的交互設計)
此時的設計人員：“到底你是產品，還是我是產品？？？”
“簡單、規范、統一的必要文字說明”：因為有些功能點描述在文本中表現可能不夠清晰，所以直接在原型上給予標注，這部分要盡量克制。
三、文檔撰寫
1. 我們為什么要寫文檔？
文檔的撰寫目的，筆者認為主要有以下四點：
- 幫助產品經理梳理思路、流程及細節，完善產品。
- 減少設計、開發、測試過程中反復溝通造成的時間浪費和進度延誤。
- 增強用戶意識及程序思維。
- 反向通過完整的PRD、原型對產品進行驗收及質量評價。
以上的一、三、四點都比較好理解，主要是為了完善產品經理的產品思維、減少出錯。而第二點可能有很多人會疑惑，做產品本來就需要我們反復的去跟開發、設計、測試進行溝通，為什么還要減少呢？
這主要是因為：產品經理與他們之間的許多溝通本來是可以不發生的。
例如：一個Button的字段，你在文檔里沒有描述清晰，那么開發就會過來找你問，如果沒有問你直接照著他的想法做了。最后方向和你想的不一樣，那就悲劇了，要接著溝通怎么改了。
所以，對于一個產品經理，最好的狀態是當你完成了某個項目的V1.0版本時，你就應該立刻著手準備V1.1版本的迭代與更新了，而不是接著和團隊的其他成員在V1.0版本上扯皮。
請務必記住：“產品經理是帶著團隊跑，不是和團隊一起跑。”
2. 優秀文檔應具有哪些特性？
筆者認為，優秀的文檔主要具有以下特性：
- 邏輯性：內容有層次，描述可遞進，文檔中的結論要有客觀事實來說明。
- 敏捷性：文檔的內容要盡可能精簡，切勿長篇大論。
- 完整性：在保證文檔內容精簡的同時，也不能缺三少四，重要的模塊不能丟。
- 可讀性：盡量避免使用二義性的語句，這容易造成使用人員曲解你的想法。
- 規范性：每份文檔盡量保證格式相同或類似，減少使用人員的適應成本。
- 一致性：在需求分析模塊的劃分和命名上與原型文檔保持一致。
3. 優秀文檔應該包含哪些模塊？
上文提到：一個好的需求文檔應該做到完整性——即包含所有的重要模塊，不能缺三少四。
那么又有哪些模塊是重要的呢？
筆者在仔細分析了團隊正在做的產品業務后，總結了優秀文檔所需要包含的23個重要模塊，其中有11個模塊是必備的。
筆者相信，這也同樣適用于大部分其他產品的業務。
筆者簡單解釋一下，上圖中各個模塊應包含的內容和存在意義。
（1）版本修訂記錄(必備)：主要包含現有版本的版本號、主要更改內容、更改原因等，它在產品出現問題，追根溯源時可以起到巨大作用。同時，也便于使用人員梳理邏輯。
（2）產品目標（必備）：可以是功能或者產品上線后想要達到的效果。
（4）需求方及背景（必備）：簡述需求產生背景以及原因，需求面向哪些人群？一定要有事實或者數據作為佐證，開發吐槽產品經理亂提需求也不是一天兩天了。
（5）預估收益（必備）：最好能用數字量化產品或功能開發產生的收益，也就是ROI，對收益的正確評判也是產品經理的一項重要能力。這里舉個例子，如“優化公司內部系統某流程，預計耗時13人天，完成后預計可以為公司其他部門每年節省35人天”。這樣的描述，清晰且可信。
（6）風險描述：簡要概述產品或功能開發過程中可能會遇到的內部風險和外部風險，例如：新項目遷移可能遇到未知問題，這就是內部風險。前端開發缺人，項目撞車，這就屬于外部風險。
（7）目標用戶（必備）：簡要描述一下產品或功能上線后服務的人群，有群體特征的最好也寫上。
（8）使用場景：簡要描述一下產品或功能上線后使用的場景。
（9）參與人員（必備）：記錄產品或功能從孵化到上線過程中負責的工作人員，這樣的好處是某個環節一旦出了問題，可以快速的定位到相關的負責人，提高效率，特別是翻看歷史記錄的時候。
（10）項目周期：主要是方便使用人員進行時間規劃，同時可用于進行項目管理，如果所在團隊項目的時間管理已經足夠好，那么這個模塊可以不寫。
（11）名詞解釋：對使用人員可能不了解的名詞進行注釋。
（12）功能流程（必備）：這是PRD需求文檔里最重要的一個模塊，所以在保持簡潔的同時要做到盡可能的詳細。
流程圖的作用不必多說，邏輯清晰的流程圖可以幫助使用者快速的理清業務邏輯，提高效率，減少出錯。而在“交互流程”中，我建議產品經理可以直接用Axure生成的HTML網址進行表示，方便且快捷。
接下來是“頁面及彈窗”，這部分對前端開發意義很大，能有效的避免漏掉某些重要頁面。
最后便是“功能及說明”，這部分主要對產品的每個功能進行詳盡的描述。
以Web端的一個頁面舉例，我們需要介紹這個頁面的操作路徑，頁面上的操作形式，數據的來源，額外的說明等。
具體的示例，筆者在下面用圖片展示：
（13）權限&角色：簡要描述一下使用這個產品或功能的不同特征人群的權限，舉個例子，企業做一個自己的日報系統，老板和員工的使用權限肯定是不一樣的。
（14）性能需求：簡要描述一下產品對性能的要求，如QPS、請求訪問時長等。
（15）營銷&運營需求：這部分主要是面向C端產品，寫出方向性就可以，是與運營聯動的一個模塊。
（16）安全需求：不同產品或功能對于安全的要求往往不盡相同，例如“支付功能”的安全需求比大多其他功能都要高，這個模塊建議寫上產品或功能安全等級的高低，應該做好哪些預防。
（17）法務需求：主要是專利著作權、版權等可能遇到的法務風險，大多產品或功能不存在這個問題。
（18）異常情況（必備）：簡要描述一下用戶使用產品或功能時可能碰到的異常情況，例如突然斷網等。
（19）測試要點（必備）：這部分非常重要，產品經理需要在這個模塊介紹產品或功能在上線前有哪些重點功能是需要反復測試的，有哪些異常邏輯是需要注意的。因為測試人員在一些細節的把控上可能沒有產品經理來的仔細，如果一些重要的點沒能被測試到就直接Pass，在后續的開發中就可能會惹上大麻煩（回爐重造等），從而導致項目延期。
（20）數據埋點及統計需求：寫清楚應該在產品中的哪些維度進行數據埋點，和與之對應的統計需求。
（21）上線前準備（必備）：分點敘述上線前需要完成那些事件，例如把Bug狀態都變為“已解決”。
（22）上線后工作（必備）：大多數產品或功能不是上線就結束了，往往需要后續的跟進，例如進行回歸測試，對用戶進行意見調研、實際收益評估等。
（23）設計規范：針對有交互原則的團隊。
（24）補充說明：其他不屬于以上22個模塊的解釋描述。
四、需求評審
1. 評審的主要流程
- 自評清單，自評通過再內審。
- 內審評價，內審通過再外審。
- 外審評價，外審通過進入開發。
2. 如何做好內審？
內審是評審的第一步，如果沒有卡好內審這門關卡，隨意的讓項目通過，會導致外審時項目出現諸多紕漏，浪費團隊其他人員的時間，所以內審一定要足夠謹慎。
針對內審，筆者總結了六條原則：
- 至少應有3人參與內審；
- 內審必須邀請項目管理者參與；
- 要提前給定好內審預計所需要的時間；
- 基礎測試一旦沒有通過，內審必須當即中斷；
- 評審結束后，相關人員應該在幕后形成相關的結論；
- 每次內審需做內審會議紀要，紀要包括內審的結論和問題。
這六條原則應該都是比較通俗易懂的，但關于基礎測試，筆者要額外解釋一下：所謂基礎測試其實就是需求或功能流程，如果在內審當中，因為產品經理個人的靈光乍現或者是他人異議發現原定流程中有一段已經完全行不通了，那此時的內審也就沒有意義了。產品經理應立刻停止內審，回去重新思考并修改流程，但如果僅僅是某一個節點需要修改，影響較小，則可以繼續進行。
3. 評審需要符合那些標準？
- 合理性：成本、收益、用戶、痛點、風險等評估要合理。
- 完整性：角色是否完整、狀態是否完整、功能是否完整。
- 可行性：技術的可行性，是否觸碰到已知邊界。
- 一致性：保持相同的視覺風格、交互方式和情感傳達。
- 邏輯性：流程是否清晰便于其他人理解。
- 準確性：字段、數據源、數據計算方式、異常狀態等。
- 易用性：用戶使用成本是否足夠低，路徑足夠簡潔。
- 復用性：是否考慮復用已有產品、框架、設計。
- 創新性：是否能夠盡可能發揮創新的能力。
以上標準既適用于內審，也適用于外審。
總結
文檔的撰寫與合格交付一直是困擾在許多產品經理心中的一個難題。現在許多的人都建議直接用Axure來同時進行原型與PRD文檔的制作，這種方式的確非常節省時間，但要注意這個時間只是節省了寫文檔的時間，在接下來的設計、開發、測試過程中，由于前期文檔內容不夠詳盡，耗費的時間實際上是大幅度增加了。
在筆者寫下這篇原則之前，所在團隊也是采取Axure原型和文檔一起做的模式，但實行起來效果并不好——前端、測試、設計飽受這種不規范文檔之苦。所以，依舊建議大家用文字表達。
這套原則因為是第一版，且筆者作為一個實習生還沒有太多的產品工作經歷，所以在部分模塊細節上可能仍然有許多疏漏。特別的，可能因為從事的業務相關，這套原則不能完全的適用于其他團隊產品的工作模式，不過筆者相信它依舊能給你們以啟發。
至于這套原則的下一步，筆者目前所考慮的是協同文檔，WIKI、石墨等等，如果大家有好的建議或者是看法，也歡迎在評論中提出，筆者都會認真聆聽并虛心接受，謝謝！
本文由 @天下 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
額，看了半天，看到最后居然表明自己是新人，還是實習。額，經驗真的有點少啊…………作為要入行的人，看到這樣的字眼，頓時感覺就不太好了，還是希望看到成熟些的總結。不好意思了作者，請原諒。雖然我還是很欣賞你。只是希望能在一開篇就表明，不好意思了。
這是免費的分享交流平臺，人家雖然經驗不是很豐富，但是比你強吧？白給你看還提那么多要求。
好的很好的很
真棒
寫的真不錯
很不錯的文章，又拓寬了我的知識面，感謝作者
寫的好。
好文
你好，能不能發我一份需求文檔啊，我是新人
非常感謝您的文章，反復看了很多遍。簡單梳理后我覺得可以做出以下七點流程：
『版本修訂記錄』~1.需求方及背景（風險描述）――2.目標用戶（使用場景）――3.產品目標（預估收益）――4.需求流程（異常情況）――5.功能流程（性能需求）――6.交互流程（頁面及彈窗）――7.營銷&運營需求（數據埋點&統計需求）~『測試要點』
我是一名對產品崗有興趣的在校學生，不足之處還望前輩指正。
個人覺得本文缺少案例，理論難有說服力
工作中遇到困擾，想請教一下作者，原型和文檔都是必須的嗎？比如原型里面寫的十分詳細，那么還需要寫prd嗎？設計和開發是看原型多一些還是prd多一些？哪種形式他們更容易理解？
總體來說，原型圖也好還是PRD文檔也好，通常都是內部輸出的文件。原型圖的設計在我看來是必須的，沒有原型圖，那么只是直觀的對頁面進行描述那就會導致UI和前端對需求的認知較為模糊。而PRD通常要看這個產品的復雜程度，如果產品簡單在原型圖上做標注能夠清晰展示那么也ok，但是如果產品相對復雜，在原型標注上無法清晰展示那么就需要一份詳細的PRD文檔作為支撐。另外，沒有哪個產品的設計是百分之百的，留存PRD文檔，是在進行產品評估或是需求變更的時候一個基本參考依據。PS
:沒有產品PRD，你們測試怎么寫的測試文檔？？？
看原型圖寫測試用例呀，都在原型上寫清楚，磨磨唧唧的比prd篇幅還多呢
只有需求說明是必須的，原型和PRD文檔只是產品需求的載體而已。獨立的PRD文檔已經發展很多年了，有成熟的規范和標準，撰寫起來不容易遺漏，按照模板填就好了。而越來越多產品經理將PRD直接寫在原型上面，使需求更易閱讀和理解，但由于沒有形成規范，需求產出的質量參差不齊，結果可想而知。其實只要你們團隊定好規范，這種展現方式是絕對可以淘汰獨立PRD文檔的。
其實必要的注釋說明直接附在Axure上面是可以的，做到詳盡；考慮欠妥、缺乏交代的文檔才是浪費時間的最大原因。
很不錯的，整理歸納了一下產品prd的要點
謝謝！