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

作者：Lisa Deng，教育公司产品总监

题图来自 Unsplash，基于 CC0 协议

—————— BEGIN ——————

在产品同质化严重的当下，竞争的主战场早已从产品价值转移到了开发效率与运营策略：运营策略经过几番摸爬滚打总能找到节奏，但开发效率却是很难在短时间内提升。

作为一名产品经理，你不仅需要了解技术，用开发小哥能听明白的话语描述需求，更重要的是让技术团队与你一条心一起走。

所以，一个略懂技术的产品经理会非常占优势。

无数个夜晚，你会不会在月光前发愿，要是技术小哥每次对我说这句话就好了：这个需求很清晰，我们隔天就能上线。

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

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

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

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

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

孙子曰：用兵者，役不再籍，粮不三载。

一次把事情做对，一次搞定，不返工，就是最高的效率，一起加油哦~

天津市犀思科技有限公司是专业从事web应用定制开发的一家公司，主营业务包括定制功能型网站建设开发、微信小程序开发、微信公众号开发、APP定制开发、天津企业微信开发、ERP、CRM、OA等企业应用场景信息化解决方案等服务，致力于成为中国领先的IT服务及行业解决方案的提供商。