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

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

（1）產(chǎn)品類需求

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

（2）交互類需求

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

1. 需求來源

基于上面提到的需求類型，后臺產(chǎn)品的需求來源主要會分為三大類：業(yè)務人員、其他業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理、老板。

（1）業(yè)務人員

業(yè)務人員的需求往往針對于后臺產(chǎn)品經(jīng)理負責的產(chǎn)品或業(yè)務系統(tǒng)，這類業(yè)務系統(tǒng)為支撐業(yè)務人員實現(xiàn)某些業(yè)務場景而設計，對于業(yè)務場景的變更或者業(yè)務的發(fā)展，業(yè)務人員往往會對現(xiàn)有業(yè)務系統(tǒng)提出新的需求。

（2）其他業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理

對于大型業(yè)務平臺來說，多個業(yè)務系統(tǒng)之間是上下游關系，在業(yè)務流程、數(shù)據(jù)交互上都會有所關聯(lián)，那么其他業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理當需要進行系統(tǒng)重構、系統(tǒng)需求迭代時，也會提出需要配合的需求。

（3）老板

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

2. 需求溝通

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

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

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

3. 需求分析

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

（1）重要緊急程度分析

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

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

（2）依賴性原則

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

（3）全局性思維

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

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

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

4. 需求排期

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

（1）需求明確

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

（2）開發(fā)

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

（3）測試

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

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自 Pixabay，基于 CC0 協(xié)議