什麼需求算是好需求？

聊過需求，看過需求，也寫過需求，最近在想，什麼樣的需求才算是好需求？

產品經理的一大作用就是「承上啟下」，無論是寫PRD，畫原型，還是去考察行業，搜集、理解競品，都是在重複「收集挖掘->學習理解->轉化輸出」，將自己得到的內容梳理後，以清晰、簡潔又直觀的形式，輔助他人做進一步的工作。其中對需求的描述，就是最常見的「承上啟下」形式。

題圖是舊金山的塗鴉，唐人街有很多，但是這個塗鴉在Fillmore St.和Fulton St.的交口，非常jazz了。

筆者認為，好的需求應該至少有如下特徵：

闡述需求背景

說明需求來源，整理出需求方的原始描述。並依據該描述，能與需求方進一步溝通，來理解該需求的目的，對需求進行粗略分類：

1. 功能補充：是不是產品現在的版本完全沒有應對需求的方式方法？
2. 優化建議：是不是產品包含了該功能，但是用起來不方便？或者只能通過walk around去達到目的？
3. 問題修復：是不是產品提供的功能有bug？
4. 常規變更：是不是上線一段時間後，用戶提出的需求變更？
5. 其他：是不是用戶對項目、產品、甚至公司的不滿，導致的吐槽或情緒發泄？

通過溝通，進一步判斷出需求的級別：

1. 產品級：滿足此需求後，能對產品本身的通用性、易用性等帶來提升，讓產品所在的各個客戶項目受益，或者能為銷售提供有力武器。
2. 項目級：需求不具備行業通用性，也對產品本身沒有本質提升、優化，但對於改善項目中的產品體驗有所幫助。
3. 個人級：個別用戶的單方面意見，不具備項目內通用性，但對緩解用戶情緒有所幫助。

判斷優先順序

對需求有了初步理解之後，要了解客戶對滿足需求的時間期望。同時，應該對需求的「規模」有一定的判斷（可依據前文需求級別、分類），粗略評估工作量，避免低效、被動溝通，並儘可能為處理需求贏得時間。

判斷優先順序，要綜合考慮客戶的時間期望，和需求本身的影響範圍。而定義優先順序可以通過四象限法，說明該需求的重要性和緊急程度。比如，影響SaaS產品全部租戶的重大bug（需求類型：問題修復），即使客戶沒有時間期望，也應該是「重要&緊急」的最高優先順序進行處理。

說明業務場景

對於一個前台模塊/功能，通常都有其完整的業務場景。從對該需求涉及到的用戶入手，描述該用戶對於此需求的業務期望，通過滿足該需求，具體解決了此用戶什麼樣的問題？提升了工作效率？還是完善了其在產品中的體驗完整性？

有了期望，針對該期望去設計並描述業務場景涉及到的流程、邊界、系統影響，並以此去確認自己的理解和設計，是否真正滿足了客戶需要，啟發客戶進一步明確需求。

在說明業務場景的過程中，進一步將該需求進行模塊化、功能化的拆解，把一個場景梳理為一個個步驟。可通過用例圖、流程圖，將業務場景進行描述。

* 推薦工具：Xmind

考慮實現難度

這個見仁見智，畢竟對於產品經理是不是應該懂技術這件事都沒有共識，儘管本人堅決認為產品經理必須要懂點技術。

一個需求，如果其業務場景憑空而來，產品經理無法判斷目前系統是否在技術、數據上可以支持的話，設計地再精妙，也可能落不了地，導致需求在產品經理和研發之間變來變去，最終做出來的也未必能滿足用戶的原始需求了。當然，也不要被現狀所累，不敢去承接需求，不敢去擁抱變化，技術現狀如果不夠好，那麼需求本身就是個去挑戰現狀的機遇，總不能做一隻鴕鳥，把頭埋在土裡視而不見。

如若了解當前系統的實現方式，知道目前數據結構以及結構變動的代價，在描述需求、開展設計的時候就考慮到實現的難度，那麼至少可以去貼近現有的技術方案（或發現現在的不足）、更清晰地描述數據流程。

梳理數據流程

在業務流程圖之上的，是一條業務數據在系統內流轉的完整故事。業務流程可以粗略、直觀，便於與需求方進行溝通、確認，而數據流程則應該細緻、精準，把這一條數據從「出生」到「消亡」，起承轉合，所經歷地增刪改查，乃至對其他業務對象的影響，儘可能完整地梳理、呈現出來。

該過程涉及到對底層系統、數據結構的了解。要清楚理解一個操作對數據的影響，以及數據對後續系統自動化處理的影響，有邏輯，有依據地表達出來。

* 推薦工具：ProcessOn

文檔結構清晰

有的需求文檔看著就頭大，有的文檔看著就舒適——這很可能是因為文檔結構、格式所帶來的直觀感受，完全是寫文檔的態度、對文檔工具利用程度的問題，甚至到不了「文字功底」這個級別。

對於需求文檔：

1. 有清楚的目錄。讓閱讀者清楚了解文檔結構，也能讓撰寫者有一以貫之的思路。
2. 格式、字體統一。並不是全篇都是「正文」，而是依據文檔目錄結構，該正文的時候就是正文，該標題的時候就用標題，對於粘貼來的文本也要將其統一為當前文檔應有的格式。
3. 善用條目。無論是1、2、3、4這樣的編號，還是一個個項目符號（bullets），把觀點逐一列明，提高文檔的可讀性。
4. 少用顏色。除非強調關鍵點，否則盡量避免多種字色混雜，加粗、斜體濫用。
5. 「一圖勝千言」的前提是——圖要畫得好。尤其是流程圖，看過畫了還不如不畫的流程圖，依據這圖做解釋講都講不清楚。流程圖是闡述邏輯的工具，千萬避免形式大於內容，為了畫圖而畫圖，要先有邏輯，再出圖，把流程圖的格式布局調整清晰，對於完善邏輯和思路都有幫助。

避免成為傳話筒

最後想說的是處理需求的態度。作為承上啟下的產品經理，如果不能「對上深挖需求，向下清晰表達」，而僅僅是複述轉達，沒有任何消化理解，這就不是需求好或不好的問題了，而是產品經理對待本職工作的態度問題。

需求說明，是對客戶的責任，對產品的責任，對個人工作的責任，對團隊成員的責任。也許以上每一點都可以做的不夠好，但是至少不要只做一個需求的傳話筒。

自勉，共勉。