編輯導(dǎo)語(yǔ)：作為一名產(chǎn)品經(jīng)理，撰寫需求文檔是必不可少的。那么要如何去寫一份完整的需求文檔？作者總結(jié)了四個(gè)部分，詳細(xì)介紹了需求文檔的撰寫指南，有興趣的童鞋一起來(lái)看看吧。
對(duì)每位產(chǎn)品經(jīng)理都知道需求文檔是最基礎(chǔ)的基本功，但是要想寫好需求文檔還真不是一件簡(jiǎn)單的事情，那么本篇文章我就向大家來(lái)分享一下這么多年做產(chǎn)品經(jīng)理以及帶產(chǎn)品線新人得出的經(jīng)驗(yàn)，要如何去寫一份完整的需求文檔。
一、需求文檔描述層次
要想寫出好的需求文檔，那我們首先要明白什么樣的文檔才算是一個(gè)好的需求文檔。在我看來(lái)，一份頂級(jí)的需求文檔至少要講清楚三個(gè)層次的問(wèn)題：
- 是否設(shè)計(jì)正確：設(shè)計(jì)的需求是否正確（重要性：60%）；
- 是否設(shè)計(jì)全面：產(chǎn)品模塊與業(yè)務(wù)規(guī)則描述是否全面（重要性：30%）；
- 設(shè)計(jì)是否高效：設(shè)計(jì)的是否有可優(yōu)化點(diǎn)（重要性：10%）。
我們來(lái)一個(gè)一個(gè)講。
第一個(gè)點(diǎn)實(shí)際上就是要求我們?nèi)ピO(shè)計(jì)對(duì)的需求，比如我們需要一個(gè)用戶下單功能，我們以是否完整的講通這個(gè)下單模塊作為依據(jù)，也就是在需求描述的過(guò)程中，我們來(lái)看你所設(shè)計(jì)的方案是否能跑通？開發(fā)是否可以實(shí)現(xiàn)？這樣稱之為需求的設(shè)計(jì)正確。
第二個(gè)點(diǎn)就是要求我們。對(duì)我們所定義的需求，例如下單需求在設(shè)計(jì)的過(guò)程中，不僅要描述主流程還要將與該流程相配合的相關(guān)其他模塊都描述清楚。
例如，下單過(guò)程中涉及的用戶中心，支付中心，風(fēng)控中心都與你的訂單流轉(zhuǎn)有密切的關(guān)系，所以我們都應(yīng)該去描述與之交互的規(guī)則。
第三個(gè)點(diǎn)實(shí)際上是在前兩者的基礎(chǔ)上進(jìn)行一個(gè)升級(jí)，也就是當(dāng)我們能正確的完整的描述一個(gè)需求之后接下來(lái)希望你所描述的需求能是最優(yōu)方案，也就是能給用戶帶來(lái)更好的用戶體驗(yàn)的一種方案。
例如我們下單可以設(shè)計(jì)的很麻煩，也可以在網(wǎng)站上增加一鍵快捷下單的方式那么明顯后者就是優(yōu)化后的設(shè)計(jì)方案。
二、需求文檔公式
前面我們主要給大家談了需求文檔撰寫的，原則以及對(duì)應(yīng)的重要性。接下來(lái)我們要談一談寫需求文檔經(jīng)常會(huì)遇到的一些情況。
需求文檔其實(shí)本身撰寫沒(méi)有什么復(fù)雜性，問(wèn)題在于很多人撰寫需求文檔都寫不完整。這里的寫不完整不是指他沒(méi)有遵循我們上面提到的全面性原則，也就是少了哪對(duì)哪個(gè)模塊的描述。
而是在他描述需求的時(shí)候描述的規(guī)則不完整。要么是缺少對(duì)于某個(gè)環(huán)節(jié)具體的計(jì)算邏輯，要么是缺少對(duì)于頁(yè)面上錯(cuò)誤提示的描述。那么這種問(wèn)題的出現(xiàn)，實(shí)際上就是他對(duì)需求文檔的一個(gè)完整框架沒(méi)有建立一個(gè)認(rèn)知。
我們寫需求文檔除了描述能看到的交互外，更多的要深入系統(tǒng)定義運(yùn)行規(guī)則。因此我們可以用一個(gè)公式來(lái)解讀需求文檔：
需求文檔=系統(tǒng)規(guī)則 界面交互
- 界面交互：指的是原型加對(duì)應(yīng)的交互規(guī)則，常見的如按鈕的交互樣式，錯(cuò)誤提示，字段長(zhǎng)度限制等等。
- 系統(tǒng)規(guī)則描述：指的是一個(gè)系統(tǒng)在各個(gè)節(jié)點(diǎn)運(yùn)作時(shí)信息流處理邏輯。大家都知道計(jì)算機(jī)的本質(zhì)或者說(shuō)軟件系統(tǒng)的本質(zhì)就是一個(gè)信息黑盒。
其實(shí)拆解一下需求，需求的本質(zhì)就是將用戶所輸入的信息在一系列的規(guī)則處理情況下得到了用戶希望想要的信息結(jié)果。
像圖中我們就是將用戶想要計(jì)算的兩個(gè)數(shù)輸入到了一個(gè)系統(tǒng)中，在我們用程序定義的規(guī)則——除法規(guī)則的運(yùn)算處理下，得到了用戶希望的信息輸出也就是商。
所以說(shuō)，需求文檔中最重要的部分其實(shí)就是規(guī)則的描述，一個(gè)規(guī)則描述的完整與否決定了這個(gè)系統(tǒng)是否是用戶所需要。
三、需求文檔組成元素
在前面說(shuō)了這么多之后，我們具體來(lái)看一下一份完整的需求文檔到底有哪些組成部分？我用這樣一張表來(lái)概括需求文檔的完整組成部分。
四、需求評(píng)審評(píng)什么？
除了需求文檔之外，另一個(gè)相信大家都是有一定陰影的就是需求評(píng)審會(huì)?？赡苡袩o(wú)數(shù)同學(xué)在初次上需求評(píng)審會(huì)的時(shí)候。在面對(duì)各個(gè)。評(píng)審方提出的種種質(zhì)疑下，讓自己對(duì)自己的設(shè)計(jì)喪失了信心。
所以我來(lái)為大家解讀一下需求評(píng)審。實(shí)際上，需求評(píng)審本質(zhì)上就是在評(píng)審下邊這三個(gè)東西。
角色1：業(yè)務(wù)方
評(píng)審中關(guān)注方向：是否符合業(yè)務(wù)要求。
角色2：技術(shù)方
評(píng)審中關(guān)注方向：開發(fā)可行性。
角色3：上級(jí)
評(píng)審中關(guān)注方向：投入產(chǎn)出比。
因此只要我們?cè)趯?shí)際評(píng)審和需求設(shè)計(jì)的階段，圍繞這三個(gè)角度去進(jìn)行思考，就能大大避免一會(huì)少了這個(gè)部分邏輯說(shuō)明，一會(huì)少了這個(gè)流程說(shuō)明的局面。
五、最后
作為一個(gè)產(chǎn)品經(jīng)理，我們的工作核心是圍繞產(chǎn)品方案輸出的，不斷的通過(guò)一個(gè)新產(chǎn)品或者產(chǎn)品迭代來(lái)開展自己的持續(xù)性工作。
不管是日常的溝通，還是參加各式的會(huì)議，以及輸出相關(guān)的方案，我們的很多工作都需要通過(guò)一個(gè)核心中介來(lái)產(chǎn)出，這個(gè)核心中介產(chǎn)出就是：PRD。因此請(qǐng)大家練好基本功，這也是產(chǎn)品人最基本的職業(yè)要求了。
#專欄作家#
三爺，微信公眾號(hào)：三爺茶館，人人都是產(chǎn)品經(jīng)理專欄作家，2019年年度作者。《中臺(tái)產(chǎn)品經(jīng)理寶典》作者，原萬(wàn)達(dá)高級(jí)產(chǎn)品、MBA特約講師、獨(dú)立創(chuàng)業(yè)者，現(xiàn)叮咚買菜B端產(chǎn)品線負(fù)責(zé)人，擁有多款集團(tuán)項(xiàng)目從零到一經(jīng)驗(yàn)并帶領(lǐng)實(shí)現(xiàn)商業(yè)化布局。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載
題圖來(lái)自Unsplash，基于CC0協(xié)議
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)，該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲(chǔ)空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請(qǐng)發(fā)送郵件至 舉報(bào)，一經(jīng)查實(shí)，本站將立刻刪除。