南順網絡
如(rú)何正确地(dì)提需求才不會被噴？
雖然能寫一(yī)份好的(de)需求文檔并不代表就是一(yī)個好的(de)産品經理(lǐ)，也不代表這樣就能成為(wèi)一(yī)個好的(de)産品經理(lǐ)。但是一(yī)份好的(de)需求文檔能夠從一(yī)定程度上反應出你這個人是否足夠專業和(hé)細心，考慮是否全面，是否注重細節，是否能夠提高(gāo)整個團隊的(de)便捷度和(hé)效率。
背景介紹
在産品經理(lǐ)的(de)日常工作中，接收需求或提需求都是最基礎最常規的(de)工作內(nèi)容。
大家都知道(dào)，需求來源多種多樣，有來源于用戶反饋的(de)，有來源于運營、推廣、市場、客服等業務部門或者直接來自(zì)老闆的(de)，也有産品經理(lǐ)通過數據分析、用戶調研、問卷調查、競品分析等獲取的(de)需求，當然還有一(yī)種常見的(de)需求來源就是産品經理(lǐ)自(zì)己yy的(de)。
不管需求來源于哪裏，最終需求都是通過産品經理(lǐ)提交給開發或設計的(de)。
那麽，如(rú)何正确地(dì)提需求才不會被噴呢(ne)？
這篇文章(zhāng)筆(bǐ)者試着從自(zì)己的(de)過往經驗出發，對這個問題作一(yī)個簡單的(de)分享。
由于不同團隊的(de)差異性較大，每個人的(de)能力和(hé)風格也不同，即使是同一(yī)個團隊內(nèi)部不同的(de)産品經理(lǐ)做(zuò)事方法與風格都會不一(yī)樣。筆(bǐ)者無法得知大家在工作中都是怎樣給開發提需求的(de)。
筆(bǐ)者先後在小公司和(hé)大公司都待過，小公司和(hé)大公司的(de)開發模式和(hé)風格都有接觸和(hé)了解。就我個人的(de)經驗來說，不是每個公司和(hé)團隊都有規範的(de)産品開發流程。
小公司更加講究高(gāo)效機動，沒那麽多規矩和(hé)繁瑣流程——怎麽方便怎麽來；而大公司一(yī)般流程繁瑣，有着一(yī)套較為(wèi)完善的(de)開發流程（但要注意，流程雖完善，但不一(yī)定合理(lǐ)）。從産品經理(lǐ)接收需求到需求分析與确認，再到需求提交和(hé)開發測試需要很長(cháng)一(yī)段時間。
我們平時經常會聽到别人問一(yī)些關于文檔撰寫的(de)問題，比如(rú)“你們都是用什麽寫PRD的(de)？用什麽工具比較好呀？”“請問PRD要寫到什麽程度呀？”這樣的(de)問題在我剛入行的(de)時候我也喜歡問，而且不厭其煩地(dì)去(qù)找一(yī)些模闆來模仿學(xué)習。
但結合筆(bǐ)者的(de)兩份工作經曆，有一(yī)個比較深的(de)感受——并不是每個需求都需要産出完整規範的(de)PRD，甚至大部分需求都不需要。因為(wèi)花大量時間去(qù)産出一(yī)份幾千字甚至上萬字的(de)PRD，意義并不是很大，更多情況下我們隻需要寫一(yī)份簡化版的(de)需求文檔即可(kě)。事實上的(de)确也是，什麽形式什麽工具都不重要，重要的(de)是怎麽方便在團隊內(nèi)部溝通和(hé)查閱，開發并不喜歡看長(cháng)篇大論的(de)文檔。
因此，本文不針對長(cháng)篇大論的(de) PRD 進行探讨與分析，隻針對工作中的(de)小需求或小項目用得到的(de)簡化版需求文檔來作分析。
需求文檔必備要素
一(yī)份較為(wèi)完整的(de)簡化版需求文檔應當包含哪些要素呢(ne)？根據筆(bǐ)者的(de)經驗，有以下幾點供參考：
需求背景或原因
為(wèi)什麽要提這個需求，基于什麽樣的(de)業務背景提出來的(de)。
比如(rú)用戶到了商詳頁，但是加入購物車的(de)人就是很少，一(yī)直上不去(qù)，運營想要優化商詳頁，提升用戶加車的(de)數量；或者用戶經常将商品加入購物車，但就是遲遲不肯下單，希望加速用戶下單時間，提升下單轉化率。
目前現狀
問題現狀是什麽，當前是怎麽處理(lǐ)的(de)。确認是否是這個原因導緻了需求中提到的(de)問題——即确認問題與原因之間的(de)因果關聯性，避免文不對題。
需求詳情
這個需求的(de)詳細內(nèi)容包括哪些。注意一(yī)下幾點：
建議用總——分的(de)表達方式，即總體需求是什麽，細分需求點分别是什麽（需求點1，需求點2……）；需求是否需要同時處理(lǐ)前後台、需要在哪些端開發（web、wap or app）；需求類型是什麽，是新增功能，還是修複bug，或者用戶體驗優化，網站性能優化等等，具體需要處理(lǐ)哪個功能模塊或頁面；需求涉及的(de)場景是什麽，用戶會在什麽場景下使用該功能，前置/後置條件是什麽；需求是否涉及到産品規則或者參數，如(rú)果有則要列出來；建議将開發需求和(hé)設計需求分開來表達，不要籠統地(dì)放在一(yī)個文檔裏。尤其是設計需求，單獨用一(yī)個文檔或表格或頁面來表達（設計師會特别開心的(de)）。筆(bǐ)者是用 Axure 寫需求文檔的(de)，我會單獨開一(yī)個頁面列出設計需求，一(yī)遍設計師查閱，節省設計師時間。是否需要跟其他部門對接合作，期望其他部門什麽時候可(kě)以配合，什麽時候可(kě)以交付等等。
需求來源
這個需求來源于誰，方便有問題不清楚時及時找到相關人進行溝通确認。
需求目标
需求方提出需求，産品經理(lǐ)提出解決方案，開發按照需求方案進行處理(lǐ)後，期望達到什麽樣的(de)目标，要用數據「量化」。諸如(rú)提高(gāo)用戶付費轉化、降低(dī)用戶退貨率、提高(gāo)用戶注冊率…..等諸如(rú)此類無法用數據量化的(de)籠統目标，都是廢話。要知道(dào)，我們做(zuò)的(de)所有工作，都是為(wèi)了不斷優化用戶體驗，提升用戶數據，提高(gāo)下單轉化率，提升銷量。
無法用數據衡量的(de)目标，都是耍流氓。一(yī)定要「數據化」和(hé)「可(kě)視(shì)化」，這也是 SMART 原則中可(kě)量化衡量原則的(de)體現。
預定效果
增加的(de)這個功能最終想要實現什麽樣的(de)效果？這個一(yī)般是交互和(hé)視(shì)覺層面的(de)效果。
比如(rú)一(yī)個按鈕，鼠标 hover 時、移開時、點擊時和(hé)點擊後分别是什麽樣的(de)效果和(hé)前後狀态變化。比如(rú)用戶未付款狀态顯示「付款」和(hé)「取消」按鈕，用戶付款成功收到貨後付款和(hé)取消按鈕隐藏，顯示「評價」按鈕。而不應當描述成，增加一(yī)個評價按鈕，跟付款和(hé)取消按鈕放在一(yī)起。
技術可(kě)行性分析
這個問題一(yī)般要産品、技術、設計一(yī)起進行分析。有些時候想法是美好的(de)，但是以公司目前的(de)技術實力，可(kě)能還難以做(zuò)到，或者技術上投入産出比太低(dī)，開發必要性不大，或者是當前技術無法實現等各方面的(de)原因，都有可(kě)能導緻我們的(de)想法落空。這個時候一(yī)般就隻有“等待”——等待時機或技術成熟時再考慮開發。
需求優先級
産品經理(lǐ)的(de)需求池裏往往有大量需求，那麽如(rú)何定義每個需求的(de)優先級呢(ne)，這裏有幾個需求優先級的(de)判定方法供參考：
KANO模型法：基本型需求>期望型需求>興奮型需求矩陣分析法：重要且緊急>重要不緊急>緊急不重要>不重要也不緊急經濟收益法：經濟收益高(gāo)且緊迫的(de)功能需求 ＞ 經濟收益高(gāo)但不緊迫的(de)功能需求 ＞ 緊迫但經濟收益不高(gāo)的(de)功能需求 ＞ 不緊迫且經濟收益不高(gāo)的(de)功能需求前/後置需求分析法：前置需求的(de)優先級 ＞ 後置需求的(de)優先級；前置需求的(de)重要性和(hé)緊迫性 ＞ 後置需求的(de)重要性和(hé)緊迫性滿足核心用戶需求的(de)優先（二八原則）滿足核心業務的(de)需求優先（資源最大化利用）滿足核心業務的(de)投入産出比最大的(de)需求優先（ROI最大化）當然，有些需求可(kě)能難以按照以上方法清晰地(dì)排出優先順序，那也可(kě)以采用另一(yī)種方法：P0、P1、P2（優先級依次遞減）
需求排期
這個需求期望在什麽時間開發完成，什麽時間提測，以及什麽時間安排上線。如(rú)果沒有按時上線，下次什麽時間可(kě)以上線，或者上線後出現問題，補救時間是什麽時候。
人員分配
前端由誰負責，後端由誰負責，設計由誰負責，每個人多少工時（在有工時的(de)公司），這些都要盡量明确到個人。
下面是我平時提需求的(de)模闆，放在這裏供參考。
注意：該模闆中提到的(de)數據都是虛假數據，隻作舉例說明之用。
下面這張圖是分開的(de)設計需求表：
總結
雖然能寫一(yī)份好的(de)需求文檔并不代表就是一(yī)個好的(de)産品經理(lǐ)，也不代表這樣就能成為(wèi)一(yī)個好的(de)産品經理(lǐ)。但是一(yī)份好的(de)需求文檔能夠從一(yī)定程度上反應出你這個人是否足夠專業和(hé)細心，考慮是否全面，是否注重細節，是否能夠提高(gāo)整個團隊的(de)便捷度和(hé)效率。
文檔寫好一(yī)點，提需求的(de)姿勢正确一(yī)點，專業度提高(gāo)一(yī)點，你在團隊裏也就顯得更靠譜，不至于每次都被其他人噴。
編輯:--ns868
