經(jīng)常有產(chǎn)品經(jīng)理和我吐槽，辛辛苦苦做的需求，得到的卻得不到團(tuán)隊(duì)和需求方的認(rèn)同。在和研發(fā)溝通的時(shí)候，差不多就是跪著講的，上線之后需求方還來吐槽，說也預(yù)期還是有一些差距的。

[[322772]]

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

1. 你接到一個(gè)需求的，立刻去想怎么解決這個(gè)問題，想的差不多就開始畫原型，很快就畫好原型拿給領(lǐng)導(dǎo)看，領(lǐng)導(dǎo)劈頭蓋臉的指出一系列的問題。
2. 經(jīng)過幾輪的修改，終于進(jìn)入需求評審階段，在需求評審會議上，方案被研發(fā)、運(yùn)營挑戰(zhàn)，直接在評審會議上開撕，一個(gè)需求評審會議，要進(jìn)行 1-2 個(gè)小時(shí)，最終還要進(jìn)行二次評審。
3. 上線之后，業(yè)務(wù)方反饋說，其實(shí)這個(gè)和他們想要的，還是有一些差距的。你感覺心好累，不被理解。

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

01 需求分析

當(dāng)我們接到需求，不要馬上去想怎么來實(shí)現(xiàn)，先問需求方幾個(gè)問題：

• 這個(gè)需要要解決什么問題
• 解決之后，能給你們帶來什么價(jià)值
• 如果不處理，那會有什么影響?

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

舉個(gè)例子：運(yùn)營同學(xué)說我們的登錄系統(tǒng)不滿足現(xiàn)在需求，希望系統(tǒng)能支持微信登錄。按照上面 3 個(gè)問題，我們來和需求方溝通，需求方說：

“下個(gè)季度我們的重點(diǎn)是做微信粉絲購買轉(zhuǎn)化，但現(xiàn)在賬號系統(tǒng)只支持“郵箱登錄”和“手機(jī)號碼”登錄，幾輪運(yùn)營測試下來，發(fā)現(xiàn)未注冊的粉絲購買轉(zhuǎn)化很低，很大程度上卡在注冊環(huán)節(jié)，不愿意填寫手機(jī)號碼，怕收到騷擾短信。支持微信登錄后，會極大增加粉絲的付費(fèi)轉(zhuǎn)化效果。”

了解到需求方的使用場景“微信體系場景下粉絲快速登錄”，不做會影響轉(zhuǎn)化，是必須要做的事情了。接下來要進(jìn)入第二個(gè)環(huán)節(jié)「手繪線框圖」

02 手繪線框圖

做這件事的目的是整理這個(gè)需求有哪些功能模塊，以及模塊之間的關(guān)聯(lián)，產(chǎn)出物可以是紙上涂鴉。這時(shí)候要做的事情:

1. 是拿上手繪圖，去找研發(fā)負(fù)責(zé)人，討論一下方案的可行性，避免踩不懂技術(shù)的坑。
2. 同時(shí)也讓研發(fā)同學(xué)參與進(jìn)來，知道接下來產(chǎn)品要做什么事情，解決什么問題。

舉個(gè)例子：拿上你畫好的登錄流程手繪圖，和研發(fā)同學(xué)講清楚要解決什么問題，研發(fā)同學(xué)看了之后，說需求問題不大，但你要考慮一下，已經(jīng)注冊過的用戶，用微信登錄后賬號如何關(guān)聯(lián)在一起。

和研發(fā)同學(xué)溝通完畢之后，你再增加了一個(gè)“新老用戶關(guān)聯(lián)”線框圖。

接下來進(jìn)入「產(chǎn)品結(jié)構(gòu)」整理階段。

03 結(jié)構(gòu)圖整理

整理好手繪圖，那我們來進(jìn)一步梳理產(chǎn)品結(jié)構(gòu)。這階段的產(chǎn)出物，是模塊的定義，或者說這個(gè)模塊解決了什么問題。

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

• 新「用戶登錄」，支持微信賬號登錄即注冊。
• 「新老用戶關(guān)聯(lián)」，解決「老用戶」用微信賬號登錄后，與原來賬號綁定或解綁問題;
• 涉及到「修改密碼」模塊優(yōu)化：要關(guān)注只有微信登錄的用戶，是無法修改密碼的;
• 原來賬號系統(tǒng)中，支持手機(jī)驗(yàn)證碼登錄模式有安全漏洞，增加「手機(jī)號碼注冊限流」。

完成了結(jié)構(gòu)圖，就要開始模塊之間的流程整理。

04 流程圖

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

1. 拿著流程圖，找你 leader 講一下，看下流程有沒有問題;如果業(yè)務(wù)比較復(fù)雜，可以和需求方溝通下，看有沒有需求遺漏;
2. 和研發(fā)同學(xué)提前溝通下，讓研發(fā)同學(xué)也了解整個(gè)模塊的流程是什么。

舉個(gè)例子：

05 結(jié)構(gòu)圖細(xì)化

每個(gè)功能模塊，要細(xì)化到字段，避免信息遺漏，前后臺數(shù)據(jù)要保持一致。

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

06 原型交互設(shè)計(jì)

以上 5 步完成之后，那產(chǎn)品 80%的思考已經(jīng)完成。可以根據(jù)團(tuán)隊(duì)習(xí)慣，確定交互的細(xì)致程度，如要求高保真原型，那就把交互做的更完善一些，有交互的地方做好標(biāo)記，有邏輯的地方標(biāo)明規(guī)則。這里不討論如何畫交互原型，如果有需要，可以留言溝通。

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

工具推薦：Axure、墨刀。

07 需求文檔

和需求方溝通之后，就開始寫需求文檔。關(guān)于需求文檔，有的團(tuán)隊(duì)要求寫成doc 文檔，有的只要求在原型處標(biāo)記就好。

我比較傾向于寫成 doc 文檔，因?yàn)樾枨笪臋n是產(chǎn)品產(chǎn)出的再一次檢查和梳理。需求文檔的第一讀者是產(chǎn)品經(jīng)理，然后才是研發(fā)、測試等小伙伴們。

文檔中幾個(gè)關(guān)鍵點(diǎn)要注意:

1. 首先是按模塊寫文檔，要明確每個(gè)模塊的背景和定義，
2. 當(dāng)需求較多(超過 3 個(gè))時(shí)，要標(biāo)注優(yōu)先級(P0、P1、P2)，確保核心功能優(yōu)先處理。
3. 注意不要造名詞，同一個(gè)內(nèi)容前后保持一致。

完成以上，就可以進(jìn)入需求評審階段了。

08 需求評審

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

需求評審也是有流程的：

1. 需求文檔提前 1 天發(fā)給團(tuán)隊(duì)中的小伙伴，讓大家提前了解下需求情況。
2. 正式的需求評審會議上，先講和大家同步，這次需求，我們?yōu)槭裁匆鲞@個(gè)需求，解決了什么問題;更高階一點(diǎn)的可以講此次需求，能給業(yè)務(wù)或團(tuán)隊(duì)帶來了什么價(jià)值。
3. 要先講結(jié)構(gòu)圖和流程圖，這兩個(gè)講解完畢，團(tuán)隊(duì)小伙伴們基本上了解此次需求的重點(diǎn)是什么了，然后著重講一下邏輯判斷。
4. 最后，要有一個(gè)時(shí)間計(jì)劃表，然后團(tuán)隊(duì)小伙伴填寫，確保團(tuán)隊(duì)合作的節(jié)奏，如果有 deadline，團(tuán)隊(duì)小伙伴會更合理安排時(shí)間。

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