業(yè)務(wù)項(xiàng)產(chǎn)品，業(yè)務(wù)如何做需求分析？項(xiàng)產(chǎn)析設(shè)（設(shè)計(jì)前期這樣做）

做業(yè)務(wù)產(chǎn)品時(shí)，如果接到了含糊不清、品何關(guān)鍵信息不全面的做需需求匯總，你會(huì)不會(huì)十分頭疼，求分期樣甚至不知道如何下手？計(jì)前而面對(duì)同樣的難題，作者進(jìn)行了思考，業(yè)務(wù)并給出了建議。項(xiàng)產(chǎn)析設(shè)

long long ago，品何我還很天真地以為PRD都是做需產(chǎn)品經(jīng)理匯總好的業(yè)務(wù)需求，我再進(jìn)行下一步的求分期樣需求分析，理清主次功能、計(jì)前主次流程并轉(zhuǎn)變?yōu)榭蓤?zhí)行操作的業(yè)務(wù)產(chǎn)品界面……

事情并沒有那么簡單……

交付性的項(xiàng)目產(chǎn)品，產(chǎn)品經(jīng)理往往是項(xiàng)產(chǎn)析設(shè)這么一句話：

“這個(gè)產(chǎn)品我們以前有個(gè)類似的平臺(tái)，就做一個(gè)類似這樣的品何平臺(tái)產(chǎn)品，多了幾個(gè)XXXX功能，然后原有的xx流程去掉，有問題再問我”

許多交互/UI在接需求時(shí)也會(huì)遇到這種情況，是不是感同深受？

每次有新業(yè)務(wù)就有新產(chǎn)品設(shè)計(jì)的我，意識(shí)到并不是每個(gè)需求方都有能力將需求描述的符合我意。甚至于做產(chǎn)品設(shè)計(jì)時(shí)，每一個(gè)平臺(tái)的行業(yè)、功能、業(yè)務(wù)需求也不一樣，很多設(shè)計(jì)規(guī)范和組件并不能復(fù)用。我之前也跟很多做業(yè)務(wù)向設(shè)計(jì)的小伙伴討論過，設(shè)計(jì)價(jià)值在交付性產(chǎn)品中很難被界定，而且設(shè)計(jì)環(huán)節(jié)在整個(gè)開發(fā)流程的夾縫中很難做人。

可能我們理想中的開發(fā)流程，如下↓↓↓↓↓

理想狀態(tài)：大項(xiàng)目，長周期

可以根據(jù)功能迭代排期，合理安排產(chǎn)品開發(fā)進(jìn)度、設(shè)計(jì)進(jìn)度。低保真原型還原需求是否合理，高保真原型還原功能表現(xiàn)是否合理，并進(jìn)行優(yōu)化體驗(yàn)。除非是企業(yè)級(jí)/工具類產(chǎn)品做大版本更新，不然很少會(huì)有這種情況出現(xiàn)。

但實(shí)際遇到的項(xiàng)目流程是這樣：

常見狀態(tài)：大項(xiàng)目，短周期

看到這個(gè)流程是不是很懵逼？

這種流程結(jié)構(gòu)，交互在進(jìn)行產(chǎn)品設(shè)計(jì)、開發(fā)進(jìn)行底層架構(gòu)時(shí)都很痛苦。交互需要把整體產(chǎn)品的功能用低保真表現(xiàn)出來方便測(cè)試和底層架構(gòu)；然后再根據(jù)功能優(yōu)先級(jí)和排期，與產(chǎn)品、視覺一起對(duì)核心功能進(jìn)行再設(shè)計(jì)和細(xì)節(jié)功能優(yōu)化、刪減。

近期項(xiàng)目真的是經(jīng)歷了一場大型砍功能現(xiàn)場：

合同里沒有這個(gè)小功能，砍；前端實(shí)現(xiàn)不了，砍；底層沒架構(gòu)，砍；時(shí)間來不及了，砍；

項(xiàng)目按照復(fù)雜需求設(shè)計(jì)的功能流程，因?yàn)殚_發(fā)周期的緣故砍了很多功能，導(dǎo)致甲方對(duì)最終產(chǎn)品反饋說使用有點(diǎn)復(fù)雜。那這時(shí)我能有什么辦法？我也想有用戶體驗(yàn)，我也想優(yōu)化功能和改善需求，但基于現(xiàn)實(shí)，也只是我想……

當(dāng)然還有這樣的流程：

常見狀態(tài)：小項(xiàng)目，短周期

這種流程由于項(xiàng)目的產(chǎn)品需求較為簡單，底層框架邏輯可以復(fù)用，整體開發(fā)流程會(huì)壓縮的更短，甚至于會(huì)有“交互和視覺”職能雜糅的情況。

根據(jù)項(xiàng)目和需求的“成本預(yù)算”去進(jìn)行產(chǎn)品設(shè)計(jì)、功能設(shè)計(jì)，不能本著“體驗(yàn)最優(yōu)”去考慮整個(gè)項(xiàng)目開發(fā)。既然不能要求每一個(gè)項(xiàng)目的需求方都能輸出較為精準(zhǔn)的需求，保證后期設(shè)計(jì)輸出無誤，不會(huì)更改需求和設(shè)計(jì)增加開發(fā)風(fēng)險(xiǎn)。身為“交互狗”只能盡量精準(zhǔn)的進(jìn)行需求分析，力求需求評(píng)估時(shí)保證產(chǎn)品設(shè)計(jì)方向的正確，以下也算是復(fù)盤怎么對(duì)接、思考B端業(yè)務(wù)需求的幾個(gè)環(huán)節(jié)，可以根據(jù)不同項(xiàng)目開發(fā)的時(shí)間成本擇優(yōu)進(jìn)行需求分析和功能設(shè)計(jì)：

也算是怎么問需求方要需求吧，畢竟需求對(duì)接還是要多溝通~

01 明確目標(biāo)

曾經(jīng)有個(gè)產(chǎn)品經(jīng)理給我一張?jiān)衅脚_(tái)的截圖，在圖上標(biāo)注上“增刪改查”的內(nèi)容，讓我做一個(gè)新的后臺(tái)管理產(chǎn)品，說實(shí)話接到需求的我當(dāng)時(shí)就懵了。我很難一下子明確產(chǎn)品的業(yè)務(wù)目標(biāo)、產(chǎn)品目標(biāo)，甚至是目標(biāo)用戶，只是簡單的對(duì)接了一下業(yè)務(wù)流程，就丟出來這么個(gè)需求信息量比較太少。

需求方甚至?xí)X得做一個(gè)后臺(tái)產(chǎn)品很簡單啊，我們有現(xiàn)成的，我的訴求表達(dá)清楚了啊。

確實(shí)，對(duì)于業(yè)務(wù)性產(chǎn)品而言，業(yè)務(wù)是帶來利潤的，產(chǎn)品只是一個(gè)輔助的工具，好不好用不打緊。

但是在執(zhí)行側(cè)下游的同事并不能完全了解需求方背后的業(yè)務(wù)邏輯和商業(yè)訴求，如果連需求都描述不清楚，來回溝通返工設(shè)計(jì)的成本太高，需求變更帶來的開發(fā)代價(jià)也太高。

因此，設(shè)計(jì)前期，做需求分析前最重要的就是明確“項(xiàng)目背景”的內(nèi)容：

01 明確項(xiàng)目目標(biāo)

優(yōu)先級(jí)：★★★★★

首先明確這個(gè)項(xiàng)目的大?。óa(chǎn)品需求量+項(xiàng)目成本+時(shí)間成本），如果是短周期小項(xiàng)目，產(chǎn)品功能不會(huì)過于復(fù)雜，肯定是優(yōu)先滿足合同書里面明確的基礎(chǔ)需求。畢竟開發(fā)周期短，有短開發(fā)節(jié)奏的解決方案，長開發(fā)周期有長開發(fā)周期的解決方案，部分優(yōu)化體驗(yàn)功能在項(xiàng)目中可以適當(dāng)削弱，滿足常規(guī)基礎(chǔ)功能即可。

對(duì)于項(xiàng)目整體目標(biāo)是提升業(yè)務(wù)效率、提升產(chǎn)品易用性還是滿足招標(biāo)需要的從0→1……一定要始終謹(jǐn)記項(xiàng)目目標(biāo)，這可是影響整個(gè)產(chǎn)品的“首要綱領(lǐng)”。

02 目標(biāo)用戶與業(yè)務(wù)之間的利益關(guān)系

優(yōu)先級(jí)：★★★★

在對(duì)接快速需求時(shí)，由于不同的業(yè)務(wù)、項(xiàng)目、產(chǎn)品經(jīng)理，大家很容易忽略這個(gè)平臺(tái)使用者與業(yè)務(wù)流程之間的關(guān)系（即業(yè)務(wù)流程），以及相關(guān)的載體表現(xiàn)（APP還是web）和傳遞過程（如信息流、數(shù)據(jù)流、資金流、權(quán)限功能）與業(yè)務(wù)之間的關(guān)系，這其實(shí)會(huì)影響到主次功能的流程邏輯是否符合目標(biāo)用戶的心智模型（目標(biāo)用戶的業(yè)務(wù)邏輯關(guān)系會(huì)映射到使用產(chǎn)品時(shí)對(duì)功能邏輯的預(yù)期）。

03 確定項(xiàng)目涉及的平臺(tái)和技術(shù)范疇

優(yōu)先級(jí)：★★★

需要設(shè)計(jì)的功能平臺(tái)較多時(shí)，肯定需要后臺(tái)類產(chǎn)品管理功能、引擎、數(shù)據(jù)等，針對(duì)不同的項(xiàng)目平臺(tái)需要積累對(duì)應(yīng)的設(shè)計(jì)規(guī)范和組件來提升效率，許多功能雖然業(yè)務(wù)不同但也有基礎(chǔ)的共性操作。

例如后臺(tái)管理類“增刪改查”“審核狀態(tài)”等都有類似的異常情況可以通用，確定技術(shù)范疇也會(huì)影響功能提出后，該項(xiàng)目的開發(fā)人員能否實(shí)現(xiàn)。

04 按照時(shí)間節(jié)點(diǎn)來進(jìn)行把控

優(yōu)先級(jí)：★★★

設(shè)計(jì)環(huán)節(jié)在整個(gè)立項(xiàng)周期中，屬于壓縮時(shí)間周期最短的一環(huán)，在既定時(shí)間完成功能需求，要根據(jù)整個(gè)團(tuán)隊(duì)的能力評(píng)估當(dāng)前的解決方案是否是最優(yōu)方案，因此在時(shí)間范圍內(nèi)盡可能提出多個(gè)方案供團(tuán)隊(duì)評(píng)估。

05 甲方

優(yōu)先級(jí)：★★★

為什么要在這里把“甲方”列舉出來呢？

在既定時(shí)間內(nèi)甲方會(huì)根據(jù)原型提出功能是否合理，可能會(huì)導(dǎo)致功能原型返工，耽誤后面開發(fā)流程進(jìn)度的情況。因此，在分析團(tuán)隊(duì)情況后，決定是否滿足甲方提出來的非合同標(biāo)注的需求時(shí)，需要打個(gè)大大的感嘆號(hào)，會(huì)增加團(tuán)隊(duì)的開發(fā)成本！至于需求滿不滿足還是要跟產(chǎn)品、項(xiàng)目、技術(shù)討論之后決定。

理清以上的內(nèi)容，基本就能清楚項(xiàng)目的業(yè)務(wù)邏輯如何影響產(chǎn)品功能，可以進(jìn)行下一步需求分析了 。

02 理清功能

為什么在上一part我沒講“產(chǎn)品定義”？

能夠一兩句話講清楚這個(gè)產(chǎn)品是在干什么，對(duì)于2B產(chǎn)品而言，很多都是滿足業(yè)務(wù)目標(biāo)的產(chǎn)品目標(biāo)解釋，有時(shí)不太能明確知道產(chǎn)品的主次功能，明確的大都是業(yè)務(wù)的解決方案和利益相關(guān)者的描述。

因此具體的需求分析通過以下幾個(gè)模塊來明確???

（大家也可根據(jù)自己業(yè)務(wù)需求自行補(bǔ)充）

具體到需求分析，首先要明確需求?功能?界面之間的關(guān)系：

01 首先要明確產(chǎn)品的需求是怎么來的？

可能是業(yè)務(wù)流程有問題，可能是用戶有某些痛點(diǎn)沒有得到解決，也可能是當(dāng)前數(shù)據(jù)反饋出來這個(gè)功能不合理……這些才是我們需要解決的“痛點(diǎn)”（即需求）。所以在還原需求時(shí)我們可以借用“問題描述”來拆解需求到底該怎么表達(dá)，以及我們要做一個(gè)什么“功能”來解決這個(gè)“需求”；

問題描述：__（誰）__在__（時(shí)間、地點(diǎn)、情景）__，遇到__問題；功能描述：要為__（誰）__做一個(gè)__功能，從而實(shí)現(xiàn)__指標(biāo)提升；

02 同樣的功能，解決的“需求”并不一樣

我們都知道在做功能時(shí)要還原“需求”的來源，即場景/業(yè)務(wù)還有目標(biāo)人群。

拿我之前做的轉(zhuǎn)寫功能來講，市面上具有轉(zhuǎn)寫類功能的產(chǎn)品，多為筆記類產(chǎn)品，能夠滿足日常辦公/備忘錄筆記即可，做的比較好的產(chǎn)品可以“轉(zhuǎn)寫+翻譯”功能同時(shí)實(shí)現(xiàn)。

但我們項(xiàng)目里基于功能分層以及商業(yè)模式考慮，需要分開處理，因此“轉(zhuǎn)寫”為一個(gè)大功能（包含3個(gè)小功能），“翻譯”為一個(gè)大功能（包含2個(gè)小功能），這就是同樣的“功能”由于“需求”還原不同，帶來具體解決方案不同的做法。

03 競品分析會(huì)告訴你這類“需求”怎么解決

同一個(gè)“功能”對(duì)應(yīng)的“產(chǎn)品目標(biāo)”不同，帶來的解決方案也不同。而競品分析除了可以理出“功能”具體在界面的信息架構(gòu)和層級(jí)關(guān)系的展示方式、信息層級(jí)和小功能點(diǎn)有哪些外，還可以分析“功能”帶來的用戶操作行為與功能目標(biāo)，拆分功能與產(chǎn)品結(jié)構(gòu)之間的關(guān)系就能知曉這是針對(duì)什么“需求”的解決方案，參考產(chǎn)品的定位和發(fā)布公司，也能大概了解其背后的競爭格局、推廣策略等。

03 產(chǎn)品差異化

交付類產(chǎn)品一般不太會(huì)進(jìn)行產(chǎn)品差異化分析，這需要對(duì)行業(yè)、市場、人群有精準(zhǔn)的定位和細(xì)致的區(qū)分。牽扯到to B一定會(huì)有大的業(yè)務(wù)變動(dòng)和商業(yè)模式的變化，產(chǎn)品/項(xiàng)目的目標(biāo)才會(huì)發(fā)生差異化的變更，這時(shí)一般都是我們認(rèn)為需要進(jìn)行改版來滿足這個(gè)“大目標(biāo)”的時(shí)候。一般交付性產(chǎn)品到2.0的需求分析就已經(jīng)足矣，可以出具較為符合業(yè)務(wù)需求的產(chǎn)品功能并提供解決方案（產(chǎn)品原型）了。

由于在我經(jīng)驗(yàn)范圍內(nèi)，經(jīng)手的這些交付性項(xiàng)目需求分析基本也就到2.0左右，所以有補(bǔ)充的內(nèi)容也可以根據(jù)自身的業(yè)務(wù)情況/需要進(jìn)行更加細(xì)致的補(bǔ)充。