大廠方法論+案例:從0到1輕松拆解產品需求,對程序員的質疑說不
產品需求是如何落地到原型設計的?本文將結合案例和大廠產品經理常用的方法論,通俗化講解如何系統拆解產品需求,希望對你有所收獲。
一、產品經理設計思路是什么樣
面臨新業務線拓展或者產品升級的時候,在收集到一大堆亂七八糟的需求后,你可能會想,我要怎么著手呢?答案是,搭框架找思路。
這是一個產品經理通用的設計思路框架,遵循由粗到細、自上而下的流程,具體如下:
- 戰略層—–業務目標是什么,即定方向,含用戶、使用終端、市場競爭力和解決方案、項目計劃;想清楚做什么,即把具備價值的需求進行梳理優先級排序包括形成產品初步架構
- 搭框架—–(功能和DFX非功能框架)難點在于梳理功能的全面和思路;dfx需求:保證用戶使用產品的安全、性能、可拓展等需求注:DFX其實很重要但大部分都會被忽視,此文不做拓展、后續會通過一篇文章進行詳細說明,(產品經理千萬不能只盯住功能做產品)
- 拆細節—–業務流程(重點梳理異常分支和外圍數據交互)、業務操作、信息結構)
- 畫界面—–交互設計、信息設計
以上的思路大家可以按需參考,本文著重講解拆解2步驟的方法,即搭建初步功能框架,并可落地到原型指導設計。
二、如何搭建功能框架呢?
注:搭功能框架也是從寬度上定義業務范圍,而不是要深挖細節、要注意避免陷入思路混亂、把握好分寸、見好就收。
1. 用例驅動設計法(UDD)
用例驅動設計是一種基于用戶行為和需求來設計軟件開發的方法,有步驟有層次梳理出系統功能的方法,可粗淺理解為用戶故事,是一個通用的搭框架方法;如類似網購下單、酒店預定、銀行貸款等場景;
整體思路遵循:識別參與者使用場景及問題—–定義描述用例(目標層用例—步驟層用例—-實現層用例)并簡化
(1)識別使用場景及問題
首先,我們通過華為IPD需求管理思路那篇,知道產品需求=基于場景的解決方案,因此拿到一個產品需求,我們需要想清楚對應的場景,即5w1h1e。
who(面向對象)、why、when+where(場景)、what(干什么)、以及how(怎么實現)、else(限前置和后置)
比如要做一個訪客預約系統,按照上面的描述方法,我們明白了系統的使用場景是這樣:
一個基于外來訪客,由于園區為了保障安全管理,在臨時進入園區前,需要進行線上登記個人資料、并實名認證的產品,并且園區審核通過,驗證身份才可以進入和離園。
(2)拆分:目標層-步驟層-實現層
結合上面的例子:
訪客進入園區就是目標層用例,為了實現這個整體目標,我們需要步驟層用例進行支撐,這時候就可以拆分為第一個大框架
具體為:
步驟1:訪客在系統上提前登記—–線上預約
步驟2:訪客填寫登記資料—–填寫表單
步驟3:園區通過系統審核資料并通知訪客結果—–審核管理
步驟4:訪客接收通知—-消息提醒
步驟5:訪客查看提交記錄—–預約記錄
步驟6:訪客獲得許可進入園區—身份驗證
步驟7:訪客離園確認—身份驗證
那針對每一個步驟層、具體如何實現呢?按照這個思路,通過拆分形成實現層用例(也就是用什么方案實現)
最終這個功能框架會形成這樣、(注意把不同用戶端分開保證用例全面)如圖:
當然這是初步框架,僅作部分舉例說明,你們可以自行拓展,只要保證覆蓋全部的用例就行。
在這里,我們要注意幾點:
在多種實現方案并存的情況下,如何權衡呢?
1、結合功能實現成本、第三方對接周期、客戶需要、技術實現能力、外圍的交互模塊等多方面因素進行決策,選擇一個較為合理的實現方案:
2、如上面的進出身份驗證,給了4種方案,有通行掃碼、臨時卡、人臉識別、指紋、語音,包括我們常見的支付也可以多種路徑實現,如現金支付、信用卡支付、微信支付等
小結:
1、工具:建議用思維導圖、或者用例圖進行梳理
2、目標:是形成產品功能結構(含一級特性、二級特性、甚至三級特性)
3、適用項目:比較獨立、小型或需要快速迭代和更新的項目,注重從用戶的角度出發來描述系統的功能需求
4、特點:方便快捷、拓展性較差、易于理解協作,但難以適用復雜業務
2. 流程驅動設計法(PDD)
適用于業務協作方較多,具備較復雜的業務層級及審核,更注重流程標準化管理的產品,如CRM、ERP系統、工單管理系統、采購系統、數據精細管理等。
整體思路遵循:識別關鍵業務流程—–拆分目標層用例—–業務操作
比如CRM系統的流程是有明顯前后順序的,且為了精準做好客戶關系管理,標準化的流程非常重要。通常按照以下步驟進行操作:
1、客戶檔案創建和維護—–客戶管理流程
2、銷售機會(Lead)創建和跟進——銷售管理流程
3、市場活動的策劃、執行和跟進——-市場活動管理流程
結合以上順序流程,就很適合用PDD來搭框架,我們大概拆分出幾個目標層,并進一步落地到具體的功能模塊中。下面是一些可能包括的模塊:
客戶管理模塊:
a. 客戶檔案:創建、查看、編輯、刪除客戶資料;
b. 客戶分類:對客戶進行分組和標記,例如根據客戶來源、優先級、交易狀態等進行分類;
c. 客戶關系歷史記錄:記錄客戶與企業之間的活動歷史,包括通話、郵件、漏斗進展等。
銷售管理模塊:
a. 銷售機會(Leads):創建、跟進、評估及關閉銷售機會,可以關聯相關的客戶信息;
b. 產品/服務信息:錄入、查看、編輯和刪除產品或服務信息;
c. 報價單/訂單:創建、發送、聽取意見、確認并完成報價和訂單交付等流程;
d. 合同信息:建立一個合同管理庫存儲合同信息,以追蹤合同執行情況和收款計劃。
市場活動管理:
a. 活動策劃:創建市場活動,定義主題,摘要、預算、時間表等參數;
b. 活動跟蹤:批量創建活動推廣計劃來實現對活動方案的執行,包括在線廣告、email、電話營銷等;
c. 活動分析:記錄活動成效,比如郵件打開率、轉化率等進行績效統計,以及對活動與銷售數據的關系分析。
在設計過程中,功能模塊要盡量緊密貼合上述CRM系統的整體流程,具體實現時,也可依據企業的運營或者工作方式進行特定的定制。
例如,在某些企業中市場活動管理可能更為重要,根據不同的客戶屬性,社交媒體營銷方式有些偏年輕化公司會利用大量互聯網和移動設備,而傳統行業的企業上門拜訪更常見。
小結:
1、適用項目:PDD適用于更大型、復雜或需要對業務流程進行全面分析和優化的項目。
2、工具:UML流程圖、狀態圖等
3、優點:幫助理清內部系統數據、業務流程,基于過程建模,從整體到局部深度設計,復雜業務簡單化
4、缺點:過于關注流程,導致各個子系統業務耦合較高,難以實現拓展
3. 領域驅動設計(DDD)
領域驅動設計(Domain-Driven Design,DDD)是由領域驅動設計之父埃里克·埃文斯提出的,涵蓋面較廣,其核心思想是先梳理領域信息結構和業務規則,再梳理業務的用例、流程和操作等內容。
整體思路遵循:確定場景領域—-識別核心領域對象(信息結構)—-業務規則(定義對象之間的屬性關系及行為)—–其他模塊的交互
舉例:場景領域—-電子商務平臺
我們識別到的核心對象為:
- 商品管理:包括商品信息的管理、上架、下架、分類、標簽等。
- 訂單管理:包括訂單的生成、查詢、修改、刪除等。
- 用戶管理:包括用戶信息的注冊、登錄、個人信息維護等。
- 支付管理:包括各種支付方式的接入、支付狀態的管理和處理等。
- 物流管理:包括訂單狀態的跟蹤、配送信息的記錄、快遞單信息的管理等。
- 售后服務:包括退換貨的處理、客戶服務的管理、投訴反饋的處理等
這里以訂單管理為例,用類圖表達信息結構。
信息結構表述了信息內容之間的關系。這種關系可以用類圖(Class Diagram)來表達。
該圖片來源于圖書【“圖解”產品:產品經理業務設計與UML建?!孔髡咔嫔n
當我們使用類圖來識別領域模型和實體關系后,需要根據業務需求和限制條件定義對象、屬性、操作業務規則和流程,如買家只能在特定時間段內下單,不能重復購買同樣的商品;訂單滿足3人立刻成團進入待支付;訂單超時未支付自動取消等。
最后,在實現層,我們需要識別系統內的其他部分或與系統交互的部分,并確定他們對業務領域的影響。比如,與支付相關的銀行接口、第三方支付接口、物流跟蹤動態數據的集成等都是我們必須考慮的。
小結:
- 適用行業:復雜且靈活多變的行業需求,開發此軟件的公司,通常是行業的引領者,如中臺等大型團隊項目
- 工具:UML類圖、思維導圖
- 優點:低耦合可擴展、能靈活應對復雜業務變更需求、可增強代碼質量
- 缺點:團隊技能要求高、時間成本高、協調難度高、編碼量增加(長期來看是值得的)
注:通過選擇合適的方法論,我們完成了產品設計第2步:搭框架,后續再通過第3步拆細節,重點梳理各分支下的異常流程,逐步完善細節,最后一步,再進行頁面信息收集填充,剩下的就是畫原型了,此處不做展開。
三、面對不同項目,如何選擇?
綜上,通過以上3種搭功能框架的方法論,我們知道,產品設計方法論,包含用例驅動設計發(UDD)、流程驅動設計法(PDD)、領域驅動設計法(DDD),我們來整體再做個對比總結,通過以下維度進行決策,方便我們在具體的項目設計中,選擇較為合適的方法。
當然,他們各自有優缺點,在一個項目里,完全可以結合交叉使用。
四、拆解需求需要具備的能力和思維
- 設計思維:清晰的產品設計思路、并形成自己的通用方法論,掌握并應用(如上面的3種方法)、包括其他的成熟模型(如AARRR模型…)
- 設計方案:內心要有很多成熟可用的方案思維和評估方案的能力,就需要多練多看、多去關注一些最新的技術,不然沒法梳理框架里具體都包含什么,怎么實現
- 深度思考能力:多使用結構化思維培養深度思考能力、體現在異常流程、外圍數據交互處理上(平時要多觀察競品、多問幾個為什么、包括開發階段潛在的問題、面對開發的質疑才可以真正說不)
- 最佳的UI感及交互設計能力(審美、人機交互最佳策略)
- 工具使用能力:巧用UML建模,事半功倍(重點關注類圖、用例圖、狀態圖、流程圖)、還有其他思維導圖等
五、其他想說的話
本文的重點是教大家如何通過成熟的方法論,拆解需求指導原型設計,在寫的時候,里面其實包含了很多知識點,并沒有展開:
比如最容易被忽視的DFX需求:UDD、PDD、DDD3種方法論如何靈活保證系統的DFX需求,這部分產品經理必須有相應地思考和考量,不能老是產品做了用不起來或者代碼混亂、后面維護難、迭代難……
UML建模能力的學習:高效輔助產品經理工作,梳理需求和團隊協作、包括作為評審材料后期可進行系統設計檢視,很值得研究運用,但不是都要學;
再比如產品設計由靜態到動態,框架的各個模塊之間如何進行交互設計關聯;頁面信息結構怎么收集并合理展示……..
后續我也會慢慢整理總結、輸出。
最后,我們還可以問自己一個問題,從程序員角度,逆向考慮下,程序員拿到一個需求,都是怎么拆解并實現的?
或許你會知道,你設計的功能是不是相對完美的。
本文由@凱拉Kella 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!