寫需求文檔容易犯的錯(cuò)
每個(gè)產(chǎn)品經(jīng)理的工作都會(huì)寫需求文檔，而對(duì)于需求文檔的格式由于各個(gè)公司要求不統(tǒng)一，實(shí)際上也沒(méi)有一個(gè)標(biāo)準(zhǔn)的模版給產(chǎn)品經(jīng)理。
產(chǎn)品經(jīng)理都會(huì)做的是對(duì)于某個(gè)功能/頁(yè)面/彈窗上展開(kāi)需求表述，還是會(huì)有相同的撰寫格式。比較常見(jiàn)的包含前置條件、交互描述、字段解釋、后置條件
可是到底一個(gè)需求文檔要寫多細(xì)？實(shí)際上是沒(méi)有答案的的。
因此會(huì)困擾不少產(chǎn)品經(jīng)理到底是否應(yīng)該把這部分需求加上。因?yàn)樯晕⒉蛔⒁饩统闪死速M(fèi)工作時(shí)間，本身需求文檔的目的是為了給開(kāi)發(fā)、設(shè)計(jì)同學(xué)進(jìn)行查看，但過(guò)于細(xì)節(jié)則容易造成閱讀率降低。
普遍的做法是把需求文檔中的文本描述和原型進(jìn)行并列展示。圖文并茂的用于表達(dá)功能描述。
當(dāng)然為了對(duì)于某些流程較復(fù)雜比如業(yè)務(wù)系統(tǒng)、后臺(tái)產(chǎn)品或某個(gè)運(yùn)營(yíng)活動(dòng)，就需要加上時(shí)序圖、流程圖、泳道圖等多個(gè)圖表來(lái)說(shuō)明。
產(chǎn)品經(jīng)理的需求到底要寫多細(xì)
一個(gè)功能由多個(gè)頁(yè)面組成，而撰寫需求都是以頁(yè)面展開(kāi)。比如下面是PMTalk小程序「我的票圈」詳情頁(yè)，可以看到從上到下本頁(yè)面分為4個(gè)紅色矩形進(jìn)行展開(kāi)。
分別有導(dǎo)航欄、banner、票圈信息流、底部導(dǎo)航欄4個(gè)部分。
「我的票券」這個(gè)功能也是這個(gè)頁(yè)面，產(chǎn)品經(jīng)理撰寫需求文檔就會(huì)從上面4個(gè)方向開(kāi)始寫。
第一個(gè)矩形部分：導(dǎo)航欄
包含了返回按鈕、小程序縮小按鈕、小程序分析按鈕3個(gè)操作。如果要撰寫需求文檔，實(shí)際上面3個(gè)按鈕都可以展開(kāi)功能描述。
可是微信小程序有官方自帶的能力，小程序分享按鈕就自帶下面標(biāo)準(zhǔn)的8個(gè)入口（安卓）。而產(chǎn)品經(jīng)理可以對(duì)這8個(gè)進(jìn)行部分篩選或添加部分能力，比如小程序的朋友圈分享能力，但是由于目前該能力僅支持安卓機(jī)型，用戶的使用數(shù)據(jù)特別低。
所以在需求文檔撰寫的時(shí)候，這一部分是可以省略的。同時(shí)導(dǎo)航欄返回圖標(biāo)已經(jīng)明確表達(dá)了是返回上一層級(jí)操作，需求文檔也可以不用撰寫。
所以如果是產(chǎn)品新人，會(huì)糾結(jié)是否要撰寫這部分的需求。而產(chǎn)品老鳥(niǎo)則不會(huì)撰寫這部分了。
第二部分矩形：banner的需求描述
對(duì)于這部分需求，因?yàn)閎anner涉及手勢(shì)操作，所以會(huì)有交互、和banner的展示邏輯2部分。
交互部分：
什么樣的手勢(shì)操作會(huì)觸發(fā)banner變化，同時(shí)banner的速度、切換效果等。這都是可以在需求文檔表達(dá)，去做開(kāi)發(fā)的。
但實(shí)際上這是沒(méi)有意義的
banner這類都是前端開(kāi)發(fā)都會(huì)采用現(xiàn)有組件完成，就像產(chǎn)品經(jīng)理在原型產(chǎn)品設(shè)計(jì)會(huì)用部件庫(kù)完成一樣。所以只需要告知banner的展示邏輯即可
banner的圖片尺寸、banner允許展示的數(shù)量、banner是否有推薦算法、banner的埋點(diǎn)等，這類需求是產(chǎn)品經(jīng)理需要撰寫的。
第三部分矩形：我的票券信息流
這部分因?yàn)樯婕暗叫袨椴僮鳎瑯訒?huì)分為2部分，一個(gè)是交互、和信息流展示邏輯、還有信息流的跳轉(zhuǎn)。
交互部分：
同樣信息流到底是如何滾動(dòng)的、滾動(dòng)的速度是什么樣、觸發(fā)滾動(dòng)的交互面積在哪里，這是可以撰寫的。
可信息流有標(biāo)準(zhǔn)的規(guī)范和組件，這部分同樣不需要產(chǎn)品經(jīng)理撰寫。
信息流展示邏輯：
這部分包含了信息流的標(biāo)題、摘要展示邏輯、長(zhǎng)度顯示、同時(shí)展示順序的約束。比如為了提升票券的使用率，對(duì)「我的票券」里對(duì)于即將過(guò)期、已經(jīng)過(guò)期、還沒(méi)有過(guò)期的票券展示順序。
可是需求設(shè)計(jì)要求盡可能在第一版本保持簡(jiǎn)單，所以核心是提供我的票券查看能力。而不用撰寫信息流展示順序，把展示的標(biāo)題長(zhǎng)度說(shuō)明清楚就好。
第四部分：小程序的tab
同樣這部分也會(huì)包含交互和邏輯展示2個(gè)部分
交互部分：
是否支持長(zhǎng)按、點(diǎn)擊、輕觸等手勢(shì)操作；tab展示邏輯是否有前置條件，比如有的tab需要用戶一定要登錄注冊(cè)賬戶后才能展示內(nèi)容。
產(chǎn)品經(jīng)理在需求文檔只需要寫出tab點(diǎn)擊跳轉(zhuǎn)的頁(yè)面就行。而上面其他的要么是超出了常規(guī)開(kāi)發(fā)的能力、要么是把需求做復(fù)雜了。
以上就是一個(gè)產(chǎn)品經(jīng)理的需求文檔撰寫方式，你可以看到越是老鳥(niǎo)的產(chǎn)品經(jīng)理越能把握需求的核心功能和邏輯，而去掉將需求變得越來(lái)越復(fù)雜，有版本計(jì)劃的對(duì)需求進(jìn)行擴(kuò)展。同時(shí)知曉固定的組件和交互規(guī)范，減少在交互和動(dòng)畫效果的時(shí)間
01
每天體驗(yàn)1款A(yù)PP社群
02
今日視頻號(hào)分享
03
推薦閱讀