工作了也有一段時間,總算對PRD這玩意兒有個懵懵懂懂的認識,市面上教我們寫PRD的文章大多是含糊其辭遮遮掩掩過于流程化和理論化,現在我大概了解到撰寫的套路,結合我自己的案列在此給大家分享一篇實踐干貨型PRD.
首先來介紹下說明文檔的生成流程:
1.需求確認
2.梳理邏輯,確認產品所需功能
3.繪畫原型,添加說明
需求確認
需求就是做產品的動機、目的,其核心是為什么人解決了什么問題.
這句話牢記于心,邏輯大方向的梳理就很難出錯,用句裝逼的話說那就是"勿忘初心,方得始終".
我們要學會如何辨別偽需求和真需求,如同那個在業內說爛了的段子一樣"用戶需要一匹馬,但實際上他只想更快地到達目的地",很多時候用戶是不知道自己想要什么的,他們只會表達想要的結果(功能),而我們需要從中抽絲剝繭,找出真實需求.
需求來源方式:
1.版本的長期規劃
現在都流行MVP,先上線基礎功能的一期初版,后面在根據已有市場的反饋和版本規劃慢慢進行二期三期的需求確認.
這種需求一般都是真實需求、強需求,且優先級強烈.
2.運營部門、同事的需求.這種需求通常與活動、KPI一并到來
"哎,你看Uber有這個邀請碼,我們也搞一個唄,拉新肯定有效"
"我們的商城價格怎么沒有小數呢?這有小數多好啊"
第2種需求來源,當時就要問清楚,為什么突然要做這個功能,目的是什么?
先確認需求的必要性,不需要那就拋棄,需要那就先思考,能否用當前可用的模塊或功能去完成需求,如果不能,那就添加到需求池并加以排序.
3.用戶的反饋 or 數據分析得出的結論
需求來源3就比較有意思,"用戶的反饋"類似與來源2類似,要進行分析歸納.
"數據分析得出的結論"與來源1類似,通過百度指數、GA、GrowingIO等數據支持和已有的市場反饋進行分析,從而得來需求.
4.PM的滴水不漏和天馬行空.大部分需求都是對已有產品細節的完善.
前者靠經驗、產品的體驗測試:
"這個搜索算法要優化一下,特定關鍵詞增加特定商品展示幾率"
"個人中心顯示邏輯不對啊,怎么一打開就是修改地址"
后者靠思考、學習、類比:
網易云音樂的云盤、微信的搖一搖、微交互的崛起.
這次我的需求來源方式是1,即——版本規劃.
此次的需求是增加"賬戶明細"模塊,為用戶和財務雙方提供便捷的對賬功能.
梳理邏輯
做這個模塊是由于To B業務的特殊性,我們60%的客戶是選擇線下付款的,貨物直接送到用戶手中而不收錢款,在月末統一結賬,所以金額是有賬期的.為了避免用戶和銷售人員無意義的扯皮(財務對賬依據ERP,不以web為標準),因此推出賬戶明細功能.
梳理邏輯從需求出發,先不要畫原型,先不要畫原型,先不要畫原型!
梳理邏輯就要考慮需求的使用場景(為什么用這個功能、什么時候用這個功能)、使用方法(怎么用這個功能、要用那些功能)、字段數據(需要提供什么信息).
拿這次我要做的需求舉例子:為用戶和財務雙方提供便捷的對賬功能.
具體的功能就是:
1.用戶下訂單選擇支付方式,選擇支付寶微信交易,用戶的授信額度不變,使用線下付款,即貨到月結,授信額度對應的減少.
2.然后生成每一筆的交易流水,方便客戶和銷售人員對賬.
3.同時可以支持運營的活動,變相的實現訂單改價、返現、充值等功能.
那如何對賬(梳理邏輯)?
1.分析用戶使用狀態
? ?對于用戶而言,他要看到每一筆的收支金額、收支類型、購買時間等關鍵信息.
? ?對后臺而言,在對賬這一模塊,是不需要添加什么功能的,搜索用戶加篩選時間就OK,因為對賬的信息本質就是訂 ? ? ?單列表中的一些核心字段,所以后臺直接篩選訂單就可以查看用戶的所有交易流水.
? ?在運營功能性這一模塊,要添加返現、充值、退款、提現等操作.(其核心是對余額這一字段做增減變化).
2.有哪些核心字段?(該步驟推薦使用MindManager等工具枚舉字段信息,避免遺漏)
?3.明細信息生成規則
? ? 由于業務的特殊性,所以交易流水生成規則不像C端,以支付狀態為準,用戶付款,交易流水生成.
? ? 一開始的打算是準備以提交訂單為準,用戶一提交訂單,就生成一條新的交易流水,根據交易流水中的支付信息對 ? ? 余額進行操作.后來發現這種判斷方式太過草率毛躁,有很多的問題,比如:
? ? "用戶訂單提交錯了但是他自己不取消去提交新的訂單怎么辦?"——后果:交易流水會有過多的無效信息
? ? "如果采用這種方法,后臺如何判斷用戶流水?"——后果:無法判斷,不知道這條流水用戶到底要沒要
? ? 最終我使用的是:通過訂單狀態來生成交易流水,即:用戶提交訂單后臺發貨,用戶的賬戶明細才會生成新的交易 ? ? ? 流水,如此一來以上的問題便通通都解決了.
繪畫原型
關于如何繪畫原型這里就不展開篇幅一一敘述了,下次另開文章詳細講解,這次就簡要的說說繪畫原型的要點:
1.對齊對齊對齊,整體設計語言一致
對齊我認為是原型的第一要素,可能很多人都嗤之以鼻,一個原型而已,表達我想要的就行了,低保真足矣,對齊何用?
但我的理解是一個對齊的原型有助于UI的快速開發,不用在UI上浪費太多的口舌,其次審美好點的PM(比如我,我就是這么不要臉~~~)直接上色高保真分分鐘的事好嗎?然后直接交付給開發,UI都省去了(也就想想別當真,畢竟難度太高)
整體設計語言和對齊一樣,整個原型的通用要素一致,如按鈕都是矩形的、頂欄都是藍色的、間距都是一致的等.這樣方便UI制圖,原型一給,跟他說照著圖片上色,畢竟他不是我小棉襖,不懂我的心,我也不用過多操心,后期的毛病較少,省時間.
2.追求完美的心態
有的時候你認為原型很完美了,但是在你Boss的眼里,呵呵,呵呵呵.
畢竟這是人的缺點,對自己做的東西總是趨向于正面評價,看不到缺點.也別說一秒變小白這么高端的事情了,原型制作完畢,等個1、2個小時,時間充裕的話明天在看,你可以發現有很多可以優化的地方.
從一個原型初稿到最終版經歷個8、9次是很正常的.
3.多上上設計的網站,多看看潮流設計
沒有審美,那就培養審美.這里推薦幾個網站:
不會設計原型那就借鑒競品、同行,這是上手的最快方式,別不好意思.
撰寫文檔
最最重點的部分,撰寫文檔,下面我就先說說它的要點:
1.邏輯清晰,條理分明
PM最重要一項能力就是邏輯,而寫需求文檔則完美的體現了一個PM的邏輯層次.
說一個故事簡單,但是說一個起承轉合跌宕起伏的故事那就難了,而寫需求文檔也是如此.
先寫前端、再寫后臺.
先寫模塊、再寫功能.
先定義字段、再說明生成邏輯.
這三句話是核心中的核心(如有不對,歡迎指正)
2.格式一致、還有對齊
雖然我是雙子,但是寫文檔的時候我就秒變處女(不是處男嗎,廢話當然不是).
格式體現了你的工作態度、你的專業程度,甚至是你的工作能力.
就算你是瞎BB,開發哥哥看到這么美麗的文檔也不會說啥了(反正我是不信)
3.語言直白、通俗易懂
不要自己制造些云里霧里讓人看不懂或者有誤會的詞組詞語,多用大白話.
這方面別學蘋果,動不動就bigger than bigger,你要真這么寫了,開發會拿著他的mbp讓你知道什么叫pain than pain.
格式一致邏輯清晰語言直白,只需要注意這些,撰寫一份優美直觀的說明文檔不再是問題.
寫了這么多,估計你們還是迷糊的,啥也不說了,冒死上工作圖.
被Boss看見我就炸了.
還是王炸.
這是word版本的,也是我所使用所熱愛的(瞎說,明明是Boss要求的).
word版本更集中于邏輯的說明,語言簡練,描述集中.
Axure版由于原型的存在,所以直觀易懂,畢竟一圖勝千言.
Axure的PRD模板如下(由@臻龍 ?PRD文檔刪減而來),歡迎關注私聊索取
說了這么多,不準備點個贊嗎,少年
未經允許,謝絕轉載,更拒絕抄襲.
