編輯導語：B端，代表企業用户商家Business，本質是為滿足用户的工作需求，往往是基於公司層面多人對某一問題解決方案進行整體評估。在本篇文章中，作者用5W2H原則，從一個推送配置模塊的設計到交付，步步拆解，總結一套方法，希望能給各位讀者帶來幫助。
在我們還沒有能力做產品戰略規劃的時候，收到一個工作任務，我們應如何展開，既出色完成任務又讓自己有所提升？
1. 工作的惡性循環有一些新人產品會覺得自己做得事情缺乏挑戰，沒有提升空間。所做之事無非是按照領導和業務人員的要求畫個原型、增加幾個參數修改功能、配置功能、導出功能，缺乏主動思考，或者覺得這個功能做得再好也沒什麼用。
他們可能對業務和團隊開發人員熟悉之後，就開始划水了，也可能將時間花在了項目管理或開發框架等其它事情上，期望跳槽加個薪。
不認真的態度換不來出色的成績，沒有升職的機會，仍舊陷在初級的瑣碎的功能設計中。
2. 工作的良性循環當我們在具體的工作事項中，多問幾個問什麼，不僅幫助我們更加深刻得理解業務，也能更出色的完成任務。
產品的技能不像研發同學，有具體的開發語言或者框架，如果你跟面試者説你表達能力好，邏輯思維能力強，人家還覺得你一無所長。
對於面試來説，過往的成績才是最好的證明。
所以與其不認真的工作加一點似有似無的理論知識學習，不如認真工作，持續覆盤總結。就算沒能獲得亮眼的數據成績，也能沉澱出來自己的方法論，正如我此刻在做的事情一樣。
下面我將從一個推送配置模塊的設計到交付，步步拆解，總結一套方法，希望也能給各位讀者帶來幫助。
5W2H法則：
- WHAT——是什麼？目的是什麼？做什麼工作？
- WHY——為什麼要做？可不可以不做？
- WHO——由誰來做？
- WHEN——何時？什麼時間做？什麼時機最適宜？
- WHERE——何處？在哪裏做？
- HOW ——怎麼做？如何提高效率？如何實施？方法是什麼？
- HOW MUCH——多少？做到什麼程度？
當我們還沒有能力做產品規劃之前，需求總是由業務人員或者領導提出。剛開始它只是一句話：“需要做一個推送配置，不同渠道用户需要看到不同的續費頁面”。
不着急一次拎清楚，5W2H是從需求導入到功能輸出全流程的一個指導法則。
在瞭解需求階段，我們重點要整明白這個需求為什麼要做，目的是什麼。
在幾番詢問後，我瞭解到我們有好幾個客户，他們採購了我們運營的流量卡，所以在他們自己開發的APP上需要有一個地方充值流量套餐，在流量服務快到期或不足時需要有相應的提醒，這樣可以提高續費率。
提高續費率對我司有益，對客户也有益，因為我們的商業模式是按續費套餐給客户一定的返點。
我將這些需求分為以下幾種類型：
1. 痛點需求1）給流量套餐充值
2）在對應場景作出提醒
2. 衍生需求消息的埋點及數據分析
3. 規劃類需求1）個性化充值頁面
2）提醒的個性化配置
三、列出實現方案：確定怎麼做，做到什麼程度我們並非是定好一個目標，然後再定方案；而是討論方案，並且不斷的調整我們的目標，最終得出一個最佳方案。
為什麼呢？
目標是可長遠可短視的，我們都希望是用一個長遠的方案來解決現在的問題，可未來是什麼樣子都沒有看真切，很難説你現在制定的所謂長遠的方案能夠在未來依然閃閃發光。
長遠的方案往往復雜程度高，這個時候就要來取捨了。
實現的方案和應該達到的效果像蹺蹺板的兩頭，我們不斷推演權衡中，使其達到一個平衡狀態，這個時候就選出了一個性價比最高的方案。
我的領導還給過一個快速做決策的金句：“業務上的需求可做可不做的，那就不做；技術上的需求可做可不做的，那就做。”
他就是考慮到市場萬變，今天銷售説想要這個，説不定又要別的了，在你把握不定的時候，就別做了。
但是技術上的問題，比如服務器的訪問能力、架構的優化，這些問題如果你不優化，那就埋下了一個隱患，遲早會爆發出問題。
話説回來，那麼本次推送配置模塊該怎麼做呢？
1. 關於賬號體系搭建1）方案一
啓用運營平台賬號體系，並與業務平台進行映射，推送配置作為一個運營功能，有利於加強運營平台的綜合運營服務能力。
2）方案二
啓用業務平台賬號，業務平台採用樹形結構，目前一個賬號對應一個樹形節點，在接口調用範圍上不夠靈活。
如未來對外接口要統一一個賬號調用，那麼它的工作量比放在運營平台還是小一些。
和研發負責人討論的結論是：兩套賬號體系都不採用，後台有兩套開放接口，一套就是我提到的業務平台開放接口，已經再投入使用；一套是在研、還未開放的，兩者很難合併，未來也不一定非要合併。
同一個客户提供兩個賬號讓其調用我司接口顯然不合理，但是我們可以將兩個賬號做成一模一樣的，那客户在調兩邊的接口時就不會感覺到他實際上是調用的兩個平台。
我們暫且把一個需要調用我們接口獲取推送服務的客户稱作“推送客户”，那麼新建一個推送客户時，然後確定他可以獲得的信息範圍呢？
這裏也有兩個方案：
- 改造業務平台的賬號範圍，新建時選擇某個業務平台已經建立的賬號，記錄其範圍；
- 直接選擇業務平台的用户樹，圈定其範圍。
方案1有一個顯著的問題是如果在業務平台修改了賬號的範圍，那麼運營平台是否要同步。不同步不合理，同步太費勁，因而在新建推送客户時選擇方案1。
2. 關於賬號配置1）方案一
賬號列表和配置項放置在同一頁面，壞處是不利於B端客户自己調整配置（不過目前暫無此需求，都是我們運營）。
2）方案二
賬號列表僅做管理和權限配置；推送配置放置在另一頁面，可由B端客户自己登陸平台配置。
壞處是我司人員如何給B端客户配置呢？難道要登錄客户的賬號？其實也未嘗不可，初始的時候給一個默認值。
討論後的結論：前期客户並無配置需求，最終運營還是由我司把控，未來的事情太遠，看不真切，最後決定採用方案一。
3. 關於開放接口原來麥聯寶已有一套API接口，裏面也包含了推送的幾個配置（掃二維碼續費、狀態變化、機卡分離、實名推送），配置項理應統一管理；而且對外接口是否應全部歸在一起，使我們的客户在與我司任意一款產品對接時都是同一套賬號密匙。
討論後的結論：同“關於賬號體系搭建”一樣，做到形似，不強求合併。不合並的弊端就是對外給出的接口調用賬號未統一管理；API未統一規範管理。
四、與產品的關係：確定在哪裏做，誰來做從業務上來看，它是屬於流量業務；從屬性上來看，具有運營屬性。在我司也是既有業務平台，也有綜合運營平台。到底放哪裏更合適呢？這取決於我們用什麼方案來實現？採用什麼方案又取決於我們要做到什麼程度。
1. 首先我們要做到什麼程度？在前一章的討論中我們已經決定未來不一定合併公司全部開放接口，這一次也不需要考慮將賬號開放給用户去配置。
2. 其次該功能偏業務還是偏運營？到期提醒、降速提醒等原來是按照默認的規則寫好，無法支持自定義。
這些會更偏重運營，關鍵在於什麼時候發送？發送什麼內容？發送幾次？
3. 最後該功能該功能在業務平台上有多少可複用的東西，能在實現需求的情況下減少開發？
原來已提供一套充值的H5頁面，可嵌入到APP裏。不過從用户使用的角度看，假設小愛音箱不能連wifi，裏面有一張流量卡需要買流量套餐。
那麼在APP裏面可以完全不提到流量卡，只説給設備購買流量服務，有一個流量充值入口。
原頁面進來是看當前流量卡的套餐及使用詳情，點擊另一個按鈕才可以續費。
那我們完全可以讓用户直接抵達充值頁面，流量卡的詳情放在第二級，也就是説原來的H5頁面並不是很完美。
業務平台的賬號體系，在和技術的討論中得知，對未來接口合併沒有幫助，既然如此，那就放在運營平台。
五、梳理具體功能清單：確定具體做什麼這一步確定怎麼做之後的方案細化，講具體怎麼做以原型和文檔的方式固定下來。
功能清單列出來，思路已經非常清晰，剩下的就只是畫原型和寫需求文檔了，Axure的高手兩個小時就繪製完畢了。
六、給需求排優先級：決定什麼時候做需求提出方一般都會有一個期望交付時間，有些人過分一點就説越快越好。心裏忍不住生氣：越快越好？是多快？24小時加班搞夠不夠快不快？
需求方是站在自己的角度出發給了一個期望時間，可是研發資源相當於公共基礎資源，除非是特別大又有錢的公司，不然研發資源總是稀缺。
排優先級顯得非常重要，可以讓他們始終在忙目前對公司來説最重要的東西。
定完優先級，就知道什麼時候做了；再預估一下工期，就知道什麼時候能交付了。需求方問你，心裏就不慌了。
七、總結5W2H原則廣泛適用於各行各業，不過在產品一行，我覺得他的幾個問題的順序可以些微調整一下：
- 通過問what、why來了解需求：需求方最終的目的是什麼？這個需求是幹什麼事的？
- 通過問how 、how much來制定方案：陳列出方案與最期望達成的目標，將兩者放在蹺蹺板上，不斷調整，選擇出性價比最高的方案。
- 通過問where來揭曉它和已有產品的關係,從而確定who：當公司既有業務平台又有運營平台時，可以通過三連問來確定到底在那個產品上來做需求。
- 通過問when來排定需求優先級：從公司戰略層面確定好優先級我們就知道什麼時候可以開始做了。
作者：榮三歌 ；公眾號：奇怪的猩猩
本文由 @榮三歌 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議