中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：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）提醒的個性化配置

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

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

為什么呢？

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

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

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

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

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

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

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

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 協議