產品PRD自查清單以及需求評審
編輯導語:完成一份產品PRD需求不難,但是需求產出后的各項設計細節也非常容易被遺漏,因此準備一份產品PRD自查清單就顯得很重要,它能夠確保你更加有效地完成整個過程。
一、產品PRD自查清單
即:針對產品經理寫的需求方案PRD文檔進行各項指標檢查的檢查清單。
對產品經理來說:
- 需求的產出不難,但是需求產出后的設計細節容易有遺漏(包含各方面);
- 很多PM產出需求后自己不會進行嚴格審查,在一些綜合原因情況下,很多需求都是急急忙忙的產出,然后快速評審推進開發測試落地,后續會發現或多或少的細節漏洞或者明顯缺陷;
- 在需求到測試用例、UX設計、技術方案、開發落地時,回頭一看或者被人戳住需求漏洞,猛然醒悟,噢,這里漏了,稍等,我補一下,然后修改原型、PRD、溝通項目經理、研發、測試,大一點缺陷甚至有推翻部分設計的可能或者想辦法犧牲一下方案的完美度來彌補。
需求的自查、有效有用的自查,是一個非常有效也有用的方法之一,也是成本最低的方法之一,能避免PRD文檔出現低級錯誤或者明顯的遺漏,導致后續時間成本、溝通成本、人力成本的增漲。
針對具體需求的背景介紹、表單、業務、場景、數據、交互、發布初始化、測試、報表/圖表 每一項細節都需要進行一一排查是否有遺漏,而每次檢查不是臨時想到要檢查哪些內容,需要針對需求自查清單梳理出一個標準檢查表,根據標準檢查表逐步排查。
當然不同的行業、項目、產品細化成需求后,檢查項都會有比較大差異,需要針對產品、行業或者項目針對性的列出自己的標準,而后逐步迭代完善。
提供一個RPD需求自查清單模板,僅供參考。
二、需求評審
產品的需求通常都要經歷好幾輪評審,這是非常重要的過程,可以幫助產品經理將需求梳理的更清晰、更合理、更完善。
需求評審通常包含4輪:
1. 需求版本迭代規劃評審
需求迭代版本規劃完成后需要進行一次評審,確定產品需求的版本以及上線時間,且每個版本的需求優先級。評審的時候需要對每個版本的需求情況進行簡述,說明需求背景、重要程度、解決問題、需求優先級等,然后確定這個需求做不做、放入哪個版本做。
2. 產品需求方案PRD內審
確定需求版本規劃后,產品經理要開始產出需求方案PRD文檔,完成后要進行需求方案PRD內審,內審即產品團隊內部評審,需求負責人將需求方案PRD文檔詳細講解一遍,然后評審人員提問以及相關討論。
主要評審人為團隊負責人還有產品相關同事,對需求的重要性、合理性、完整性、整體性以及細節交互進行評審。
需求評審時,如果需求問題不大,只是一些小細節調整,那么會后調整完即可,如果需求有些漏洞或邏輯、流程問題等,則需求會被認定為評審不通過,下次還要繼續進行需求內審。
3. 產品需求方案PRD技術評審
通過需求內審后,需求方案PRD要和技術經理或技術負責人進行評審討論,確定從技術的角度考慮需求時,技實現起來沒什么問題。
有時候技術會希望換一種實現方式,因為涉及到很多技術方案、框架等問題,這時產品經理要和技術經理達成共識。
有些復雜需求或者偏技術性需求在需求方案在設計時,就需要先和技術經理私下討論,確定方向上實現上是沒有問題的,否則在技術評審時,技術負責人說這個需求方案實現不了,那就很尷尬了。
4. 產品需求方案PRD公審評審
需求公審是在技術評審后,需求評審人員比較多(產品經理、項目經理、 技術經理、開發人員、測試經理、測試人員、UX、UI),產品經理要提前發起需求公審會議,并發需求方案PRD發出來。
技術經理、測試經理要提前分配每個需求對應的開發負責人以及測試負責人,所有評審人員需要提前查看方案進行預審,如果有問題要準備好問題,以便需求評審能高效快速且有質量的完成。
需求評審的注意事項:
- 注意控制好每次的評審時間,要控制好會議的節奏。
- 評審會議要提前發出來,需求評審前要對需求提前預審。
- 產品經理要進行需求自查。
- 需求評審的人員要安排好,特別是公審時,具體開發人員不用每個需求都全部參加,通常是參加自己負責得部分即可。
- 每次需求的評審記錄要記錄清楚,主要是需求評審后的待辦事項以及問題。
版本需求迭代評審表:
下面舉例列出一個需求版本迭代評審表,用于某個版本的需求評審時,對版本所有需求以及需求狀態的統一管理,僅供參考,可以根據公司情況進行調整。
本文由 @瞬移的螞蟻 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
能否分享一份prd文檔 感謝
哇,這么細致,收啦,自查清單里好多和我前面做過的功能撞上了