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

《一种可拯救产品与开发关系的良药——高内聚低耦合》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、一种可拯救产品与开发关系的良药——高内聚低耦合需求是一个很玄的东西，总会影响产品经理和开发的关系。为此，本文分享了一种可拯救产品与开发关系的良药——“高内聚低耦合”。因为“高内聚低耦合”的产品设计能保证“可复用／可扩展／够灵活／可维护”，从而提升产品迭代效率／增进和开发的感情。产品经理做功能规划时一定经常遇到这样的问题：需求变更或产品设计不合理导致修改成本很高时，产品被开发骂，甚至被打。需求评审时，开发会说“不要相信产品经理“／”这里不要听他的，到时候肯定会让我们改”，信任崩坏。其实，产品一点也不

2、想改需求。可是业务情况不断在变，导致和开发的关系总是被改需求这件事破坏。怎么办？首先，冲突是不可避免的。承认产品和开发中任务目标和思考方式上存在差异，不必太过紧张，在冲突中协作并推进项目是常态。其次，需求总是会改的。与其承诺不改，不如让产品改起来十分顺滑。这就要努力去理解开发的工作特征，在设计产品的时候做个“有脑子的pm”。今天和大家分享其中非常重要的一点——产品设计中的*高内聚低耦合*就是拯救产品开发关系的良药。什么是高内聚低耦合？这犀利的措辞一看就是来自开发界的术语。高内聚是说一个功能模块最好

3、仅完成一个独立的子功能并且完成的很好。低耦合是指模块与模块之间尽量独立／联系少／接口简单。这个原则出现的背景是为了让程序“可复用／可扩展／够灵活／可维护”。干过一阵子产品的人对这几个词应该都不陌生。对于程序设计者来说，这几个词是十分重要的，不亚于产品经理口中的“用户体验”（原则or挡箭牌）。那么，怎么能让你的需求设计符合以上原则呢？分3步：把一个具体的问题抽象成一类问题；根据用户体验流程划分功能模块；针对每个功能设计封闭的解决方案。下面一个一个讲：1、从对象到类，从具体到抽象，产品经理要尽量解决一

4、类问题而不是一个问题比如老板说这周要上一个大转盘抽奖的活动，送两部iPhone7拉升一下用户活跃。大转盘几乎时每个产品经理／开发的噩梦，拿到题目立即打开axure开始飙车？no！先把这个具体到活动需求升级到一类问题来考虑：这次的大转盘送iPhone7，下次送话费怎么改？大转盘是个抽奖活动，下次老板又看上了砸金蛋怎么改？这次是奖励新用户的，下次换成会员才可以抽奖怎么改？大转盘是运营型产品，万一下个月要对接外部合引流怎么改？甚至下次开始做转发集赞送礼品了，怎么改？你要从“策划一个（抽奖）活动系统”的角

5、度来思考，目标定为解决快速支持运营（抽奖）活动这一类问题；如此得出的方案才有可能是“通用”的，支持比较多的“变种”。2、绘制用户体验流畅图，按照“单一责任原则”划分功能模块不同的角色甚至同一角色都可能有不同的任务目标，需要逐一分析。比如在大转盘类产品中，一个参与用户在活动中的体验流程是：①用户看到活动页面→②系统判断活动有效性→③用户执行抽奖操作→④系统判断用户是否符合参与条件→⑤系统给出奖励结果→⑥输出结果页面给用户→⑦用户执行领奖操作最初应该如何划分事件模块？我的经验是参考生活经验并根据你当前

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

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

8、动有效性→③用户执行抽奖操作→**A系统给出奖励结果**→⑥输出结果页面给用户→⑦用户执行领奖操作右边举例：假设将“⑤系统给出奖励结果”拆成两个模块“A用户抽中哪个奖品→B该奖品是否已达最大量”，我们将会发现要得到用户中奖结果一定要模块A和B同时起作用才行，也可以说A和B在承担同一个责任。说明该模块的内聚度低——应该合并成1个模块。①用户看到活动页面→②系统判断活动有效性→③用户执行抽奖操作→④系统判断用户是否符合参与条件→**A用户抽中哪个奖品→B该奖品是否已达最大量（已抽完或每