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