如何寫一篇挑不出毛病的需求文檔?
作為產(chǎn)品經(jīng)理,撰寫需求文檔是一門必須掌握的基本功,那么除了知道需求文檔應(yīng)當(dāng)包含哪些內(nèi)容,你知道需求文檔究竟應(yīng)該怎么“寫”嗎?怎樣才能寫出一份可以讓每個項(xiàng)目成員都能清晰明了得到所需信息的PRD文檔呢?一起來看看作者的經(jīng)驗(yàn)分享。
需求文檔是產(chǎn)品經(jīng)理的基本功,也是產(chǎn)品能力的體現(xiàn),產(chǎn)品能力行不行看文檔就能看出來。
我從實(shí)際工作+日??偨Y(jié),整理了一些自己寫PRD的方法,分享給各位,希望能對各位有用~
一、原則與前提
在文章開始前,我們簡單看下在什么時候用、誰去用,來明確需求文檔的書寫原則:
- 產(chǎn)品需求評審的時候看;
- 研發(fā)技術(shù)方案設(shè)計、敲代碼的時候看;
- UI進(jìn)行界面設(shè)計的時候看;
- 測試寫測試用例、執(zhí)行用例的時候看。
PRD 文檔的目的就是讓每個項(xiàng)目成員知道需求為什么做、要做什么、怎么做。
所以可以得到PRD的書寫原則有:
- 有理有據(jù):從項(xiàng)目成員知道為什么做;
- 全面、清晰、準(zhǔn)確:讓大家知道做什么、怎么做;
- 易讀性:讓大家方便快捷的理解文檔內(nèi)容。
明確了原則,還有2個前提:「需求類型、需求大小」
- 需求類型有:功能需求、接口需求、性能需求、策略需求、埋點(diǎn)需求、統(tǒng)計需求等等。
- 需求大?。?/strong>可以是從0-1的大項(xiàng)目,包含上邊的所有需求類型,還有就是日常迭代版本的小需求。
我們接下來文章內(nèi)容都是基于以上原則與前提,接下來正文開始~
二、需求文檔用啥寫
我們以終為始,先看需求文檔的呈現(xiàn)方式。目前主要有以下2類:
1. Axure一體化需求文檔
使用Axure將全部需求文檔,最終通過Axure打包提供出去。好處是方便查看,看原型的基礎(chǔ)上又能看文檔說明。但有一種不是很“嚴(yán)肅”的感覺。
2. Word版
通過Word進(jìn)行需求描述,并統(tǒng)一提供。容易留存,也比較正規(guī),在閱讀上以文字為主。
具體選擇那種方式,可以先看公司要求。
像我之前有公司要求,必須用word,就算是有大量原型的,也只能把頁面原型畫好,然后再復(fù)制到word里,在word寫需求內(nèi)容。
如果沒有要求,具體采用的方式可以看不同的需求類型:
如果只涉及到畫原型的,可以使用Axure。
如果只有偏后端需求的,邏輯相關(guān)的需求,比如說是接口需求、算法需求,并不涉及到前端需求的,我們可以直接使用word寫。
如果是做的大項(xiàng)目,同時有功能需求,又有接口需求、算法需求的,我建議都放在一起,比如說都用Axure寫需求。
我之前做新項(xiàng)目的時候,同時提供了功能需求的axure文檔+word版的接口需求,后來用例評審的時候,測試說不知道word版接口需求,之后我就統(tǒng)一寫在axure里了。
三、需求文檔包含哪些內(nèi)容
需求有大有小,同樣的需求文檔也有大有小,小到直接一句話描述,大到上百個原型頁面,好幾萬個字。
一句話的需求我們在這就不說了,我們說下正常的需求文檔。
不論是使用Axure還是word,也不論需求大小是什么,PRD文檔中一般需要包含以下內(nèi)容:
1. 文檔修改記錄
需求文檔在需求評審、研發(fā)、測試過程中一定會改的。
比如說加個限制,補(bǔ)充個遺漏的邏輯等等,不過我們一定要記錄下修改內(nèi)容,并及時更新需求文檔、及時同步項(xiàng)目成員。
一般通過表格展示出以下內(nèi)容:
- 修改內(nèi)容:說清楚修改的哪個模塊,哪個頁面、哪個功能點(diǎn)。當(dāng)然也可以分成修改模塊、修改頁面多個列。
- 修改原因:就是為啥要修改,比如說邏輯缺失需要補(bǔ)充等等。
- 修改人:誰改的。
- 修改日期:修改時間。
在使用Axure時,我們可以在文檔修改記錄中加上文本鏈接跳轉(zhuǎn),項(xiàng)目成員點(diǎn)擊文字可直接進(jìn)入到對應(yīng)頁面查看。
對于word,也是同樣的,加個文檔修改記錄。
對于文檔修改記錄,不僅在PRD文檔中可以用到,在寫其它文檔時都可以加上,比如操作手冊。
2. 項(xiàng)目背景 or 需求背景
背景同樣也是有大有小,對于新項(xiàng)目,則需要介紹下整個項(xiàng)目的大背景。對于每個需求,我們同樣也可以簡單說下需求背景。
參考格式如下:
當(dāng)前的現(xiàn)狀是什么,有哪些問題/痛點(diǎn),這些問題導(dǎo)致了什么結(jié)果,為了解決這個問題,我們需要采取什么動作,達(dá)到什么目的,能夠獲取哪些收益,產(chǎn)生什么價值。
3. 名詞解釋
如果有專業(yè)名詞,一定要寫上。
在不同行業(yè)、不同公司、不同團(tuán)隊(duì)中都有專門的名詞,項(xiàng)目成員是不明白一些名詞的,這個時候一定要說明。
比如說抗菌藥物DDD值,絕對的專業(yè)名詞,不說一般沒人知道。
另外在說名詞解釋的時候,盡量加上示例說明方便大家快速理解。
4. 流程圖
當(dāng)涉及跨角色、跨系統(tǒng)、跨模塊、多判斷邏輯時,我們一定要畫出來,讓各方更快地了解產(chǎn)品流程。
流程圖同樣有大有小:
包括整體產(chǎn)品業(yè)務(wù)流程圖、單個模塊的流程圖、單個功能的流程圖。
1)整體流程圖
為了將這個產(chǎn)品的功能業(yè)務(wù)串起來,可以不用畫的太詳細(xì),畫出大的概覽圖,從大而全的角度將這個項(xiàng)目表達(dá)出來。
一般是在0-1的新項(xiàng)目中畫,日常迭代的需求中不需要。
2)單個模塊功能的流程圖
當(dāng)一個功能模塊功能很多時,為了將模塊內(nèi)的功能串起來,說清楚單獨(dú)模塊的流程,這個就要畫的細(xì)致一點(diǎn)。
當(dāng)涉及到新的模塊時一定要畫。
3)單個功能的流程圖
對于復(fù)雜的單個功能,涉及到的處理邏輯比較多時,我們也需要畫出單獨(dú)的流程圖進(jìn)行說明。
流程圖的類型有很多種,像業(yè)務(wù)流程圖、頁面流程圖、泳道圖、uml里的時序圖、用例圖等等。
我們可以基于不同流程圖的特性去選擇不同的類型,比如有多角色時,我們可以使用泳道圖。
對于UML,像用例圖、序列圖,在畫的時候有一定的門檻,同樣的一定會有團(tuán)隊(duì)成員看不懂。我是從來沒畫過,所以大家可以自行選擇學(xué)習(xí)與繪制。
對于頁面流程圖,是表達(dá)出頁面之間的跳轉(zhuǎn)邏輯,像移動端的頁面,我們可以直接平鋪出每個頁面,展示出頁面間的跳轉(zhuǎn)邏輯。
對于PC端產(chǎn)品,頁面尺寸較大,我們可以通過頁面名稱展示出頁面流程。
流程圖的能夠達(dá)到業(yè)務(wù)清楚,表明重點(diǎn),項(xiàng)目成員能夠快速理解的目的就行。
5. 需求說明
對需求的詳細(xì)說明,這一點(diǎn)肯定是必須的,我們下邊單獨(dú)說。
以上內(nèi)容是我認(rèn)為在寫需求文檔時,需要包含的內(nèi)容,下邊的內(nèi)容我們則可以自行選擇~
1)產(chǎn)品架構(gòu)圖
在0-1產(chǎn)品搭建的時候進(jìn)行展示,將整個產(chǎn)品抽象化,通過數(shù)據(jù)層、服務(wù)層、應(yīng)用層、展現(xiàn)層等抽象層面表現(xiàn)出產(chǎn)品的整體架構(gòu)。
來自Processon
產(chǎn)品架構(gòu)圖是非常大的層面,當(dāng)你沒有獨(dú)立負(fù)責(zé)一條業(yè)務(wù)線的時候,很難有這種大的架構(gòu)概念。
當(dāng)你需要規(guī)劃一條產(chǎn)品線的時候,可以畫出來產(chǎn)品架構(gòu)圖,讓之后的產(chǎn)品方向再這個大的框架下去走。
我也是在最近這2年,獨(dú)立負(fù)責(zé)產(chǎn)品線的時候才開始繪制的,主要是和領(lǐng)導(dǎo)們匯報使用的。
具體怎么畫,大家可以在平臺上搜一下,有很多。
2)功能架構(gòu)圖 or 信息架構(gòu)圖
對于功能架構(gòu)圖,就是寫清楚產(chǎn)品功能的層級架構(gòu),簡單說就是一級菜單、二級菜單是什么,每個菜單里有哪些功能,展示出功能的層級關(guān)系。
我一次都沒有畫過。
對于功能架構(gòu)的展示,我一般在畫原型的時候規(guī)劃出來,然后直接畫原型。
當(dāng)然也可以通過思維導(dǎo)圖的方式畫出來,但是吧,畫出來也沒人看。
還有一個信息架構(gòu)圖,這個我也沒畫過。
我有很長的一段時候都沒整明白功能架構(gòu)圖與信息架構(gòu)圖有啥區(qū)別~
現(xiàn)在我的理解是:
- 功能架構(gòu)圖是展示出功能層級關(guān)系,體現(xiàn)出菜單-功能的層級邏輯。
- 信息架構(gòu)圖是展示出每個功能頁面內(nèi)的展示字段內(nèi)容,主要用于研發(fā)設(shè)計表結(jié)構(gòu)與表字段。
對于功能架構(gòu)圖和信息架構(gòu)圖,一般是在產(chǎn)品0-1的時候畫,而且涉及到的內(nèi)容比較多,多的內(nèi)容一定沒人去看。
到底要不要畫是一方面,大家一定要知道功能結(jié)構(gòu)圖和信息架構(gòu)圖是個什么東西,具體畫不畫大家自行選擇。
四、畫原型寫文檔
需求類型里有一個功能需求,這個就是每個產(chǎn)品避免不了的,所以我們單獨(dú)說下畫原型+寫文檔~
1. 首先根據(jù)要做的需求范圍進(jìn)行分類
當(dāng)有多個需求類型時,按類型進(jìn)行分類,使用Axure時可以通過建立文件夾。
使用word則可以加個一級標(biāo)題。
目的是將需求有層級的依次展示出來。
然后在不同的文件夾下,在進(jìn)行分級。
比如「功能需求說明」文件夾下有多個功能模塊,則按照模塊/菜單名稱建立子文件夾,然后再在每個模塊下建立對應(yīng)頁面;
當(dāng)同一個頁面內(nèi)有多個tab頁/子頁面時:
對于PC端,我一般是分頁面說明;APP的頁面尺寸小,我們可以在一個Axure頁面內(nèi)統(tǒng)一說明。
然后再對每個頁面單獨(dú)畫原型,寫文檔。
2. 需求文檔的表現(xiàn)方式
當(dāng)采用Axure寫需求文檔的時候,常見的布局是:左圖右文。
左邊展示原型圖,右邊展示需求說明。
對于word版,常為:原型頁面展示,單獨(dú)寫文檔說明。
3. 提取公共邏輯,放入全局說明
在畫原型、寫文檔的時候,一定會有相同的功能邏輯、相同的需求邏輯。
例如說后臺系統(tǒng),會有一堆的列表,列表就涉及到分頁數(shù)量、默認(rèn)排序等。
我們可以直接統(tǒng)一使用全局說明。
將相同的功能邏輯、需求內(nèi)容當(dāng)在一個單獨(dú)的全局說明里,在全局說明里進(jìn)行單獨(dú)說明。
當(dāng)在某個頁面中需要說明的功能點(diǎn)已經(jīng)在「全局說明」里存在時,可以加個說明:請見全局說明。
同時對文字添加文字跳轉(zhuǎn)鏈接,閱讀者點(diǎn)擊可直接跳轉(zhuǎn)到對應(yīng)的全局說明頁面。
3. 功能點(diǎn)序號標(biāo)注
先畫出原型圖,在原型中標(biāo)注「序號」,然后在右側(cè)按照相同的序號進(jìn)行功能需求描述。
- 標(biāo)注順序:一般按照從左到右,從上到下的順序。
- 標(biāo)注哪些點(diǎn):需要進(jìn)行功能說明的功能點(diǎn),但是并不意味著每一個點(diǎn)都要進(jìn)行標(biāo)注。
我一般按照從大到小,按照模塊化的方式。
以下方的表單頁面為例:
當(dāng)原型畫出后,在頁面上標(biāo)個序號[1],對頁面進(jìn)行下簡介,一般說明頁面是什么,使用角色是誰。
然后繼續(xù)標(biāo)注「返回」,對「返回」進(jìn)行說明。
因?yàn)辄c(diǎn)擊返回時,沒有添加其它判斷邏輯(如是否二次確認(rèn)),所以直接描述交互邏輯即可。
然后接著對下方的「患者信息」進(jìn)行標(biāo)注。
我們可以看到「患者信息」里有很多字段,我不建議對每個字段進(jìn)行說明。
我們直接對「患者信息」整個模塊進(jìn)行標(biāo)注,然后對每個字段進(jìn)行說明。
由于只是表單輸入,我們需要說明是否必填、采用什么組件、是能輸入文字、還是數(shù)字輸入框,數(shù)字范圍限制、數(shù)字小數(shù)點(diǎn)限制(如最多2位小數(shù))、輸入小數(shù)點(diǎn)超過如何處理(是直接限制輸入,還是能四舍五入)、字符長度限制、當(dāng)字符輸入超長如何處理。
如果是采用選擇框,選擇框里的值是寫死的,還是從哪里取值。
……
這就是對需求的描述,我們需要盡可能的寫全,就是盡可能的把考慮到的限制加上,你寫的越全,在評審的時候,才會少挨懟。之后的需求變更才會少。
(現(xiàn)在看其實(shí)上邊的需求描述還是不全,比如漏了小數(shù)點(diǎn)位數(shù)說明,文本輸入框內(nèi)能不能輸入表情emoji符號等等)
當(dāng)頁面內(nèi)出現(xiàn)彈窗時,我們需要對彈窗里的內(nèi)容進(jìn)行說明,單獨(dú)對彈窗里功能點(diǎn)進(jìn)行標(biāo)注,然后再下方繼續(xù)對需求進(jìn)行說明。
對于彈窗里的內(nèi)容,我一般從「1」開始重新編號。不把序號順序和其他頁面夾雜在一起。當(dāng)調(diào)整一個功能點(diǎn)后,需要重新編號,增加了多余的工作量。
4. 需求詳細(xì)書寫
對需求的詳細(xì)描述,是最核心的內(nèi)容,我們可以按照下方的格式來寫:
- 標(biāo)題:功能點(diǎn)名稱。
- 角色權(quán)限:如當(dāng)前登錄用戶角色為管理員時,則顯示此按鈕。
- 規(guī)則邏輯:主要有校驗(yàn)邏輯、前置條件、觸發(fā)時機(jī)等,當(dāng)涉及到的校驗(yàn)邏輯太多時,可以采用分行分段、添加序號、使用表格等方式,將每個邏輯有條理的全部說明清楚。
比如:確定按鈕。
當(dāng)角色為「管理員」時,展示出確認(rèn)按鈕;
- 當(dāng)XX未填寫時,按鈕顯示為禁用狀態(tài),點(diǎn)擊時出現(xiàn)toast提示:請?zhí)顚慩XX。
- 當(dāng)XXX、XXX全部填寫后,按鈕置為可點(diǎn)擊狀態(tài),點(diǎn)擊后跳轉(zhuǎn)至XXX頁面。
極值說明:如輸入框輸入字符的長度,數(shù)字輸入的范圍值。
交互說明:如點(diǎn)擊調(diào)整至XXX頁面。
在寫需求時,根據(jù)不同的需求內(nèi)容,盡可能的將全部內(nèi)容寫清楚。
這個時候一定會有一個問題:寫不全。
我們可以明確一點(diǎn),沒有產(chǎn)品經(jīng)理把所有情況都考慮到,喬布斯、張小龍也考慮不了那么全。
我們需要做的是盡可能的考慮全,盡可能是個很虛的詞,受行業(yè)經(jīng)驗(yàn)、項(xiàng)目經(jīng)驗(yàn)等影響,不同級別的產(chǎn)品經(jīng)理的需求文檔寫的水平很顯而易見,當(dāng)然你考慮的越全面,產(chǎn)品能力可以說就越強(qiáng)。
我們可以在需求評審前,先和研發(fā)提前碰下,避免有大的遺漏。
也可以借助「需求自查表」來輔助,自查出遺漏的說明。
5. 其它
1)文字描述言簡意賅,避免口語化,別使用模棱兩可的文字。需求文檔里的內(nèi)容必須明確,別寫「盡量」「盡快」。
2)添加示例:被誤解是表達(dá)者的宿命,文字說明都會有一定的片面理解,對于比較復(fù)雜的內(nèi)容,我們可以添加示例說明:
同時在原型上,盡量使用貼合實(shí)際場景的內(nèi)容。比如說時間別寫出:13:88:99。
3)為了便于閱讀,可以采用多分段,多分行,加序號的方式。
4)使用標(biāo)點(diǎn)符號,將內(nèi)容說清楚,如:點(diǎn)擊「確認(rèn)」按鈕,跳轉(zhuǎn)至【XXX頁面】。
關(guān)于標(biāo)點(diǎn)符號,大家可以看這個文章:https://zhuanlan.zhihu.com/p/359255980
5)結(jié)合axure的特性,添加文字鏈接,便于閱讀者快速跳轉(zhuǎn)查看,不用自己找。
添加「返回」按鈕,比如閱讀者跳轉(zhuǎn)到【全局說明頁面】,看完后,想在回到來源頁繼續(xù)看需求,我們可以在【全局說明頁面】中添加個「返回來源頁」按鈕,加個返回上一頁的交互,直接能返回。
6)對于變量值,使用特殊符號標(biāo)記下
對于會變化的值,我一般使用用兩個百分號,如下方的‘科室名稱’,會根據(jù)不同的選擇展示不同的名稱,所以我就通過‘%科室名稱%’進(jìn)行表示,然后單獨(dú)說明,并舉例說明。
7)重要內(nèi)容進(jìn)行標(biāo)記
可以通過加粗、換個顏色等方式進(jìn)行提醒,當(dāng)內(nèi)容較多的時候,大家很容易忽略掉,所以很有必要進(jìn)行加粗加大標(biāo)色提醒。
8)涉及到邏輯時,可以使用公式進(jìn)行說明
如:當(dāng)A+B≥100時,則XXXX。
9)寫完后自己再過一遍
就像上學(xué)做題后,自己zai再驗(yàn)算一遍,在寫文檔的時候,自己肯定會有抽風(fēng)的時候,不知道哪個地方就給寫錯了。
10、對外提供時,對于Axure,可以打包出html提供。
如果是word版本,可以提供出pdf版。
以上是對功能需求的說明,對于接口需求、性能需求、埋點(diǎn)需求等非功能性需求,當(dāng)涉及到的時候,一定要寫上,不然就是需求遺漏了。
我之前一直以為產(chǎn)品經(jīng)理只需要寫功能需求就夠了。
有一次讓我寫接口需求,我就很郁悶,這明明是技術(shù)的活,干嘛產(chǎn)品寫。后來,我明白了一件事,產(chǎn)品經(jīng)理不往前站,之后就會是一堆坑。
除了接口需求,還是像研發(fā)數(shù)據(jù)庫建表時,這些我也建議產(chǎn)品經(jīng)理去介入,因?yàn)楸砝镉心男┳侄?,字段最大長度是多少,需要建哪些字段等等,都是和業(yè)務(wù)有關(guān)系的。
舉個示例,藥品的「規(guī)格」這個字段,研發(fā)把最大長度設(shè)置成250個字符,但是在實(shí)際業(yè)務(wù)上,「規(guī)格」會有2000個字的情況。
研發(fā)絕對是不理解的,所以最清楚這個情況的是產(chǎn)品,就需要提醒研發(fā)關(guān)注下。避免上線后,字?jǐn)?shù)超長導(dǎo)致保存錯誤。
對于性能需求怎么寫,大家可以看這篇:《5000字詳解性能需求》。
對于接口需求、埋點(diǎn)需求等大家可以在平臺上搜一下,接口需求可以看:http://zhangjingwei.cn/pmd/2297401.html
總結(jié)
寫出好的需求文檔受很多方面的影響,從前期的需求分析,當(dāng)確定業(yè)務(wù)流程,然后再到畫原型,最終把PRD寫出來,這里邊涉及到的內(nèi)容非常非常多。
這篇文章是給大家提供的概述,大家可以在日常中總結(jié)積累,多和項(xiàng)目成員溝通,每一次需求評審就是一次淬煉,挨個一次懟后就總結(jié),下次別再犯。
另外,當(dāng)你把一篇完美的需求文檔交付后,一定會有研發(fā)、測試不看的,只會問,就不看文檔。我一般是“微笑服務(wù)”,把文檔內(nèi)容截個圖發(fā)過去。
專欄作家
王大鹿,公眾號:產(chǎn)品大鹿,人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注醫(yī)療領(lǐng)域,擅長原型設(shè)計、需求分析和方案設(shè)計,分享能落地的工作技能~
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)
“功能結(jié)構(gòu)圖,畫了也沒人看”太真實(shí)了
但功能結(jié)構(gòu)圖,可以作為在腦子里設(shè)計功能點(diǎn)的梳理工具
0·1的項(xiàng)目還是需要的!開發(fā)會看的。
需求明確、無疑義,很棒,這樣就不需要再次確認(rèn)需求。
很詳細(xì),很實(shí)用;多謝?。?!
講得很好,請問實(shí)例中的axure文檔方便發(fā)一下么,我這邊撰寫的時候方便參照
獲取方式:公眾號:產(chǎn)品大鹿 后臺回復(fù):prd
很實(shí)用
有幫助