产品老司机都知道的“耦合性”

12 评论 31942 浏览 235 收藏 12 分钟

为什么研发总是会和你说,这样做很复杂,为什么你的需求变动总是比预期的成本更大?

这大概是最常见的产品落地技巧吧,我们作为产品经理,很多时候不只是要考虑做什么,还要考虑怎么做。

大多数的结果都是可以通过不同的方法得到实现的,而这些实现方法其实很多都掌握在产品经理的思维里。

换言之:成熟的产品经理,同样会输出成熟的产品方案,也许结果是相同的,但投入的成本以及价值,却截然不同。

这也是我一直遵守的原则。

今天要和大家分享的“耦合性”就是属于会影响产品方案的一种观念。

什么是“耦合性”

对于产品经理而言,“耦合性”主要体现在功能和逻辑层面,是指多个功能或逻辑存在过深的“交叉性”。

产品的功能和逻辑最终都会以技术的方法实现,换言之,最终都会形成代码语言,多和开发人员就需求的实现方法展开沟通,讨论,这有助于我们理解代码逻辑,从而形成耦合性的概念。

案例

最典型的耦合性体现在功能交叉关联,这里就用微信公众号后台来给大家分析一下吧。

我们先来确定一下业务逻辑,微信公众号最本质的功能是公众号的运营人员将文章发送给多个指定对象

我们先来看看这个方案怎么样:

(方案A)

截图1

毫无疑问,这个方案能够达到我们的目的,即:是公众号的运营人员将文章发送给多个指定对象。

但这个方案存在多个容易为我们造成负担及风险的“耦合性”。

1.如果运营人员要将同一篇文章投放多次怎么办?

公众号的内容是较为严谨的,理论上,公众号的内容是有很大概率被重复投放的,

2.如果生产内容的人和投放内容的人不是同一个运营人员,又怎么办?

公众号支持以组织,团队的方式进行运作, 这一点体现在一个公众号可以添加运营号,从而实现多个微信账号共同操作一个公众号。

3.我最近会有一段时间比较忙,因此我想预先将内容都准备好,到时候只要发布就可以了,怎么办?

或许你会说,我们可以做一个定时器,坦白讲,我们很少看到定时器在用户层的使用,因为这会降低用户对产品的使用频率,从而削弱用户粘性。

方案A在实际操作过程中,还会出现许多的薄弱点。

正如我们对这套方案的评论一样,方案A,能且只能达到:让公众号的运营人员将文章发送给多个指定对象。

我们把这个方案转化成技术方案就会很明显感知到“耦合”了,因为这套方案同时包含了“内容上传”和“内容下发”,在功能上,产生了“交叉关联”

而微信是怎么实现的呢?

微信公众号采用的方案则是将“内容上传”独立成一个功能,将“内容下发”独立成一个功能,两者之间存在“调用”的顺序关系,不存在“交叉”的耦合关系。

(内容下发)

截图2

(内容上传)

截图3

一旦将两者分离后,我们的设计思路就会更专注,比如对于内容上传而言,我们可以围绕内容展开设计,对于内容下发而言,也可以围绕下发展开设计。

截图4

这个设计方案不仅能满足“公众号的运营人员将文章发送给多个指定对象”

而且能更全面的满足这个需求,方案A中的问题,在这里就不再存在了。

对于开发来讲,最典型的特征是我们可以将内容上传与内容下发交给不同的开发人员甚至开发小组进行代码实现了。

耦合性越强,越难以将其分配给多个人同时进行。

坦言,这违背了用户体验,原本“一步”就能完成的事,为什么要分两步甚至更麻烦呢?

我们在避免功能耦合的时候,确实会增加一定的操作成本,但我很遗憾的告诉你,“用户体验”更多的是产品经理的自我素养,是一个加分项,而不是价值体现。

用户在使用产品时,通常是为价值买单,而不是为体验买单,尽管我们都很努力,且很刻意的追求用户体验,但当体验与价值产生冲突时,必然会出现“降维”

“内容上传”和“内容下行”是我们最常遇见的“耦合性”,类似的还有“内容属性”与“内容数量”等等,大家可以留意一下平时的设计。

1:n

随着产品的发展,会逐渐增加自身的复杂性,这个观念并不是始终正确的,产品的发展最终改变得应该是企业,而产品则要始终追寻自身的“简易性”,因为产品的复杂度和可行性成反比。

越是复杂的产品,越难以得到市场的认可。

1:n,是我们常见的一种关系模式,同时也是最容易产生复杂度的模式。如果你遇到同样的关系模式了,我建议你尽量将其还原成1:1的关系模式。

比如视频广告的投放,在爱奇艺,优酷等视频类产品里,都会有广告投放的业务,而且一段视频的播放过程中,存在不同的广告投放位置。

我们来还原一个场景。

现在,用户A是一位准备投放广告的广告主,他已经将广告内容上传到了相应的内容库里,现在A需要设置投放广告的位置以及广告生效的时间。我们很确定A需要投放到两个以上的广告位

我们来为他设计一个投放的后台,你会怎么设计呢?

方案A

截图5

方案A,用户可以选择多个广告位,而广告有效期则根据广告位的选择状态进行动态调整,如果用户勾选的广告位是片头广告位和暂停广告位,则需要设定对应的广告有效期。

这个方案怎么样?

逻辑上是可行的,然而实际上却毫无可行性而言,这个方案具备太多“耦合性”

耦合性越大,意味着需要越多的“条件满足”,丧失越多的“可塑性”

我们来看看方案A难以实现的原因:

1.每个广告位的生效时间与失效时间是不同的

对于视频广告而言,广告位置是有限的,同时广告主对于投放的广告位有极强的自定义性质,比如这个场景里,就导致片尾广告的空闲状态,这样就会导致每个广告位的生效时间和失效时间是不一样的。

2.基于广告的有效时间难以界定。

由于存在两段时间关系,我们只能取全集,即最早生效的广告位生效时间为开始时间到最迟 失效的广告位失效时间为结束时间。

3.难以定价

不同广告位的售价是不一样的,我们需要单独统计该广告在不同广告位的相应数据,而在方案A里,这些数据都会混合在一起,导致我们难以识别各自的数据。

这个场景是典型的1:n场景,用户执行的1个操作,对应的确是多个操作对象。

我们再看看B方案:

截图6

调整的内容很简单,只是将广告位的复选逻辑,更改为了单选逻辑,这样就从1:n的关系变成了1:1的关系。

即用户的一次操作,对应一个操作对象。

在这个方案里,同样的,上述的问题就已经不再存在了,用户若需要将广告内容投放到不同的广告位,只需要选择上传的广告内容,并且执行多次操作就好了。

从操作成本而言,面对全投放的场景,也只是需要新增3条记录,而我们的产品却会比A方案要简单许多。

滴滴和uber等打车软件,都会有一个看似奇怪的逻辑:只允许用户存在一笔有效订单,现在你知道为什么这么设计了吗?

可以尝试分析一下,如果一个用户存在多笔有效订单,这个程序会是什么样的。

总结

最后,我们再来明确一下文中提到的观点:

1.”耦合性”越强,产品“复杂度”越高,价值越低

2.降低“耦合性”会增加一定的用户操作成本,但不会影响产品“价值”

3.用户体验是加分项,当遇上价值时,必须为价值“降维”

4.产品的迭代过程中,需要不断的为自身减负,过多的“耦合性”只会加速产品的死亡,进入“无法迭代”的状态

#专栏作家#

枯叶,微信公众号,枯叶咖啡馆,人人都是产品经理专栏作家。擅长社交,社区,细分群体挖掘。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. “用户体验”更多的是产品经理的自我素养,是一个加分项,而不是价值体现。 受教

    回复
  2. i

    回复
  3. 楼主,视频广告投放的场景,方案A只是前台交互逻辑差异,属于动态配置,与方案B没觉得有什么差异,后台逻辑一定是三种独立的关系啊,求醍醐灌顶 😮

    来自北京 回复
  4. 在实际工作中,会出现设计产品功能时,很容易陷入误区:在一个功能点上恨不得把所有可能出现的情况都考虑进去,造成一个功能承载了太多的路径。给开发的兄弟们挖了不少坑,耦合性太强,难于后期维护和迭代,貌似不这样就显不出产品的通用性。
    这篇文章给了一种新的产品功能设计思路,有些逆向思维的味道,值得好好揣摩,想起了面向对象编程的一个基本规则:低耦合,高内聚。 异曲同工之妙。

    来自北京 回复
    1. v

      回复
    2. 个人以为笔者的分析并不是完全准确,太过片面,事实上两种方案各有利弊。数据统计方案A也是可以单独统计的,广告位涉及时间的投放的时候,远比这个复杂,并不止作者所列,参考就可,并非真理

      回复
  5. 没怎么用过打车软件……简单猜一下,1.多笔有效订单出现的场景可能是,A帮助B,C,D……下订单,而打车软件希望更多的用户拥有自己的账号;2.多笔有效订单出现的场景可能是,A瞎几把下单,导致的后果可能是多名司机接单而放空造成损失;3.像滴滴这样的打车软件是先体验服务,后进行支付,如果允许多笔有效订单存在,可能导致多笔坏账的存在。 😥 公交党打车不多,想偏了求不嘲笑。

    来自江苏 回复
    1. 预付款策略和风控

      来自北京 回复
  6. 强烈要求置顶

    来自江苏 回复
  7. 很受用,在做后台设计,也不会考虑太多耦合的问题,可深度现在用户和开发的角度想去,确实会有这样那样的坑等着以后去埋……为了避免成为坑王,出功能得多维度去思考啊……难!但有意思!

    回复
    1. 我也是做后台的产品,还有一种就是表单特别多,我也收藏了一章,下个版本就准备是试用

      回复
    2. i

      回复