后臺產品和前臺產品因面對的用戶不同，在需求上也有比較明顯的區別，前臺產品又可以稱為用戶產品，主要面向的是C端或B端用戶，在進行產品規劃、設計時更多的考慮的是用戶需求、用戶體驗。而后臺產品則有些不同，后臺產品主要為內部用戶使用，或者與內部其他業務系統之間發生交互以實現某種功能。

所以對于后臺產品來說，在需求獲取過程中大致可分為兩種類型的需求：產品類需求、交互類需求。

（1）產品類需求

這類需求往往是針對于公司內部業務人員使用的產品，如一個資訊類產品，內容運營人員需要使用一個后臺系統對內容進行整理、編輯，并發布到前端讓用戶可見。這樣的一個業務系統就是后臺產品，那么這類產品的需求一般由其他部門業務人員提出，產品的設計就要滿足業務人員的需求。

（2）交互類需求

對于大公司或者較大的業務平臺，從前端到后臺，涉及多個系統或多個業務模塊，業務模塊之間根據流程或者功能進行區分，每個模塊由不同團隊負責，這種情況下，當一個業務模塊需要進行需求優化時，可能就會依賴流程上下游其他模塊的支持。如對于大型電商平臺來說，用戶選擇產品下單支付的這樣一個行為，后端系統就涉及到前端、訂單、支付平臺之間的交互，那么如果前端對于支付方式或者支付流程進行了更改，后臺的訂單模塊、支付模塊也需要進行相應的更改，這就涉及到業務模塊之間的交互，更多的是交互流程和數據之間的需求。

1. 需求來源

基于上面提到的需求類型，后臺產品的需求來源主要會分為三大類：業務人員、其他業務系統的產品經理、老板。

（1）業務人員

業務人員的需求往往針對于后臺產品經理負責的產品或業務系統，這類業務系統為支撐業務人員實現某些業務場景而設計，對于業務場景的變更或者業務的發展，業務人員往往會對現有業務系統提出新的需求。

（2）其他業務系統的產品經理

對于大型業務平臺來說，多個業務系統之間是上下游關系，在業務流程、數據交互上都會有所關聯，那么其他業務系統的產品經理當需要進行系統重構、系統需求迭代時，也會提出需要配合的需求。

（3）老板

之所以把老板這個需求來源放在最后，主要是因為他既可能提出業務人員的需求、也有可能提出其他業務系統產品經理的需求。老板的視角通常是站在整個業務線甚至是事業群的視角去看待產品的迭代或優化，所以他提出的需求可能是只針對一個業務模塊，也有可能針對整個業務流程，所以對于老板提出的需求需要具體問題具體分析。

2. 需求溝通

對于后臺產品來說，需求的獲取方式比前端或者用戶產品更容易，不用通過用戶訪談、問卷調查這些方式去獲取需求。后臺產品涉及到的“用戶”通常都是公司內部人員，通過組織需求溝通會即可，然而，需求容易獲取并不代表可以容易的明確需求。

組織需求溝通會，對于后臺產品來說是基本功之一：

• 首先要明確需求涉及的相關干系人，通過會前通知、會議邀請等方式，在需求溝通會上將需求相關干系人全部組織到一起。
• 其次，在需求溝通的過程中，不要被帶入誤區，一定要明確需求的背景，即為什么要做這個需求嗎，做這個需求可以解決什么問題。很多時候業務人員會在提出需求后緊接著提出解決方案，但是這種方式一定是有問題的。業務人員可以提出自己的業務解決方案，但是產品的解決方案一定是產品經理去思考的，不能被業務人員帶到溝里，往往業務人員提出的方案會有一定的局限性，也許是局部最優，但一定不是全局最優。
• 最后，如果需求涉及多個角色或多個業務系統，一定要在溝通需求的時候讓各方達成共識，否則后期一旦有一方產生意見不一致，很容易造成需求的delay。

3. 需求分析

經過需求溝通會明確需求內容后，下一步就是要對需求進行分析，分析的目標主要有兩個：如何做以及什么時候做，分析的方法這里介紹三種比較接地氣的：

（1）重要緊急程度分析

重要緊急程度四象限分析法比較常見，主要思想即對一個需求從重要和緊急兩個維度進行分析，排序需求的優先級。

• 對于重要緊急的需求要優先做，比如老板說XX日前必須實現某某功能。
• 對于重要不緊急的工作可以排期到迭代中，比如某業務線說，這個功能不著急，在這個季度結束前能用就好。
• 對于緊急不重要的需求，要進行一定辨析，緊急但不重要的原因是什么，是否可以選擇簡單的解決方案優先排期。
• 對于不緊急且不重要的需求來說，可以與需求提出人進行溝通，爭取將需求砍掉。

（2）依賴性原則

上文中提到后臺需求中，有部分需求的完成是需要依賴于業務上下游其他業務系統的，那么對于這類需求的排期和解決方案，就需要與有依賴的業務系統模塊進行確認，確認對方什么時候做，對方的排期與自己排期之間是否有時間上沖突。此外還要確認自己的解決方案與對法解決方案是否有沖突，保證雙方可以完美適配。

（3）全局性思維

全局性思維其實上面也提到過，就是不要沉浸在自己負責的獨立業務系統當中，要跳出這個小圈，從整個業務流程的視角去思考問題，去設計解決方案。

以前端或用戶產品為例，這類產品經理在產品設計時就經常會忽略全局性思維，他們往往考慮更多的是用戶體驗，是某一個功能應該在哪一個頁面展現給用戶，但是他們卻不會思考，當用戶點下某一個按鈕或者完成某一個操作后，后臺的業務是如何流轉的，后臺的業務系統之間數據是如何交互的。這就是后臺產品需要具備的全局性思維，不僅要考慮前端用戶的操作，又要考慮到后臺系統之間的交互以及流程。

上面三種接地氣的需求分析方法中，前兩種解決的是需求什么時間做的問題，而最后一種思維方法則解決的是需求如何做的問題。

4. 需求排期

需求排期即將明確的需求排進產品迭代周期中，保證研發、測試明確需求內容，且需求可以正常進入開發、測試、上線流程。按照需求明確、開發、測試三個環節進行一一解析：

（1）需求明確

在每一個迭代周期開始之前，組織需求會以及沖刺會。需求會即組織所有開發同學，就需求背景、需求內容與開發進行溝通，確認開發明確需求做什么，然后由開發同學將需求拆分成具體的可落地任務項。沖刺會即組織所有開發以及測試同學，就需求會確認過的需求，由開發反講給測試，這樣做的目的是保證開發正確理解了產品經理的需求內容，同時測試同學也會就疑問提出質疑，在產品、開發、測試三方同時在場的情況下，保證需求明確，不會在開發、測試過程中再產生撕逼的情況出現。

（2）開發

在開發過程中，每天通過站立會了解需求的進度，如果遇到需求的變更或者開發、測試同學的疑問，可以及時進行溝通，避免出現重大的delay。

（3）測試

對于產品內部的功能，由組內的開發與測試溝通測試事項即可，但是對于涉及多業務模塊之間的聯調測試，就需要提前溝通所有相關的負責人進行確認。

• 如果你是需求的發起人，那么在需求進入開發尾聲，就需要協調不同團隊的產品、開發、測試負責人組會溝通開發聯調、測試聯調的時間點，保證各團隊之間可以在產品上線時保證統一。
• 如果你不是需求的發起人，那么也需要明確與你的業務模塊有依賴關系的業務模塊的測試時間，需要提前確認聯調時間，保證不會因為自己負責的模塊出現問題而導致整體需求的delay。

#專欄作家#

記小憶，人人都是產品經理專欄作者，野蠻生長的產品經理，擅長從0-1搭建產品經理知識體系。公眾號：PM龍門陣。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pixabay，基于 CC0 協議