從需求分析到需求評審，筆者總結了需求實現前的八個步驟以及其中的要點，希望對產品經理們有所幫助，避免經常被研發與運營懟。

經常有產品經理和我吐槽，辛辛苦苦做的需求，得到的卻得不到團隊和需求方的認同。在和研發溝通的時候，差不多就是跪著講的，上線之後需求方還來吐槽，說也預期還是有一些差距的。

先描繪一個場景，看看裡面有沒有你的影子：

1. 你接到一個需求的，立刻去想怎麼解決這個問題，想的差不多就開始畫原型，很快就畫好原型拿給領導看，領導劈頭蓋臉的指出一系列的問題。
2. 經過幾輪的修改，終於進入需求評審階段，在需求評審會議上，方案被研發、運營挑戰，直接在評審會議上開撕，一個需求評審會議，要進行 1-2 個小時，最終還要進行二次評審。
3. 上線之後，業務方反饋說，其實這個和他們想要的，還是有一些差距的。你感覺心好累，不被理解。

如果你身上也有類似的事情發生，按照下麵的步驟進行，會極大減少這種場面的發生。

01 需求分析

當我們接到需求，不要馬上去想怎麼來實現，先問需求方幾個問題：

• 這個需要要解決什麼問題
• 解決之後，能給你們帶來什麼價值
• 如果不處理，那會有什麼影響？

問了這幾個問題之後，你大致就清楚這個需求的來龍去脈，以及需求的優先級，如果需求方連這幾個問題都回答不了，那需求可以拒絕了。

舉個例子：運營同學說我們的登錄系統不滿足現在需求，希望系統能支持微信登錄。按照上面 3 個問題，我們來和需求方溝通，需求方說：

“下個季度我們的重點是做微信粉絲購買轉化，但現在賬號系統只支持“郵箱登錄”和“手機號碼”登錄，幾輪運營測試下來，發現未註冊的粉絲購買轉化很低，很大程度上卡在註冊環節，不願意填寫手機號碼，怕收到騷擾短信。支持微信登錄後，會極大增加粉絲的付費轉化效果。”

瞭解到需求方的使用場景“微信體系場景下粉絲快速登錄”，不做會影響轉化，是必須要做的事情了。接下來要進入第二個環節「手繪線框圖」

02 手繪線框圖

做這件事的目的是整理這個需求有哪些功能模塊，以及模塊之間的關聯，產出物可以是紙上塗鴉。這時候要做的事情:

1. 是拿上手繪圖，去找研發負責人，討論一下方案的可行性，避免踩不懂技術的坑。
2. 同時也讓研發同學參與進來，知道接下來產品要做什麼事情，解決什麼問題。

舉個例子：拿上你畫好的登錄流程手繪圖，和研發同學講清楚要解決什麼問題，研發同學看了之後，說需求問題不大，但你要考慮一下，已經註冊過的用戶，用微信登錄後賬號如何關聯在一起。

和研發同學溝通完畢之後，你再增加了一個“新老用戶關聯”線框圖。

接下來進入「產品結構」整理階段。

03 結構圖整理

整理好手繪圖，那我們來進一步梳理產品結構。這階段的產出物，是模塊的定義，或者說這個模塊解決了什麼問題。

舉個例子：上面支持微信登錄的例子，涉及到的功能模塊有：

• 新「用戶登錄」，支持微信賬號登錄即註冊。
• 「新老用戶關聯」，解決「老用戶」用微信賬號登錄後，與原來賬號綁定或解綁問題；
• 涉及到「修改密碼」模塊優化：要關註只有微信登錄的用戶，是無法修改密碼的；
• 原來賬號系統中，支持手機驗證碼登錄模式有安全漏洞，增加「手機號碼註冊限流」。

完成了結構圖，就要開始模塊之間的流程整理。

04 流程圖

目的要定義角色，在核心功能模塊的邏輯規則、分支條件和最終結果。也防止我們遺漏場景。這時候可以做兩件事：

1. 拿著流程圖，找你 leader 講一下，看下流程有沒有問題；如果業務比較複雜，可以和需求方溝通下，看有沒有需求遺漏；
2. 和研發同學提前溝通下，讓研發同學也瞭解整個模塊的流程是什麼。

舉個例子：

05 結構圖細化

每個功能模塊，要細化到字段，避免信息遺漏，前後臺數據要保持一致。

舉個例子：還是上面講的微信登錄場景，用戶第一次用微信方式登錄，要獲取到用戶的 userid、手機號碼，如果手機號碼不存在，那還要生成用戶名（username）。把所有關鍵字段羅列出來，對產品思路重新進行梳理。

06 原型交互設計

以上 5 步完成之後，那產品 80%的思考已經完成。可以根據團隊習慣，確定交互的細緻程度，如要求高保真原型，那就把交互做的更完善一些，有交互的地方做好標記，有邏輯的地方標明規則。這裡不討論如何畫交互原型，如果有需要，可以留言溝通。

完成原型交互設計，拿給你的 leader 看下，組織一次小規模的需求方評審，看看是不是解決了需求方的問題。

工具推薦：Axure、墨刀。

07 需求文檔

和需求方溝通之後，就開始寫需求文檔。關於需求文檔，有的團隊要求寫成doc 文檔，有的只要求在原型處標記就好。

我比較傾向於寫成 doc 文檔，因為需求文檔是產品產出的再一次檢查和梳理。需求文檔的第一讀者是產品經理，然後才是研發、測試等小伙伴們。

文檔中幾個關鍵點要註意:

1. 首先是按模塊寫文檔，要明確每個模塊的背景和定義，
2. 當需求較多（超過 3 個）時，要標註優先級（P0、P1、P2），確保核心功能優先處理。
3. 註意不要造名詞，同一個內容前後保持一致。

完成以上，就可以進入需求評審階段了。

08 需求評審

現在我們要重新認識下「需求評審會」，它不是一個PK 工作量的會議，而是與研發、測試等團隊小伙伴信息同步，宣告這個項目的開始，更多的工作是要前置到評審會議之前。

需求評審也是有流程的：

1. 需求文檔提前 1 天發給團隊中的小伙伴，讓大家提前瞭解下需求情況。
2. 正式的需求評審會議上，先講和大家同步，這次需求，我們為什麼要做這個需求，解決了什麼問題；更高階一點的可以講此次需求，能給業務或團隊帶來了什麼價值。
3. 要先講結構圖和流程圖，這兩個講解完畢，團隊小伙伴們基本上瞭解此次需求的重點是什麼了，然後著重講一下邏輯判斷。
4. 最後，要有一個時間計劃表，然後團隊小伙伴填寫，確保團隊合作的節奏，如果有 deadline，團隊小伙伴會更合理安排時間。

最後：需求評審只是一個宣講，重點都在線下。希望以上能給你帶來一些幫助。

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產品經理專欄作家。8年+互聯網資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業互聯網產品相關的硬核知識點。

本文原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議。