產品經理小白該如何練習寫PRD?

想入行產品經理,想自己動手寫一份prd,看了很多資料和模板發現,每個人的說法不同,講的東西也不同,讓人很迷茫,作為新手到底如何不斷提升寫prd的能力。


最好的PRD,是自己一步一步積累出來的。

每個人都需要一份自己的PRD

迭代PRD,主要是迭代PRD模板。

模板是做什麼的?主要是提醒作用,讓我們做選擇題而不是填空題。

所以好的模板,幫助我們完成好的PRD。

那麼如何獲得好的模板?好的模板都是量身定做的。

只有自己積累的,才是最適合自己的。

那麼如何不斷為自己積累一份好的模板?

可以從如下幾個問題入手:

  1. 我的PRD總是遺漏哪些問題?
  2. 我的讀者有什麼習慣?
  3. 哪些東西可以沉澱下來?

下面我們逐一展開一下,看看實際落地過程中怎麼做。

我的PRD總是遺漏哪些問題?

PRD的原則就是不漏不缺、表述清晰。

那麼如何做到不漏不缺呢?

主要的原則就是靠模版:通過不斷地迭代完善模版來達到自我規範的目的。

比如,我工作的第一年,遇到的問題如下:

  1. 2次因為忘記寫清楚埋點規則,導致分析時缺少數據。
  2. 1次因為沒有寫清楚並發量,導致沒有提前安排好伺服器。
  3. 因為忘記更新變更歷史,導致開發使用了舊版文檔。

針對這些問題,我做了如下改動:

&-->

&-->

  1. 在需求詳述表格裡面,增加了數據分析的部分,提醒自己寫清楚埋點和口徑等情況。
  2. 在文檔結尾處,新增了運營需求,舉一反三總結了伺服器、關聯方、運營等配合要求。
  3. 在更新文檔後,反覆檢查命名和變更歷史,確保無歧義。

通過這樣的方式,我就逐步搭建起來了一套適合自己的需求模板。

通過這套模板的不斷迭代,我們把發生的問題一步步吸納到了模板沉澱下來,讓需求逐步走向了完備。

我的讀者有什麼習慣?

PRD的讀者主要是評審時候的各位,以研發、測試為主。

這個群體講究理性思維,喜歡迅速切入核心問題並全局規劃,不喜歡贅余的東西。

根據這個核心點,我要求自己每個需求點一定要做到2+2,2+2就是:

  • 2個需求背景:用戶側的需求背景,對公司業務的需求背景;
  • 2個以圖代言:任務流程圖描述用戶路徑,泳道圖解釋系統跳轉。

&-->

這兩個部分,可以保證開發同學對需求背景有詳細的認知,對邏輯也有整體的把控。

在清晰表達邏輯的同時,也能讓開發同學體會到你的用心。

哪些東西可以沉澱下來?

沉澱,就是成果的固化和總結。

沉澱不僅僅限於模板的沉澱。模板的沉澱算是一種規則和提醒的沉澱,更重要的沉澱是內容的沉澱。

什麼是優質的,應該沉澱下來的內容呢?

我這裡認為,和PRD相關的,只要做好如下3個點的沉澱,就可以走向專業:

  1. 原型風格沉澱;
  2. PRD語法沉澱;
  3. 項目邏輯沉澱。

1. 原型風格沉澱

&-->

指的是:要沉澱一套自己的原型風格,包括:

  • 整體有什麼元素?
  • 每個元素什麼樣式表示?
  • 每個元素如何描述,描述哪些信息?
  • 哪些常用的控制項可以模板化?

&-->

直接把好的部分用axure保存起來,編輯一個riplib文件即可。

每次畫完新的原型,保存到lib裡面。下次載入的時候直接使用即可。

這一套做下來,就可以保證你不再需要轉發朋友圈的模板大放送活動,而開開心心地經營自己的一套模板了。

不論對於自己,還是寫的人,都有很好的可讀性。

如果你是經常設計前端界面的產品經理,請務必做好這個工作。

2. PRD語法沉澱

PRD的語法,包括以下2個方面:

  1. 需求的背景講解;
  2. 需求的方案講解。

講背景的時候,我的語法偏重於敘事。給出需求的價值和畫面感,描述用戶故事。這樣可以讓開發同學看起來比較輕鬆,又能充分了解。

講方案的時候,我的語法偏重於理性。同樣的動作,用同樣的辭彙。

比如,同樣一個需求點,一定要做好命名,讓大家溝通起來沒有障礙。如果用戶反饋的功能,你叫用戶評價,他叫用戶建議,這就是不合理的。同樣,如果本頁面有彈窗,就講彈出;如果是搜索條件,就說呼起;如果是換了界面,就講跳轉。千萬不要顛三倒四胡亂用詞,這樣讀起來是特別費力的。

發現了嗎,PRD語法是很重要的一部分。這部分最好和開發同學約定來做。

並不需要多少專心研究的時間,只要注意一下,就可以很快地上手了。

3. 項目邏輯沉澱

項目邏輯沉澱,是最重要的一點。

每個人都要維護一份自己項目的全景邏輯圖,這樣不論是對於交接還是講解邏輯,都很方便。

想做這件事,分為以下幾個步驟:

&-->

  1. 前端:界面跳轉關係是什麼樣的,每個界面有哪些許可權?
  2. 後台:後台許可權和准入情況是什麼樣的,有哪些邏輯變動?
  3. 數據:每個資料庫的欄位有哪些,每個欄位是什麼邏輯落庫的?

梳理完這三項,就可以基本了解了項目目前邏輯的全貌。

有了這份材料,可以幫你對接很多運營和客服的需求。

比如,當運營提出要限制新註冊用戶使用某活動時,你可以清楚地解答:我們現在已經支持未身份認證用戶無法參加活動,全渠道新用戶都是沒有認證的,所以無需新增功能。

這樣就省掉了好多溝通成本和思考成本。

再根據項目現在的目標和進展,規划下一步的邏輯走向,下線不必要的贅余功能。

不只讓產品精簡,也讓我們的思維精簡。

把這份材料作為PRD的補充文檔附在裡面,一份成熟的PRD就完成了。

不但有新增的需求描述,也有字典一樣的邏輯梳理。

小結

  • 最適合你的PRD,是你自己沉澱下來的PRD。
  • 沉澱模板的同時,沉澱內容和經驗。
  • 通過:查缺補漏、用戶訪談、全流程檢視,來發現提高的機會點。

沒有天生的強者,都是一點一滴的積累練習。

以上內容轉載自公眾號產品之術,作者是知名的金融產品經理花生醬先生,希望能夠給你帶來收穫,接下來我們來討論一下:

優質的產品文檔應該是什麼模樣?

完成一份產品文檔需要花費諸多時間和精力,如果追求精細化和完備性,時間消耗還會加倍增長。一份真正優秀的產品文檔背後需要做非常多功能,它需要滿足以下要求:

  • 易寫:輕鬆創作,富文本撰寫,表格好用,可充分表達;
  • 易讀:可與原型圖、設計稿結合,並能相互深度引用,相互說明論證;
  • 易審:多人協作,打點評論,實時審閱,可高效溝通

目前,Office文檔和Axure是產品經理比較常用的產品文檔撰寫方式,它們雖然都能實現一些目標,但非常遺憾,兩者均無法滿足以上幾點要求。此外,如果還需要流程圖和交互圖說明,產品文檔就會不可避免地成為一個臃腫的文檔大合集。

顯然,產品經理們需要一種全新的產品文檔創作模式,更高效、更輕鬆地編寫產品文檔。

產品經理應該如何撰寫產品文檔?

產品經理該如何高效輕鬆地撰寫產品文檔?摹客iDoc近期重磅推出的產品文檔在線撰寫功能,為產品經理帶來了全新的產品文檔寫作解決方案。

摹客iDoc是一個產品協作設計平台。從產品、設計、到開發,研發流程的每一個環節都可以匯聚到一個平台,形成一個完整閉環。摹客iDoc將產品文檔在線撰寫無縫接入其柔性工作流,打造了一款自帶協作基因的產品文檔寫作神器,不僅可以幫助產品經理高效寫作產品文檔,還能讓產品經理充分深入到產品開發流程中來,極大地降低溝通成本,提升團隊效率。

在線寫作模式

產品文檔沒有標準化的模板,因此,產品文檔寫作的自由度和流暢度很大程度上決定了文檔的效率。對此,摹客iDoc提供了全新的寫作模式:

  • 富文本在線編輯,產品經理可以像使用Word一樣編輯文案,並通過雲存儲來實時查看和修改;
  • 產品文檔中可插入線框原型或高保真設計稿,深度引用;設計稿在iDoc中有任何更新,文檔中也會自動同步更新。

此外,產品經理還可以直接上傳已編寫好的產品文檔,iDoc會自動解析目錄,並生成文檔樹,方便查閱。

&-->

和設計稿完美結合

產品經理在寫作產品文檔時可插入設計稿,團隊成員在設計稿上進行評論時也可以引用產品文檔進行說明,可以精確至引用文檔的某一部分,創建引用點,並標記該內容為高亮狀態,方便查閱。這樣,文檔、原型圖、設計稿就能無縫銜接,相互引用,無論是需求評審,還是開發時查閱,統統都能搞定。

&-->

多人在線協作、審閱

文檔編寫完成後,通過鏈接分享給團隊成員,成員可對文檔進行實時審閱,通過打點評論來標記內容,無需頻繁開會。

&-->

我們有準備一份教程,歡迎去看看哦:添加產品文檔

最後,為閱讀到這裡的朋友提供摹客團隊的一些心意:

疫情當前,做好防控,減少聚集,倡導遠程辦公,摹客團隊與知乎用戶攜手共渡難關!

即日起至3月5日,我們為產品設計團隊免費提供遠程產品設計協作服務,助力產品經理、設計師、開發人員遠程辦公,實現高效設計協作。包括:

  • 摹客在線設計協作 團隊版,免費贈送90天
  • 摹客在線設計協作 企業私有部署,免費部署90天
  • Mockplus原型工具,所有版本6折優惠

點擊下方鏈接即可領取:

戰「疫」打響,摹客上場?

www.mockplus.cn圖標編輯於 2020-02-10繼續瀏覽內容知乎發現更大的世界打開Chrome繼續薛老闆薛老闆《產品經理求職面試筆記》作者/公眾號:薛老闆產品派

為什麼每個人的說法不同呢?

本質上是當前市面上沒有一個統一的PRD寫作規範,每家公司寫PRD的方法、模板都是不一樣的。

所以作為產品小白,不要在意這些「表象」

一定要「直擊本質」!

作為產品經理,一定要把我們的每一個產出物都當做一款「產品」,去思考這款產品的目標用戶是誰?他們的痛點是什麼?

PRD這款產品的目標用戶是誰呢?研發、測試、UI等內部人員對不對?他們的需求是什麼呢?研發需要根據你的PRD寫代碼,測試需要根據你的PRD撰寫測試用例,UI需要根據你的PRD輸出UI稿。

所以PRD的寫作宗旨是:產品邏輯表達清晰且完整,這就是寫PRD的本質!只要能達成該宗旨的PRD寫作方法都是OK的。

京東產品說明文檔的寫作框架及寫作方法

為了更好的講解產品說明文檔的撰寫方法,我們以京東的PRD撰寫方法為例。

京東功能型產品經理一份完整的PRD,一般會包含以下幾個部分:

第一個:項目概述。包含項目背景和項目目標,即為什麼要做這個需求?做完之後希望達到的目標是什麼?等等。這一部分有助於讓項目參與方和其他對項目感興趣的角色更好的理解需求的來龍去脈。

第二個:修改記錄。修改記錄會包含下面幾個信息:

1、版本。版本是指PRD修改的版本,一般每修改一次PRD都要更新一下版本;

2、修改內容。在此部分直接撰寫PRD的修改或者更新內容即可。由於PRD整體內容偏多,直接將修改內容體現在這一部分,可以大大提高相關參與方檢索信息的效率。

3、修改人。因為各種原因,比如多個產品經理負責同一個功能或者產品離職,都有可能存在一份PRD多人更新的情況。所以修改人這一欄有助於文檔的閱讀者產生問題時,直接定位相關責任人進行溝通。

4、修改時間。即產品經理每次更新內容的時間,對於產品經理自己定位修改內容大有幫助。

&-->

第三個:需求列表。

京東產品經理每次迭代輸出PRD之前,先跟直屬領導過一遍需求列表,確定這一個版本要做的需求有哪些。然後,才開始通過腦圖、流程圖、原型圖梳理產品邏輯。原型圖梳理完成之後再跟領導過一版方案,確認沒問題開始寫PRD,所以需求列表起到需求總覽的作用。

需求列表一般會包含序號、頁面,需求名稱,需求詳情、優先順序這幾個信息。

其他幾項信息非常好理解,重點說一下優先順序。當項目著急上線而研發資源不足的時候,一般通過優先順序的方法讓研發先做優先順序高的需求,從而保證項目能夠按時上線。

大部分公司都是用T1/T2來標識優先順序,而T1的優先順序高於T2,至於哪個功能優先順序更高,這就需要產品經理按照用戶價值以及實現難度等維度去衡量了。

&-->

第四個:流程圖。即核心功能的業務流程圖,放到PRD中可以讓相關方從宏觀上了解核心的業務的關鍵節點。

第五個:思維導圖。即複雜功能的功能框架圖,放到放到PRD中可以讓相關方從宏觀上了解產品/功能的布局邏輯。

第六個:功能描述。

當相關方從宏觀上有個大概了解以後就開始進入了對於功能細節的了解了,即第六部分功能描述中我們需要把每一個功能的詳細邏輯(包含前端交互邏輯、服務端邏輯、演算法邏輯等)都要寫清楚。這是PRD最核心的部分。

在撰寫每一個詳細功能的詳細邏輯時,建議大家按照信息、交互、數量、狀態、來源、異常情況等6個維度進行梳理,這樣可以保證產品方案更全面。

信息:即每個頁面上可視化的所有信息元素,包含可以點擊的和不可點擊的部分;

交互:即點擊或者滑動有反應的地方,需要在此部分將交互跳轉邏輯是敘述清楚;

數量:即元素的個數限制。比如以朋友圈為例最多可以上傳9張圖片,這就是圖片數量的限制;還比如微信群語音通話最多支持9個人同時在線,這就是一個人數的限制。

狀態:每個實體元素的狀態類型。比如電商中的訂單狀態會分為待支付、已支付、待發貨、已收貨、待評價、已評價等等;還比如約騎活動會存在可報名、已報名、已結束等狀態。當然,有些實體元素是沒有狀態的,那這時就可以不寫狀態。

來源:即元素的數據來源。比如輪播圖一般是運營人員在運營後台配置的,所以輪播圖的數據來源是運營後台;還比如電商網站中優惠券各項信息是從優惠券後台獲取的,所以優惠券的各項信息元素來源是優惠券後台。在大公司中業務系統及其複雜,分別由不同的團隊負責,作為產品經理將各項數據來源梳理清楚之後,可以極大的提升研發的開發效率。

當然針對中小型公司,系統相對簡單,在撰寫PRD可以考慮不寫來源。

異常情況:是指極少數情況下才會出現的場景。比如絕大多數用戶在使用百度搜索內容的時候,都可以匹配到相關的內容,這是正常場景。但是約有0.4%的用戶在搜索某些特殊內容時,如下圖所示,百度無法匹配相關內容,即為異常情況。

在此類異常情況下,作為產品經理需要給出對應的產品方案。比如百度產品經理給出的方案是,先給出一句文案說明沒有搜索到相關內容,再給出溫馨提示和相關搜索,引導用戶找到需要的內容。

&-->

下面以騎友APP首頁的輪播圖為例,講解這6個維度是如何在PRD中體現的。

&-->

第一步,先把活動卡片上的信息元素羅列出來;第二步,然後再考慮該功能存在哪些交互行為;第三步,撰寫元素來源;第四步,定義展示數量限制;最後一步,輸出異常場景下的產品方案。由於活動圖片不涉及到狀態,所以在詳細邏輯中沒有狀態一欄。

同時,做到圖文對照,每撰寫完一個頁面的邏輯,把相應的原型圖貼到下面,這樣研發、測試、UI看PRD的時候如果對文字描述不理解,可以和圖片對照一下,極大的降低他們的閱讀成本。

在這可能有人會產生一個疑問:為什麼要按照如上的方式撰寫PRD呢?回答這個問題之前請大家先想一個問題:PRD的目標用戶是誰?也就是誰會查看我們的PRD。

大概分為4類:UI、客戶端開發、服務端開發和測試人員,這些人組成了PRD這款「產品」的目標用戶。

UI關心什麼內容?關心頁面布局樣式,對不對?所以在PRD中要把原型圖羅列清楚;客戶端開發關心什麼呢?關心頁面布局及跳轉邏輯對不對?其實也就是PRD中的信息和交互這兩部分所呈現的邏輯。服務端開發是提供數據的,所以來源,狀態,邊界等內容是寫給服務端開發看的。測試呢?測試關心前後端的所有邏輯,因為要以PRD為準梳理測試用例。所以大家可以看到我們PRD這麼寫也是在滿足目標用戶的需求,產品經理的每一個產出物你都要把他當做自己的產品,去優化用戶體驗。

以上就是京東產品說明文檔的寫作框架及撰寫方法,不一定具有普適性,大家重點學習思路即可。

以下知乎高贊答案也許同樣對你有幫助:

薛老闆:產品經理面試必備常見10道題及解析

通過BAT、網易、京東產品經理的簡歷大概什麼樣?

有哪些經典的產品原型或 PRD、BRD 範例可以分享?

to B 的產品經理和 to C 的產品經理有什麼差別? to B 的產品經理的價值如何體現?

產品經理需要懂技術嗎?懂到什麼程度?

產品經理的日常工作是怎樣的?

面試產品經理時總感覺自己回答不到點上,具體分析一款產品時該怎麼回答呢?

互聯網行業產品經理(PM)的月薪一般是多少?

薛老闆:產品經理面試必備常見10道題及解析

薛老闆:2020年,寫給想轉行做產品經理的你

??看完兩件事??

看完這篇內容之後如果對你有幫助,我想請您幫我兩個忙

1、點贊,讓更多的人看到這篇內容(收藏又點贊,手拉手好朋友

2、關注我和專欄,讓我們成為長久的朋友關係,精彩回答可以第一時間收到


為什麼每個人的說法不同呢?

本質上是當前市面上沒有一個統一的PRD寫作規範,每家公司寫PRD的方法、模板都是不一樣的。

所以作為產品小白,不要在意這些「表象」

一定要「直擊本質」!

作為產品經理,一定要把我們的每一個產出物都當做一款「產品」,去思考這款產品的目標用戶是誰?他們的痛點是什麼?

PRD這款產品的目標用戶是誰呢?研發、測試、UI等內部人員對不對?他們的需求是什麼呢?研發需要根據你的PRD寫代碼,測試需要根據你的PRD撰寫測試用例,UI需要根據你的PRD輸出UI稿。

所以PRD的寫作宗旨是:產品邏輯表達清晰且完整,這就是寫PRD的本質!只要能達成該宗旨的PRD寫作方法都是OK的。

京東產品說明文檔的寫作框架及寫作方法

為了更好的講解產品說明文檔的撰寫方法,我們以京東的PRD撰寫方法為例。

京東功能型產品經理一份完整的PRD,一般會包含以下幾個部分:

第一個:項目概述。包含項目背景和項目目標,即為什麼要做這個需求?做完之後希望達到的目標是什麼?等等。這一部分有助於讓項目參與方和其他對項目感興趣的角色更好的理解需求的來龍去脈。

第二個:修改記錄。修改記錄會包含下面幾個信息:

1、版本。版本是指PRD修改的版本,一般每修改一次PRD都要更新一下版本;

2、修改內容。在此部分直接撰寫PRD的修改或者更新內容即可。由於PRD整體內容偏多,直接將修改內容體現在這一部分,可以大大提高相關參與方檢索信息的效率。

3、修改人。因為各種原因,比如多個產品經理負責同一個功能或者產品離職,都有可能存在一份PRD多人更新的情況。所以修改人這一欄有助於文檔的閱讀者產生問題時,直接定位相關責任人進行溝通。

4、修改時間。即產品經理每次更新內容的時間,對於產品經理自己定位修改內容大有幫助。

&-->

第三個:需求列表。

京東產品經理每次迭代輸出PRD之前,先跟直屬領導過一遍需求列表,確定這一個版本要做的需求有哪些。然後,才開始通過腦圖、流程圖、原型圖梳理產品邏輯。原型圖梳理完成之後再跟領導過一版方案,確認沒問題開始寫PRD,所以需求列表起到需求總覽的作用。

需求列表一般會包含序號、頁面,需求名稱,需求詳情、優先順序這幾個信息。

其他幾項信息非常好理解,重點說一下優先順序。當項目著急上線而研發資源不足的時候,一般通過優先順序的方法讓研發先做優先順序高的需求,從而保證項目能夠按時上線。

大部分公司都是用T1/T2來標識優先順序,而T1的優先順序高於T2,至於哪個功能優先順序更高,這就需要產品經理按照用戶價值以及實現難度等維度去衡量了。

&-->

第四個:流程圖。即核心功能的業務流程圖,放到PRD中可以讓相關方從宏觀上了解核心的業務的關鍵節點。

第五個:思維導圖。即複雜功能的功能框架圖,放到放到PRD中可以讓相關方從宏觀上了解產品/功能的布局邏輯。

第六個:功能描述。

當相關方從宏觀上有個大概了解以後就開始進入了對於功能細節的了解了,即第六部分功能描述中我們需要把每一個功能的詳細邏輯(包含前端交互邏輯、服務端邏輯、演算法邏輯等)都要寫清楚。這是PRD最核心的部分。

在撰寫每一個詳細功能的詳細邏輯時,建議大家按照信息、交互、數量、狀態、來源、異常情況等6個維度進行梳理,這樣可以保證產品方案更全面。

信息:即每個頁面上可視化的所有信息元素,包含可以點擊的和不可點擊的部分;

交互:即點擊或者滑動有反應的地方,需要在此部分將交互跳轉邏輯是敘述清楚;

數量:即元素的個數限制。比如以朋友圈為例最多可以上傳9張圖片,這就是圖片數量的限制;還比如微信群語音通話最多支持9個人同時在線,這就是一個人數的限制。

狀態:每個實體元素的狀態類型。比如電商中的訂單狀態會分為待支付、已支付、待發貨、已收貨、待評價、已評價等等;還比如約騎活動會存在可報名、已報名、已結束等狀態。當然,有些實體元素是沒有狀態的,那這時就可以不寫狀態。

來源:即元素的數據來源。比如輪播圖一般是運營人員在運營後台配置的,所以輪播圖的數據來源是運營後台;還比如電商網站中優惠券各項信息是從優惠券後台獲取的,所以優惠券的各項信息元素來源是優惠券後台。在大公司中業務系統及其複雜,分別由不同的團隊負責,作為產品經理將各項數據來源梳理清楚之後,可以極大的提升研發的開發效率。

當然針對中小型公司,系統相對簡單,在撰寫PRD可以考慮不寫來源。

異常情況:是指極少數情況下才會出現的場景。比如絕大多數用戶在使用百度搜索內容的時候,都可以匹配到相關的內容,這是正常場景。但是約有0.4%的用戶在搜索某些特殊內容時,如下圖所示,百度無法匹配相關內容,即為異常情況。

在此類異常情況下,作為產品經理需要給出對應的產品方案。比如百度產品經理給出的方案是,先給出一句文案說明沒有搜索到相關內容,再給出溫馨提示和相關搜索,引導用戶找到需要的內容。

&-->

下面以騎友APP首頁的輪播圖為例,講解這6個維度是如何在PRD中體現的。

&-->

第一步,先把活動卡片上的信息元素羅列出來;第二步,然後再考慮該功能存在哪些交互行為;第三步,撰寫元素來源;第四步,定義展示數量限制;最後一步,輸出異常場景下的產品方案。由於活動圖片不涉及到狀態,所以在詳細邏輯中沒有狀態一欄。

同時,做到圖文對照,每撰寫完一個頁面的邏輯,把相應的原型圖貼到下面,這樣研發、測試、UI看PRD的時候如果對文字描述不理解,可以和圖片對照一下,極大的降低他們的閱讀成本。

在這可能有人會產生一個疑問:為什麼要按照如上的方式撰寫PRD呢?回答這個問題之前請大家先想一個問題:PRD的目標用戶是誰?也就是誰會查看我們的PRD。

大概分為4類:UI、客戶端開發、服務端開發和測試人員,這些人組成了PRD這款「產品」的目標用戶。

UI關心什麼內容?關心頁面布局樣式,對不對?所以在PRD中要把原型圖羅列清楚;客戶端開發關心什麼呢?關心頁面布局及跳轉邏輯對不對?其實也就是PRD中的信息和交互這兩部分所呈現的邏輯。服務端開發是提供數據的,所以來源,狀態,邊界等內容是寫給服務端開發看的。測試呢?測試關心前後端的所有邏輯,因為要以PRD為準梳理測試用例。所以大家可以看到我們PRD這麼寫也是在滿足目標用戶的需求,產品經理的每一個產出物你都要把他當做自己的產品,去優化用戶體驗。

以上就是京東產品說明文檔的寫作框架及撰寫方法,不一定具有普適性,大家重點學習思路即可。

以下知乎高贊答案也許同樣對你有幫助:

薛老闆:產品經理面試必備常見10道題及解析

通過BAT、網易、京東產品經理的簡歷大概什麼樣?

有哪些經典的產品原型或 PRD、BRD 範例可以分享?

to B 的產品經理和 to C 的產品經理有什麼差別? to B 的產品經理的價值如何體現?

產品經理需要懂技術嗎?懂到什麼程度?

產品經理的日常工作是怎樣的?

面試產品經理時總感覺自己回答不到點上,具體分析一款產品時該怎麼回答呢?

互聯網行業產品經理(PM)的月薪一般是多少?

薛老闆:產品經理面試必備常見10道題及解析

薛老闆:2020年,寫給想轉行做產品經理的你

??看完兩件事??

看完這篇內容之後如果對你有幫助,我想請您幫我兩個忙

1、點贊,讓更多的人看到這篇內容(收藏又點贊,手拉手好朋友

2、關注我和專欄,讓我們成為長久的朋友關係,精彩回答可以第一時間收到


編寫PRD的技巧

一份優秀的PRD,基本可以增加30%~40%的協作效率

分模塊

編寫PRD時,往往已經有明確的產品構思,只是還沒有具象化,因此,為了避免需求之間的互相干擾,第一步要做的是分模塊

通常我們會按照幾個維度進行模塊劃分

  • 按頁面劃分
  • 按系統劃分
  • 按獨立性劃分
  • 按綜合性劃分

實戰案例

微信,可以如此劃分模塊

按頁面:信息列表,通訊錄,發現頁,個人中心

按系統:會話系統,朋友圈系統,用戶中心

按獨立性劃分:微信錢包,微信卡包,收藏

按綜合性劃分:設置模塊

(沒有完全劃分,僅作為舉例)

拆需求

在這個階段往往是有框線圖的,因此我們需要對框線圖所表達出來的需求進行拆分。

拆需求有三個技巧,

  • 相對完整性:每一條需求描述都需要相對完整和獨立
  • 最小顆粒化:每一條需求僅針對一個功能點。
  • 需求類型:尋找需求共性,對需求進行分類

實戰案例

我們來對登陸模塊拆需求試試。

&-->

&-->

補需求

這裡提到的補需求,重點在於補充看不見的需求,框線所無法表達的部分,

一個模塊往往分成可視化需求以及非可視化需求兩部分組成。

非可視化需求,涵蓋了諸如異常處理機制,刷新載入邏輯,判斷條件,交互邏輯,伺服器數據邏輯等等隱藏的需求點。

在補需求的階段,我們要盡量全面的去思考,像完成填空題一樣,一個一個填進去,可以亂可以散,但盡量全。

實戰案例

&-->

是不是需求補充以後,增加了很多 O(∩_∩)O

完善需求

你的PRD基本已經成形狀了,但還是不能投入使用,原因在於還沒有對需求進行參數化和技術化,因此逐個將他們參數化,技術化吧。

開發同學拿著這樣的需求會出現很多自定義的開發內容,很容易導致"五端不一致"(H5前端,安卓端,IOS端,伺服器,QA)

因此,我們需要做的是將需求技術化並且參數化。

參數化:是指將某些需求點明確具體數值和要求,如對於輸入框的字元長度,字元類型,對於需要時間判定的具體時間30秒,15秒

技術化:在一些特定場景,明確使用技術手段,比如某些頁面載入邏輯,緩存邏輯,甚至判定條件以及業務邏輯。

實戰案例

&-->

小知識

微博和QQ的第三方登陸有兩種實現方法,

A.調用客戶端介面

定義:直接喚醒相應軟體的app程序,在第三方客戶端內執行登陸功能

缺點:若用戶未安裝相應軟體的客戶端,則會返回調用

優點:更快速,流程,過程中用戶不需要再輸入相關賬號信息

B.調用web登陸介面:

定義:打開第三方應用的登陸網頁,在網頁上進行登陸操作

缺點:需要重新錄入賬號信息,操作成本較高

優點:不需要用戶安裝指定應用

目前較為廣泛使用的任然是客戶端登陸的方式

簡單結構

我們來看下簡單版的PRD結構

&-->

根據環境,公司,項目組不同,甚至個人習慣,PRD的結構是會產生變化的。比如會增加優先順序,完成度等

需求類型是我最近一個項目才加入進去的一個板塊。

我們在開發過程中存在大量的重複溝通,而需求類型則是強調需求之間的共性,屬於哪種類型的需求,長時間合作的團隊,看到需求類型時就會知曉需求的實現效果,降低協作過程中的溝通成本。

總結一下吧

1,分:對一個版本的需求進行模塊拆分

2,拆:將某個模塊的需求按照最小顆粒度的原則進行拆分

3,補:補充上非可視化的需求點

4,完善需求:為需求點增加參數化和技術化的需求描述


本回答基於5W+1H原則簡單聊聊產品經理小白如何練習寫PRD,乾貨較多,建議碼住 !

Why——為什麼要寫PRD?

現在,越來越多的產品經理採用將文本說明和原型結合成一個PRD文檔的方式,因為之前的word+原型的方式管理起來繁瑣,而且還容易產生信息疏漏。

將原型和文本說明統一,直接分享一個鏈接,開發人員就能看到所有信息,是理想狀態。

Who——涉及群體:

主要產品寫給是開發看的,當然後續也涉及測試、運營、業務等。

What——什麼是PRD?

先從我們相對擅長的思維開始:假設產品需求文檔(PRD)是一個產品,如何做出一個擁有良好用戶體驗的PRD?

來考察下PRD的用戶群體(User Persona):主要是開發人員,在繁忙的開發任務中最希望看到「簡潔易懂」的產品需求文檔。

梳理下PRD的功能

  • 傳達出產品需求;
  • 管理記錄產品迭代過程;
  • 各部門共享產品信息,以促進溝通;

因此一個好的PRD的原則是:

  • 結構清晰
  • 語言簡潔易懂
  • 實時共享

通常PRD包含的內容:

包含「產品概述」、「流程圖」、「功能詳情和原型」,「全局說明」,「非功能性需求」

如何把這些內容清晰有條理地呈現在一個文檔里呢?使用一個網頁般的多級導航結構即可。

1 產品概述

產品概述部分用於展示文檔修訂歷史、版本說明、開發周期、和產品介紹。

「文檔修訂歷史」用來記錄產品經理對該PRD文檔的修改狀況,也方便成員能及時了解到PRD是否有改動;

「版本說明」展示上線產品各版本的核心功能;

「開發周期」用於梳理開發、測試、上線的預計開始和結束日期。

「產品介紹」用來記錄產品名稱、簡介、用戶畫像、使用場景、產品定位等等。

&-->
墨刀「PRD模版A」中的「版本信息」模塊,by 小龍

2 流程圖

流程圖是產品經理梳理產品邏輯和功能的一個思維Map,一般會有「功能結構圖』、「信息結構圖」、「任務流程圖」。

「功能結構圖」 展示產品的功能模塊,一般展開用戶可見的最小單元。

「信息結構圖」則是以信息為維度,用來描述有哪些數據欄位,展現用戶信息/行為信息等。

「流程圖」記錄著用戶使用產品的路徑,也是一種產品線路圖,展示著產品的所有頁面及對應關係,有助於產品理解。

&-->
墨刀「PRD模版A」中的「結構圖」模塊,by 小龍

3 功能詳情和原型

這個模塊是開發人員查看頻率最高的模塊了。目前一種快捷高效的呈現方式便是「原型」+「注釋」。

圖文互補,把圖片傳遞不了的信息用文字補充清楚,比如產品的一些使用邏輯,方便同事理解。

使用墨刀的話,可以創建一個大的畫布,然後把墨刀製作的原型頁面粘貼到畫布里,並添加文字注釋,在關鍵位置有一些邊界條件的說明。

或者,直接在產品原型項目里通過「批註」添加註釋。

&-->
「PRD模版A」中的「交互原型」模塊,直接嵌入了墨刀原型,by 小龍

4 全局說明

這個頁面用來展示整個產品的設計規範,一些通用的規則可以附在這裡。

對於這點,使用墨刀製作的方便之處在於:

可以直接把有關設計規範的原型項目通過網頁鏈接的方式嫁接過來,還能點擊「標註」查看各元素的細節信息。

&-->
墨刀「PRD模版A」中的「全局說明」模塊,by 小龍

5 非功能性需求

對於不同類型的產品,非功能性需求會有各種差異,一般會涉及到的有:

  • 性能需求
  • 系統需求
  • 運營需求
  • 安全需求
  • 統計需求
  • 財務需求
  • ……

這部分就要自己按需要調整。

How——高效產出PRD方法:

原型好畫,PRD也好寫,但是同時完成這兩樣事情的工具卻不好找。既要展示原型,又要讓其他人看明白,軟體切換麻煩,交付協作更是不易......

為了幫助產品經理們,解決這個問題,推薦使用墨刀的「PRD」模式,支持邊畫原型邊寫PRD~

簡單來說:在編輯區,放置在設備框(畫板)外面的元素也可以在預覽頁顯示出來。

誇張點說就是:在頁面編輯區外的廣大區域中(簡稱為畫板外)已經變得無所不能,它像是鑲在原型上無邊界的紙,你可以在上面放置任意你展示的內容,無論是圖片、文字,還是表格、矩形等墨刀中已有的組件,都可以在「PRD」模式展示出來。

有了「PRD」模式展示,原型的批註說明變得無比清晰。

ps:

當你只想展示原型交互時,可選擇設備框,更加貼近實際場景;

當你只想給展示全貌時,可以選擇長頁面,內容呈現的更加豐富;

當你想交付設計、開發時,你可以選擇「PRD」模式,將你所有的批註更好的呈現

&-->

「PRD」模式怎麼用

1、首先在編輯項目的時候,頁面編輯區內正常製作(圖中綠色區域)。在頁面編輯區外,可以放置產品迭代記錄表格、產品流程圖等(圖中紅色區域)。

&-->

2、項目編輯完成後,可以通過右上角分享,設置允許切換到「PRD」模式,且設置默認預覽模式為「PRD」。

&-->

3、設置好之後,將項目分享鏈接發給其他同事,在拿到鏈接後,就可以查看「PRD」內容。

&-->

4、「PRD」內容導出

導出HTML: 在分享設置中,點擊允許切換到「PRD」模式,就可以將畫板外內容一起導出了。

導出PNG: 暫時還不支持「PRD」內容一起導出,敬請期待。

「PRD」模式應用範例

1.產品迭代記錄:讓變化一覽無餘。

&-->

2.繪製流程圖: 闡述操作過程。

(流程圖需要藉助mindnode/xmind等工具實現,截圖粘貼進墨刀)

&-->

3.需求說明/修改:說明為什麼做/修改這個功能。

&-->

4.功能描述:說明用戶可以做什麼操作以及可以看到哪些內容。

&-->

5.約束性描述:說明整個功能描述裡面相關的規則,主要有顯示規則,欄位規則,防呆規則。

&-->

總而言之,「PRD」模式能夠顯示出你在畫板外放置的一切內容,讓你的原型設計與交付開發變得更加方便快捷!

總結

PRD作為一種重要的公司內部溝通的文檔,能把必要的信息彙集在一個邏輯清晰的結構里是提高工作效率的一個優勢。語言上要簡潔易懂,再結合可視化的結構圖和原型,都是為了增強易讀性,讓溝通更高效。

把PRD當作一個小產品去打磨一下,不是浪費時間,一個好的PRD文檔可以繼用很久。

最後分享兩款可以直接復用的PRD文檔模板示例:

&-->

&-->

獲取方法:在墨刀素材廣場中搜索關鍵詞即可。

&-->


沒有所謂的模板、格式,要求,適合自己的就是最合適的。想寫好,沒其他辦法,多寫、多練,年輕人最缺的就是鍛煉機會。下面我將我寫的PRD模板分享給大家。

一、為什麼會有PRD

首先來說說為什麼會有PRD文檔。

1、稍微大一點的團隊產品經理未必能向每個人傳達產品需求,這就需要有一個文檔的形式來向項目的所有成員來傳達需求,這就是文檔的來源。

2、由於產品經理經常會變更需求,經常愛拍腦袋,容易變卦,所以程序員就想到用一個文檔來約束產品經理。

3、測試人員需要根據產品需求文檔來驗收產品質量。

4、當你的項目有新人進入的時候,可以讓新人更快的了解產品。當你離職的時候,繼任的產品經理也可以根據你的文檔來熟悉產品迭代的內容。

二、什麼是敏捷開發

埃德蒙·伯克說過[我們擔心人們會依照自身的理性主導起生活和交易,因為我們懷疑每個人的理性是相當有限的。]應用到產品經理身上,我們可以把它翻譯為:[我們擔心產品經理們會依照自身對用戶和社會的理解,來固執的設計產品,因為我們懷疑每個產品經理對用戶的理解都是相當有限的。]這就是敏捷開發的起源,那麼我們該如何做到敏捷開發呢?

1、快速迭代。

產品通過短周期的迭代交付,通過不斷的迭代完善產品。

2、快速嘗試避免長時間的需求分析和用戶調研,快速進行嘗試。快速驗證市場和需求的真偽,搶佔市場。

3、快速改進在地帶周期過後根據客戶反饋快速改進。因為產品迭代很快,肯定會有不完善的情況,產品上線後需要收集用戶需求,方向錯了就調整方向,有bug就快速改bug。

4、充分交流。

團隊成員的無縫交流,如每天短時間的站立會議。交流盡量扁平化,團隊成員可以在坐的近一些,這樣交流起來比較方便,而不是像大公司一樣,一件事情需要走很多流程。

5、簡化流程拒絕一切形式化的東西,使用簡單易用的東西開始工作。

例如;把冗長的word文檔去掉,代指在原型上簡單的標註,其實說實話,你寫的很長篇幅的PRD文檔,開發的兄弟妹妹也不一定會看,白白浪費寫文檔的時間。

三、敏捷開發PRD文檔該怎麼寫

既要敏捷開發,又要保證開發質量,這個時候PRD文檔就顯得重要了。

1、做好版本控制

版本歷史記錄要有。你的原型可能會更新好幾次,這個時候你需要做好版本控制。每次更新的時候在版本命名上顯示是那個幾點幾版本。同時在版本控制上顯示每一版本更新了那些內容,這樣別人一看就會一目了然。

&-->

2、feature list要有

feature list 告訴項目成員我們這一版本迭代那些內容,前台需要做那些,後台需要做那些,這樣開發即使沒有文檔,也可以根據feature list來,而不會有遺漏,測試也可以根據你的feature list。feature list可能會更新,每一次更新可以用不同顏色的文字給表示出來。

&-->

3、功能說明直接在原型圖上標註

程序猿一般都是看著原型開發,你之前寫的冗長的PRD文檔根本不看的。那麼遵循敏捷開發的「盡量減少文檔原則」,可以直接講功能說明和需要注意的東西標註在文檔上面,對於減少PM和PD的工作量都很有幫助,當然前提是你的PRD需求完整且邏輯清晰。

&-->

4、產品全局結構圖以及一些重要的流程圖不能省略

首先,全局結構圖。產品全局結構圖相當於房子的骨架,相當於文章的目錄,別人看過你的全局結構圖就知道你的產品大概分成那幾個部分,這樣別人閱讀接下來的原型設計和文檔的時候就會思路清晰。其次,一些重要的功能流程圖需要寫。一些基本的流程圖可以不寫,但是一些重要的功能流程圖,例如:充值、提現、購買這些流程。這樣項目成員在會議以後也可以通過文檔來重新溫習一下。同時你把流程圖整理好,也有助於開發人員的開發思路的建立,大大提升開發速度。

&-->

4、需要把規則和異常情況寫上去

很多時候產品經理開需求評審會挨批的原因就是沒有考慮周全,只考慮正常的流程,而沒有考慮異常流程情況,無網路的情況等。例如:網貸平台用戶支付系統你只想到用戶輸入支付密碼,完成購買。但你沒想到新用戶用戶如果沒有實名認證是不是先要實名認證,認證完成以後要不要設置交易密碼,如果交易密碼輸入錯誤怎麼辦?是提示他忘記密碼還是讓它重新輸入?同時交易密碼錯誤次數需不需要進行限制?如果支付金額不足怎麼半…等等。這些只有考慮的細,考慮的全面。開會的時候才能少被噴,才能有氣場。同時你考慮全面了,開發人員也會節省時間,不會在做的過程中給你發個郵件說出現某某情況怎麼辦。只有讓他們信服你,減少他們的工作量,你和他們溝通起來,才會順暢。

5、重要的名詞需要清晰簡潔的定義

重複出現的名字就不需要解釋了。例如用戶,當然如果你的目標用戶變更了就需要重新解釋一下,當然解釋的詞語的原則就是第一次出現而且比較重要,同時盡量用簡潔精鍊的語言把名詞解釋出來。

總結:其實實現敏捷開發文檔只是一個手段,更重要的是多溝通,減少因為溝通少而產生的誤解。當然一個好的PRD文檔可以增加你們的溝通效率。需要PRD文檔模版的童鞋可以加我V:chanpin628進行交流。

更多乾貨可關注微信公眾號:chanpinliu880


推薦閱讀:

TAG:產品經理 | 產品 | PRD |