后台管理系统PRD该怎么写?
近段時間獨立完成一份運營管理平臺的PRD,借此分享一份在下的心得體會。在此之前僅寫過完整的C端產品PRD,因此也參考了大量與B端產品需求相關的文章。慚愧,因為并沒有找到合適的用于B端的PRD模板,所以參考各位大佬的見解,自己總結了一套方法。
不能參照C端的PRD來寫嗎?
原則上來講是行不通的,C端產品和B端產品所面向的用戶及功能業務少有共同點。C端產品側重如何滿足用戶的衣食住行需求,針對個體用戶;而B端產品更加貼合企業實際,側重提升客戶的生產和辦公效率,降低生產成本,針對企業或組織。側重方向的差異,也就導致了PRD的差異。
一、為什么要寫PRD??
這個問題得先嘮叨一下,因為剛入行時因為某些原因并不是很重視這個問題,只知道是產品經理必備技能之一,但是鮮有機會去實際操作,也難以領會其深意。對于想在產品這條路上砥礪前行的人來說,這是不容忽視的一個重點。
PRD(產品需求文檔)從需求到功能的具體實現,包含各項業務解決方案及相關數據項,是所有開發及測試人員在產品開發過程中的必備文檔。一份完整的、詳盡的PRD,在下認為主要作用有以下幾點:
減少產品與研發之間的溝通成本;
增強產品的容錯率,確保產品的準確性;
幫助產品經理梳理思路、流程及細節;
作為后期對產品驗收的憑據之一。
每個產品都需要一份完整的、詳盡的PRD嗎?也不盡然。對于某些復雜度不高,產品研發團隊默契度高,或者不易產生歧義的產品來說,如果沒有特殊的用途,PRD盡量簡潔,提升文檔的可閱讀性,反而更有利于產品的研發效率。
如果沒有PRD,所有細節可能都需要產品與研發保持密切溝通,按時總結盤錯。避免研發人員研發時遇到不明了的地方添加過多自己的想法,否則最終的產品做成什么模樣真得看天意了~~
二、后臺管理系統PRD應該包含哪些內容?
1)版本修訂記錄。主要包含版本號、修訂人、修訂日期、修訂描述等。它在產品出現問題,追根溯源時可以起到巨大作用。(新人注意:版本修訂不是在原版本上修改,每個版本修訂完成后都需要單獨保存)
2)簡介。這里的簡介不是僅僅對產品的簡介,可以是對文檔的簡介、產品泛義上的介紹(背景、目的、產品適用范圍、目標用戶詳情)等。閱讀后能夠對整個產品有大概印象。可視情況添加預期收益、競品情況、名詞解釋等內容。
3)產品概述。這里的概述跟上述的簡介有所不同,主要是對于產品各功能模塊的概述。包含功能概述、產品總體流程、功能摘要等。其中,功能概述是在功能層面上的一個概述,不需要寫太多;產品總體流程是各功能模塊之間的聯系,通過流程圖或者思維導圖體現出來,盡可能清晰詳細;功能摘要是對各模塊的摘要描述。閱讀產品概述后對整個產品具有的功能及各功能能做到什么有大致印象。
4)策略介紹。不同于C端產品重視用戶視覺體驗及交互體驗。后臺管理系統更重視數據管理、各項分類,盡可能簡化客戶操作,以到達提升效率、減少成本的終極目標。針對某項業務或者某類需求場景,怎么做能夠實現并且清晰易懂好操作,這便是策略需要解決的問題了。
5)前端頁面功能詳情。使用者是直接通過前端頁面操作的,內部邏輯及業務這里可能看不出來,但是這里看到的是最直觀的產品。每一個模塊有哪些頁面,每個頁面有哪些功能,功能點有哪些交互,哪里與上述策略有關聯都可詳細描述。要求具備原型制作基本能力,有較好的交互設計,圖文搭配可以更直觀的表達各功能詳情。
6)其他產品需求。這部分根據產品實際情況進行增刪,可能包含性能需求、數據監控需求、兼容性需求等。都是業務需求之外的關于系統本身的需求,直接影響產品的第一使用感受,研發團隊默契度不高的話最好做詳細描述。
7)風險分析。在下認為,對于一個看文檔的人來講,如果對產品本身功能都沒有太多了解,看風險分析也沒有多大用處。此處的風險分析僅作為整個產品從研發到發布這個階段可能遇到的風險作出分析,不需要太過復雜。包含風險內容、可能性、嚴重性、應對策略、可應對性等信息即可。
8)其他。對于撰寫本文檔相關的文檔、附件、項目排期、測試用例等信息,可根據實際需要增刪。
三、策略介紹怎么寫?
策略介紹是整個文檔中最重要的一部分。每一個策略介紹需要從問題描述到最終如何解決形成一個邏輯閉環。先從各視角(應用場景、技術、邏輯)做一個詳細介紹,明確策略重點及需要解決的問題;再對策略制定及制定原因做詳細描述,為了方便解讀,可配上流程圖或思維導圖輔助說明;最后加以小結,確認有無漏洞。
四、前端頁面功能詳情怎么寫?
前端頁面功能詳情在文檔中的重要性僅次于策略介紹。可以通過模塊與頁面的層級關系作為標題的關系,務必包含系統主要功能模塊,通常來說,這部分是最容易造成文檔完整性不足的地方了。
就單個頁面的說明而言,在下更喜歡做成表格的形式,層次分明。主體包含前置條件、優先級、需求詳細描述、后置條件,可視情況添加應用場景、功能摘要、補充說明。其中,需求詳細描述可以配合原型設計做詳細解讀,更容易理解。
五、如何提升文檔的可閱讀性?
1)前后描述一致。就上述內容而言,功能摘要、策略、前端頁面功能詳情必然會存在關聯的情況。務必確保各部分的內容描述一致,不出現偏差,不能給研發曲解的機會。
2)層次分明,圖文并茂。對不同性質的內容,比如查詢輸入、操作按鈕、數據列表做明確區域劃分,一看描述就知道在哪里找對應的原型圖。又比如管理系統中的功能結構、賬戶管理、角色管理等,正確的劃分層次,圖文配合說明,均能獲取不錯的效果。
3)抓重點、重細節。用簡介的抓語言抓住重點可以保證重要內容不會缺失,并且容易領會要表達的核心意思;重細節可以避免不必要的彎路,影響整體研發效率。能用一句話說清楚的不再多加說明,能用一個例子講清楚的不再反復強調,能用一個詞表達的不用句子來敘述。
?
結語:本篇內容主要是在下的心得體會,并沒有刻意的加入圖文及樣例(太費時間了/wo bi jiao lan),以此勉勵自身繼續努力學習。也希望對各位看官有所幫助。
總結
以上是生活随笔為你收集整理的后台管理系统PRD该怎么写?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 产品需求文档(PRD)模板下载(附完整案
- 下一篇: 用u盘启动盘没法安装win7-(用u盘启