產品經理該如何把業務需求變成產品方案

12 評論 1.1萬 瀏覽 83 收藏 12 分鐘

編輯導讀:產品經理日常工作中最常聽到的詞就是需求,而產品經理的核心工作也就是把需求變成可使用的產品。那當我們接到需求時,我們是如何把它轉化成產品呢?本文將從七個方面進行分析,希望對你有幫助。

一、對“需求”這個詞的理解

首先我們先了解一下,在產品開發過程中所溝通的“需求”到底指的是什么。我們先舉幾個我們工作中常常聽到的需求:

  • 老板:現在經營效率太低了,我們要上個系統,提高效率(目標需求);
  • 財務:每筆費用報銷都要走審批,加強對費用支出的管理(業務需求);
  • 運營:日常經營數據需要支持導出功能,好進行加工分析(功能需求)。

我們可以將平常聽到的需求都歸為這三類,產品經理需要做的就是將目標需求和業務需要轉化為產品方案,然后交付給開發團隊。

接下來我們將以羽毛球館訂場地這個業務需求,來拆解一下整個過程,看它是一步步變成產品方案的。

二、定位業務問題

場館運營部門提出一個需求,我們需要實現線上訂場地。

業務需求的提出,肯定是為了解決某些業務問題。通過調研,現在純線下訂場的方式存在以下問題:

球友:

  • 想運動,但不知道哪里有合適的場館?
  • 不知道場館是如何收費的?
  • 場館有沒有空閑的場地?
  • 場館的有哪些項目?有沒有停車場、淋浴等設施?

場館:

  • 球友打電話過來,詢問場地價格和空余等情況耗費時間;
  • 新球友訂場交定金麻煩,不交定金又可能爽約,造成場地未預定出去的損失;
  • 人工登記場地預定情況,易產生失誤,導致一場多訂等情況,極大影響客戶體驗;
  • 場地預定情況很難統計成分析數據,對運營決策無法提供幫助;

業務問題定位了,后面的設計就要圍繞這些問題展開,設計完后要回過來看有沒有解決這些問題,否則一切都是徒勞的。

三、梳理業務流程

流程是產品設計的關鍵,梳理流程能讓你對整個過程更清晰。梳理過程前,先要明確下訂場有幾個場景,因為每個場景的流程可能不太一樣。通過調研和分析得知,訂場主要有以下幾種場景:

  • 線上訂場—球友在微信或者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協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 可以向你請教一下
    功能需求和業務需求的區分標準嗎?
    是需求大小的分別,比如是設計一個系統還是設計一個功能
    還是需求解析到產品需求過程的區別,一開始是業務需求,在業務進行過程中產生的新需求,為功能需求

    回復
    1. 個人理解:需求這個詞范圍比較模糊,在不同場景每個人表達的意思都不太一樣,我自己對業務需求和功能需求的區分,業務需求是個比較大的概念,提出后不能立馬做,比如加個報表讓老板知道每天的營業情況,需要產品經理去細化各個指標,形成功能需求,功能需求就比較具體了,比如加個導出功能、加個按時間篩選功能等等,簡單粗暴的理解,業務需求是由若干個功能需求組成的。

      回復
  2. 1:客觀梳理業務現狀。
    2:總結業務問題
    3:輸出產品解決方案
    4:衡量收獲

    回復
    1. 厲害厲害!

      回復
  3. 寫得很好,思路清晰,對產品新人幫助很大的。

    回復
  4. 看必存

    回復
  5. 來自點嘀員工的贊許

    回復
    1. 哈哈,你是景林?

      回復
  6. 很贊

    回復
  7. 寫的很棒,贊一個

    回復
  8. 謝謝,受益匪淺

    回復
  9. 寫的挺好的

    回復