雖然能寫一份好的需求文檔并不代表就是一個(gè)好的產(chǎn)品經(jīng)理，也不代表這樣就能成為一個(gè)好的產(chǎn)品經(jīng)理。但是一份好的需求文檔能夠從一定程度上反應(yīng)出你這個(gè)人是否足夠?qū)I(yè)和細(xì)心，考慮是否全面，是否注重細(xì)節(jié)，是否能夠提高整個(gè)團(tuán)隊(duì)的便捷度和效率。

背景介紹

在產(chǎn)品經(jīng)理的日常工作中，接收需求或提需求都是最基礎(chǔ)最常規(guī)的工作內(nèi)容。

大家都知道，需求來(lái)源多種多樣，有來(lái)源于用戶反饋的，有來(lái)源于運(yùn)營(yíng)、推廣、市場(chǎng)、客服等業(yè)務(wù)部門或者直接來(lái)自老板的，也有產(chǎn)品經(jīng)理通過(guò)數(shù)據(jù)分析、用戶調(diào)研、問(wèn)卷調(diào)查、競(jìng)品分析等獲取的需求，當(dāng)然還有一種常見(jiàn)的需求來(lái)源就是產(chǎn)品經(jīng)理自己yy的。

不管需求來(lái)源于哪里，最終需求都是通過(guò)產(chǎn)品經(jīng)理提交給開(kāi)發(fā)或設(shè)計(jì)的。

那么，如何正確地提需求才不會(huì)被噴呢？

這篇文章筆者試著從自己的過(guò)往經(jīng)驗(yàn)出發(fā)，對(duì)這個(gè)問(wèn)題作一個(gè)簡(jiǎn)單的分享。

由于不同團(tuán)隊(duì)的差異性較大，每個(gè)人的能力和風(fēng)格也不同，即使是同一個(gè)團(tuán)隊(duì)內(nèi)部不同的產(chǎn)品經(jīng)理做事方法與風(fēng)格都會(huì)不一樣。筆者無(wú)法得知大家在工作中都是怎樣給開(kāi)發(fā)提需求的。

筆者先后在小公司和大公司都待過(guò)，小公司和大公司的開(kāi)發(fā)模式和風(fēng)格都有接觸和了解。就我個(gè)人的經(jīng)驗(yàn)來(lái)說(shuō)，不是每個(gè)公司和團(tuán)隊(duì)都有規(guī)范的產(chǎn)品開(kāi)發(fā)流程。

• 小公司更加講究高效機(jī)動(dòng)，沒(méi)那么多規(guī)矩和繁瑣流程——怎么方便怎么來(lái)；
• 而大公司一般流程繁瑣，有著一套較為完善的開(kāi)發(fā)流程（但要注意，流程雖完善，但不一定合理）。從產(chǎn)品經(jīng)理接收需求到需求分析與確認(rèn)，再到需求提交和開(kāi)發(fā)測(cè)試需要很長(zhǎng)一段時(shí)間。

我們平時(shí)經(jīng)常會(huì)聽(tīng)到別人問(wèn)一些關(guān)于文檔撰寫的問(wèn)題，比如“你們都是用什么寫PRD的？用什么工具比較好呀？”“請(qǐng)問(wèn)PRD要寫到什么程度呀？”這樣的問(wèn)題在我剛?cè)胄械臅r(shí)候我也喜歡問(wèn)，而且不厭其煩地去找一些模板來(lái)模仿學(xué)習(xí)。

但結(jié)合筆者的兩份工作經(jīng)歷，有一個(gè)比較深的感受——并不是每個(gè)需求都需要產(chǎn)出完整規(guī)范的PRD，甚至大部分需求都不需要。因?yàn)榛ù罅繒r(shí)間去產(chǎn)出一份幾千字甚至上萬(wàn)字的PRD，意義并不是很大，更多情況下我們只需要寫一份簡(jiǎn)化版的需求文檔即可。事實(shí)上的確也是，什么形式什么工具都不重要，重要的是怎么方便在團(tuán)隊(duì)內(nèi)部溝通和查閱，開(kāi)發(fā)并不喜歡看長(zhǎng)篇大論的文檔。

因此，本文不針對(duì)長(zhǎng)篇大論的 PRD 進(jìn)行探討與分析，只針對(duì)工作中的小需求或小項(xiàng)目用得到的簡(jiǎn)化版需求文檔來(lái)作分析。

需求文檔必備要素

一份較為完整的簡(jiǎn)化版需求文檔應(yīng)當(dāng)包含哪些要素呢？根據(jù)筆者的經(jīng)驗(yàn)，有以下幾點(diǎn)供參考：

需求背景或原因

為什么要提這個(gè)需求，基于什么樣的業(yè)務(wù)背景提出來(lái)的。

• 比如用戶到了商詳頁(yè)，但是加入購(gòu)物車的人就是很少，一直上不去，運(yùn)營(yíng)想要優(yōu)化商詳頁(yè)，提升用戶加車的數(shù)量；
• 或者用戶經(jīng)常將商品加入購(gòu)物車，但就是遲遲不肯下單，希望加速用戶下單時(shí)間，提升下單轉(zhuǎn)化率。

目前現(xiàn)狀

問(wèn)題現(xiàn)狀是什么，當(dāng)前是怎么處理的。確認(rèn)是否是這個(gè)原因?qū)е铝诵枨笾刑岬降膯?wèn)題——即確認(rèn)問(wèn)題與原因之間的因果關(guān)聯(lián)性，避免文不對(duì)題。

需求詳情

這個(gè)需求的詳細(xì)內(nèi)容包括哪些。注意一下幾點(diǎn)：

• 建議用總——分的表達(dá)方式，即總體需求是什么，細(xì)分需求點(diǎn)分別是什么（需求點(diǎn)1，需求點(diǎn)2……）；
• 需求是否需要同時(shí)處理前后臺(tái)、需要在哪些端開(kāi)發(fā)（web、wap or app）；
• 需求類型是什么，是新增功能，還是修復(fù)bug，或者用戶體驗(yàn)優(yōu)化，網(wǎng)站性能優(yōu)化等等，具體需要處理哪個(gè)功能模塊或頁(yè)面；
• 需求涉及的場(chǎng)景是什么，用戶會(huì)在什么場(chǎng)景下使用該功能，前置/后置條件是什么；
• 需求是否涉及到產(chǎn)品規(guī)則或者參數(shù)，如果有則要列出來(lái)；
• 建議將開(kāi)發(fā)需求和設(shè)計(jì)需求分開(kāi)來(lái)表達(dá)，不要籠統(tǒng)地放在一個(gè)文檔里。尤其是設(shè)計(jì)需求，單獨(dú)用一個(gè)文檔或表格或頁(yè)面來(lái)表達(dá)（設(shè)計(jì)師會(huì)特別開(kāi)心的）。筆者是用 Axure 寫需求文檔的，我會(huì)單獨(dú)開(kāi)一個(gè)頁(yè)面列出設(shè)計(jì)需求，一遍設(shè)計(jì)師查閱，節(jié)省設(shè)計(jì)師時(shí)間。
• 是否需要跟其他部門對(duì)接合作，期望其他部門什么時(shí)候可以配合，什么時(shí)候可以交付等等。

需求來(lái)源

這個(gè)需求來(lái)源于誰(shuí)，方便有問(wèn)題不清楚時(shí)及時(shí)找到相關(guān)人進(jìn)行溝通確認(rèn)。

需求目標(biāo)

需求方提出需求，產(chǎn)品經(jīng)理提出解決方案，開(kāi)發(fā)按照需求方案進(jìn)行處理后，期望達(dá)到什么樣的目標(biāo)，要用數(shù)據(jù)「量化」。諸如提高用戶付費(fèi)轉(zhuǎn)化、降低用戶退貨率、提高用戶注冊(cè)率…..等諸如此類無(wú)法用數(shù)據(jù)量化的籠統(tǒng)目標(biāo)，都是廢話。要知道，我們做的所有工作，都是為了不斷優(yōu)化用戶體驗(yàn)，提升用戶數(shù)據(jù)，提高下單轉(zhuǎn)化率，提升銷量。

無(wú)法用數(shù)據(jù)衡量的目標(biāo)，都是耍流氓。一定要「數(shù)據(jù)化」和「可視化」，這也是 SMART 原則中可量化衡量原則的體現(xiàn)。

預(yù)定效果

增加的這個(gè)功能最終想要實(shí)現(xiàn)什么樣的效果？這個(gè)一般是交互和視覺(jué)層面的效果。

• 比如一個(gè)按鈕，鼠標(biāo) hover 時(shí)、移開(kāi)時(shí)、點(diǎn)擊時(shí)和點(diǎn)擊后分別是什么樣的效果和前后狀態(tài)變化。
• 比如用戶未付款狀態(tài)顯示「付款」和「取消」按鈕，用戶付款成功收到貨后付款和取消按鈕隱藏，顯示「評(píng)價(jià)」按鈕。而不應(yīng)當(dāng)描述成，增加一個(gè)評(píng)價(jià)按鈕，跟付款和取消按鈕放在一起。

技術(shù)可行性分析

這個(gè)問(wèn)題一般要產(chǎn)品、技術(shù)、設(shè)計(jì)一起進(jìn)行分析。有些時(shí)候想法是美好的，但是以公司目前的技術(shù)實(shí)力，可能還難以做到，或者技術(shù)上投入產(chǎn)出比太低，開(kāi)發(fā)必要性不大，或者是當(dāng)前技術(shù)無(wú)法實(shí)現(xiàn)等各方面的原因，都有可能導(dǎo)致我們的想法落空。這個(gè)時(shí)候一般就只有“等待”——等待時(shí)機(jī)或技術(shù)成熟時(shí)再考慮開(kāi)發(fā)。

需求優(yōu)先級(jí)

產(chǎn)品經(jīng)理的需求池里往往有大量需求，那么如何定義每個(gè)需求的優(yōu)先級(jí)呢，這里有幾個(gè)需求優(yōu)先級(jí)的判定方法供參考：

• KANO模型法：基本型需求>期望型需求>興奮型需求
• 矩陣分析法：重要且緊急>重要不緊急>緊急不重要>不重要也不緊急
• 經(jīng)濟(jì)收益法：經(jīng)濟(jì)收益高且緊迫的功能需求??＞ 經(jīng)濟(jì)收益高但不緊迫的功能需求??＞ 緊迫但經(jīng)濟(jì)收益不高的功能需求??＞ 不緊迫且經(jīng)濟(jì)收益不高的功能需求
• 前/后置需求分析法：前置需求的優(yōu)先級(jí)??＞ 后置需求的優(yōu)先級(jí)；前置需求的重要性和緊迫性??＞ 后置需求的重要性和緊迫性
• 滿足核心用戶需求的優(yōu)先（二八原則）
• 滿足核心業(yè)務(wù)的需求優(yōu)先（資源最大化利用）
• 滿足核心業(yè)務(wù)的投入產(chǎn)出比最大的需求優(yōu)先（ROI最大化）
• 當(dāng)然，有些需求可能難以按照以上方法清晰地排出優(yōu)先順序，那也可以采用另一種方法：P0、P1、P2（優(yōu)先級(jí)依次遞減）

需求排期

這個(gè)需求期望在什么時(shí)間開(kāi)發(fā)完成，什么時(shí)間提測(cè)，以及什么時(shí)間安排上線。如果沒(méi)有按時(shí)上線，下次什么時(shí)間可以上線，或者上線后出現(xiàn)問(wèn)題，補(bǔ)救時(shí)間是什么時(shí)候。

人員分配

前端由誰(shuí)負(fù)責(zé)，后端由誰(shuí)負(fù)責(zé)，設(shè)計(jì)由誰(shuí)負(fù)責(zé)，每個(gè)人多少工時(shí)（在有工時(shí)的公司），這些都要盡量明確到個(gè)人。

下面是我平時(shí)提需求的模板，放在這里供參考。

注意：該模板中提到的數(shù)據(jù)都是虛假數(shù)據(jù)，只作舉例說(shuō)明之用。

下面這張圖是分開(kāi)的設(shè)計(jì)需求表：

總結(jié)

雖然能寫一份好的需求文檔并不代表就是一個(gè)好的產(chǎn)品經(jīng)理，也不代表這樣就能成為一個(gè)好的產(chǎn)品經(jīng)理。但是一份好的需求文檔能夠從一定程度上反應(yīng)出你這個(gè)人是否足夠?qū)I(yè)和細(xì)心，考慮是否全面，是否注重細(xì)節(jié)，是否能夠提高整個(gè)團(tuán)隊(duì)的便捷度和效率。

文檔寫好一點(diǎn)，提需求的姿勢(shì)正確一點(diǎn)，專業(yè)度提高一點(diǎn)，你在團(tuán)隊(duì)里也就顯得更靠譜，不至于每次都被其他人噴。

作者：卿宗偉，產(chǎn)品經(jīng)理。專注探索電商與移動(dòng)社交領(lǐng)域的產(chǎn)品設(shè)計(jì)與用戶體驗(yàn)，分享一個(gè)產(chǎn)品人的野蠻成長(zhǎng)歷程。同名公眾號(hào)：@卿宗偉（ID：HaloThanksBye）

本文由 @卿宗偉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。