需求文檔(PRD)是產品經理與項目成員之間的溝通媒介,移動互聯網時代,產品上線迭代節(jié)奏非??欤环葸壿嬊逦乙c分明的需求文檔可以讓成員之間的溝通更為高效;同時,產品需求文檔的撰寫,也能很大程度上看出產品經理的專業(yè)素養(yǎng)和水平。那么,最為經濟化高性價比的需求文檔,應該如何撰寫呢?
首先,我們需要知道需求文檔的存在價值是什么?
1、確保需求思考的全面性
產品經理在需求落地過程中,如果沒有真正落實到對全流程細節(jié)的仔細斟酌,很容易出現細節(jié)遺漏或需求不合理,所導致的結果就是功能設計不完善,溝通模糊化,甚至導致需求的頻繁變更,多做無用功。不僅影響產品的上線規(guī)劃,還容易引起成員公憤。PRD的撰寫可在一定程度上確保產品經理思考的全面性。
2、資料傳承
一款產品在其生命周期中,有可能經由數個產品經理之手,中間的優(yōu)化迭代改版,如果沒能及時記錄下來,往往到達下一個接盤者手上的時候,又得重新開始摸索一遍,極大降低了效率。因此,需求文檔的撰寫和變更記錄,能實現資料的有效傳承,方便后人迅速上手跟進。
3、存證
我們都知道,需求文檔不可能一成不變,在需求評審、實際開發(fā)過程中,往往有大大小小的調整,需求變更后及時更新記錄,而非停留于口頭的需求邏輯敲定,方便后續(xù)搜索求證,避免遺忘。
6步寫出高性價比PRD
實際撰寫PRD時,采用的載體形式很多,如word、excel、在線協(xié)同工具、交互原型圖+標注等,但無論哪種形式的PRD,最終的目標都是最高效且最準確地將需求傳遞給開發(fā)。因此,一般不建議長篇大論贅述太多,這樣容易提高大家的閱讀和理解成本,我們只需保證準確表達出“開發(fā)同學需要知道的邏輯/內容”即可。
一般而言,一份經濟化的PRD僅需包含以下6個部分:變更歷史、需求簡介、框架結構&功能模塊(核心)、消息觸達相關、數據埋點相關、異常流。
具體應用時可再根據實際項目進行調整刪改。
1、變更歷史
可分為3個部分:更新時間、更新內容(版本號、更新內容描述、標注)、撰寫更新內容的人。目的是記錄每一次需求的更新/迭代,方便項目成員了解方案細節(jié),快速跟上節(jié)奏。該部分有兩個小技巧:
- a、版本號V x.x,對于大改動/大版本變動,用變更小數點前1位表示,如V1.0,V2.0;小更新用小數點后1位表示,如V1.1,V1.2
- b、正文更新部分標注上特殊標識,如加粗、標紅、底色高亮等,并在變更內容中說明,便于團隊成員最快速找到更新點
2、需求簡介
主要包括需求背景和功能列表概覽(標注優(yōu)先級)。
需求背景是信息同步的一部分,團隊開發(fā)成員往往前期沒參與到市場調研、匯報等環(huán)節(jié),該部分可幫助團隊成員了解項目背景、目標,并達成項目價值、上線時間等預期共識。
功能列表概覽則是為了讓開發(fā)同學對整體需求有一個完整的把握,適用于需求開發(fā)周期評估、需求完成checklist等場景。
3、結構框架&功能模塊
該部分是需求文檔的核心部分,囊括了產品方案的全局和細節(jié)邏輯,主要是向開發(fā)同學清晰且準確說明需求實現期望,盡可能覆蓋各類場景,盡可能使用案例/圖例輔助說明,盡可能使用邏輯性語言表述。該模塊可統(tǒng)分為全局結構和功能模塊兩大部分:
- a、全局結構
包括產品核心主路徑、各分支路徑的邏輯流程圖,闡述產品全局的路徑跳轉、閉環(huán)邏輯,方便全局性理解需求。如下全局邏輯流程圖:
- b、功能模塊
該模塊主要針對各分支路徑進行詳細的需求描述,落到產品層面,則是追求 “場景窮舉說透、邏輯到位可行”。以日期為例,方案中涉及的日期是工作日、節(jié)假日、自然日、交易日、還是非交易日,需要做到準確用詞無歧義。
為了盡可能簡單而清晰地表達,對于每個功能模塊,都可以嘗試從4個方面結合進行敘述:
- 1)應用場景:落實到產品上線時會遇到的各種場景,分別列舉。
- 2)頁面元素組成:對應于上述的某個場景,該頁面包括了哪些元素,頁面布局如何。
- 3)觸發(fā)條件及響應效果:相當于輸入條件和輸出結果,在什么樣的時間節(jié)點、觸發(fā)了什么樣的條件、會產生什么樣的反饋/響應結果。
- 4)舉例示意:通過實際例子,或附上具體的交互圖輔助說明,提升上述內容描述的可理解性。
如對于某電商平臺而言,應用場景上大致有:
新用戶注冊、老用戶登錄、推薦流、搜索、下單流程(添加到購物車/直接購買)、訂單提交流程、結算流程、物流跟蹤、售后服務等具體場景。
具體到購買某款商品的單一場景上,頁面布局元素包括:商品圖片示意模塊、商品信息概覽(名稱、價格、月銷量、產地等)、商品參數介紹頁、用戶評價、店鋪介紹、更多推薦。還有吸底的加入購物車、立即購買、收藏、客服按鈕。
下鉆到該場景下的“加入購物車”這一動作而言,其觸發(fā)響應邏輯如下:
觸發(fā)條件:用戶點擊“加入購物車”按鈕;
響應結果:后臺將商品添加至用戶購買清單中,前端彈出告知彈層,告知用戶“商品已成功添加至購物車”。
4、消息觸達相關
消息觸達,可作為產品功能服務、推廣拉新、活躍/留存提升、流失召回的有效方式,主要渠道可包括公眾號、短信、app push、產品站內彈層等。該部分在作為PRD的一部分時,為了避免邏輯遺漏,可套用6個元素做呈現:觸達形式、消息ID、觸達場景、消息模板示意、文案示意、跳轉路徑。
以電商平臺購買某款商品后用戶簽收的場景為例:
觸達形式:app push
消息ID:123456
應用場景:某款商品(xxx)物流已送達且用戶完成簽收
消息模板:已簽收,您在$store$購買的寶貝已于$date$順利送達,確認收貨可獲積分哦>> ($$內為變量)
文案示意:已簽收,您在xx小店購買的寶貝已于4月15日順利送達,確認收貨可獲積分哦>>
跳轉路徑:點擊跳轉到該款商品的訂單詳情頁
5、數據埋點相關
產品上線后,產品經理需要及時跟蹤上線效果并做優(yōu)化迭代,因此配合產品上線節(jié)點,數據的埋點也要同步ready。產品經理需自身先明確該業(yè)務/功能的目標是什么,需用何種數據指標來描述衡量;體現在PRD中,則主要包括埋點位置、埋點ID、觸發(fā)場景。
如統(tǒng)計互金平臺某款理財產品的點擊率和申購轉化率,埋點位置會體現在產品曝光頁面、買入按鈕、買入成功頁面;
ID包括點擊流ID(統(tǒng)計UV、PV)和渠道號(統(tǒng)計申購人數、金額等信息);
觸發(fā)場景則是理財產品曝光、用戶點擊申購、申購成功時分別統(tǒng)計數據并上報。
6、異常流
PRD的撰寫,不僅要覆蓋產品功能的正常邏輯和場景,還需全面考慮到產品上線可能出現的異常情況和相應的應對方案。提前預見可能有的坑,才能避免產品上線后真的踩坑……
舉個栗子,當前很多產品設計時會走情感化路線,如允許用戶自定義名稱、自定義圖片上傳。在此過程中,用戶輸入了非法字符(如emoji表情)時,是提示用戶修改,還是允許正常顯示?當用戶輸入的詞匯包含敏感詞,是不允許提交,還是直接做過濾屏蔽處理?
更多異常流情況如弱網環(huán)境、訪問超時、刷新/獲取信息失敗、信息缺省、權限獲取失敗等,都需要根據具體的產品case體現在PRD中。實際撰寫時可按“異常流描述+處理方案“的搭配方式呈現。
附上PRD撰寫6大模塊checklist,方便大家后續(xù)參考:
需求管理三大原則
除了PRD,產品經理在項目實操過程中還會遇到需求管理的相關問題。如同項目多個需求,甚至不同項目多線程進行的情況,難免會產生需求沖突。在需求管理上,怎么讓“高效有序”代替“慌亂焦慮”,本質上,即是需求的優(yōu)先級如何權衡?用什么原則標準權衡?回答這樣兩個問題,可以從以下三個方面考慮:戰(zhàn)略定位、用戶影響范圍、實現成本。
1、戰(zhàn)略定位
經濟基礎決定上層建筑,戰(zhàn)略定位決定發(fā)力方向。每一階段的需求方向形成跟該階段整個團隊的戰(zhàn)略目標息息相關。作為產品經理,要明確部門階段性發(fā)展的目標,并將其落地到自身的業(yè)務需求中來,如今年部門的目標是創(chuàng)收,則需求大方向、資源等都會相應地往商業(yè)化產品傾斜。無論是怎樣的產品需求,都應該向戰(zhàn)略方向靠攏,并由此來權衡項目優(yōu)先級。
一般來說,對于某些戰(zhàn)略型的跨部門合作項目,同樣需要把需求優(yōu)先級提升。一方面,既然合作達成,說明該需求項目對雙方而言都是符合目標預期的;另一方面,當前項目上線的進程和效果,是后續(xù)長期合作共贏的前提和基礎。
2、用戶影響范圍
衡量需求優(yōu)先級,離不開重要性和緊急性的判斷。
重要性,可從以下三個原則綜合來看:
a、主干邏輯優(yōu)先
如電商類型產品,用戶從挑選商品,到下單,到支付,即是其主干流程,該流程的任何問題,都會影響到業(yè)務的整體,需要優(yōu)先考慮。
b、業(yè)務目標優(yōu)先
產品需求,需要對業(yè)務效果負責,需求上線后數據效果反應不好,是每個人都不愿意看到的。因此,需優(yōu)先處理“可產生最佳效果,對業(yè)務目標有最大化貢獻”的需求,即核心driver,在有限的資源基礎上,優(yōu)先滿足對業(yè)務目標的最大化貢獻。其次,才是其它“可產生效果,提升效用次之”的需求。
c、用戶體驗優(yōu)先
理想狀態(tài)下,要求產品能滿足所有用戶的需求,體驗絕佳。但因用戶千人千面(即使定位某一特定用戶群體)、客觀資源條件等問題,實際情況往往需要對產品功能有所取舍,此時我們應該優(yōu)先保證絕大部分用戶的體驗,大致原則是:對核心/大部分用戶有影響的>對較小部分用戶有影響的>一般產品使用體驗問題>錦上添花需求
而從問題解決版本的緊急性來看的話,可以有以下原則:線上bug>當前有一定不良影響的需求>短時間內可控,解決后會有較為明顯的積極影響的需求
3、實現性價比
大部分需求產生時,更多的從用戶角度/業(yè)務角度出發(fā),尋求效果的最大化,不會被實現成本、實現難度束縛住思維。但是,當需求逐漸成型,實現的性價比,就要同步考慮了。衡量其可實現性、實現成本損耗、資源現狀及其性價比;基于現有資源的基礎上,再決定產品需求的最終方案(照常or調整),以達到性價比最高,并擇優(yōu)優(yōu)先實現。例如:方案A和B都是可為業(yè)務用戶盤子帶來快速增長的核心渠道,但方案B的實現周期需要2周,方案A最快1周即可上線,則權衡性價比之下,優(yōu)先級會A>B。
掌握PRD快速且高效的撰寫能力,產品經理可根據所在業(yè)務歸納沉淀下相應checklist或模板,形成該過程的SOP;同時在多需求纏繞的時候,形成自身一套優(yōu)先級和性價比權衡標準,可有效提升自身效率,在多需求中更游刃有余。
也許,產品經理就是雕刻家,在有形的章法和無形的力度弧度把控中游走,深鐫淺刻,終將雕刻出屬于自己的大衛(wèi)像。
文:
(tencent_university)首席增長官推薦:
《工具型產品運營如何能促進用戶增長?》
《增長黑客如何基于心理賬戶、效應及決策,運用在股票App的產品設計中》
《做內容怎么能不懂用戶增長,增長黑客了解一下?》
更多精彩,關注:增長黑客(GrowthHK.cn)
增長黑客(Growth Hacker)是依靠技術和數據來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度,梳理整合產品發(fā)展的因素,實現低成本甚至零成本帶來的有效增長…
本文經授權發(fā)布,不代表增長黑客立場,如若轉載,請注明出處:http://m.gptmaths.com/cgo/product/10812.html