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

[[322772]]

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

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，團隊小伙伴會更合理安排時間。

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