江苏龙网

  1. 首页 > 人文 > >

【产品经理】需求“简简单单”，后台开发为什么要做好几天？( 二 )


但是 ， 如果我们在一开始就告诉开发小哥 ， 未来业务的逻辑是需要支持录音也有可能支持视频的 ， 这种情况下 ， 数据接口就可以在一开始的时候就做好适配设计 。
什么叫适配设计 ， 其实就是增加一个数据适配器（类似电脑的转接头） ， 让功能可以支持更多类型的数据 。
这样一对比 ， 我们就知道了：
同样的需求 ， 如果开发方式是 ， 来一个需求做一个需求 ， 那么开发时间是：2 天录音 + 2 天视频 = 4 天如果一开始就告诉开发小哥未来业务可能的扩展性 ， 一开始就考虑了数据接口适配 ， 那么总体的开发时间是：2 天录音 + 0.5 天扩展性 + 0.5天视频 = 3 天怎么样？以后不要再抱怨你们开发小哥能力不行或者效率太低了哦 。 最根本的原因还是在于产品经理是否足够有预见性与规划性 。
03 为什么同样的功能 ， 体验总是不尽如人意？
其实主要的问题就出在开发方式上：
开发方式A：用户点击发布录音 ， 后台保存录音 ， 并为每个粉丝逐个生成数据 ， 然后通知用户发布成功 。
从逻辑上来看流程很简单 ， 速度应该很快 。 可是 ， 一旦这个用户拥有百万粉丝 ， 那么② ~ ④ 的过程变为需要给百万粉丝都生成完数据后 ， 再反馈用户成功 ， 这中间的等待时间非常非常非常长 ， 这个时候你不慢谁慢？
而开发方式B：用户点击发布录音 ， 后台保存录音 ， 立刻反馈用户发布成功 。 然后 ， 再逐个为粉丝生成数据 ， 通知粉丝 。
妙就妙在 ， 这个过程中 ， 我们将粉丝收到录音过程的实时性舍弃掉了 ， 而发布录音者却能很快得到反馈 ， 在使用感官上 ， 体验就非常棒了 。
明白了吗？同样的功能 ， 如果你能清晰的交代清楚 ， 哪些场景是需要实时的 ， 哪些场景是不需要实时的 ， 用户量的情况等等 ， 开发小哥就可以引入异步化或者其他的开发方式 ， 极大地优化产品的用户体验 。
04 功能刚上线响应还很快 ， 后来怎么逐渐变慢了？
还是这个录音数据的例子 ， 这个功能上线一段时间之后 ， 突然某一天有用户反馈说 ， 怎么加载越来越慢了？前两天还好好的呀 ， 问题又出在了哪里？
其实 ， 主要的问题是出在数据量上 。 我们再回归到功能本身 ， 一个有百万粉丝的大V发布录音 ， 那么产生的数据量 = 录音数 * 100万 ， 这个过程中数据膨胀是非常快的 。
如果你要去查询数据 ， 就必须从1~100w一个一个去查 ， 就算你把数据进行了分类检索 ， 还是会不可避免的慢 。
如果 ， 我们改变一下开发方式 ， 同样的录音 ， 我们只把数据推给近期活跃的用户 ， 而对于不活跃用户 ， 我们在他上线时再推 ， 情况会不会好很多呢？
根据早些年新浪微博和腾讯微博的用户分析结果 ， 大V的僵尸粉或不活跃用户占比均达到16.96%和56.73% ， 这部分僵尸粉基本不上线 ， 或者不查看信息 。 使用这种方案 ， 可以极大地减缓数据膨胀的速度 ， 实际产生的数据量会指数级下降 。
所以 ， 明白了吗？一个功能慢或者不慢 ， 其实主要差距就是在对数据的处理方式上 ， 一个优秀的产品经理 ， 如果能了解这部分原理 ， 就能与开发小哥一起设计一款体验良好 ， 并且维护成本极低的产品 。
05 增加一个小功能 ， 开发小哥怎么看起来很为难？
有没有试过 ， 当你与开发小哥提一个你看起来觉得很小的需求时 ， 他们会满脸畏难：这不好搞啊~代码改起来非常恶心 。
恶心？why？
其实就像下面这两个例子 ， A、B分别代表了两个功能的代码逻辑 ， 这时有一个需求 ， 需要在流程结束前 ， 增加一个操作 。
这个时候你会有什么感受？哈哈哈~~
在代码流程A里 ， 需要在4个不同的部分增加这个操作 ， 而代码流程B ， 只需要增加1个操作 ， 这就是为什么代码改得很“恶心”的主要原因 。 因为如果一开始代码流程逻辑就是混乱的 ， 新需求会变得非常复杂且繁多 。


推荐阅读


上一篇：手机大魔王■最后一款价格很厚道，目前小米最值得买的3款手机

下一篇：媒体菌▲小米依然低迷，各大手机品牌近三个月销量数据曝光！“华V”领衔