雖然能寫一份好的需求文檔并不代表就是一個好的產品經理，也不代表這樣就能成為一個好的產品經理。但是一份好的需求文檔能夠從一定程度上反應出你這個人是否足夠專業和細心，考慮是否全面，是否注重細節，是否能夠提高整個團隊的便捷度和效率。

背景介紹

在產品經理的日常工作中，接收需求或提需求都是最基礎最常規的工作內容。

大家都知道，需求來源多種多樣，有來源于用戶反饋的，有來源于運營、推廣、市場、客服等業務部門或者直接來自老板的，也有產品經理通過數據分析、用戶調研、問卷調查、競品分析等獲取的需求，當然還有一種常見的需求來源就是產品經理自己yy的。

不管需求來源于哪里，最終需求都是通過產品經理提交給開發或設計的。

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

這篇文章筆者試著從自己的過往經驗出發，對這個問題作一個簡單的分享。

由于不同團隊的差異性較大，每個人的能力和風格也不同，即使是同一個團隊內部不同的產品經理做事方法與風格都會不一樣。筆者無法得知大家在工作中都是怎樣給開發提需求的。

筆者先后在小公司和大公司都待過，小公司和大公司的開發模式和風格都有接觸和了解。就我個人的經驗來說，不是每個公司和團隊都有規范的產品開發流程。

• 小公司更加講究高效機動，沒那么多規矩和繁瑣流程——怎么方便怎么來；
• 而大公司一般流程繁瑣，有著一套較為完善的開發流程（但要注意，流程雖完善，但不一定合理）。從產品經理接收需求到需求分析與確認，再到需求提交和開發測試需要很長一段時間。

我們平時經常會聽到別人問一些關于文檔撰寫的問題，比如“你們都是用什么寫PRD的？用什么工具比較好呀？”“請問PRD要寫到什么程度呀？”這樣的問題在我剛入行的時候我也喜歡問，而且不厭其煩地去找一些模板來模仿學習。

但結合筆者的兩份工作經歷，有一個比較深的感受——并不是每個需求都需要產出完整規范的PRD，甚至大部分需求都不需要。因為花大量時間去產出一份幾千字甚至上萬字的PRD，意義并不是很大，更多情況下我們只需要寫一份簡化版的需求文檔即可。事實上的確也是，什么形式什么工具都不重要，重要的是怎么方便在團隊內部溝通和查閱，開發并不喜歡看長篇大論的文檔。

因此，本文不針對長篇大論的 PRD 進行探討與分析，只針對工作中的小需求或小項目用得到的簡化版需求文檔來作分析。

需求文檔必備要素

一份較為完整的簡化版需求文檔應當包含哪些要素呢？根據筆者的經驗，有以下幾點供參考：

需求背景或原因

為什么要提這個需求，基于什么樣的業務背景提出來的。

• 比如用戶到了商詳頁，但是加入購物車的人就是很少，一直上不去，運營想要優化商詳頁，提升用戶加車的數量；
• 或者用戶經常將商品加入購物車，但就是遲遲不肯下單，希望加速用戶下單時間，提升下單轉化率。

目前現狀

問題現狀是什么，當前是怎么處理的。確認是否是這個原因導致了需求中提到的問題——即確認問題與原因之間的因果關聯性，避免文不對題。

需求詳情

這個需求的詳細內容包括哪些。注意一下幾點：

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

需求來源

這個需求來源于誰，方便有問題不清楚時及時找到相關人進行溝通確認。

需求目標

需求方提出需求，產品經理提出解決方案，開發按照需求方案進行處理后，期望達到什么樣的目標，要用數據「量化」。諸如提高用戶付費轉化、降低用戶退貨率、提高用戶注冊率…..等諸如此類無法用數據量化的籠統目標，都是廢話。要知道，我們做的所有工作，都是為了不斷優化用戶體驗，提升用戶數據，提高下單轉化率，提升銷量。

無法用數據衡量的目標，都是耍流氓。一定要「數據化」和「可視化」，這也是 SMART 原則中可量化衡量原則的體現。

預定效果

增加的這個功能最終想要實現什么樣的效果？這個一般是交互和視覺層面的效果。

• 比如一個按鈕，鼠標 hover 時、移開時、點擊時和點擊后分別是什么樣的效果和前后狀態變化。
• 比如用戶未付款狀態顯示「付款」和「取消」按鈕，用戶付款成功收到貨后付款和取消按鈕隱藏，顯示「評價」按鈕。而不應當描述成，增加一個評價按鈕，跟付款和取消按鈕放在一起。

技術可行性分析

這個問題一般要產品、技術、設計一起進行分析。有些時候想法是美好的，但是以公司目前的技術實力，可能還難以做到，或者技術上投入產出比太低，開發必要性不大，或者是當前技術無法實現等各方面的原因，都有可能導致我們的想法落空。這個時候一般就只有“等待”——等待時機或技術成熟時再考慮開發。

需求優先級

產品經理的需求池里往往有大量需求，那么如何定義每個需求的優先級呢，這里有幾個需求優先級的判定方法供參考：

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

需求排期

這個需求期望在什么時間開發完成，什么時間提測，以及什么時間安排上線。如果沒有按時上線，下次什么時間可以上線，或者上線后出現問題，補救時間是什么時候。

人員分配

前端由誰負責，后端由誰負責，設計由誰負責，每個人多少工時（在有工時的公司），這些都要盡量明確到個人。

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

注意：該模板中提到的數據都是虛假數據，只作舉例說明之用。

下面這張圖是分開的設計需求表：

總結

雖然能寫一份好的需求文檔并不代表就是一個好的產品經理，也不代表這樣就能成為一個好的產品經理。但是一份好的需求文檔能夠從一定程度上反應出你這個人是否足夠專業和細心，考慮是否全面，是否注重細節，是否能夠提高整個團隊的便捷度和效率。

文檔寫好一點，提需求的姿勢正確一點，專業度提高一點，你在團隊里也就顯得更靠譜，不至于每次都被其他人噴。

作者：卿宗偉，產品經理。專注探索電商與移動社交領域的產品設計與用戶體驗，分享一個產品人的野蠻成長歷程。同名公眾號：@卿宗偉（ID：HaloThanksBye）

本文由 @卿宗偉 原創發布于人人都是產品經理。未經許可，禁止轉載。