长远的方案往往复杂程度高 ， 这个时候就要来取舍了 。
实现的方案和应该达到的效果像跷跷板的两头 ， 我们不断推演权衡中 ， 使其达到一个平衡状态 ， 这个时候就选出了一个性价比最高的方案 。
我的领导还给过一个快速做决策的金句：“业务上的需求可做可不做的 ， 那就不做；技术上的需求可做可不做的 ， 那就做 。 ”
他就是考虑到市场万变 ， 今天说想要这个 ， 说不定又要别的了 ， 在你把握不定的时候 ， 就别做了 。
但是技术上的问题 ， 比如的访问能力、架构的优化 ， 这些问题如果你不优化 ， 那就埋下了一个隐患 ， 迟早会爆发出问题 。
话说回来 ， 那么本次推送配置模块该怎么做呢？
1. 关于体系搭建
1方案一
启用平台体系 ， 并与业务平台进行映射 ， 推送配置作为一个功能 ， 有利于加强平台的综合服务能力 。
2方案二
启用业务平台 ， 业务平台采用树形结构 ， 目前一个对应一个树形节点 ， 在接口调用范围上不够灵活 。
如未来对外接口要统一一个调用 ， 那么它的工作量比放在平台还是小一些 。
和研发负责人讨论的结论是：两套体系都不采用 ， 后台有两套开放接口 ， 一套就是我提到的业务平台开放接口 ， 已经再投入使用；一套是在研、还未开放的 ， 两者很难合并 ， 未来也不一定非要合并 。
我们暂且把一个需要调用我们接口获取推送服务的客户称作“推送客户”那么新建一个推送客户时 ， 确定他可以获得的信息范围呢？
这里也有两个方案：
改造业务平台的范围 ， 新建时选择某个业务平台已经建立的 ， 记录其范围 。
直接选择业务平台的用户树 ， 圈定其范围 。
方案1有一个显著的问题是如果在业务平台修改了的范围 ， 那么平台是否要同步 。 不同步不合理 ， 同步太费劲 ， 因而在新建推送客户时选择方案1 。
2. 关于配置
1方案一
列表和配置项放置在同一页面 ， 坏处是不利于B端客户自己调整配置（不过目前暂无此需求 ， 都是我们）
2方案二
列表仅做和权限配置；推送配置放置在另一页面 ， 可由B端客户自己登陆平台配置 。
坏处是我司人员如何给B端客户配置呢？难道要登录客户的？其实也未尝不可 ， 初始的时候给一个默认值 。
讨论后的结论：前期客户并无配置需求 ， 最终还是由我司把控 ， 未来的事情太远 ， 看不真切 ， 最后决定采用方案一 。
3. 关于开放接口
讨论后的结论：同“关于体系搭建”一样 ， 做到形似 ， 不强求合并 。 不合并的弊端就是对外给出的接口调用未统一；API未统一规范 。
四、与产品的关系：确定在哪里做 ， 谁来做
从业务上来看 ， 它是属于流量业务；从属性上来看 ， 具有属性 。 在我司也是既有业务平台 ， 也有综合平台 。 到底放哪里更合适呢？这取决于我们用什么方案来实现？采用什么方案又取决于我们要做到什么程度 。
1. 首先我们要做到什么程度？
在前一章的讨论中我们已经决定未来不一定合并公司全部开放接口 ， 这一次也不需要考虑将开放给用户去配置 。
2. 其次该功能偏业务还是偏？
【从一个推送配置模块的设计到交付，用5W2H原则】到期提醒、降速提醒等原来是按照默认的规则写好 ， 无法支持自定义 。
这些会更偏重 ， 关键在于什么时候发送？发送什么内容？发送几次？
3. 最后该功能该功能在业务平台上有多少可复用的东西 ， 能在实现需求的情况下减少？
那么在APP里面可以完全不提到流量卡 ， 只说给设备购买流量服务 ， 有一个流量充值入口 。
那我们完全可以让用户直接抵达充值页面 ， 流量卡的详情放在第二级 ， 也就是说原来的H5页面并不是很完美 。
业务平台的体系 ， 在和技术的讨论中得知 ， 对未来接并没有帮助 ， 既然如此 ， 那就放在平台 。

来源：(未知)

【江苏龙网】网址：/a/2021/0326/lmkd0ZA001492020.html

标题：从一个推送配置模块的设计到交付，用5W2H原则( 二 )