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

19 评论 8809 浏览 41 收藏 12 分钟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 同样的需求,如果开发方式是,来一个需求做一个需求,那么开发时间是: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点:

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

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

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

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

 

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

本文由 @Lisa Deng 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 好文,一看就懂

    来自湖南 回复
  2. 这种方式好好啊!谢谢 Lisa,希望你可以写更多这种帮助产品理解技术的文章~~

    来自浙江 回复
    1. 我尽力呀

      回复
  3. 学习了~~~

    来自云南 回复
    1. 蟹蟹

      回复
  4. 很棒呀

    回复
    1. 谢谢啦

      回复
  5. 😉 不敢怒怼开发啊

    来自山东 回复
    1. 大胆一点

      回复
  6. 哇 受益匪浅

    来自江西 回复
    1. 👏👏

      回复
  7. 对新汪很有帮助~干货呀

    来自河南 回复
    1. 嗯嗯,就是写给新人看的。有帮助就是最大的回报啦。

      回复
  8. 回复
    1. 职业喷?

      回复
    2. 01例子中的需求显然是需求分析师提的,成熟的需求分析师都给你拆解好了,而且产品经理本身也需要把需求拆解为可落地的“功能”。

      来自北京 回复
  9. 很有帮助

    回复
    1. 谢谢。

      来自广东 回复
  10. 很多内容都被删掉了,欢迎关注我的公众号呀~

    来自广东 回复