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

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

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

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

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

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

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

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

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

二、需求評審

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

需求評審?fù)ǔ０?輪：

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

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

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)隊內(nèi)部評審，需求負(fù)責(zé)人將需求方案PRD文檔詳細(xì)講解一遍，然后評審人員提問以及相關(guān)討論。

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

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

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

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

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

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

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

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

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

需求評審的注意事項：

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

版本需求迭代評審表：

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

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

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