產品經理該如何把業務需求變成產品方案
編輯導讀:產品經理日常工作中最常聽到的詞就是需求,而產品經理的核心工作也就是把需求變成可使用的產品。那當我們接到需求時,我們是如何把它轉化成產品呢?本文將從七個方面進行分析,希望對你有幫助。
一、對“需求”這個詞的理解
首先我們先了解一下,在產品開發過程中所溝通的“需求”到底指的是什么。我們先舉幾個我們工作中常常聽到的需求:
- 老板:現在經營效率太低了,我們要上個系統,提高效率(目標需求);
- 財務:每筆費用報銷都要走審批,加強對費用支出的管理(業務需求);
- 運營:日常經營數據需要支持導出功能,好進行加工分析(功能需求)。
我們可以將平常聽到的需求都歸為這三類,產品經理需要做的就是將目標需求和業務需要轉化為產品方案,然后交付給開發團隊。
接下來我們將以羽毛球館訂場地這個業務需求,來拆解一下整個過程,看它是一步步變成產品方案的。
二、定位業務問題
場館運營部門提出一個需求,我們需要實現線上訂場地。
業務需求的提出,肯定是為了解決某些業務問題。通過調研,現在純線下訂場的方式存在以下問題:
球友:
- 想運動,但不知道哪里有合適的場館?
- 不知道場館是如何收費的?
- 場館有沒有空閑的場地?
- 場館的有哪些項目?有沒有停車場、淋浴等設施?
場館:
- 球友打電話過來,詢問場地價格和空余等情況耗費時間;
- 新球友訂場交定金麻煩,不交定金又可能爽約,造成場地未預定出去的損失;
- 人工登記場地預定情況,易產生失誤,導致一場多訂等情況,極大影響客戶體驗;
- 場地預定情況很難統計成分析數據,對運營決策無法提供幫助;
業務問題定位了,后面的設計就要圍繞這些問題展開,設計完后要回過來看有沒有解決這些問題,否則一切都是徒勞的。
三、梳理業務流程
流程是產品設計的關鍵,梳理流程能讓你對整個過程更清晰。梳理過程前,先要明確下訂場有幾個場景,因為每個場景的流程可能不太一樣。通過調研和分析得知,訂場主要有以下幾種場景:
- 線上訂場—球友在微信或者APP上訂場;
- 線下訂場—球友直接到場館前臺臨時訂場;
- 電話訂場—打電話給場館前臺,讓前臺預留場地;
- 長期球友固定訂場—有些企業會固定在某個時段訂場,比如周三的18:00~20:00,一次預訂即可,定好有效期,不用每次臨時預訂;
- 包場—企業搞團建時會包下整個場館;
這里就要思考一下,我們這次設計是否要滿足這5個場景呢?我們回到定位業務問題這一步,問題都是在想要運動的球友在訂場時存在的,而方式e在線下的處理暫時并沒有多大問題,再深入一步調研可了解到,包場都是直接線下談好價格,這個價格也是可浮動的,然后將錢線下轉給場館,放到線上反而不靈活,所以我們就先不考慮線上實現這個場景。
Tips:產品經理需要學會做減法,并不是把線下所有業務搬到線上來,開發出來后發現并沒有什么用,又浪費這么多資源。
將待實現場景確定下來后,我們需梳理每個場景的業務流程,這樣才能對整個過程清晰。因為我們這次只是講方法,所以就只拿場景a來舉例,繼續下面的分析過程。
我們梳理出線上訂場流程圖后,這時我們需要分析一下,這些環節哪些需要做到線上?
入場前:訂場、付款、鎖場肯定是需要做到線上的,產品的目標就是為了解決訂場效率低的問題;
前臺接待:出示訂場憑證、校驗訂場憑證、開燈、放行這些環節并沒有太大的影響效率。出示訂場憑證、校驗訂場憑證可通過報手機號的形式解決。開燈和放行涉及到智能燈控和智能閘機的對接,沒有這些東西業務也能跑的通,也能正常營業,這期也先不考慮在線上實現;
入場后:到點提示也涉及到智能設備的對接,先可人工提示。
Tips:產品經理需要定義需求的優先級,先把影響業務正常運行的問題解決掉,再來迭代優化。
四、梳理業務規則
業務規則是運營部門為使業務正常運行而定義的,就算沒有系統也是存在的。產品經理需要做的是把這些業務規則梳理出來,然后用產品的語言把它描述出來。還是以線上訂場舉例,場地什么時候可以訂?訂的時候有沒有時間限制?價格會由哪些因素影響?可不可以退場?會員有沒有什么特殊權限?這些規則聽著是不是很亂,這就需要產品經理一條一條梳理清楚,梳理規則的同時還需要多問為什么要這樣做呢,一來以后方便和開發等同事說清楚為什么這樣設計,二來也能加深自己對業務的了解。
通過調研我們梳理出以下預訂規則,但我們需注意以下兩點:
- 這些規則都是比較容易通過調研得到的,還有一些隱性的規則,調研的時候很難得到,可能在產品上線一段時間后才能想到。例如訂場后要在一定時間內支付,不支付就將場地變成空閑狀態。產品上線后這種規則缺失一定會暴露出來的,但產品經理最好能提前考慮到這種規則,盡量避免損失。
- 這些規則僅僅為一個場館的規則,為將產品的適用更多的場館,也為防止以后場館的業務規則變動,盡量做成可配置的。
以上只列舉了線上訂場的預訂規則,還有退訂規則、價格方案規則、會員權限等規則都需要一條一條梳理出來,這里就不一一列舉出來了。
五、繪制原型
業務流程和業務規則都梳理出來后,就可以畫原型了。這一步對產品經理來說,即簡單又困難。簡單是因為去想象具象的軟件操作比思考抽樣的業務邏輯更容易,難是因為畫的原型最終要符合業務流程和業務規則,并且還要符合常規交互原則。
從業務流程分析,整個訂場環節涉及到球友和場館,那肯定要有球友訂場端和場館管理端。球友訂場端剛開始也沒必要做APP,做個H5放在微信公眾號就可以了,還能引流到公眾號。確定好用什么來實現后,我們要梳理一下線上訂場有哪些頁面,不要想到一個畫一個,這樣很容易漏頁面。
Tips:剛開始設計原型時,盡量不要添加一些和主流程無關的頁面,比如你覺得別人做了個VR查看場館,你也要做一個,但是前期最重要的是把業務跑通,再來添加一些附加功能。
工具類產品原型設計多參考一下美團、淘寶等移動端產品,因為移動端產品發展到現在,已經培養了用戶的操作認知,我們不用去發明輪子,讓用戶再重新去學習。
六、可用性測試
產品的原型出來了,可以給客戶演示,讓客戶跑一遍整個流程,看先前提的業務問題有沒有得到解決。如果有問題,再進行調整。其實讓客戶跑一遍流程也不能發現所有問題,只有在真正使用的時候才會暴露出問題來,但這一步也是不可少了。
七、撰寫PRD
PRD全稱為Product Requirement Document,中文名為“產品需求文檔”。其核心目的是幫助開發、測試、運營、產品人員理解該需求的背景和具體要求,減少產品實現過程中諸多不必要的重復解答,從而提升整體項目推進效率。當業務規則、業務流程、原型圖都出來后,我們需要把它交付給我們的開發團隊去實現,交付的形式就是PRD。這里就不闡述PRD怎么寫了。
八、總結
當接到業務需求時,變成產品的過程是:
- 定位業務問題;
- 梳理業務流程;
- 梳理業務規則;
- 繪制原型;
- 可用性測試;
- 撰寫PRD。
以上只是個理想化的流程,產品經理并不是寫完PRD扔給開發就沒事了。包括后面的需求評審、跟進開發進度和問題、測試上線、迭代優化等,都需要產品經理主導。
寫在最后:文中只講了分析的方法,并沒有把實際的過程細節描述出來。如果各位大佬有其他見解,也歡迎提出,產品路上我們一起成長。
本文由 @康力文 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自pexels,基于CC0協議
新產品的落地差不多經歷了這些環節:
用戶需求>-產品需求采集 >產品策劃 >產品交互設計 >產品視覺設計 >產品頁面重構 >產品研發 >產品測試 >產品發布 >需求收集 >迭代
—
那從用戶需求到原型生成,是怎么抽象到具象的? 就像生活中 蓋房子,拿到的原材料都鋼筋 混凝土, 產出的高樓卻各不同;
公司餐廳,廚師拿到的原材料是番茄和面,產出的卻是番茄臊子面,為啥不是湖湯面。
就像你在設計工作中, 我覺得研究用戶、組織、競品、政策, 這些都是原材料, 經你輸出出原型時,基本就具體化了,我看網稱為具象就也這么說了。 張三拿到同樣的原材料,輸出了臊子面,李四卻輸出了糊湯面,這個過程發生了什么?
—
一段時間里我對這點很是困惑。
個人的一點淺見:原型可以看作是產品需求的具象化展示,所以這個問題在我看來就是用戶需求如何轉化為產品需求,而產品需求換一個角度來講其實就是針對用戶需求的解決方案。如果用戶的目的只是為了填報肚子,那么提供臊子面還是糊湯面都是可以的,當然最好是再了解用戶的口味喜好最終確定下來;如果用戶就是專門為臊子面而來的,那就提供臊子面不要考慮糊湯面。至于用戶需求轉化為產品需求的過程就是產品設計,基于用戶的業務場景、業務流程來設計產品的功能模塊、功能入口、操作步驟、交互體驗等,設計過程中要充分考慮到明面上或隱藏的業務規則以及各種異常情況。
可以向你請教一下
功能需求和業務需求的區分標準嗎?
是需求大小的分別,比如是設計一個系統還是設計一個功能
還是需求解析到產品需求過程的區別,一開始是業務需求,在業務進行過程中產生的新需求,為功能需求
個人理解:需求這個詞范圍比較模糊,在不同場景每個人表達的意思都不太一樣,我自己對業務需求和功能需求的區分,業務需求是個比較大的概念,提出后不能立馬做,比如加個報表讓老板知道每天的營業情況,需要產品經理去細化各個指標,形成功能需求,功能需求就比較具體了,比如加個導出功能、加個按時間篩選功能等等,簡單粗暴的理解,業務需求是由若干個功能需求組成的。
1:客觀梳理業務現狀。
2:總結業務問題
3:輸出產品解決方案
4:衡量收獲
厲害厲害!
寫得很好,思路清晰,對產品新人幫助很大的。
看必存
來自點嘀員工的贊許
哈哈,你是景林?
很贊
寫的很棒,贊一個
謝謝,受益匪淺
寫的挺好的