編輯導(dǎo)語：B端，代表企業(yè)用戶商家Business，本質(zhì)是為滿足用戶的工作需求，往往是基于公司層面多人對某一問題解決方案進(jìn)行整體評估。在本篇文章中，作者用5W2H原則，從一個(gè)推送配置模塊的設(shè)計(jì)到交付，步步拆解，總結(jié)一套方法，希望能給各位讀者帶來幫助。

一、產(chǎn)品的碎碎念

在我們還沒有能力做產(chǎn)品戰(zhàn)略規(guī)劃的時(shí)候，收到一個(gè)工作任務(wù)，我們應(yīng)如何展開，既出色完成任務(wù)又讓自己有所提升？

1. 工作的惡性循環(huán)

有一些新人產(chǎn)品會覺得自己做得事情缺乏挑戰(zhàn)，沒有提升空間。所做之事無非是按照領(lǐng)導(dǎo)和業(yè)務(wù)人員的要求畫個(gè)原型、增加幾個(gè)參數(shù)修改功能、配置功能、導(dǎo)出功能，缺乏主動思考，或者覺得這個(gè)功能做得再好也沒什么用。

他們可能對業(yè)務(wù)和團(tuán)隊(duì)開發(fā)人員熟悉之后，就開始劃水了，也可能將時(shí)間花在了項(xiàng)目管理或開發(fā)框架等其它事情上，期望跳槽加個(gè)薪。

不認(rèn)真的態(tài)度換不來出色的成績，沒有升職的機(jī)會，仍舊陷在初級的瑣碎的功能設(shè)計(jì)中。

2. 工作的良性循環(huán)

當(dāng)我們在具體的工作事項(xiàng)中，多問幾個(gè)問什么，不僅幫助我們更加深刻得理解業(yè)務(wù)，也能更出色的完成任務(wù)。

產(chǎn)品的技能不像研發(fā)同學(xué)，有具體的開發(fā)語言或者框架，如果你跟面試者說你表達(dá)能力好，邏輯思維能力強(qiáng)，人家還覺得你一無所長。

對于面試來說，過往的成績才是最好的證明。

所以與其不認(rèn)真的工作加一點(diǎn)似有似無的理論知識學(xué)習(xí)，不如認(rèn)真工作，持續(xù)復(fù)盤總結(jié)。就算沒能獲得亮眼的數(shù)據(jù)成績，也能沉淀出來自己的方法論，正如我此刻在做的事情一樣。

下面我將從一個(gè)推送配置模塊的設(shè)計(jì)到交付，步步拆解，總結(jié)一套方法，希望也能給各位讀者帶來幫助。

5W2H法則：

1. WHAT——是什么？目的是什么？做什么工作？
2. WHY——為什么要做？可不可以不做？
3. WHO——由誰來做？
4. WHEN——何時(shí)？什么時(shí)間做？什么時(shí)機(jī)最適宜？
5. WHERE——何處？在哪里做？
6. HOW ——怎么做？如何提高效率？如何實(shí)施？方法是什么？
7. HOW MUCH——多少？做到什么程度？

二、了解需求：確定做什么，為什么做

當(dāng)我們還沒有能力做產(chǎn)品規(guī)劃之前，需求總是由業(yè)務(wù)人員或者領(lǐng)導(dǎo)提出。剛開始它只是一句話：“需要做一個(gè)推送配置，不同渠道用戶需要看到不同的續(xù)費(fèi)頁面”。

不著急一次拎清楚，5W2H是從需求導(dǎo)入到功能輸出全流程的一個(gè)指導(dǎo)法則。

在了解需求階段，我們重點(diǎn)要整明白這個(gè)需求為什么要做，目的是什么。

在幾番詢問后，我了解到我們有好幾個(gè)客戶，他們采購了我們運(yùn)營的流量卡，所以在他們自己開發(fā)的APP上需要有一個(gè)地方充值流量套餐，在流量服務(wù)快到期或不足時(shí)需要有相應(yīng)的提醒，這樣可以提高續(xù)費(fèi)率。

提高續(xù)費(fèi)率對我司有益，對客戶也有益，因?yàn)槲覀兊纳虡I(yè)模式是按續(xù)費(fèi)套餐給客戶一定的返點(diǎn)。

我將這些需求分為以下幾種類型：

1. 痛點(diǎn)需求

1）給流量套餐充值

2）在對應(yīng)場景作出提醒

2. 衍生需求

消息的埋點(diǎn)及數(shù)據(jù)分析

3. 規(guī)劃類需求

1）個(gè)性化充值頁面

2）提醒的個(gè)性化配置

三、列出實(shí)現(xiàn)方案：確定怎么做，做到什么程度

我們并非是定好一個(gè)目標(biāo)，然后再定方案；而是討論方案，并且不斷的調(diào)整我們的目標(biāo)，最終得出一個(gè)最佳方案。

為什么呢？

目標(biāo)是可長遠(yuǎn)可短視的，我們都希望是用一個(gè)長遠(yuǎn)的方案來解決現(xiàn)在的問題，可未來是什么樣子都沒有看真切，很難說你現(xiàn)在制定的所謂長遠(yuǎn)的方案能夠在未來依然閃閃發(fā)光。

長遠(yuǎn)的方案往往復(fù)雜程度高，這個(gè)時(shí)候就要來取舍了。

實(shí)現(xiàn)的方案和應(yīng)該達(dá)到的效果像蹺蹺板的兩頭，我們不斷推演權(quán)衡中，使其達(dá)到一個(gè)平衡狀態(tài)，這個(gè)時(shí)候就選出了一個(gè)性價(jià)比最高的方案。

我的領(lǐng)導(dǎo)還給過一個(gè)快速做決策的金句：“業(yè)務(wù)上的需求可做可不做的，那就不做；技術(shù)上的需求可做可不做的，那就做?！?/p>

他就是考慮到市場萬變，今天銷售說想要這個(gè)，說不定又要別的了，在你把握不定的時(shí)候，就別做了。

但是技術(shù)上的問題，比如服務(wù)器的訪問能力、架構(gòu)的優(yōu)化，這些問題如果你不優(yōu)化，那就埋下了一個(gè)隱患，遲早會爆發(fā)出問題。

話說回來，那么本次推送配置模塊該怎么做呢？

1. 關(guān)于賬號體系搭建

1）方案一

啟用運(yùn)營平臺賬號體系，并與業(yè)務(wù)平臺進(jìn)行映射，推送配置作為一個(gè)運(yùn)營功能，有利于加強(qiáng)運(yùn)營平臺的綜合運(yùn)營服務(wù)能力。

2）方案二

啟用業(yè)務(wù)平臺賬號，業(yè)務(wù)平臺采用樹形結(jié)構(gòu)，目前一個(gè)賬號對應(yīng)一個(gè)樹形節(jié)點(diǎn)，在接口調(diào)用范圍上不夠靈活。

如未來對外接口要統(tǒng)一一個(gè)賬號調(diào)用，那么它的工作量比放在運(yùn)營平臺還是小一些。

和研發(fā)負(fù)責(zé)人討論的結(jié)論是：兩套賬號體系都不采用，后臺有兩套開放接口，一套就是我提到的業(yè)務(wù)平臺開放接口，已經(jīng)再投入使用；一套是在研、還未開放的，兩者很難合并，未來也不一定非要合并。

同一個(gè)客戶提供兩個(gè)賬號讓其調(diào)用我司接口顯然不合理，但是我們可以將兩個(gè)賬號做成一模一樣的，那客戶在調(diào)兩邊的接口時(shí)就不會感覺到他實(shí)際上是調(diào)用的兩個(gè)平臺。

我們暫且把一個(gè)需要調(diào)用我們接口獲取推送服務(wù)的客戶稱作“推送客戶”，那么新建一個(gè)推送客戶時(shí)，然后確定他可以獲得的信息范圍呢？

這里也有兩個(gè)方案：

1. 改造業(yè)務(wù)平臺的賬號范圍，新建時(shí)選擇某個(gè)業(yè)務(wù)平臺已經(jīng)建立的賬號，記錄其范圍；
2. 直接選擇業(yè)務(wù)平臺的用戶樹，圈定其范圍。

方案1有一個(gè)顯著的問題是如果在業(yè)務(wù)平臺修改了賬號的范圍，那么運(yùn)營平臺是否要同步。不同步不合理，同步太費(fèi)勁，因而在新建推送客戶時(shí)選擇方案1。

2. 關(guān)于賬號配置

1）方案一

賬號列表和配置項(xiàng)放置在同一頁面，壞處是不利于B端客戶自己調(diào)整配置（不過目前暫無此需求，都是我們運(yùn)營）。

2）方案二

賬號列表僅做管理和權(quán)限配置；推送配置放置在另一頁面，可由B端客戶自己登陸平臺配置。

壞處是我司人員如何給B端客戶配置呢？難道要登錄客戶的賬號？其實(shí)也未嘗不可，初始的時(shí)候給一個(gè)默認(rèn)值。

討論后的結(jié)論：前期客戶并無配置需求，最終運(yùn)營還是由我司把控，未來的事情太遠(yuǎn)，看不真切，最后決定采用方案一。

3. 關(guān)于開放接口

原來麥聯(lián)寶已有一套API接口，里面也包含了推送的幾個(gè)配置（掃二維碼續(xù)費(fèi)、狀態(tài)變化、機(jī)卡分離、實(shí)名推送），配置項(xiàng)理應(yīng)統(tǒng)一管理；而且對外接口是否應(yīng)全部歸在一起，使我們的客戶在與我司任意一款產(chǎn)品對接時(shí)都是同一套賬號密匙。

討論后的結(jié)論：同“關(guān)于賬號體系搭建”一樣，做到形似，不強(qiáng)求合并。不合并的弊端就是對外給出的接口調(diào)用賬號未統(tǒng)一管理；API未統(tǒng)一規(guī)范管理。

四、與產(chǎn)品的關(guān)系：確定在哪里做，誰來做

從業(yè)務(wù)上來看，它是屬于流量業(yè)務(wù)；從屬性上來看，具有運(yùn)營屬性。在我司也是既有業(yè)務(wù)平臺，也有綜合運(yùn)營平臺。到底放哪里更合適呢？這取決于我們用什么方案來實(shí)現(xiàn)？采用什么方案又取決于我們要做到什么程度。

1. 首先我們要做到什么程度？

在前一章的討論中我們已經(jīng)決定未來不一定合并公司全部開放接口，這一次也不需要考慮將賬號開放給用戶去配置。

2. 其次該功能偏業(yè)務(wù)還是偏運(yùn)營？

到期提醒、降速提醒等原來是按照默認(rèn)的規(guī)則寫好，無法支持自定義。

這些會更偏重運(yùn)營，關(guān)鍵在于什么時(shí)候發(fā)送？發(fā)送什么內(nèi)容？發(fā)送幾次？

3. 最后該功能該功能在業(yè)務(wù)平臺上有多少可復(fù)用的東西，能在實(shí)現(xiàn)需求的情況下減少開發(fā)？

原來已提供一套充值的H5頁面，可嵌入到APP里。不過從用戶使用的角度看，假設(shè)小愛音箱不能連wifi，里面有一張流量卡需要買流量套餐。

那么在APP里面可以完全不提到流量卡，只說給設(shè)備購買流量服務(wù)，有一個(gè)流量充值入口。

原頁面進(jìn)來是看當(dāng)前流量卡的套餐及使用詳情，點(diǎn)擊另一個(gè)按鈕才可以續(xù)費(fèi)。

那我們完全可以讓用戶直接抵達(dá)充值頁面，流量卡的詳情放在第二級，也就是說原來的H5頁面并不是很完美。

業(yè)務(wù)平臺的賬號體系，在和技術(shù)的討論中得知，對未來接口合并沒有幫助，既然如此，那就放在運(yùn)營平臺。

五、梳理具體功能清單：確定具體做什么

這一步確定怎么做之后的方案細(xì)化，講具體怎么做以原型和文檔的方式固定下來。

功能清單列出來，思路已經(jīng)非常清晰，剩下的就只是畫原型和寫需求文檔了，Axure的高手兩個(gè)小時(shí)就繪制完畢了。

六、給需求排優(yōu)先級：決定什么時(shí)候做

需求提出方一般都會有一個(gè)期望交付時(shí)間，有些人過分一點(diǎn)就說越快越好。心里忍不住生氣：越快越好？是多快？24小時(shí)加班搞夠不夠快不快？

需求方是站在自己的角度出發(fā)給了一個(gè)期望時(shí)間，可是研發(fā)資源相當(dāng)于公共基礎(chǔ)資源，除非是特別大又有錢的公司，不然研發(fā)資源總是稀缺。

排優(yōu)先級顯得非常重要，可以讓他們始終在忙目前對公司來說最重要的東西。

定完優(yōu)先級，就知道什么時(shí)候做了；再預(yù)估一下工期，就知道什么時(shí)候能交付了。需求方問你，心里就不慌了。

七、總結(jié)

5W2H原則廣泛適用于各行各業(yè)，不過在產(chǎn)品一行，我覺得他的幾個(gè)問題的順序可以些微調(diào)整一下：

1. 通過問what、why來了解需求：需求方最終的目的是什么？這個(gè)需求是干什么事的？
2. 通過問how 、how much來制定方案：陳列出方案與最期望達(dá)成的目標(biāo)，將兩者放在蹺蹺板上，不斷調(diào)整，選擇出性價(jià)比最高的方案。
3. 通過問where來揭曉它和已有產(chǎn)品的關(guān)系,從而確定who：當(dāng)公司既有業(yè)務(wù)平臺又有運(yùn)營平臺時(shí)，可以通過三連問來確定到底在那個(gè)產(chǎn)品上來做需求。
4. 通過問when來排定需求優(yōu)先級：從公司戰(zhàn)略層面確定好優(yōu)先級我們就知道什么時(shí)候可以開始做了。

作者：榮三歌 ；公眾號：奇怪的猩猩

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

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