数极客首页

需求“简简单单”,后台开发为什么要做好几天?

数极客,拥有16种数据分析模型的新一代用户行为分析平台!

当产品经理和后台开发提需求时,本以为小迭代、小需求简简单单,但在后台开发眼中却有些麻烦。那么在需求实现的角度上,是什么原因导致的呢?我们又该如何从后台开发的视角去理解需求的实现过程呢?

需求“简简单单”,后台开发为什么要做好几天?

在产品同质化严重的当下,竞争的主战场早已从产品价值转移到了开发效率运营策略

运营策略经过几番摸爬滚打总能找到节奏,但开发效率却是很难在短时间内提升。因为作为一个产品经理,你不仅需要了解技术,用开发小哥能听明白的话语描述需求,更重要的是让技术团队与你一条心一起走。

所以一个略懂技术的产品经理会非常占优势。无数个夜晚,你会不会在月光前发愿,要是技术小哥每次对我说这句话就好了:这个需求很清晰,我们隔天就能上线

可残酷的现实,就像你的丈母娘一样总在啪啪打你的脸:

  • 你认为“很简单”的小需求,开发小哥评估至少要N天才能完成;
  • 明明别人都已经实现的功能,怎么在我们这里就实现不了了?
  • 你认为只是优化的小迭代,在开发小哥这里怎么就变成了动架构了?

今天丽莎阿姨就要带着你一起走进后台技术小哥的内心世界,一起去开悟之坡~

01 一个需求,后台到底在做什么?

举个例子:一个英语学习的APP,我们希望用户发布了录音后,可以让他的粉丝也能看到他发布的录音。

需求“简简单单”,后台开发为什么要做好几天?

在这个看似简单的需求里,后台开发会如何处理这些数据呢?

  • 第一步,将流程里包含的信息拆解为:用户(小A、小B)、行为(录音、发布、收听)、数据(读音)
  • 第二步,维护好用户数据,确保在需要的时候可以快速地访问到。
需求“简简单单”,后台开发为什么要做好几天?

这下你明白了吗?当你在表达一个需求的时候,其实是在描述一个现象,而后台小哥就会把这个现象结构化地拆解为:用户、行为、数据以及之间的运转逻辑

所以在今后的需求沟通中,我们不妨也可以提前做一下这样的拆解,这样沟通效率就会大大提升了。

02 这个需求很简单,为什么要开发N天?

某一天,你跟开发小哥说:既然我们已经实现了粉丝可以听到录音,那么再增加一个粉丝可以看到视频的功能吧,这个需求应该很简单,交互逻辑之前都是一样的,是不是很快就能上线呀?

开发小哥一番评审告诉你:2天~

此时在你心里是不是觉得:不是一样的东西吗?好像半天就能搞定的事情,为啥要花两天?

那么这两天后台小哥到底在做什么呢?

需求“简简单单”,后台开发为什么要做好几天?

在我们看来录音和视频现象都是一致的,但在后台小哥的开发中是非常不同的。前文提到,后台开发主要是处理用户行为,维护用户数据,这个不同就是在于数据上。

如果最开始开发没有考虑扩容性,那么录音数据与视频数据就是两个截然不同的接口,所以开发周期当然是一样的。

需求“简简单单”,后台开发为什么要做好几天?

但是,如果我们在一开始就告诉开发小哥,未来业务的逻辑是需要支持录音也有可能支持视频的,这种情况下,数据接口就可以在一开始的时候就做好适配设计

什么叫适配设计,其实就是增加一个数据适配器(类似电脑的转接头),让功能可以支持更多类型的数据。

需求“简简单单”,后台开发为什么要做好几天?

这样一对比,我们就知道了:

  • 同样的需求,如果开发方式是,来一个需求做一个需求,那么开发时间是:2 天录音 + 2 天视频 = 4 天
  • 如果一开始就告诉开发小哥未来业务可能的扩展性,一开始就考虑了数据接口适配,那么总体的开发时间是:2 天录音 + 0.5 天扩展性 + 0.5天视频 = 3 天

怎么样?以后不要再抱怨你们开发小哥能力不行或者效率太低了哦。最根本的原因还是在于产品经理是否足够有预见性与规划性。

03 为什么同样的功能,体验总是不尽如人意?

还是前面的例子,让粉丝听到关注者的录音的功能。有时候你发现,完全一样的功能,在人家的产品上和自己的产品上体验怎么会差很多?好像我们的页面总是不那么顺滑,那真正的原因到底是什么?

其实主要的问题就出在开发方式上:

开发方式A:用户点击发布录音,后台保存录音,并为每个粉丝逐个生成数据,然后通知用户发布成功。

从逻辑上来看流程很简单,速度应该很快。可是,一旦这个用户拥有百万粉丝,那么② ~ ④ 的过程变为需要给百万粉丝都生成完数据后,再反馈用户成功,这中间的等待时间非常非常非常长,这个时候你不慢谁慢?

需求“简简单单”,后台开发为什么要做好几天?

而开发方式B:用户点击发布录音,后台保存录音,立刻反馈用户发布成功。然后,再逐个为粉丝生成数据,通知粉丝。

妙就妙在,这个过程中,我们将粉丝收到录音过程的实时性舍弃掉了,而发布录音者却能很快得到反馈,在使用感官上,体验就非常棒了。

需求“简简单单”,后台开发为什么要做好几天?

明白了吗?同样的功能,如果你能清晰的交代清楚,哪些场景是需要实时的,哪些场景是不需要实时的,用户量的情况等等,开发小哥就可以引入异步化或者其他的开发方式,极大地优化产品的用户体验。

04 功能刚上线响应还很快,后来怎么逐渐变慢了?

还是这个录音数据的例子,这个功能上线一段时间之后,突然某一天有用户反馈说,怎么加载越来越慢了?前两天还好好的呀,问题又出在了哪里?

其实,主要的问题是出在数据量上。我们再回归到功能本身,一个有百万粉丝的大V发布录音,那么产生的数据量 = 录音数 2223_37_20191224175437.csv spark-jobs 100万,这个过程中数据膨胀是非常快的。

如果你要去查询数据,就必须从1~100w一个一个去查,就算你把数据进行了分类检索,还是会不可避免的慢。

需求“简简单单”,后台开发为什么要做好几天?

如果,我们改变一下开发方式,同样的录音,我们只把数据推给近期活跃的用户,而对于不活跃用户,我们在他上线时再推,情况会不会好很多呢?

需求“简简单单”,后台开发为什么要做好几天?

根据早些年新浪微博和腾讯微博的用户分析结果,大V的僵尸粉或不活跃用户占比均达到16.96%和56.73%,这部分僵尸粉基本不上线,或者不查看信息。使用这种方案,可以极大地减缓数据膨胀的速度,实际产生的数据量会指数级下降。

所以,明白了吗?一个功能慢或者不慢,其实主要差距就是在对数据的处理方式上,一个优秀的产品经理,如果能了解这部分原理,就能与开发小哥一起设计一款体验良好,并且维护成本极低的产品。

05 增加一个小功能,开发小哥怎么看起来很为难?

有没有试过,当你与开发小哥提一个你看起来觉得很小的需求时,他们会满脸畏难:这不好搞啊~代码改起来非常恶心。

恶心?why?

其实就像下面这两个例子,A、B分别代表了两个功能的代码逻辑,这时有一个需求,需要在流程结束前,增加一个操作。

需求“简简单单”,后台开发为什么要做好几天?

这个时候你会有什么感受?哈哈哈~~

在代码流程A里,需要在4个不同的部分增加这个操作,而代码流程B,只需要增加1个操作,这就是为什么代码改得很“恶心”的主要原因。因为如果一开始代码流程逻辑就是混乱的,新需求会变得非常复杂且繁多。

同样是开发功能、写代码,为什么会导致这样的差别呢?主要原因以下3点:

  1. 功能设计不合理,代码逻辑不清晰,扩展性差
  2. 业务迭代,功能不断更新,模块逐渐臃肿
  3. 时间不够,先上线、后优化

对,你想的没错,其实就是代码写得“差”,敞开你的嗓子,放心地怼开发小哥就好,哈哈哈哈~

相信阿姨,把这篇文章看明白,拿着需求好好评审,“怒怼”开发小哥一百遍。

孙子曰:用兵者,役不再籍,粮不三载。一次把事情做对,一次搞定,不返工,就是最高的效率,一起加油哦~

 

作者:Lisa Deng;公众号:丽莎D的产品手记

本文由 @Lisa Deng 原创发布,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

数极客是新一代用户行为分析与数据智能平台,支持用户数据分析运营数据分析留存分析路径分析漏斗分析用户画像SEM数据分析等16种分析模型的数据分析产品,支持网站统计网站分析APP统计APP分析等分析工具,以及会员营销系统A/B测试工具等数据智能应用,支持SAAS和私有化部署,提升用户留存和转化率,实现数据驱动增长!

发表评论

评论已关闭。

相关文章