一种可拯救产品与开发关系的良药——“高内聚低耦合”

2017-07-17 09:55:00

需求是一个很玄的东西，总会影响产品经理和开发的关系。为此，本文作者分享了一种可拯救产品与开发关系的良药——“高内聚低耦合”。因为“高内聚低耦合”的产品设计能保证“可复用／可扩展／够灵活／可维护”，从而提升产品迭代效率／增进和开发的感情。

产品经理做功能规划时一定经常遇到这样的问题：

需求变更或产品设计不合理导致修改成本很高时，产品被开发骂，甚至被打。
需求评审时，开发会说“ 不要相信产品经理 “／”这里不要听他的，到时候肯定会让我们改” ，信任崩坏。

其实，产品一点也不想改需求。可是业务情况不断在变，导致和开发的关系总是被改需求这件事破坏。

怎么办？

首先，冲突是不可避免的。承认产品和开发中任务目标和思考方式上存在差异，不必太过紧张，在冲突中协作并推进项目是常态。
其次，需求总是会改的。与其承诺不改，不如让产品改起来十分顺滑。这就要努力去理解开发的工作特征，在设计产品的时候做个“有脑子的pm”。

今天和大家分享其中非常重要的一点——产品设计中的 高内聚低耦合 就是拯救产品开发关系的良药。

什么是高内聚低耦合？

这犀利的措辞一看就是来自开发界的术语。高内聚是说一个功能模块最好仅完成一个独立的子功能并且完成的很好。低耦合是指模块与模块之间尽量独立／联系少／接口简单。

这个原则出现的背景是为了让程序“可复用／可扩展／够灵活／可维护”。干过一阵子产品的人对这几个词应该都不陌生。对于程序设计者来说，这几个词是十分重要的，不亚于产品经理口中的“用户体验”（原则or挡箭牌）。

那么，怎么能让你的需求设计符合以上原则呢？

分3步：

把一个具体的问题抽象成一类问题；
根据用户体验流程划分功能模块；
针对每个功能设计封闭的解决方案。

下面一个一个讲：

1、从对象到类，从具体到抽象，产品经理要尽量解决一类问题而不是一个问题

比如老板说这周要上一个大转盘抽奖的活动，送两部iPhone7拉升一下用户活跃。大转盘几乎时每个产品经理／开发的噩梦，拿到题目立即打开axure开始飙车？no！先把这个具体到活动需求升级到一类问题来考虑：

这次的大转盘送iPhone7，下次送话费怎么改？
大转盘是个抽奖活动，下次老板又看上了砸金蛋怎么改？
这次是奖励新用户的，下次换成会员才可以抽奖怎么改？
大转盘是运营型产品，万一下个月要对接外部合作者引流怎么改？
甚至下次开始做转发集赞送礼品了，怎么改？

你要从“策划一个（抽奖）活动系统”的角度来思考，目标定为解决快速支持运营（抽奖）活动这一类问题；如此得出的方案才有可能是“通用”的，支持比较多的“变种”。

2、绘制用户体验流畅图，按照“单一责任原则”划分功能模块

不同的角色甚至同一角色都可能有不同的任务目标，需要逐一分析。

比如在大转盘类产品中，一个参与用户在活动中的体验流程是：

①用户看到活动页面→②系统判断活动有效性→③用户执行抽奖操作→④系统判断用户是否符合参与条件→⑤系统给出奖励结果→⑥输出结果页面给用户→⑦用户执行领奖操作

最初应该如何划分事件模块？我的经验是参考生活经验并根据你当前所要处理的任务目标来确定粒度的粗细，比如现在我们在设计一个抽奖的活动系统，我的划分粒度就先到组成这个系统的大模块。如果现在我们开始设计抽奖的前端页面，我们的划分粒度就要拆解到页面的组成部分。
如何确定模块规划符合高内聚低耦合的标准？一个判断标准是：单一责任原则。简单说就是一个模块只做一件事，只承担一项职责，因为承担的责任越多，它被复用的可能性就越小。如果承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，于是就会导致开发骂娘——“这个功能改不动”、“这相当于重做一个”

为了方便操作，我个人总结如下图：

左边举例：假设将“④系统判断用户是否符合参与条件→⑤系统给出奖励结果”规划为一个功能模块A，我们将会发现A的输出结果有两种类型，一个类型是用户老王不是注册用户不具备抽奖资格（假设活动要求平台注册用户才能抽奖），另一个类型是老王具备抽奖资格但是没有抽中（假设完全随机抽奖）。在这种情况下，出现两种类型的结果输出，说明该模块的耦合度高了——应该拆成2个模块，一个专门判断用户是否有资格来抽一把，一个专门判断有资格的用户得到哪个奖品。