產品需求文檔(PRD)怎么寫?新人必備攻略
作為產品經理的必備技能,寫PRD是基本功之一。但就是這么基礎的要求,還是有部分產品經理不知道怎么寫,或者剛入門還不會寫。這篇文章,作者給我們詳細說明了PRD的要求和寫法,希望可以幫到大家。
1.需求文檔的作用
1.1 對設計任務管理的作用
在做一個設計任務時,需要收集現有情況、歷史原因、設計阻礙點等信息,輸出當前任務的設計文檔,當前文檔又可作為后續優化設計的方向和參考依據。
- 產品需求文檔是產品工作流程中各個環節對需求描述和傳達最快速的工具,減少溝通成本:每一個環節和任務協作人都需要理解需求的定義和描述,通過文檔對需求的傳達,能減少產品經理在各環節與各方的溝通交流。
- 產品需求文檔保證各部門溝通有理有據,還可以為產品質量控制做好保障:當產品設計研發過程中不斷偏離需求時,此時需求文檔作為一份需求評審時已統一目標的文檔,有利于團隊回歸到產品設計的正軌上,保障產品按照目標順利完成上線。
- 產品需求文檔有利于產品迭代管理中回溯:此前需求的設計及規劃產品迭代管理中,我們可以回溯上一版需求文檔中的迭代計劃的背景及需求的目標,結合當前的效果及不足,做出新的迭代的規劃。
- 產品需求文檔有助于新成員快速熟悉項目:對于組內新的產品經理來說,了解過往的產品需求文檔可以更好地了解產品的內在邏輯和外在表現。
1.2 對協作人員的作用
一般情況下,任務納入迭代計劃后,協作流程中第一個設計環節是產品設計,即輸出需求文檔。任務迭代過程中,協作人員需要閱覽需求文檔,依據需求文檔做設計和開發,其使用場景如下:
2. 如何寫好需求文檔
要想寫出好的需求文檔,那我們首先要明白什么樣的文檔才算是一個好的需求文檔。在我看來,一份好的需求文檔至少要講清楚以下幾個問題:
- 方案是否合理:選擇的方案是否為解決當前問題的最優解。
- 功能規則設計是否詳盡:功能改動點和業務規則描述是否合理且詳盡,是否已存在邏輯漏洞。
- 設計是否具有拓展性:對后續迭代和拓展是否提供了良好的基礎。
第一點實際上就是要求我們去設計對的需求。第二個點是要求對我們所定義的需求,不僅要描述主流程還要將與該流程相配合的相關其他模塊都描述清楚。第三點是在前兩者的基礎上進行一個升級,也就是當我們能正確的完整的描述一個需求之后接下來希望你所描述的需求能是最優方案,也就是能給用戶帶來更好的用戶體驗的一種方案。
3. 需求文檔各模塊要點
3.1 需求背景&歷史原因
需求是當前背景下的需求。這里的背景,需要寫明白的內容可包括但不限于當前產品所處行業的現狀,產品/功能模塊所處的狀態、目標,開發團隊的資源限制、技術限制等。在作為用戶體驗其他競品的一些功能時,不免吐槽,這里怎能這樣做?應該那樣做啊。對于自己所做的產品同樣如此,應當明白,任何一個需求都受限于當時的背景狀況、資源限制,拋開這些背景談實現都是扯淡,產品經理要做的是在當前背景下,找到最佳的實現方案。因此,梳理需求背景是產品經理對當前資源現狀的考量,是實現需求的第一步。
通過對歷史原因和歷史設計方案的梳理,可以讓自己對當前任務的阻礙點更加明確,甚至可以為自己的解決方案提供新思路。簡道云內,雖然各模塊任務都是分開設計,但不同任務之間可能有關聯關系,在需求背景梳理中,這些都可以明確。
3.2 需求分析
來源于用戶的需求才是最真實的需求,有些功能點無法滿足用戶需求,但是只有在具體業務場景下才能體現,通過對用戶場景的分析,挖掘出當前要解決的問題以及后續衍生出的問題。
用戶回訪是其中一個重要環節,很多用戶需求,都有替代方案可以解決問題,但是用戶不愿意采用替代方案,內在原因需要深究。需求庫里的需求是經過幾次轉手和加工的,可能會存在偏差和信息不對等,通過用戶回訪可以與用戶直接溝通,消除信息誤差。
3.3 競品分析
競品分析可分為兩部分:
直接競品分析:
- 直接競品是否存在該問題
- 是否解決了該問題。若沒解決,原因是什么。若解決了,是用何種方式解決的
- 競品的解決方案是最優方案嗎,是否存在更好的方案
非標競品分析:
- 非標競品中是否存在相似場景,該場景提供的適用范圍有哪些交叉點
- 成熟的非標競品,一般具有更成熟的解決方案,當前解決方案是否適用于當前產品中
3.4 問題分析與方案抉擇
方案是背景下需求的實現方案。既然需求會受到資源現狀的限制,那么方案也必然有所不同,甚至可能會有折中妥協,會有不完整的方案。有時需求本身就是試驗性質的,是為了快速測試效果,那么在方案上選擇一些實現簡單、開發難度較小的方案也就不足為奇了。
在寫方案時,可以按照「用戶-場景-問題-方案」這個框架簡要寫明實現方案,也就是什么樣的用戶在什么樣的場景下遇到了什么問題,提供的解決方案是什么——這里要求方案要經過提煉,能夠通過一句話說清楚。
價值是指實現這個需求能夠帶來什么樣的價值,包括用戶價值和業務價值,用戶價值是指實現這個需求能夠給用戶帶來什么樣的價值,例如提升用戶的使用體驗等;業務價值是指實現這個需求能給產品的業務帶來什么樣的價值,例如提升用戶留存或者提升業務收入等。
需求不一定要同時提供用戶價值和業務價值,也不一定兩個價值都需要為正(例如帶來很大的業務價值而犧牲很小的用戶價值也是可以的),具體需要依據產品當前的狀態來考慮,但不能帶來價值的需求一定是有問題的。
此外,在思考需求能夠產生什么價值時,同時要思考的是以什么數據指標來評估這個價值,也就是需求上線后效果的好與壞要有量化的指標。不一定所有的需求都能夠找到量化的效果指標,但一定要盡量找到這個指標。只有需求的效果能夠被衡量,產品才能夠往更優的方向迭代。
3.5 功能規則&需求詳述
主要是需求實現的部分,詳述需求解決方案和功能規則邏輯。業務邏輯部分描述的是需求中涉及到的數據流向和用戶流向,特別是需求涉及到多個系統時,數據和用戶在系統之間如何交互的。目前針對業務邏輯部分,我主要的輸出是多通道的泳道圖來描述系統間的交互。這里應該特別注意的是在說明數據流向時要兼顧考慮正常流程和異常流程,以及在說明用戶流向時要考慮清楚需求邊界。此外,需求的復雜程度不同,可能還會包含頁面流程圖、頁面結構圖等。
在需求文檔中需要對交互形式和前端校驗邏輯等做出簡要說明,以此來協助交互和前端更好的理解和實現需求。尤其是對重要的地方進行文字說明,包括字段邏輯、按鈕邏輯、頁面邏輯等。對一些非邏輯的交互進行說明,例如某些字段、需要突出顯示,頁面變化時需要怎樣的特殊效果等等。
3.6 數據埋點
凡是需求,必然要有驗證效果的數據,而從每一個失敗與成功的需求中不斷總結和反思,是產品經理成長的重要途徑。實際效果數據是衡量需求輸出實現方案的其中一個標準,這既能夠促使產品經理自己不斷改進產品思路,也能夠讓參與需求的相關同事了解自己的工作成果。
4. 容易出現的問題
初期寫PRD,容易出現以下問題:
- 剛開始的PRD可讀性較差,沒有站在閱讀對象的角度思考他們希望在PRD上獲取什么信息,對于結果輸出和總結內容,沒有清晰明顯的體現出來。
- PRD的信息同步有部分缺失,與研發或交互在同頻信息時,部分信息沒有傳達到,在后續設計中需要再次溝通確認。
- 當前任務邊界不明顯,對于本次需要解決的問題和以后解決的問題,該如何區分,區分依據的闡述不夠清楚。
為了解決上述的問題,需要嘗試從用戶思維、結構化思維、閉環思維來幫助思考和解決問題。
1)用戶思維:站在用戶視角,提升用戶體驗
用戶思維,顧名思義,就是“站在用戶的角度來思考問題”的思維。使得需求落地前期最為關鍵的一步,是將需求定義及描述清楚。為了讓協同的人員理解需求,產品經理需要站在他們的視角,了解他們的工作場景及訴求,輸出解決方案。
2)結構化思維:結論先行,突出重點
結構化思維的本質是框架。是從無序到有序的一種思考過程,將搜集到的信息、數據、知識等素材按一定的邏輯進行歸總,繼而讓繁雜的問題簡單化;從而讓我們的大腦更快速、更有效的處理信息。
- 產品需求文檔應從宏觀到微觀地進行鋪展,因而需要先寫總體需求(依據實際情況可附上業務流程、功能列表清單、功能結構圖、信息架構圖、角色權限等),再寫具體需求(詳細講解需求的流程、規則和實現)。
- 使用結構化思維去進行思考和表達時:結論先行,再去展開闡述,先突出重點,能夠讓對方更加輕松地理解我們想表達的觀點。如編寫背景及目標時,可先寫總的結論,在分點詳細闡述,對需要關注的地方進行加粗,避免大段文字的敘述。
- 業務流程圖繪制也可采用結構化的思維。在進行流程圖的繪制過程中,只有一個流程主線,可使得流程圖脈絡清晰,業務明了。如果異常流程非常復雜,針對每一個流程節點,如果出現異常流程,可以建立子流程模塊,在子流程中標記出異常場景的分支流程;然后把子流程鏈接到流程概圖。
3)閉環思維:有始有終,推動問題解決
閉環思維是指我們在做一件事情時,要做到有始有終。不是僅僅把事情做了,而是要保證事情做了以后,是能夠解決問題,或者有相應的見效或進展的。
- 依據評審后的討論結果,不斷修正產品需求文檔。在需求評審前,產品經理已經輸出了第一份產品需求文檔。但這個產品需求并非初步方案就能夠解決問題,在歷經交互、開發評審后,才會最終敲定方案。因此,我們需要不斷地修正需求文檔并同步給各協同人員。當然,也應該附上相應的修訂記錄,但由于工具的發展,我們可以依賴工具的變更歷史來回顧修訂記錄,因此不再需要在需求文檔上附上修訂記錄。
- 產品需求文檔解決的不僅僅是當前的一個問題,也是規劃推動下一個問題的解決。盡管每次迭代的目標細分不一樣,但是總體的目標都是把產品做好。因而為了推動這個終極目標的實現,我們需要明確清楚每一次迭代需求的目標,并且規劃好下一個迭代的需求,才能不斷推動問題解決,得到良性循環。
5. 總結
產品需求文檔是任務迭代流程中的重要內容。我們應當把PRD作為推動需求落地上線的指導綱領,提高產研效率的有效工具,將產品思維的思考方式運用到需求文檔中。在一次次的需求文檔撰寫中,需要我不斷總結思考,再運用到下一次的實踐中,反復思考優化自己的方法論。
本文由 @飛魚 B端產品站 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!