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

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

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

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

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

• 你认为“很简单”的小需求，开发小哥评估至少要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协议