如何撰寫(xiě)需求文檔
需求文檔是怎么寫(xiě)的?不同公司有不同的寫(xiě)法,并沒(méi)有硬性規(guī)定,清晰、沒(méi)有遺漏即可。這篇文章,作者分享了自己寫(xiě)需求文檔的經(jīng)驗(yàn),供大家參考。
01 什么是需求文檔
需求文檔是產(chǎn)品經(jīng)理用來(lái)詳細(xì)描述需求,滿(mǎn)足協(xié)同人員使用的內(nèi)容文檔。它面向的人群包括:設(shè)計(jì)、交互、開(kāi)發(fā)、測(cè)試、項(xiàng)目經(jīng)理、運(yùn)營(yíng)及其他業(yè)務(wù)人員。
02 為什么寫(xiě)需求文檔
寫(xiě)需求文檔本質(zhì)上是為了提高工作效率和減少溝通時(shí)間。沒(méi)有需求文檔可以開(kāi)展工作嗎?其實(shí)也可以。如果團(tuán)隊(duì)只有兩個(gè)人,坐旁邊當(dāng)面溝通甚至比文檔的效率還要高。但一個(gè)需求只有兩個(gè)人的情況極少,沒(méi)有文檔的話(huà),多方人員之間需要花大量時(shí)間不斷地進(jìn)行溝通、信息同步,人越多效率就會(huì)越低。
此外,需求實(shí)現(xiàn)過(guò)程中也會(huì)出現(xiàn)遺漏和改動(dòng)的問(wèn)題,需要當(dāng)面溝通,時(shí)間長(zhǎng)之后溝通的結(jié)論可能雙方都記不太清楚了,留存到文檔中可以避免反復(fù)扯皮,讓項(xiàng)目中的人員達(dá)成共識(shí)。
03 如何寫(xiě)需求文檔
需求文檔沒(méi)有固定的模版,但是有大致的框架。主要是需求背景、需求范圍、需求詳細(xì)說(shuō)明、埋點(diǎn)需求四部分。
3.1 需求背景
此模塊用來(lái)描述需求來(lái)源和產(chǎn)生此需求的背景,目的是幫助團(tuán)隊(duì)成員理解項(xiàng)目的起源、目標(biāo)和重要性,以便產(chǎn)品經(jīng)理更好地推進(jìn)項(xiàng)目。這部分內(nèi)容主要包括以下幾方面:
- 描述現(xiàn)狀及當(dāng)前存在的問(wèn)題,可以通過(guò)數(shù)據(jù)或用戶(hù)反饋來(lái)支持;
- 本次需求可以解決哪些問(wèn)題;
- 需求完成后可達(dá)成的具體的量化的產(chǎn)品業(yè)務(wù)目標(biāo),非基建類(lèi)的需求需要有具體數(shù)值;
- 需注明業(yè)務(wù)方的預(yù)期上線(xiàn)時(shí)間,評(píng)審后各方評(píng)估時(shí)間緊張的話(huà),可能需要調(diào)整業(yè)務(wù)預(yù)期或倒排時(shí)間。
3.2 需求范圍
業(yè)務(wù)流程圖:一般需求比較大或者比較復(fù)雜時(shí)需要補(bǔ)充該模塊,讓文檔的受眾更好地了解業(yè)務(wù)的情況和本次需求的功能范圍,可以通過(guò)泳道圖的形式進(jìn)行輸出;
變動(dòng)范圍:如果是優(yōu)化產(chǎn)品需求,簡(jiǎn)述本次需求在原有的框架中的變化(新增功能模塊/頁(yè)面,修改某功能模塊/頁(yè)面,以及刪除某個(gè)功能模塊/頁(yè)面等);
功能優(yōu)先級(jí):功能較多時(shí)可通過(guò)表格的方式來(lái)簡(jiǎn)要描述涉及到的功能模塊和優(yōu)先級(jí),以便于在人力不足或時(shí)間緊張時(shí)保證主要功能,放棄一些低優(yōu)的部分;
名詞解釋?zhuān)喝粜枨笾猩婕耙恍┥?zhuān)業(yè)的詞語(yǔ),項(xiàng)目相關(guān)人員可能不懂,可以在此部分補(bǔ)充名詞解釋。
3.3 需求詳細(xì)說(shuō)明
需求詳細(xì)說(shuō)明中需要對(duì)每個(gè)模塊的功能分別進(jìn)行需求描述。需要注意的是,需求一般是新功能,產(chǎn)品經(jīng)理需要明確定義每個(gè)頁(yè)面和每個(gè)模塊的名字,方便各方人員之間溝通時(shí)采用相同的口徑,效率更高。
需求詳細(xì)說(shuō)明這部分需要注意的是規(guī)范、全面。需求文檔也是產(chǎn)品的一部分,需要從用戶(hù)角度去考慮,規(guī)范是為了易讀性,全面是為了不遺漏。
我一般是按照模塊/頁(yè)面名稱(chēng)、原型圖、詳細(xì)說(shuō)明(分點(diǎn))的結(jié)構(gòu)來(lái)寫(xiě)。描述每個(gè)功能時(shí),考慮最常用的12個(gè)狀態(tài):等待/加載(loading)、初始態(tài)、輸入、空狀態(tài)、有數(shù)據(jù)、數(shù)據(jù)過(guò)多、關(guān)注、正確反饋、錯(cuò)誤提示、待確認(rèn)、結(jié)束態(tài)、中斷恢復(fù)。
大部分狀態(tài)很好理解,不再過(guò)多解釋?zhuān)P(guān)注態(tài)可能比較小眾一些。關(guān)注態(tài)適用于特定場(chǎng)景,指用戶(hù)在看但沒(méi)有操作的狀態(tài),比如視頻播放時(shí)用戶(hù)觀(guān)看視頻。
在撰寫(xiě)這部分的過(guò)程中,為了使描述更清晰,可以使用各種圖例來(lái)輔助表達(dá),比如狀態(tài)圖、流程圖等等。
3.4 埋點(diǎn)需求
做需求時(shí)需要考慮到需求上線(xiàn)后的效果監(jiān)控,如果涉及到埋點(diǎn),需要在文檔中注明。工程師一般在提測(cè)前最后一步才會(huì)進(jìn)行埋點(diǎn)開(kāi)發(fā),如果需求比較緊急的話(huà),可以先評(píng)審其他部分進(jìn)行功能開(kāi)發(fā),然后再補(bǔ)充埋點(diǎn)文檔,做到敏捷開(kāi)發(fā)。
3.5 需求版本及相關(guān)人員
在需求評(píng)審并確定排期后,如果公司沒(méi)有使用項(xiàng)目管理軟件,最好將需求版本和該需求的相關(guān)人員和排期均標(biāo)注在文檔中,后續(xù)需求有變動(dòng)時(shí)可以直接找到對(duì)應(yīng)人員。(但是,這部分主要是利好項(xiàng)目不相關(guān)的人或后面交接的人,所以大部分人往往不會(huì)補(bǔ)充這個(gè)模塊)
示例如下:
04 小結(jié)
以上就是撰寫(xiě)需求文檔的經(jīng)驗(yàn)和方法。當(dāng)然,需求文檔的撰寫(xiě)沒(méi)有硬性規(guī)定,清晰、沒(méi)有遺漏即可,每個(gè)團(tuán)隊(duì)之間可能有不同的規(guī)范,核心還是讓項(xiàng)目相關(guān)人員能夠高效的讀懂,方便工作更好地開(kāi)展。
本文由人人都是產(chǎn)品經(jīng)理作者【YTY】,微信公眾號(hào):【產(chǎn)品二三】,原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash,基于 CC0 協(xié)議。
- 目前還沒(méi)評(píng)論,等你發(fā)揮!