楠木軒

覆盤B端推送配置模塊:5W2H原則應用

由 簡振武 發佈於 科技

編輯導語: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 協議