复盘B端推送配置模块:5W2H原则应用

编辑导语:B端,代表企业用户商家Business,本质是为满足用户的工作需求,往往是基于公司层面多人对某一问题解决方案进行整体评估。在本篇文章中,作者用5W2H原则,从一个推送配置模块的设计到交付,步步拆解,总结一套方法,希望能给各位读者带来帮助。

复盘B端推送配置模块: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页面并不是很完美。

业务平台的账号体系,在和技术的讨论中得知,对未来接口合并没有帮助,既然如此,那就放在运营平台。

五、梳理具体功能清单:确定具体做什么

这一步确定怎么做之后的方案细化,讲具体怎么做以原型和文档的方式固定下来。

复盘B端推送配置模块:5W2H原则应用

功能清单列出来,思路已经非常清晰,剩下的就只是画原型和写需求文档了,Axure的高手两个小时就绘制完毕了。

六、给需求排优先级:决定什么时候做

需求提出方一般都会有一个期望交付时间,有些人过分一点就说越快越好。心里忍不住生气:越快越好?是多快?24小时加班搞够不够快不快?

需求方是站在自己的角度出发给了一个期望时间,可是研发资源相当于公共基础资源,除非是特别大又有钱的公司,不然研发资源总是稀缺。

排优先级显得非常重要,可以让他们始终在忙目前对公司来说最重要的东西。

定完优先级,就知道什么时候做了;再预估一下工期,就知道什么时候能交付了。需求方问你,心里就不慌了。

七、总结

5W2H原则广泛适用于各行各业,不过在产品一行,我觉得他的几个问题的顺序可以些微调整一下:

  1. 通过问what、why来了解需求:需求方最终的目的是什么?这个需求是干什么事的?
  2. 通过问how 、how much来制定方案:陈列出方案与最期望达成的目标,将两者放在跷跷板上,不断调整,选择出性价比最高的方案。
  3. 通过问where来揭晓它和已有产品的关系,从而确定who:当公司既有业务平台又有运营平台时,可以通过三连问来确定到底在那个产品上来做需求。
  4. 通过问when来排定需求优先级:从公司战略层面确定好优先级我们就知道什么时候可以开始做了。

作者:荣三歌 ;公众号:奇怪的猩猩

本文由 @荣三歌 原创发布于。未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

(0)
小多多的头像小多多创始人

相关推荐

发表回复

登录后才能评论