不管是你從事了幾年，是B端還是C端的產品經理，需求都非常重要。本文作者將從四個方面，圍繞需求展開分析，希望對你有幫助。

對于哪個階段的產品經理來說，需求都非常重要。

規劃產品功能時，產品經理需要將原本比較抽象的產品需求變得更加具體。將抽象的產品需求具體化也可以分解為四個環節：確定需求、制作流程圖、制作產品原型、編寫需求。與大家分享一個需求提出到編寫需求文檔整個過程我們都需要做什么？

一、需求確定

在需求范圍確定階段，產品經理主要的工作就是與業務方溝通做哪些需求，業務方提需求時，有可能直接說具體實現方案，而沒有說痛點，這就需要我們具有識別需求的能力，挖掘背后痛點。當遇到不合理的需求時，如何勸說對方并讓他欣然接受呢？

1. 確定需求范圍

1）確定需求來源

需求來源分主動需求和被動需求，被動需求由領導、運營、用戶等發起的需求，主動需求主要是由產品團隊理根據團隊目標來規劃的版本需求。當遇到被動需求與主動需求疊加的時候，開發資源緊張，如何來確定優先級呢？

2）確認需求目的

因為開發資源有限，確定優先級要根據需求的目的是什么，當前階段產品重要指標是什么，是數據增長還是優化體驗？比如遇到被動需求與主動需求疊加的情況，開發資源只能滿足一方的需求時，我們需要根據當前的KPI來確定優先級，如果對當前KPI提升效果不明顯，可以將需求調整到后面再考慮。這樣確定需求范圍的更加客觀。

3）需求評估

在評估需求時，若技術方案拿不準，我們需要與技術leader溝通方案的可行性，初步了解需求開發多久，根據開發團隊現有的技術能力是否能夠滿足需求，是否能夠在預期時間內完成等。

2. 如何識別需求的真偽？

產品經理最重要的能力就是對需求的判斷力，如果需求判斷不準備，不但浪費開發資源，對自己也沒有成就感，那如何做到呢，我們要考慮如下幾點：

1）了解需求的背后痛點

有的需求方提需求的時候直接說方案，但有可能不符合產品的設計原則。

比如運營提的需求是需要在頁面中增加一個字段，但是增加一個字段對表結構有改動，影響系統的范圍會比較大，需要考慮歷史數據如何處理等情況。所以我們需要了解為什么要增加字段，是遇到什么樣的問題呢？詳細溝通后可能不用增加字段就可以解決問題。所以需要產品經理了解業務方或用戶真實的痛點，根據我們的專業能力給出合理的產品方案。

2）是否是普遍需求

前面說到需求的來源分被動需求、主動需求，被動需求有可能是某一家商家或兩家提出的，不具有代表性。比如業務方提出一個需求，需要增加一個系統角色，詳細溝通以后只有一個商家提出這樣的需求。

所以當接到一個需求反饋的時候要了解是不是大多數用戶的需求，如果只是少部分有這個需求，需要進一步判斷合理性。所以這時候可以讓數據作為依據，這樣說服業務方也更有信服力。

3）是否符合產品定位

除了要考慮需求是否與目標用戶相關，還需要分析該需求是否與產品定位相符合。比如產品是針對銷售使用的，就要考慮這個人群的特點，不能學習成本太大，操作太復雜。所以如果業務方提的需求違背了這個原則，我們需要從產品定位的角度去說服對方。

3. 如何說服不合理的需求?

需求判斷能力是產品經理能力的體現，難免其他同事提的需求是不合理的，那我們如何來說服對方呢 ？

1）專業度

當對方提一個需求時，需要我們去挖掘背后的原因，其實對方也想尋求你的幫助，如果用你的專業度去和他講這個需求不合理的原因，或者輸出其他解決的方案，對方可能會欣然接受，這樣也體現我們的專業度，讓對方更加信任我們。

2）善于利用數據

如果對方提一個需求我們也判斷不準是否要做，如果能用數據來做依據的，可以利用數據說話，這樣更有信服力，對方也會認為比較合理。

3）讓對方做輸出

若是業務方提的需求，可以讓他們輸出將需求的流程或需求背景以及期望的收益，當他們在寫的時候有可能會查覺需求走不通，有可能自己就說服自己了。

綜合以上，明確了需求范圍，此時將需求的狀態更新為“待排期”，接下來產品經理需要準備需求相關的文檔了。

4. 好用的需求管理工具

給大家分享我們常用的需求管理工具wiki，它是一個團隊協同的文檔管理系統。支持各部門的人將文檔傳到系統中。

1）界面簡單

基礎內容通過文本編輯方式就可以完成，支持上傳圖片，表格等形式。

2）多職能協同

運營以及業務方可以將需求錄入，產品經理看到需求后做整理。在axure中編寫完成后上傳到wiki，技術，測試都可以訪問wiki查看需求。

3）歸檔

目錄清晰，方便歸檔，方便查找之前寫過的方案，也方便新人了解業務。

4）可追蹤歷史

記錄頁面的修訂歷史，頁面的各個版本都可以查看，也可看到文檔的編輯者。

每個公司需求管理工具可能不同，有的用wiki，有的使用teambition,無論使用什么工具，只要清晰管理需求，并且能做好歸檔就可以。

二、制作流程圖

1. 流程圖的作用

• 提高溝通效率：和運營，技術講需求時給大家演示流程圖就一目了然。
• 防止功能點遺漏：方便梳理各功能邏輯，防止對功能點有遺漏。
• 鍛煉邏輯思維：將流程的正向邏輯與逆向邏輯都進行梳理，從而判斷需求的范圍。

2. 流程圖的分類

流程圖分業務流程圖，功能流程圖、活動流程圖，頁面流程等，制作流程圖前確認目的是什么，業務流程圖幫助我們梳理業務架構，主要給領導，業務同事看。任務流程圖幫助我們梳理用戶操作行為，主要給開發，測試同事看，頁面跳轉流程幫助梳理各個頁面之間的跳轉關系，主要在需求中體現。

根據不同的需求來梳理不同的流程。比如要規劃618購物節的活動，從如何創建活動、用戶購買、以及配送等環節通過流程圖先梳理出來，與相關人員溝通確認后，若流程沒有問題，再開始畫原型。

畫流程圖時，可以先畫正向邏輯，再畫逆向邏輯，畫完以后再根據需求來檢查一遍。

3. 用什么工具畫流程圖

只要用得順手就可以。有的小伙伴使用visio，但viso不支持蘋果電腦使用，平時我使用axure畫，這樣原型圖、流程圖都在一個工具上方便使用。

三、制作原型圖

流程圖是需要我們將功能的邏輯關系表達出來，原型圖是要將需求轉化為可視化圖形。

一份完整的產品原型要包含具體的功能，頁面如何布局，具體交易細節。如何看出產品經理畫的原型是否專業呢？

1. 功能點全面

產品原型首先要保證產品功能和內容是完整的，而不是只畫主要流程。比如，注冊登錄頁面，在沒有輸入的情況下，是有文字提示，還是默認灰色，這些都是需要考慮。

2. 頁面統一

頁面的尺寸，按鈕，彈窗、表單等元素也需要統一，而不要每個頁面尺寸不一樣，按鈕大小也不同~

3. 頁面簡潔

制作原型的目的是為了更加形象地表達產品需求，以方便與技術進行需求的評估。不用做視覺圖，只需要線框圖就可以。專業的人做專業的事，視覺圖交給設計就可以啦~

4. 交互內容完整

產品原型是用于表達產品功能和內容的示意圖，因此，產品原型首先要保證產品功能和內容是完整的，要考慮周全，不要有所遺漏。比如，注冊登錄界面，在沒有輸入的情況下，是有文字提示，還是默認灰色，這些都是需要考慮的。

5. 工具使用

畫原型圖的工具除了Axure、還有墨刀、Origami等，個人一直使用axure，根據自己的使用習慣就可以，同時也要考慮團隊其他人在用什么，盡量用一種工具，這樣相互共享文件時方便打開編輯。

四、需求編寫

前面介紹如何確定需求范圍，如何制作流程圖、畫原型。最后如何輸出一份高質量的需求文檔呢？給大家總結有以下幾點：

• 信息全面：需求文檔中包含需求背景、版本說明、流程圖、原型圖、字段說明等描述。除了正常的流程，如無網絡，初始化數據，歷史數據處理等也都要說明清楚、開發過程中不要因需求信息不全面來回確認而耽誤項目進度。
• 格式清晰：寫需求也要站在用戶的角度去考慮，開發、測試看純文字會浪費時間，文檔形式采用原型+文字描述形式，如果需要表格描述盡量用表格。
• 及時更新文檔：在開發過程中難免會有需求更改的情況，及時修改，以免測試時產生歧義。

五、總結

C端產品經理寫需求注重是交互邏輯，B端產品在寫需求時更注重業務邏輯，所以流程圖是必備的。因為大多數需求與字段有關，最好運用表格說明。

B端產品經理也需要了解一些技術基礎，比如接口、數據庫相關的常識。所以還沒有從事產品經理領域或要轉行的，可以根據自己的特點選擇B端產品經理還是C端產品經理。

作者：柿子姐，8年互聯網產品經理；公眾號&視頻號：柿子姐說產品

本文由 @柿子姐 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議