從思考到撰寫,產(chǎn)品新人如何寫出自己風格的「需求文檔」
你有沒有這樣的時候,在對產(chǎn)品經(jīng)理一知半解的階段,瘋狂怒補網(wǎng)上的各種教程與干貨。到處尋找「模板」與「規(guī)范」??赡苣悴皇窍胍阉炊?,只是想知道,那些玄乎其神的文檔、原型究竟長什么樣。
好像很可笑的舉動,不過我也曾是其中一員。曾在網(wǎng)上找過各種各樣的PRD模板,感覺這貨簡直就是最神秘的東西,看到各種求職招聘信息都寫,熟練撰寫PRD文檔,看這情況,寫PRD已然成為PM的基本技能了。
那么究竟什么是PRD?
PRD的中文名字叫需求說明文檔,看名字就知道他是用來表達需求、定義產(chǎn)品的。既然是表達需求的文檔,那么我們首先要了解一下「需求」是什么?我想大神們早已有了各種專業(yè)的解釋。我這里就講個俗的例子啦。
設想這樣一個場景,早晨起來你讓媳婦給你做飯,你對他說“我要一個煎蛋8成熟,把香腸給我切成片,每片薄厚在1.5厘米,我還要一杯牛奶,把他裝在我昨天剛買的紅色杯子里,之后過來叫我?!焙孟衤犉饋砗茴^疼啊,在這里那些做飯的種種細則,那些你說“你要什么”的那個「什么」,就是你當時的「需求」。
「需求」說完了,再說「說明文檔」,文檔可以說是表達你要「什么」的一個說明書。提到說明書,就會想到那種家用電器每次都發(fā)的小冊子,他來告訴你產(chǎn)品的操作規(guī)范和注意事項。我們想象一下,當你在看一本說明書的時候是什么場景。
你正在面對一個陌生的東西,想通過里面的文字描述,知道他是什么,怎么工作,有何功能,注意事項等等,邊看邊摸索的時候,不知不覺就會用了。PRD其實也有同樣的效果,但這個文檔要比說明書高級些,因為我們可以做到與他互動,我個人在寫需求文檔的時候,通常先在Word上寫,這樣便于編輯與書寫,然后再把他們整理到Axure原型圖上,這樣做更加直觀與方便。
OK,需求跟文檔都解釋了,那么其實把他們1+1一下,就可以解釋需求說明文檔了。需求說明文檔就是一本表達你要「什么」的說明書。這樣說是不是就還算容易理解了。那么知道需求文檔是什么意思,接下來說說我們?yōu)槭裁匆獙懰?,他有什么用呢?/p>
為什么要寫PRD
我所在的公司是一個不太喜歡寫文檔的公司,對于規(guī)模不大的產(chǎn)品基本靠簡單說明和溝通解決,所以在最初讓我有種感覺,「文檔」是一個可有可無的東西。不過在后來的文檔撰寫經(jīng)歷中,的的確確從中學到了新東西。那么在什么情況下我們非常需要PRD,而不是單純靠溝通呢?
當產(chǎn)品比較「大」的時候,不管是頁面數(shù)量還是業(yè)務邏輯,比較復雜時,文檔能夠幫助執(zhí)行者理清思路;只靠單純地溝通,會顯得吃力。溝通這件事,本身就是個雙向,你說他聽,通常嘴上表達的,總是沒有寫出來的文字更理智與嚴謹。所以我們需要文檔。
此外我們在面對一個產(chǎn)品的時候,定義產(chǎn)品就是在定義一個產(chǎn)品的「標準」,不論是技術還是測試,都需要有一個標準,讓他們去執(zhí)行下去,而文檔便是這個標準的說明體,通過閱讀這個文檔,技術可以將產(chǎn)品轉化成他們認知中的功能模塊,數(shù)據(jù)庫,底層結構,同理UI或測試也是如此。
有時你也許會遇到,有個人氣沖沖跑過來跟你抱怨,你邏輯不對,功能不全,先別撕逼,看看說的有沒有道理,因為你要知道,定規(guī)則的是你,文檔就是讓他們用來執(zhí)行的,里面有缺失就等于他們沒辦法繼續(xù)執(zhí)行下去,這對他們來說是很大的困擾。所以我們需要文檔。
最后站在產(chǎn)品經(jīng)理的角度來看,撰寫文檔的過程,也是為自己「梳理」產(chǎn)品脈絡,檢查遺漏的一個過程,因為文檔要事無巨細的觀察產(chǎn)品的每個細節(jié),當你把這些細節(jié)都想過之后,你就會發(fā)現(xiàn),原來以為完成的產(chǎn)品,其實還差一些什么,所以我們需要文檔。
制定標準,產(chǎn)品復雜,自我梳理。因為這些原因我們不得不依靠文檔,當然還有另外一個利器——「溝通力」。在我看來PRD不僅僅是一個文檔,他還要加上溝通,才能真正叫做需求說明文檔。溝通是無形,卻至關重要。這里我們先拋開溝通不談,如果文檔+溝通構成了需求文檔的全部,那么文檔里都該有哪些具體的內容呢?
PRD都該有哪些東西
常聽人說,需求文檔嘛,只要表達出你想表達東西就行啦。不過對于剛入行的人,多半是不懂你在說什么的。其實對于文檔來說,產(chǎn)品經(jīng)理就是規(guī)則的設立者,這里的規(guī)則就是PRD中要呈現(xiàn)的內容,包括各方面的規(guī)則,交互,邏輯,業(yè)務等等,而PRD就是你思考過后的一個文字說明產(chǎn)出物。還是云里霧里?OK,繼續(xù)往下看。
文檔究竟要從哪里開始寫
首先不妨把自己的注意力拉遠,從細節(jié)回歸到整體,從輪廓開始梳理。在寫文檔時,總讓我想起上學時上的素描課,寫文檔其實和素描很像,他們都是從輪廓到細節(jié)的一個創(chuàng)作過程。在撰寫時應站在一無所知的讀者角度去思考,先說什么再說什么,怎么講對方才能更易看懂。先不管細節(jié),先把要寫的內容切成塊,分成大的標題段,再一一豐富起來。
我通常把PRD分成「前言」和「正文」兩部分,無需拘泥于word還是Axure,那只是形式問題,把內容寫好就可以。
先來說說前言,「前言」部分會包括修訂歷史記錄、撰寫目的、定義、術語解釋、產(chǎn)品背景等等。修訂歷史記錄用來記錄PRD文檔每次修改的內容,方便他人查閱。
撰寫目的、定義、術語解釋這些就不用解釋了,應該大家都理解。產(chǎn)品背景呢,我會用簡短的一段話來闡述產(chǎn)品,告訴讀者我們要做一件什么事,滿足什么需求,讓觀者對產(chǎn)品先有一個了解,至少知道我們在做一個什么事情,定位是什么。這就是前言部分,控制好的話,基本上兩頁就OK了。
再來就是「正文」部分了,這部分是PRD中的重點,有點像星爺練的降龍十八掌最后一掌,就是把前面的十七掌都連起來的意思。
在寫PRD之前,你已經(jīng)走過了,需求收集、分析、產(chǎn)品功能設計、業(yè)務邏輯設計、產(chǎn)品邏輯設計、原型交互設計、UI設計??纯醋哌^這么坎坷的路,手上Visio、Axure、Excel、PPT、jpg文件已經(jīng)堆滿了文件夾,這時候把他們有序的copy來就可以了。
正文的第一部分叫「點」
核心內容就是產(chǎn)品功能介紹,功能列表(版本說明)、顧名思義是羅列產(chǎn)品功能列表,主要是告訴閱讀者:
- 做什么功能
- 具體功能描述
- 為什么要做
- 緊急情況
- 商業(yè)價值
舉個具體的例子,比如做一個拼車產(chǎn)品,第一期我需要車主可以查看訂單,那么就可能需要:訂單列表功能,訂單排序功能,分頁功能,其他功能,這些是比較基礎的??梢园阉麄儗懺诠δ芰斜碇?,這些是用來表達產(chǎn)品需求的;
另外,為什么要做這個功能,為什么現(xiàn)在做,緊急情況,商業(yè)價值,是用來闡述你的理由,用來說服他人用的。這一部分決定了功能的優(yōu)先級和需求評審時被砍的概率。如果產(chǎn)品涉及到前后臺多個角色,也要在這里描述出各角色的關系,核心功能等。
正文的第二部分叫「線」
如果剛剛羅列的產(chǎn)品功能是點,那么邏輯就是連起他們的線,產(chǎn)品的整體業(yè)務邏輯是什么樣,產(chǎn)品如何運轉,用戶實際要操作的流程,這里一般用Visio圖表示。另外還有支撐整個產(chǎn)品的一個信息架構圖也需要在這一部分進行展示,關于流程圖的繪制,可以參考我之前寫的《三種常見「產(chǎn)品流程圖」是如何思考與繪制出來的?》
正文的第三部分叫「面」
現(xiàn)在功能知道了,框架知道了,邏輯有了,終于推進到了交互層。如果包含前臺與后臺頁面,建議從前臺開始寫。先將頁面流程圖畫出來,讓別人有個大致的了解。然后逐頁進行說明,可以按照頁面流程圖的順序來,一點點展開。單個頁面可以采用從左到右,從上到下的順序,一點點寫,在說明該頁面之前,可以先闡述下這一頁面的提供什么功能,主要用來做什么?然后再對頁面進行結構說明。
對于交互說明,可以把一個頁面拆解成,元素(字段)、規(guī)則和操作三部分。
我曾經(jīng)嘗試過用這樣的方式區(qū)隔他們,在Axure中將效果圖標注上元素說明。比如,如何讀取,顯示字數(shù)和文字是否有限制,表單的默認值是什么,頁面無數(shù)據(jù)會是什么等等。
因為元素說明要配上圖才更容易說明,規(guī)則就不同了,寫上來就能夠通過文字看明白。
規(guī)則說明包括,是哪個角色訪問進這個頁面,他從什么頁面進入此頁面,如果有列表,那么列表排序規(guī)則是什么,默認如何排,是否有緩存,分頁功能的規(guī)則是如何定義的等等。不僅如此在業(yè)務方面也會涉及到,如果拿訂餐來說,單日訂餐是否有份數(shù)限制,如需預定要要提前多久等等,這些也是規(guī)則的一部分。
當元素與規(guī)則闡述好之后,就需要來撰寫操作環(huán)節(jié),因為一般操作都會把用戶帶入新的頁面任務中,所以放在后面寫,這樣就可以銜接之后的頁面。
把上圖交給你,你會怎么寫?思考一下。
OK,先觀察一下,拋開導航而言,有什么是可以操作的呢?排序是不是一個?點擊地圖可以查看線路是一個,搶單按鈕很明顯是一個,圖上沒有的,其實還有一個查看更多的操作。
現(xiàn)在可操作的地方已確定,接下來就逐個去規(guī)定操作細則吧!比如操作完之后的流程是什么,登錄嗎?登錄成功之后呢,去到哪里,有什么反饋,什么節(jié)點做什么判斷,如果信息錯誤,那么錯誤提示是什么等等。
撰寫可操作規(guī)則時,實際上就是去想,當你點下這個按鈕之后的一系列流程與頁面,將他們都列舉出來。所有可以定義的內容都要定義,所有操作都像慢動作一樣,需要逐幀解釋。
其實寫到這里正文部分已經(jīng)結束了,點、線、面都被你寫到文檔中,這時候你可以召集小伙伴們來,再碰一次需求了,一份比較完整的需求文檔就搞定了,為什么說是比較完整,因為畢竟我還是個菜鳥,不知道這其中是否有疏漏之處,如果有,請大神指教,我愿意學習一下。
尾巴
不知道有沒有人是一口氣就把PRD寫好的,那有點費神了。我通常有個做法就是走三遍,第一遍走框架、第二遍走規(guī)則、第三遍走細節(jié)。
怎么理解呢?第一遍,定大的整體框架,把脈絡弄出來,知道這個文檔需要什么內容來填滿。第二遍,將內容填充好,邏輯流程走通,一般只走正向流程就可以。第三遍,補充所有字段、判斷、錯誤提示的細節(jié)等等。
當然大神可以嗤之以鼻了啊,沒有經(jīng)驗的同學可以試著這樣,用走三遍的方法,一點點做精細。最后,話說回來,依然相信把文檔寫好不過是一個開端,后續(xù)的溝通與修改也是至關重要,所謂7分靠溝通,3分靠文檔這種話真心在理。從輪廓到精細,把所有手頭的東西都扔到文檔中,再通過細致的溝通,一定能夠輸出一份不錯的東西來。祝好運。: )
#專欄作家#
辛超,微信公眾號:pmnote,人人都是產(chǎn)品經(jīng)理專欄作家。九櫻天下產(chǎn)品經(jīng)理,關注社區(qū)共享經(jīng)濟領域,曾任藍標集團策劃經(jīng)理,負責運營百萬級粉絲微博賬號,現(xiàn)轉崗產(chǎn)品,擅長產(chǎn)品設計與運營。希望未來自己打造的產(chǎn)品,能讓世界變得更好一點點。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,不得轉載。
感謝作者,寫的很棒,通俗易懂。對于我這樣沉浸在不知如何寫文檔中的小白幫助很大。
寫的真好。實在易懂。
贊一個