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

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

这大概是最常见的产品落地技巧吧，我们作为产品经理，很多时候不只是要考虑做什么，还要考虑怎么做。
大多数的结果都是可以通过不同的方法得到实现的，而这些实现方法其实很多都掌握在产品经理的思维里。
换言之：成熟的产品经理，同样会输出成熟的产品方案，也许结果是相同的，但投入的成本以及价值，却截然不同。
这也是我一直遵守的原则。
今天要和大家分享的“耦合性”就是属于会影响产品方案的一种观念。
什么是“耦合性”
对于产品经理而言，“耦合性”主要体现在功能和逻辑层面，是指多个功能或逻辑存在过深的“交叉性”。
产品的功能和逻辑最终都会以技术的方法实现，换言之，最终都会形成代码语言，多和开发人员就需求的实现方法展开沟通，讨论，这有助于我们理解代码逻辑，从而形成耦合性的概念。
案例
最典型的耦合性体现在功能交叉关联，这里就用微信公众号后台来给大家分析一下吧。
我们先来确定一下业务逻辑，微信公众号最本质的功能是公众号的运营人员将文章发送给多个指定对象
我们先来看看这个方案怎么样：
（方案A）

毫无疑问，这个方案能够达到我们的目的，即：是公众号的运营人员将文章发送给多个指定对象。
但这个方案存在多个容易为我们造成负担及风险的“耦合性”。
1.如果运营人员要将同一篇文章投放多次怎么办？
公众号的内容是较为严谨的，理论上，公众号的内容是有很大概率被重复投放的，
2.如果生产内容的人和投放内容的人不是同一个运营人员，又怎么办？
公众号支持以组织，团队的方式进行运作， 这一点体现在一个公众号可以添加运营号，从而实现多个微信账号共同操作一个公众号。
3.我最近会有一段时间比较忙，因此我想预先将内容都准备好，到时候只要发布就可以了，怎么办？
或许你会说，我们可以做一个定时器，坦白讲，我们很少看到定时器在用户层的使用，因为这会降低用户对产品的使用频率，从而削弱用户粘性。
方案A在实际操作过程中，还会出现许多的薄弱点。
正如我们对这套方案的评论一样，方案A，能且只能达到：让公众号的运营人员将文章发送给多个指定对象。
我们把这个方案转化成技术方案就会很明显感知到“耦合”了，因为这套方案同时包含了“内容上传”和“内容下发”，在功能上，产生了“交叉关联”
而微信是怎么实现的呢？
微信公众号采用的方案则是将“内容上传”独立成一个功能，将“内容下发”独立成一个功能，两者之间存在“调用”的顺序关系，不存在“交叉”的耦合关系。
（内容下发）

（内容上传）

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

这个设计方案不仅能满足“公众号的运营人员将文章发送给多个指定对象”
而且能更全面的满足这个需求，方案A中的问题，在这里就不再存在了。
对于开发来讲，最典型的特征是我们可以将内容上传与内容下发交给不同的开发人员甚至开发小组进行代码实现了。
耦合性越强，越难以将其分配给多个人同时进行。
坦言，这违背了用户体验，原本“一步”就能完成的事，为什么要分两步甚至更麻烦呢？
我们在避免功能耦合的时候，确实会增加一定的操作成本，但我很遗憾的告诉你，“用户体验”更多的是产品经理的自我素养，是一个加分项，而不是价值体现。
用户在使用产品时，通常是为价值买单，而不是为体验买单，尽管我们都很努力，且很刻意的追求用户体验，但当体验与价值产生冲突时，必然会出现“降维”
“内容上传”和“内容下行”是我们最常遇见的“耦合性”，类似的还有“内容属性”与“内容数量”等等，大家可以留意一下平时的设计。
1：n
随着产品的发展，会逐渐增加自身的复杂性，这个观念并不是始终正确的，产品的发展最终改变得应该是企业，而产品则要始终追寻自身的“简易性”，因为产品的复杂度和可行性成反比。
越是复杂的产品，越难以得到市场的认可。
1：n,是我们常见的一种关系模式，同时也是最容易产生复杂度的模式。如果你遇到同样的关系模式了，我建议你尽量将其还原成1:1的关系模式。
比如视频广告的投放，在爱奇艺，优酷等视频类产品里，都会有广告投放的业务，而且一段视频的播放过程中，存在不同的广告投放位置。
我们来还原一个场景。
现在，用户A是一位准备投放广告的广告主，他已经将广告内容上传到了相应的内容库里，现在A需要设置投放广告的位置以及广告生效的时间。我们很确定A需要投放到两个以上的广告位
我们来为他设计一个投放的后台，你会怎么设计呢？
方案A

方案A，用户可以选择多个广告位，而广告有效期则根据广告位的选择状态进行动态调整，如果用户勾选的广告位是片头广告位和暂停广告位，则需要设定对应的广告有效期。
这个方案怎么样？
逻辑上是可行的，然而实际上却毫无可行性而言，这个方案具备太多“耦合性”
耦合性越大，意味着需要越多的“条件满足”，丧失越多的“可塑性”
我们来看看方案A难以实现的原因：
1.每个广告位的生效时间与失效时间是不同的
对于视频广告而言，广告位置是有限的，同时广告主对于投放的广告位有极强的自定义性质，比如这个场景里，就导致片尾广告的空闲状态，这样就会导致每个广告位的生效时间和失效时间是不一样的。
2.基于广告的有效时间难以界定。
由于存在两段时间关系，我们只能取全集，即最早生效的广告位生效时间为开始时间到最迟 失效的广告位失效时间为结束时间。
3.难以定价
不同广告位的售价是不一样的，我们需要单独统计该广告在不同广告位的相应数据，而在方案A里，这些数据都会混合在一起，导致我们难以识别各自的数据。
这个场景是典型的1：n场景，用户执行的1个操作，对应的确是多个操作对象。
我们再看看B方案：

调整的内容很简单，只是将广告位的复选逻辑，更改为了单选逻辑，这样就从1：n的关系变成了1:1的关系。
即用户的一次操作，对应一个操作对象。
在这个方案里，同样的，上述的问题就已经不再存在了，用户若需要将广告内容投放到不同的广告位，只需要选择上传的广告内容，并且执行多次操作就好了。
从操作成本而言，面对全投放的场景，也只是需要新增3条记录，而我们的产品却会比A方案要简单许多。
滴滴和uber等打车软件，都会有一个看似奇怪的逻辑：只允许用户存在一笔有效订单，现在你知道为什么这么设计了吗？
可以尝试分析一下，如果一个用户存在多笔有效订单，这个程序会是什么样的。
总结
最后，我们再来明确一下文中提到的观点:
1.”耦合性”越强，产品“复杂度”越高，价值越低
2.降低“耦合性”会增加一定的用户操作成本，但不会影响产品“价值”
3.用户体验是加分项，当遇上价值时，必须为价值“降维”
4.产品的迭代过程中，需要不断的为自身减负，过多的“耦合性”只会加速产品的死亡，进入“无法迭代”的状态