编辑导语：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 协议