做業務産品時，如果接到了含糊不清、關鍵信息不全面的需求彙總，你會不會十分頭疼，甚至不知道如何下手？而面對同樣的難題，作者進行了思考，并給出了建議。

long long ago，我還很天真地以為PRD都是産品經理彙總好的業務需求，我再進行下一步的需求分析，理清主次功能、主次流程并轉變為可執行操作的産品界面……

事情并沒有那麼簡單……

交付性的項目産品，産品經理往往是這麼一句話：

“這個産品我們以前有個類似的平台，就做一個類似這樣的平台産品，多了幾個XXXX功能，然後原有的xx流程去掉，有問題再問我”

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

每次有新業務就有新産品設計的我，意識到并不是每個需求方都有能力将需求描述的符合我意。甚至于做産品設計時，每一個平台的行業、功能、業務需求也不一樣，很多設計規範和組件并不能複用。我之前也跟很多做業務向設計的小夥伴讨論過，設計價值在交付性産品中很難被界定，而且設計環節在整個開發流程的夾縫中很難做人。

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

理想狀态：大項目，長周期

可以根據功能叠代排期，合理安排産品開發進度、設計進度。低保真原型還原需求是否合理，高保真原型還原功能表現是否合理，并進行優化體驗。除非是企業級/工具類産品做大版本更新，不然很少會有這種情況出現。

但實際遇到的項目流程是這樣：

常見狀态：大項目，短周期

看到這個流程是不是很懵逼？

這種流程結構，交互在進行産品設計、開發進行底層架構時都很痛苦。交互需要把整體産品的功能用低保真表現出來方便測試和底層架構；然後再根據功能優先級和排期，與産品、視覺一起對核心功能進行再設計和細節功能優化、删減。

近期項目真的是經曆了一場大型砍功能現場：

• 合同裡沒有這個小功能，砍；
• 前端實現不了，砍；
• 底層沒架構，砍；
• 時間來不及了，砍；

項目按照複雜需求設計的功能流程，因為開發周期的緣故砍了很多功能，導緻甲方對最終産品反饋說使用有點複雜。那這時我能有什麼辦法？我也想有用戶體驗，我也想優化功能和改善需求，但基于現實，也隻是我想……

當然還有這樣的流程：

常見狀态：小項目，短周期

這種流程由于項目的産品需求較為簡單，底層框架邏輯可以複用，整體開發流程會壓縮的更短，甚至于會有“交互和視覺”職能雜糅的情況。

根據項目和需求的“成本預算”去進行産品設計、功能設計，不能本着“體驗最優”去考慮整個項目開發。既然不能要求每一個項目的需求方都能輸出較為精準的需求，保證後期設計輸出無誤，不會更改需求和設計增加開發風險。身為“交互狗”隻能盡量精準的進行需求分析，力求需求評估時保證産品設計方向的正确，以下也算是複盤怎麼對接、思考B端業務需求的幾個環節，可以根據不同項目開發的時間成本擇優進行需求分析和功能設計：

也算是怎麼問需求方要需求吧，畢竟需求對接還是要多溝通~

01 明确目标

曾經有個産品經理給我一張原有平台的截圖，在圖上标注上“增删改查”的内容，讓我做一個新的後台管理産品，說實話接到需求的我當時就懵了。我很難一下子明确産品的業務目标、産品目标，甚至是目标用戶，隻是簡單的對接了一下業務流程，就丢出來這麼個需求信息量比較太少。

需求方甚至會覺得做一個後台産品很簡單啊，我們有現成的，我的訴求表達清楚了啊。

确實，對于業務性産品而言，業務是帶來利潤的，産品隻是一個輔助的工具，好不好用不打緊。

但是在執行側下遊的同事并不能完全了解需求方背後的業務邏輯和商業訴求，如果連需求都描述不清楚，來回溝通返工設計的成本太高，需求變更帶來的開發代價也太高。

因此，設計前期，做需求分析前最重要的就是明确“項目背景”的内容：

01 明确項目目标

優先級：★★★★★

首先明确這個項目的大小（産品需求量 項目成本 時間成本），如果是短周期小項目，産品功能不會過于複雜，肯定是優先滿足合同書裡面明确的基礎需求。畢竟開發周期短，有短開發節奏的解決方案，長開發周期有長開發周期的解決方案，部分優化體驗功能在項目中可以适當削弱，滿足常規基礎功能即可。

對于項目整體目标是提升業務效率、提升産品易用性還是滿足招标需要的從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協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部