做業(yè)務(wù)產(chǎn)品時，如果接到了含糊不清、關(guān)鍵信息不全面的需求匯總，你會不會十分頭疼，甚至不知道如何下手？而面對同樣的難題，作者進(jìn)行了思考，并給出了建議。
long long ago，我還很天真地以為PRD都是產(chǎn)品經(jīng)理匯總好的業(yè)務(wù)需求，我再進(jìn)行下一步的需求分析，理清主次功能、主次流程并轉(zhuǎn)變?yōu)榭蓤?zhí)行操作的產(chǎn)品界面……
事情并沒有那么簡單……
交付性的項目產(chǎn)品，產(chǎn)品經(jīng)理往往是這么一句話：
“這個產(chǎn)品我們以前有個類似的平臺，就做一個類似這樣的平臺產(chǎn)品，多了幾個XXXX功能，然后原有的xx流程去掉，有問題再問我”
許多交互/UI在接需求時也會遇到這種情況，是不是感同深受？
每次有新業(yè)務(wù)就有新產(chǎn)品設(shè)計的我，意識到并不是每個需求方都有能力將需求描述的符合我意。甚至于做產(chǎn)品設(shè)計時，每一個平臺的行業(yè)、功能、業(yè)務(wù)需求也不一樣，很多設(shè)計規(guī)范和組件并不能復(fù)用。我之前也跟很多做業(yè)務(wù)向設(shè)計的小伙伴討論過，設(shè)計價值在交付性產(chǎn)品中很難被界定，而且設(shè)計環(huán)節(jié)在整個開發(fā)流程的夾縫中很難做人。
可能我們理想中的開發(fā)流程，如下↓↓↓↓↓
理想狀態(tài)：大項目，長周期
可以根據(jù)功能迭代排期，合理安排產(chǎn)品開發(fā)進(jìn)度、設(shè)計進(jìn)度。低保真原型還原需求是否合理，高保真原型還原功能表現(xiàn)是否合理，并進(jìn)行優(yōu)化體驗。除非是企業(yè)級/工具類產(chǎn)品做大版本更新，不然很少會有這種情況出現(xiàn)。
但實(shí)際遇到的項目流程是這樣：
常見狀態(tài)：大項目，短周期
看到這個流程是不是很懵逼？
這種流程結(jié)構(gòu)，交互在進(jìn)行產(chǎn)品設(shè)計、開發(fā)進(jìn)行底層架構(gòu)時都很痛苦。交互需要把整體產(chǎn)品的功能用低保真表現(xiàn)出來方便測試和底層架構(gòu)；然后再根據(jù)功能優(yōu)先級和排期，與產(chǎn)品、視覺一起對核心功能進(jìn)行再設(shè)計和細(xì)節(jié)功能優(yōu)化、刪減。
近期項目真的是經(jīng)歷了一場大型砍功能現(xiàn)場：
合同里沒有這個小功能，砍；
前端實(shí)現(xiàn)不了，砍；
底層沒架構(gòu)，砍；
時間來不及了，砍；
項目按照復(fù)雜需求設(shè)計的功能流程，因為開發(fā)周期的緣故砍了很多功能，導(dǎo)致甲方對最終產(chǎn)品反饋說使用有點(diǎn)復(fù)雜。那這時我能有什么辦法？我也想有用戶體驗，我也想優(yōu)化功能和改善需求，但基于現(xiàn)實(shí)，也只是我想……
當(dāng)然還有這樣的流程：
常見狀態(tài)：小項目，短周期
這種流程由于項目的產(chǎn)品需求較為簡單，底層框架邏輯可以復(fù)用，整體開發(fā)流程會壓縮的更短，甚至于會有“交互和視覺”職能雜糅的情況。
根據(jù)項目和需求的“成本預(yù)算”去進(jìn)行產(chǎn)品設(shè)計、功能設(shè)計，不能本著“體驗最優(yōu)”去考慮整個項目開發(fā)。既然不能要求每一個項目的需求方都能輸出較為精準(zhǔn)的需求，保證后期設(shè)計輸出無誤，不會更改需求和設(shè)計增加開發(fā)風(fēng)險。身為“交互狗”只能盡量精準(zhǔn)的進(jìn)行需求分析，力求需求評估時保證產(chǎn)品設(shè)計方向的正確，以下也算是復(fù)盤怎么對接、思考B端業(yè)務(wù)需求的幾個環(huán)節(jié)，可以根據(jù)不同項目開發(fā)的時間成本擇優(yōu)進(jìn)行需求分析和功能設(shè)計：
也算是怎么問需求方要需求吧，畢竟需求對接還是要多溝通~
曾經(jīng)有個產(chǎn)品經(jīng)理給我一張原有平臺的截圖，在圖上標(biāo)注上“增刪改查”的內(nèi)容，讓我做一個新的后臺管理產(chǎn)品，說實(shí)話接到需求的我當(dāng)時就懵了。我很難一下子明確產(chǎn)品的業(yè)務(wù)目標(biāo)、產(chǎn)品目標(biāo)，甚至是目標(biāo)用戶，只是簡單的對接了一下業(yè)務(wù)流程，就丟出來這么個需求信息量比較太少。
需求方甚至?xí)X得做一個后臺產(chǎn)品很簡單啊，我們有現(xiàn)成的，我的訴求表達(dá)清楚了啊。
確實(shí)，對于業(yè)務(wù)性產(chǎn)品而言，業(yè)務(wù)是帶來利潤的，產(chǎn)品只是一個輔助的工具，好不好用不打緊。
但是在執(zhí)行側(cè)下游的同事并不能完全了解需求方背后的業(yè)務(wù)邏輯和商業(yè)訴求，如果連需求都描述不清楚，來回溝通返工設(shè)計的成本太高，需求變更帶來的開發(fā)代價也太高。
因此，設(shè)計前期，做需求分析前最重要的就是明確“項目背景”的內(nèi)容：
優(yōu)先級：★★★★★
首先明確這個項目的大小（產(chǎn)品需求量+項目成本+時間成本），如果是短周期小項目，產(chǎn)品功能不會過于復(fù)雜，肯定是優(yōu)先滿足合同書里面明確的基礎(chǔ)需求。畢竟開發(fā)周期短，有短開發(fā)節(jié)奏的解決方案，長開發(fā)周期有長開發(fā)周期的解決方案，部分優(yōu)化體驗功能在項目中可以適當(dāng)削弱，滿足常規(guī)基礎(chǔ)功能即可。
對于項目整體目標(biāo)是提升業(yè)務(wù)效率、提升產(chǎn)品易用性還是滿足招標(biāo)需要的從0→1……一定要始終謹(jǐn)記項目目標(biāo)，這可是影響整個產(chǎn)品的“首要綱領(lǐng)”。
優(yōu)先級：★★★★
在對接快速需求時，由于不同的業(yè)務(wù)、項目、產(chǎn)品經(jīng)理，大家很容易忽略這個平臺使用者與業(yè)務(wù)流程之間的關(guān)系（即業(yè)務(wù)流程），以及相關(guān)的載體表現(xiàn)（APP還是web）和傳遞過程（如信息流、數(shù)據(jù)流、資金流、權(quán)限功能）與業(yè)務(wù)之間的關(guān)系，這其實(shí)會影響到主次功能的流程邏輯是否符合目標(biāo)用戶的心智模型（目標(biāo)用戶的業(yè)務(wù)邏輯關(guān)系會映射到使用產(chǎn)品時對功能邏輯的預(yù)期）。
優(yōu)先級：★★★
需要設(shè)計的功能平臺較多時，肯定需要后臺類產(chǎn)品管理功能、引擎、數(shù)據(jù)等，針對不同的項目平臺需要積累對應(yīng)的設(shè)計規(guī)范和組件來提升效率，許多功能雖然業(yè)務(wù)不同但也有基礎(chǔ)的共性操作。
例如后臺管理類“增刪改查”“審核狀態(tài)”等都有類似的異常情況可以通用，確定技術(shù)范疇也會影響功能提出后，該項目的開發(fā)人員能否實(shí)現(xiàn)。
優(yōu)先級：★★★
設(shè)計環(huán)節(jié)在整個立項周期中，屬于壓縮時間周期最短的一環(huán)，在既定時間完成功能需求，要根據(jù)整個團(tuán)隊的能力評估當(dāng)前的解決方案是否是最優(yōu)方案，因此在時間范圍內(nèi)盡可能提出多個方案供團(tuán)隊評估。
優(yōu)先級：★★★
為什么要在這里把“甲方”列舉出來呢？
在既定時間內(nèi)甲方會根據(jù)原型提出功能是否合理，可能會導(dǎo)致功能原型返工，耽誤后面開發(fā)流程進(jìn)度的情況。因此，在分析團(tuán)隊情況后，決定是否滿足甲方提出來的非合同標(biāo)注的需求時，需要打個大大的感嘆號，會增加團(tuán)隊的開發(fā)成本！至于需求滿不滿足還是要跟產(chǎn)品、項目、技術(shù)討論之后決定。
理清以上的內(nèi)容，基本就能清楚項目的業(yè)務(wù)邏輯如何影響產(chǎn)品功能，可以進(jìn)行下一步需求分析了 。
為什么在上一part我沒講“產(chǎn)品定義”？
能夠一兩句話講清楚這個產(chǎn)品是在干什么，對于2B產(chǎn)品而言，很多都是滿足業(yè)務(wù)目標(biāo)的產(chǎn)品目標(biāo)解釋，有時不太能明確知道產(chǎn)品的主次功能，明確的大都是業(yè)務(wù)的解決方案和利益相關(guān)者的描述。
因此具體的需求分析通過以下幾個模塊來明確???
（大家也可根據(jù)自己業(yè)務(wù)需求自行補(bǔ)充）
具體到需求分析，首先要明確需求?功能?界面之間的關(guān)系：
可能是業(yè)務(wù)流程有問題，可能是用戶有某些痛點(diǎn)沒有得到解決，也可能是當(dāng)前數(shù)據(jù)反饋出來這個功能不合理……這些才是我們需要解決的“痛點(diǎn)”（即需求）。所以在還原需求時我們可以借用“問題描述”來拆解需求到底該怎么表達(dá)，以及我們要做一個什么“功能”來解決這個“需求”；
問題描述：__（誰）__在__（時間、地點(diǎn)、情景）__，遇到__問題；
功能描述：要為__（誰）__做一個__功能，從而實(shí)現(xiàn)__指標(biāo)提升；
我們都知道在做功能時要還原“需求”的來源，即場景/業(yè)務(wù)還有目標(biāo)人群。
拿我之前做的轉(zhuǎn)寫功能來講，市面上具有轉(zhuǎn)寫類功能的產(chǎn)品，多為筆記類產(chǎn)品，能夠滿足日常辦公/備忘錄筆記即可，做的比較好的產(chǎn)品可以“轉(zhuǎn)寫+翻譯”功能同時實(shí)現(xiàn)。
但我們項目里基于功能分層以及商業(yè)模式考慮，需要分開處理，因此“轉(zhuǎn)寫”為一個大功能（包含3個小功能），“翻譯”為一個大功能（包含2個小功能），這就是同樣的“功能”由于“需求”還原不同，帶來具體解決方案不同的做法。
同一個“功能”對應(yīng)的“產(chǎn)品目標(biāo)”不同，帶來的解決方案也不同。而競品分析除了可以理出“功能”具體在界面的信息架構(gòu)和層級關(guān)系的展示方式、信息層級和小功能點(diǎn)有哪些外，還可以分析“功能”帶來的用戶操作行為與功能目標(biāo)，拆分功能與產(chǎn)品結(jié)構(gòu)之間的關(guān)系就能知曉這是針對什么“需求”的解決方案，參考產(chǎn)品的定位和發(fā)布公司，也能大概了解其背后的競爭格局、推廣策略等。
交付類產(chǎn)品一般不太會進(jìn)行產(chǎn)品差異化分析，這需要對行業(yè)、市場、人群有精準(zhǔn)的定位和細(xì)致的區(qū)分。牽扯到to B一定會有大的業(yè)務(wù)變動和商業(yè)模式的變化，產(chǎn)品/項目的目標(biāo)才會發(fā)生差異化的變更，這時一般都是我們認(rèn)為需要進(jìn)行改版來滿足這個“大目標(biāo)”的時候。一般交付性產(chǎn)品到2.0的需求分析就已經(jīng)足矣，可以出具較為符合業(yè)務(wù)需求的產(chǎn)品功能并提供解決方案（產(chǎn)品原型）了。
由于在我經(jīng)驗范圍內(nèi)，經(jīng)手的這些交付性項目需求分析基本也就到2.0左右，所以有補(bǔ)充的內(nèi)容也可以根據(jù)自身的業(yè)務(wù)情況/需要進(jìn)行更加細(xì)致的補(bǔ)充。
聯(lián)系客服
