需求文檔的撰寫與交付是每位產品經(jīng)理工作中必備的技能，而大多數(shù)的產品團隊面臨著需求文檔混亂、格式不統(tǒng)一、不具備參考性等眾多問題。在收集了多位開發(fā)、測試、設計人員的意見后，綜合了一些較為優(yōu)秀的PRD需求文檔，最終寫下了這篇文檔交付原則。它不僅僅能告訴你如何寫一份需求文檔，也能告訴你文檔在進入設計、開發(fā)流程前你需要做哪些準備工作，希望這篇原則能給讀者們以啟迪！一、文檔交付流程文檔從最開始的需求分析到真正以文本格式投入使用往往需要經(jīng)歷以下幾個階段即需求分析→原型設計→文檔撰寫→內部評審→外部評審。這也是當今主流互聯(lián)網(wǎng)大多采用的流程，筆者在本文中會主要介紹原型設計、文檔撰寫、內部評審三個方面。二、原型設計原型繪畫是產品經(jīng)理的基礎技能，但現(xiàn)在許多產品經(jīng)理都認為繪畫原型沒那么重要，所以草草了事。但實際上，一份好的原型不僅能幫助設計和后端開發(fā)較好的理解你的意圖，也能增進團隊之間的和諧。在筆者的產品工作中，設計人員不止一次因為拿到一些不規(guī)范的原型設計向筆者抱怨。那么，一份讓大家都滿意的原型應該滿足哪些要求呢？筆者認為主要是以下四點可點擊的頁面跳轉或頁面流程圖清晰且與文檔對應的框架結構美觀且較易于理解的設計草圖簡單、規(guī)范、統(tǒng)一的必要文字說明“可點擊的頁面跳轉或頁面流程圖”能夠幫開發(fā)更好的理解功能流程，也更利于產品經(jīng)理在內審時對自己做的功能進行介紹，而且這通過的“屏幕快照”功能可以非常輕松的實現(xiàn)?！扒逦遗c文檔對應的框架結構”要求PRD需求文檔功能模塊的名稱要與原型文檔里的名稱對應?！懊烙^且較易于理解的設計草圖”要求產品經(jīng)理繪畫的原型要至少保證可用性即有原型且原型交互符合規(guī)范。筆者曾遇到過有產品經(jīng)理在原型設計中將Web端交互放到了移動端，甚至直接給設計人員Web端原型，讓設計人員做一份移動端設計稿的情況。三、文檔撰寫1.我們?yōu)槭裁匆獙懳臋n？文檔的撰寫目的，筆者認為主要有以下四點幫助產品經(jīng)理梳理思路、流程及細節(jié)，完善產品。減少設計、開發(fā)、測試過程中反復溝通造成的時間浪費和進度延誤。增強用戶意識及程序思維。反向通過完整的PRD、原型對產品進行驗收及質量評價。以上的一、三、四點都比較好理解，主要是為了完善產品經(jīng)理的產品思維、減少出錯。而第二點可能有很多人會疑惑，做產品本來就需要我們反復的去跟開發(fā)、設計、測試進行溝通，為什么還要減少呢？這主要是因為產品經(jīng)理與他們之間的許多溝通本來是可以不發(fā)生的。例如一個的字段，你在文檔里沒有描述清晰，那么開發(fā)就會過來找你問，如果沒有問你直接照著他的想法做了。最后方向和你想的不一樣，那就悲劇了，要接著溝通怎么改了。所以，對于一個產品經(jīng)理，最好的狀態(tài)是當你完成了某個項目的V1.0版本時，你就應該立刻著手準備V1.1版本的迭代與更新了，而不是接著和團隊的其他成員在V1.0版本上扯皮。請務必記住“產品經(jīng)理是帶著團隊跑，不是和團隊一起跑?！?.優(yōu)秀文檔應具有哪些特性？筆者認為，優(yōu)秀的文檔主要具有以下特性邏輯性內容有層次，描述可遞進，文檔中的結論要有客觀事實來說明。敏捷性文檔的內容要盡可能精簡，切勿長篇大論。完整性在保證文檔內容精簡的同時，也不能缺三少四，重要的模塊不能丟。可讀性盡量避免使用二義性的語句，這容易造成使用人員曲解你的想法。規(guī)范性每份文檔盡量保證格式相同或類似，減少使用人員的適應成本。一致性在需求分析模塊的劃分和命名上與原型文檔保持一致。3.優(yōu)秀文檔應該包含哪些模塊？上文提到一個好的需求文檔應該做到完整性即包含所有的重要模塊，不能缺三少四。那么又有哪些模塊是重要的呢？筆者在仔細分析了團隊正在做的產品業(yè)務后，總結了優(yōu)秀文檔所需要包含的23個重要模塊，其中有11個模塊是必備的。筆者相信，這也同樣適用于大部分其他產品的業(yè)務。四、需求評審1.評審的主要流程自評清單，自評通過再內審。內審評價，內審通過再外審。外審評價，外審通過進入開發(fā)。2.如何做好內審？內審是評審的第一步，如果沒有卡好內審這門關卡，隨意的讓項目通過，會導致外審時項目出現(xiàn)諸多紕漏，浪費團隊其他人員的時間，所以內審一定要足夠謹慎。針對內審，筆者總結了六條原則至少應有3人參與內審；內審必須邀請項目管理者參與；要提前給定好內審預計所需要的時間；基礎測試一旦沒有通過，內審必須當即中斷；評審結束后，相關人員應該在幕后形成相關的結論；每次內審需做內審會議紀要，紀要包括內審的結論和問題。這六條原則應該都是比較通俗易懂的，但關于基礎測試，筆者要額外解釋一下所謂基礎測試其實就是需求或功能流程，如果在內審當中，因為產品經(jīng)理個人的靈光乍現(xiàn)或者是他人異議發(fā)現(xiàn)原定流程中有一段已經(jīng)完全行不通了，那此時的內審也就沒有意義了。產品經(jīng)理應立刻停止內審，回去重新思考并修改流程，但如果僅僅是某一個節(jié)點需要修改，影響較小，則可以繼續(xù)進行。3.評審需要符合那些標準？合理性成本、收益、用戶、痛點、風險等評估要合理。完整性角色是否完整、狀態(tài)是否完整、功能是否完整?？尚行约夹g的可行性，是否觸碰到已知邊界。一致性保持相同的視覺風格、交互方式和情感傳達。邏輯性流程是否清晰便于其他人理解。準確性字段、數(shù)據(jù)源、數(shù)據(jù)計算方式、異常狀態(tài)等。易用性用戶使用成本是否足夠低，路徑足夠簡潔。復用性是否考慮復用已有產品、框架、設計。創(chuàng)新性是否能夠盡可能發(fā)揮創(chuàng)新的能力。以上標準既適用于內審，也適用于外審。面經(jīng)專注高質量互聯(lián)網(wǎng)產品經(jīng)理面試經(jīng)驗，助力收割大廠！