經(jīng)驗總結(jié):產(chǎn)品需求文檔的編寫四步法
文章為作者結(jié)合自身工作經(jīng)驗總結(jié)的編寫需求文檔的方法,希望可以對你的產(chǎn)品工作帶來幫助。
作為產(chǎn)品經(jīng)理,編寫需求文檔是產(chǎn)品工作環(huán)節(jié)中最基本的,同時也是非常重要的工作。
剛開始,我們通常會拿別人的需求文檔作為模板來套用,這種格式化的需求文檔看起來挺專業(yè),但慢慢地會感覺到別扭。因為每項需求定義所需要的表達(dá)元素都不一樣,多了沒必要,少了又說不清楚。而這種填空式的文檔,總會讓人有一種束縛感。
經(jīng)過自己多年的工作錘煉,最終慢慢形成了自己的一套需求文檔編寫步驟和方法,從此屢試不爽。而也就從這之后自己對需求文檔的有了更深一層的理解。
我們先來說說編寫需求文檔的步驟。
1、建立版本功能需求樹。
也就是需求的結(jié)構(gòu)化可視化處理。
通常,產(chǎn)品經(jīng)理會有一個需求池。我們根據(jù)需求的重要性和緊急性從需求池中挑選出部分需求,作為產(chǎn)品迭代版本的工作內(nèi)容。確定了要納入版本開發(fā)的需求點(diǎn)之后,接下來要做的并不是編寫需求,而是畫需求樹。
這一步要用到的工具便是思維導(dǎo)圖軟件。我們將從需求池取出來的零散需求,以分類別的方式進(jìn)行結(jié)構(gòu)化處理。如按模塊化分,按用戶角色化分等,從而讓一個個的需求點(diǎn)組成一個個較完整的功能。這樣的好處是,讓需求點(diǎn)之間形成聯(lián)系,而這個過程則可能會演化出新的必要性需求,也將之納入到版本需求中去。
這個時候的需求導(dǎo)圖,類似于樹干加上枝干,已經(jīng)形成了產(chǎn)品需求樹的大概樣子。
將零散需求結(jié)構(gòu)化處理之后,便要進(jìn)行進(jìn)一步的細(xì)化,也就是畫出需求細(xì)枝。
在每個需求點(diǎn)之下,都會有些關(guān)鍵的,重要的元素構(gòu)成。將這些元素畫出來,有利于后面的需求文檔編寫工作,避免產(chǎn)生遺漏。
把所有的細(xì)枝都畫完之后,我們的需求樹便已完成??吹竭@個需求樹,自己心里已經(jīng)大概知道需求文檔要寫些什么了。
2、建立需求文檔目錄結(jié)構(gòu)。
需求文檔的目錄結(jié)構(gòu),就是用來確定文檔的內(nèi)容和表達(dá)形式的一種有力手段。在寫需求內(nèi)容前先把整個文檔的目錄結(jié)構(gòu)確定后,編寫文檔的效率會大大提高,也會使得文檔的表達(dá)邏輯更為清晰明了。
一般情況下,產(chǎn)品經(jīng)理都會有自己的一套比較常用的目錄結(jié)構(gòu),用于快速地建立文檔框架。但是在很多時候,通用目錄結(jié)構(gòu)可能并不能滿足特定需求下的表達(dá)效果。因為不同的需求所需要使用到的表達(dá)方式是不一樣的,只有針對性地采用合適的表達(dá)方式才能使你編寫的需求文檔產(chǎn)生事半功倍的效果。
比如,針對用戶端APP形態(tài)的功能定義,則更側(cè)重的是信息架構(gòu)、頁面展現(xiàn)、用戶體驗,所以在原型設(shè)計和關(guān)鍵交互要求是需要重點(diǎn)說明的。因此,在這部分需求的內(nèi)容結(jié)構(gòu)上,需要將“原型設(shè)計”及“交互說明”單獨(dú)列入到目錄結(jié)構(gòu)中去。
比如,針對后臺功能,側(cè)重的是數(shù)據(jù)處理和存儲,所以在數(shù)據(jù)項定義、數(shù)據(jù)流轉(zhuǎn)、規(guī)則說明等方面需要進(jìn)行完整說明。而如果這幾部分內(nèi)容較多,則也是需要進(jìn)行劃分,最終體現(xiàn)在目錄結(jié)構(gòu)中。
再如,涉及到多系統(tǒng)間業(yè)務(wù)交互的,或者業(yè)務(wù)流程較為復(fù)雜的,則可能需要考慮加入系統(tǒng)間業(yè)務(wù)交互說明、接口定義、業(yè)務(wù)流程描述等內(nèi)容。
如此這般,都是需要針對不同類型的需求采用不同的表達(dá)方式來描述需求。最終的目的也都是為了讓文檔使用者(開發(fā)工程師)更容易理解你所定義的需求。
所以,我們在寫文檔之前進(jìn)行目錄結(jié)構(gòu)設(shè)定,是為了框定文檔的內(nèi)容和表達(dá)方式,相當(dāng)于我們建筑里的框架結(jié)構(gòu)。搭建好之后,便可以進(jìn)行快速填充了。
3、詳細(xì)需求內(nèi)容填充。
做好以上兩步,那這一步就變得簡單多了。因為你知道了要寫什么,而且還知道要怎么寫,剩下的無非就是時間問題了。
這一步,最重要的就是把需求描述得更容易理解,要站在開發(fā)工程師的角度來考慮如何表達(dá)。另外就是邏輯要嚴(yán)密,不要產(chǎn)生需求漏洞。
4、需求文檔版本更新。
產(chǎn)品需要迭代,需求文檔也一樣。當(dāng)你的需求文檔發(fā)出去之后,經(jīng)過評審,以及在后續(xù)項目進(jìn)行過程中都有變更需求定義的可能,這就涉及到了文檔的更新問題。
我們可以稱之為需求文檔迭代。這個工作最重要的就是版本管理。每次文檔更新,我們都需要像產(chǎn)品版本一樣給予定義一個版本號。這個版本號跟產(chǎn)品版本要區(qū)分開來,文檔版本號是在產(chǎn)品版本之下的,所以只需要進(jìn)行簡單的命名即可。
通常,我會將需求文檔版本號命名為Rx,如R1,R2,R3等等。R表示requirements,即需求。默認(rèn)將首次發(fā)布的需求文檔版本定為R1,后續(xù)每次變更修改則依次命名為R2,R3……且要說明此次版本變更的說明。另外還有就是修改人,修改時間等信息。
而在具體內(nèi)容修改的地方,最好能把改動的地方標(biāo)識出來,比如用高亮的字體顏色進(jìn)行區(qū)分。這樣能讓開發(fā)人員一目了然,便于閱讀。
最后,對于需求文檔的編寫,還需要明白如下幾點(diǎn):
- 編寫產(chǎn)品需求之前的核心工作是分析理解需求,弄清楚用戶到底要什么?重視需求分析,腦補(bǔ)用戶使用場景,理解用戶目標(biāo),完整地渲染出用戶需要的產(chǎn)品功能,做出用戶需要,可用,好用的產(chǎn)品設(shè)計。
- 需求文檔的目的是產(chǎn)品經(jīng)理將用戶需求通過分析設(shè)計轉(zhuǎn)化為研發(fā)人員可理解(有來龍去脈),可實現(xiàn)(邏輯完整通暢)的產(chǎn)品開發(fā)說明書。要用研發(fā)人員可以理解的語言及方式來描述,要考慮使用對象的閱讀體驗。
- 了解必要的技術(shù)實現(xiàn)原理和流程。如對接微信支付,你需要了解微信支付接口相關(guān)的技術(shù)能力及對接流程,通過整合自己的業(yè)務(wù)需求和流程,做出合理、可實現(xiàn)的設(shè)計 。
- 當(dāng)沒有專門的交互設(shè)計師時,產(chǎn)品經(jīng)理需要同時考慮交互體驗設(shè)計,但絕不要沉浸在交互設(shè)計效果的模擬實現(xiàn)上。能說一句話說明白的事,就不要去做交互,因為你不是交互設(shè)計師,你的工作重心在于需求定義本身。
本文由 @星思維 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自PEXELS,基于CC0協(xié)議
小白提問:產(chǎn)品經(jīng)理需要設(shè)計好數(shù)據(jù)結(jié)構(gòu)表嗎?
在此之前應(yīng)該是考慮流程吧
我喜歡這種文章,可以幫我們減少新人競爭對手
what?
用word寫還是用axure寫啊
一般性的需求,axure就可以搞定
講的很系統(tǒng),和昨天我的老大傳授給我的一樣!
如有雷同,純屬巧合 ?