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

一、産品的碎碎念

在我們還沒有能力做産品戰略規劃的時候，收到一個工作任務，我們應如何展開，既出色完成任務又讓自己有所提升？

1. 工作的惡性循環

有一些新人産品會覺得自己做得事情缺乏挑戰，沒有提升空間。所做之事無非是按照領導和業務人員的要求畫個原型、增加幾個參數修改功能、配置功能、導出功能，缺乏主動思考，或者覺得這個功能做得再好也沒什麼用。

他們可能對業務和團隊開發人員熟悉之後，就開始劃水了，也可能将時間花在了項目管理或開發框架等其它事情上，期望跳槽加個薪。

不認真的态度換不來出色的成績，沒有升職的機會，仍舊陷在初級的瑣碎的功能設計中。

2. 工作的良性循環

當我們在具體的工作事項中，多問幾個問什麼，不僅幫助我們更加深刻得理解業務，也能更出色的完成任務。

産品的技能不像研發同學，有具體的開發語言或者框架，如果你跟面試者說你表達能力好，邏輯思維能力強，人家還覺得你一無所長。

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

所以與其不認真的工作加一點似有似無的理論知識學習，不如認真工作，持續複盤總結。就算沒能獲得亮眼的數據成績，也能沉澱出來自己的方法論，正如我此刻在做的事情一樣。

下面我将從一個推送配置模塊的設計到交付，步步拆解，總結一套方法，希望也能給各位讀者帶來幫助。

5W2H法則：

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

二、了解需求：确定做什麼，為什麼做

當我們還沒有能力做産品規劃之前，需求總是由業務人員或者領導提出。剛開始它隻是一句話：“需要做一個推送配置，不同渠道用戶需要看到不同的續費頁面”。

不着急一次拎清楚，5W2H是從需求導入到功能輸出全流程的一個指導法則。

在了解需求階段，我們重點要整明白這個需求為什麼要做，目的是什麼。

在幾番詢問後，我了解到我們有好幾個客戶，他們采購了我們運營的流量卡，所以在他們自己開發的APP上需要有一個地方充值流量套餐，在流量服務快到期或不足時需要有相應的提醒，這樣可以提高續費率。

提高續費率對我司有益，對客戶也有益，因為我們的商業模式是按續費套餐給客戶一定的返點。

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

1. 痛點需求

1）給流量套餐充值

2）在對應場景作出提醒

2. 衍生需求

消息的埋點及數據分析

3. 規劃類需求

1）個性化充值頁面

2）提醒的個性化配置

三、列出實現方案：确定怎麼做，做到什麼程度

我們并非是定好一個目标，然後再定方案；而是讨論方案，并且不斷的調整我們的目标，最終得出一個最佳方案。

為什麼呢？

目标是可長遠可短視的，我們都希望是用一個長遠的方案來解決現在的問題，可未來是什麼樣子都沒有看真切，很難說你現在制定的所謂長遠的方案能夠在未來依然閃閃發光。

長遠的方案往往複雜程度高，這個時候就要來取舍了。

實現的方案和應該達到的效果像跷跷闆的兩頭，我們不斷推演權衡中，使其達到一個平衡狀态，這個時候就選出了一個性價比最高的方案。

我的領導還給過一個快速做決策的金句：“業務上的需求可做可不做的，那就不做；技術上的需求可做可不做的，那就做。”

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

但是技術上的問題，比如服務器的訪問能力、架構的優化，這些問題如果你不優化，那就埋下了一個隐患，遲早會爆發出問題。

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

1. 關于賬号體系搭建

1）方案一

啟用運營平台賬号體系，并與業務平台進行映射，推送配置作為一個運營功能，有利于加強運營平台的綜合運營服務能力。

2）方案二

啟用業務平台賬号，業務平台采用樹形結構，目前一個賬号對應一個樹形節點，在接口調用範圍上不夠靈活。

如未來對外接口要統一一個賬号調用，那麼它的工作量比放在運營平台還是小一些。

和研發負責人讨論的結論是：兩套賬号體系都不采用，後台有兩套開放接口，一套就是我提到的業務平台開放接口，已經再投入使用；一套是在研、還未開放的，兩者很難合并，未來也不一定非要合并。

同一個客戶提供兩個賬号讓其調用我司接口顯然不合理，但是我們可以将兩個賬号做成一模一樣的，那客戶在調兩邊的接口時就不會感覺到他實際上是調用的兩個平台。

我們暫且把一個需要調用我們接口獲取推送服務的客戶稱作“推送客戶”，那麼新建一個推送客戶時，然後确定他可以獲得的信息範圍呢？

這裡也有兩個方案：

1. 改造業務平台的賬号範圍，新建時選擇某個業務平台已經建立的賬号，記錄其範圍；
2. 直接選擇業務平台的用戶樹，圈定其範圍。

方案1有一個顯著的問題是如果在業務平台修改了賬号的範圍，那麼運營平台是否要同步。不同步不合理，同步太費勁，因而在新建推送客戶時選擇方案1。

2. 關于賬号配置

1）方案一

賬号列表和配置項放置在同一頁面，壞處是不利于B端客戶自己調整配置（不過目前暫無此需求，都是我們運營）。

2）方案二

賬号列表僅做管理和權限配置；推送配置放置在另一頁面，可由B端客戶自己登陸平台配置。

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

讨論後的結論：前期客戶并無配置需求，最終運營還是由我司把控，未來的事情太遠，看不真切，最後決定采用方案一。

3. 關于開放接口

原來麥聯寶已有一套API接口，裡面也包含了推送的幾個配置（掃二維碼續費、狀态變化、機卡分離、實名推送），配置項理應統一管理；而且對外接口是否應全部歸在一起，使我們的客戶在與我司任意一款産品對接時都是同一套賬号密匙。

讨論後的結論：同“關于賬号體系搭建”一樣，做到形似，不強求合并。不合并的弊端就是對外給出的接口調用賬号未統一管理；API未統一規範管理。

四、與産品的關系：确定在哪裡做，誰來做

從業務上來看，它是屬于流量業務；從屬性上來看，具有運營屬性。在我司也是既有業務平台，也有綜合運營平台。到底放哪裡更合适呢？這取決于我們用什麼方案來實現？采用什麼方案又取決于我們要做到什麼程度。

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

在前一章的讨論中我們已經決定未來不一定合并公司全部開放接口，這一次也不需要考慮将賬号開放給用戶去配置。

2. 其次該功能偏業務還是偏運營？

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

這些會更偏重運營，關鍵在于什麼時候發送？發送什麼内容？發送幾次？

3. 最後該功能該功能在業務平台上有多少可複用的東西，能在實現需求的情況下減少開發？

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

那麼在APP裡面可以完全不提到流量卡，隻說給設備購買流量服務，有一個流量充值入口。

原頁面進來是看當前流量卡的套餐及使用詳情，點擊另一個按鈕才可以續費。

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

業務平台的賬号體系，在和技術的讨論中得知，對未來接口合并沒有幫助，既然如此，那就放在運營平台。

五、梳理具體功能清單：确定具體做什麼

這一步确定怎麼做之後的方案細化，講具體怎麼做以原型和文檔的方式固定下來。

功能清單列出來，思路已經非常清晰，剩下的就隻是畫原型和寫需求文檔了，Axure的高手兩個小時就繪制完畢了。

六、給需求排優先級：決定什麼時候做

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

需求方是站在自己的角度出發給了一個期望時間，可是研發資源相當于公共基礎資源，除非是特别大又有錢的公司，不然研發資源總是稀缺。

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

定完優先級，就知道什麼時候做了；再預估一下工期，就知道什麼時候能交付了。需求方問你，心裡就不慌了。

七、總結

5W2H原則廣泛适用于各行各業，不過在産品一行，我覺得他的幾個問題的順序可以些微調整一下：

1. 通過問what、why來了解需求：需求方最終的目的是什麼？這個需求是幹什麼事的？
2. 通過問how 、how much來制定方案：陳列出方案與最期望達成的目标，将兩者放在跷跷闆上，不斷調整，選擇出性價比最高的方案。
3. 通過問where來揭曉它和已有産品的關系,從而确定who：當公司既有業務平台又有運營平台時，可以通過三連問來确定到底在那個産品上來做需求。
4. 通過問when來排定需求優先級：從公司戰略層面确定好優先級我們就知道什麼時候可以開始做了。

作者：榮三歌 ；公衆号：奇怪的猩猩

本文由 @榮三歌 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部