推送|复盘B端推送配置模块：5W2H原则应用
编辑导语：B端 ， 代表企业用户商家Business ， 本质是为满足用户的工作需求 ， 往往是基于公司层面多人对某一问题解决方案进行整体评估 。 在本篇文章中 ， 作者用5W2H原则 ， 从一个推送配置模块的设计到交付 ， 步步拆解 ， 总结一套方法 ， 希望能给各位读者带来帮助 。
本文插图
一、产品的碎碎念
在我们还没有能力做产品战略规划的时候 ， 收到一个工作任务 ， 我们应如何展开 ， 既出色完成任务又让自己有所提升？
1. 工作的恶性循环
有一些新人产品会觉得自己做得事情缺乏挑战 ， 没有提升空间 。 所做之事无非是按照领导和业务人员的要求画个原型、增加几个参数修改功能、配置功能、导出功能 ， 缺乏主动思考 ， 或者觉得这个功能做得再好也没什么用 。
他们可能对业务和团队开发人员熟悉之后 ， 就开始划水了 ， 也可能将时间花在了项目管理或开发框架等其它事情上 ， 期望跳槽加个薪 。
不认真的态度换不来出色的成绩 ， 没有升职的机会 ， 仍旧陷在初级的琐碎的功能设计中 。
2. 工作的良性循环
当我们在具体的工作事项中 ， 多问几个问什么 ， 不仅帮助我们更加深刻得理解业务 ， 也能更出色的完成任务 。
产品的技能不像研发同学 ， 有具体的开发语言或者框架 ， 如果你跟面试者说你表达能力好 ， 逻辑思维能力强 ， 人家还觉得你一无所长 。
对于面试来说 ， 过往的成绩才是最好的证明 。
所以与其不认真的工作加一点似有似无的理论知识学习 ， 不如认真工作 ， 持续复盘总结 。 就算没能获得亮眼的数据成绩 ， 也能沉淀出来自己的方法论 ， 正如我此刻在做的事情一样 。
【推送|复盘B端推送配置模块：5W2H原则应用】下面我将从一个推送配置模块的设计到交付 ， 步步拆解 ， 总结一套方法 ， 希望也能给各位读者带来帮助 。
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 协议
推荐阅读
- 鸡蛋这样做太香了，不用蒸不用煎，早餐端上桌，3分钟就光盘，香
- 同事来做客，我准备了8菜1汤，半小时端上桌，吃个精光汤也不剩
- 职场妈妈准备晚餐，方便省心营养全，30分钟端上桌，家人都满意
- 土豆和鸡蛋才是绝配，做孩子爱的煎饼，松软香糯，刚端上桌就清光
- 入秋后，此菜再贵也要买，孩子吃了，身体棒个子高，端上桌就秒光
- 端午将至，多给家人吃此菜，每天炒一盘，简单易学，孩子长个头
- 简单又好吃的爽口的下饭菜，鲜美开胃，端上桌都抢着伸筷，秒光！
- 刚端上桌的饭菜，馋得家人抢着吃，被一扫而光！常吃抗菌身体壮！
- 几道家常菜往桌上一端，全家抢着吃，你一筷子我一筷子，秒光！
- 端午前最该吃它，是“穷人的阿胶”，3块钱一斤，女人常吃腰不疼！