当产物司理和靠山开拓提需求时，本觉得小迭代、小需求简简朴单，但在靠山开拓眼中却有些贫苦。那么在需求实现的角度上，是什么原因导致的呢？我们又该如何从靠山开拓的视角去领略需求的实现进程呢？

在产物同质化严重的当下，竞争的主疆场早已从产物代价转移到了开拓效率与运营计策。

运营计策颠末几番摸爬滚打总能找到节拍，但开拓效率却是很难在短时间内晋升。因为作为一个产物司理，你不只需要相识技能，用开拓小哥能听大白的话语描写需求，更重要的是让技能团队与你一条心一起走。

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

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

你认为“很简朴”的小需求，开拓小哥评估至少要N天才气完成；

显着别人都已经实现的成果，怎么在我们这里就实现不了了？

你认为只是优化的小迭代，在开拓小哥这里怎么就酿成了动架构了？

本日丽莎阿姨就要带着你一起走进靠山技能小哥的心田世界，一起去开悟之坡~

01 一个需求，靠山到底在做什么？

举个例子：一个英语进修的APP，我们但愿用户宣布了灌音后，可以让他的粉丝也能看到他宣布的灌音。

在这个看似简朴的需求里，靠山开拓会如那里理惩罚这些数据呢？

之一步，将流程里包括的信息拆解为：用户（小A、小B）、行为（灌音、宣布、收听）、数据（读音）

第二步，维护好用户数据，确保在需要的时候可以快速地会见到。

这下你大白了吗？当你在表达一个需求的时候，其实是在描写一个现象，尔靠山小哥就会把这个现象布局化地拆解为：用户、行为、数据以及之间的运转逻辑。

所以在此后的需求相同中，我们不妨也可以提前做一下这样的拆解，这样相同效率就会大大晋升了。

02 这个需求很简朴，为什么要开拓N天？

某一天，你跟开拓小哥说：既然我们已经实现了粉丝可以听到灌音，那么再增加一个粉丝可以看到视频的成果吧，这个需求应该很简朴，交互逻辑之前都是一样的，是不是很快就能上线呀？

开拓小哥一番评审汇报你：2天~

此时在你心里是不是以为：不是一样的对象吗？仿佛半天就能搞定的工作，为啥要花两天？

那么这两天靠山小哥到底在做什么呢？

在我们看来灌音和视频现象都是一致的，但在靠山小哥的开拓中长短常差异的。前文提到，靠山开拓主要是处理惩罚用户行为，维护用户数据，这个差异就是在于数据上。

假如最开始开拓没有思量扩容性，那么灌音数据与视频数据就是两个截然差异的接口，所以开拓周期虽然是一样的。

可是，假如我们在一开始就汇报开拓小哥，将来业务的逻辑是需要支持灌音也有大概支持视频的，这种环境下，数据接口就可以在一开始的时候就做好适配设计。

什么叫适配设计，其实就是增加一个数据适配器（雷同电脑的转讨论），让成果可以支持更多范例的数据。

这样一比拟，我们就知道了：

同样的需求，假如开拓 *** 是，来一个需求做一个需求，那么开拓时间是：2 天灌音 + 2 天视频 = 4 天

假如一开始就汇报开拓小哥将来业务大概的扩展性，一开始就思量了数据接口适配，那么总体的开拓时间是：2 天灌音 + 0.5 天扩展性 + 0.5天视频 = 3 天

怎么样？今后不要再诉苦你们开拓小哥本领不可可能效率太低了哦。最基础的原因照旧在于产物司理是否足够有预见性与筹划性。

03 为什么同样的成果，体验老是不尽如人意？

照旧前面的例子，让粉丝听到存眷者的灌音的成果。有时候你发明，完全一样的成果，在人家的产物上和本身的产物上体验怎么会差许多？仿佛我们的页面老是不那么顺滑，那真正的原因到底是什么？

其实主要的问题就出在开拓 *** 上：

开拓 *** A：用户点击宣布灌音，靠山生存灌音，并为每个粉丝逐个生成数据，然后通知用户宣布乐成。