編輯導(dǎo)語(yǔ)：完成一份產(chǎn)品PRD需求不難，但是需求產(chǎn)出后的各項(xiàng)設(shè)計(jì)細(xì)節(jié)也非常容易被遺漏，因此準(zhǔn)備一份產(chǎn)品PRD自查清單就顯得很重要，它能夠確保你更加有效地完成整個(gè)過程。

一、產(chǎn)品PRD自查清單

即：針對(duì)產(chǎn)品經(jīng)理寫的需求方案PRD文檔進(jìn)行各項(xiàng)指標(biāo)檢查的檢查清單。

對(duì)產(chǎn)品經(jīng)理來說：

• 需求的產(chǎn)出不難，但是需求產(chǎn)出后的設(shè)計(jì)細(xì)節(jié)容易有遺漏（包含各方面）；
• 很多PM產(chǎn)出需求后自己不會(huì)進(jìn)行嚴(yán)格審查，在一些綜合原因情況下，很多需求都是急急忙忙的產(chǎn)出，然后快速評(píng)審?fù)七M(jìn)開發(fā)測(cè)試落地，后續(xù)會(huì)發(fā)現(xiàn)或多或少的細(xì)節(jié)漏洞或者明顯缺陷；
• 在需求到測(cè)試用例、UX設(shè)計(jì)、技術(shù)方案、開發(fā)落地時(shí)，回頭一看或者被人戳住需求漏洞，猛然醒悟，噢，這里漏了，稍等，我補(bǔ)一下，然后修改原型、PRD、溝通項(xiàng)目經(jīng)理、研發(fā)、測(cè)試，大一點(diǎn)缺陷甚至有推翻部分設(shè)計(jì)的可能或者想辦法犧牲一下方案的完美度來彌補(bǔ)。

需求的自查、有效有用的自查，是一個(gè)非常有效也有用的方法之一，也是成本最低的方法之一，能避免PRD文檔出現(xiàn)低級(jí)錯(cuò)誤或者明顯的遺漏，導(dǎo)致后續(xù)時(shí)間成本、溝通成本、人力成本的增漲。

針對(duì)具體需求的背景介紹、表單、業(yè)務(wù)、場(chǎng)景、數(shù)據(jù)、交互、發(fā)布初始化、測(cè)試、報(bào)表/圖表 每一項(xiàng)細(xì)節(jié)都需要進(jìn)行一一排查是否有遺漏，而每次檢查不是臨時(shí)想到要檢查哪些內(nèi)容，需要針對(duì)需求自查清單梳理出一個(gè)標(biāo)準(zhǔn)檢查表，根據(jù)標(biāo)準(zhǔn)檢查表逐步排查。

當(dāng)然不同的行業(yè)、項(xiàng)目、產(chǎn)品細(xì)化成需求后，檢查項(xiàng)都會(huì)有比較大差異，需要針對(duì)產(chǎn)品、行業(yè)或者項(xiàng)目針對(duì)性的列出自己的標(biāo)準(zhǔn)，而后逐步迭代完善。

提供一個(gè)RPD需求自查清單模板，僅供參考。

二、需求評(píng)審

產(chǎn)品的需求通常都要經(jīng)歷好幾輪評(píng)審，這是非常重要的過程，可以幫助產(chǎn)品經(jīng)理將需求梳理的更清晰、更合理、更完善。

需求評(píng)審?fù)ǔ０?輪：

1. 需求版本迭代規(guī)劃評(píng)審

需求迭代版本規(guī)劃完成后需要進(jìn)行一次評(píng)審，確定產(chǎn)品需求的版本以及上線時(shí)間，且每個(gè)版本的需求優(yōu)先級(jí)。評(píng)審的時(shí)候需要對(duì)每個(gè)版本的需求情況進(jìn)行簡(jiǎn)述，說明需求背景、重要程度、解決問題、需求優(yōu)先級(jí)等，然后確定這個(gè)需求做不做、放入哪個(gè)版本做。

2. 產(chǎn)品需求方案PRD內(nèi)審

確定需求版本規(guī)劃后，產(chǎn)品經(jīng)理要開始產(chǎn)出需求方案PRD文檔，完成后要進(jìn)行需求方案PRD內(nèi)審，內(nèi)審即產(chǎn)品團(tuán)隊(duì)內(nèi)部評(píng)審，需求負(fù)責(zé)人將需求方案PRD文檔詳細(xì)講解一遍，然后評(píng)審人員提問以及相關(guān)討論。

主要評(píng)審人為團(tuán)隊(duì)負(fù)責(zé)人還有產(chǎn)品相關(guān)同事，對(duì)需求的重要性、合理性、完整性、整體性以及細(xì)節(jié)交互進(jìn)行評(píng)審。

需求評(píng)審時(shí)，如果需求問題不大，只是一些小細(xì)節(jié)調(diào)整，那么會(huì)后調(diào)整完即可，如果需求有些漏洞或邏輯、流程問題等，則需求會(huì)被認(rèn)定為評(píng)審不通過，下次還要繼續(xù)進(jìn)行需求內(nèi)審。

3. 產(chǎn)品需求方案PRD技術(shù)評(píng)審

通過需求內(nèi)審后，需求方案PRD要和技術(shù)經(jīng)理或技術(shù)負(fù)責(zé)人進(jìn)行評(píng)審討論，確定從技術(shù)的角度考慮需求時(shí)，技實(shí)現(xiàn)起來沒什么問題。

有時(shí)候技術(shù)會(huì)希望換一種實(shí)現(xiàn)方式，因?yàn)樯婕暗胶芏嗉夹g(shù)方案、框架等問題，這時(shí)產(chǎn)品經(jīng)理要和技術(shù)經(jīng)理達(dá)成共識(shí)。

有些復(fù)雜需求或者偏技術(shù)性需求在需求方案在設(shè)計(jì)時(shí)，就需要先和技術(shù)經(jīng)理私下討論，確定方向上實(shí)現(xiàn)上是沒有問題的，否則在技術(shù)評(píng)審時(shí)，技術(shù)負(fù)責(zé)人說這個(gè)需求方案實(shí)現(xiàn)不了，那就很尷尬了。

4. 產(chǎn)品需求方案PRD公審評(píng)審

需求公審是在技術(shù)評(píng)審后，需求評(píng)審人員比較多（產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、 技術(shù)經(jīng)理、開發(fā)人員、測(cè)試經(jīng)理、測(cè)試人員、UX、UI），產(chǎn)品經(jīng)理要提前發(fā)起需求公審會(huì)議，并發(fā)需求方案PRD發(fā)出來。

技術(shù)經(jīng)理、測(cè)試經(jīng)理要提前分配每個(gè)需求對(duì)應(yīng)的開發(fā)負(fù)責(zé)人以及測(cè)試負(fù)責(zé)人，所有評(píng)審人員需要提前查看方案進(jìn)行預(yù)審，如果有問題要準(zhǔn)備好問題，以便需求評(píng)審能高效快速且有質(zhì)量的完成。

需求評(píng)審的注意事項(xiàng)：

• 注意控制好每次的評(píng)審時(shí)間，要控制好會(huì)議的節(jié)奏。
• 評(píng)審會(huì)議要提前發(fā)出來，需求評(píng)審前要對(duì)需求提前預(yù)審。
• 產(chǎn)品經(jīng)理要進(jìn)行需求自查。
• 需求評(píng)審的人員要安排好，特別是公審時(shí)，具體開發(fā)人員不用每個(gè)需求都全部參加，通常是參加自己負(fù)責(zé)得部分即可。
• 每次需求的評(píng)審記錄要記錄清楚，主要是需求評(píng)審后的待辦事項(xiàng)以及問題。

版本需求迭代評(píng)審表：

下面舉例列出一個(gè)需求版本迭代評(píng)審表，用于某個(gè)版本的需求評(píng)審時(shí)，對(duì)版本所有需求以及需求狀態(tài)的統(tǒng)一管理，僅供參考，可以根據(jù)公司情況進(jìn)行調(diào)整。

本文由 @瞬移的螞蟻 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議