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

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

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

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

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

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

二、定位業務問題

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

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

球友：

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

場館：

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

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

三、梳理業務流程

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

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