B端产品设计:从产品角度谈“软件模块化设计”
副标题[/!--empirenews.page--]
01 软件模块化设计,“偷懒”利器为了提升写作效率,几乎任何一款编辑器都少不了“复制”“粘贴”这两个功能,对于需要编辑冗长代码的软件开发人员更是如此。但程序猿们并不满足于此,他们创建了一种开源社区,从而可以“复制”其他人共享的代码,他们把这种共享的理念叫做“不要重复造轮子”。 业务方频繁改动需求令程序猿们很是头疼,他们希望以最小的代码改动来实现业务方相要的效果;同时,当业务方提出新需求时,尽量不去动已经写好的代码…… 基于以上实用性、高效率的工作需要,程序猿们创造一个“软件模块化设计”的概念: 把一个很大很复杂的系统,按照功用性,划分成若干个模块,每个模块完成一个确定的功能;然后在这些模块之间建立相应的联系(接口),通过模块间的互相协作,最终实现业务方提出的需求。 举个例子,对不懂技术的业务方来说,上传文件和上传图片是两个完全不同的动作,但对程序猿来说,这两个动作其实可以抽象成一个行为(或功能)——“上传”。这时,假如一个系统出现多处需要“上传”功能的模块,程序猿只需要把相应的代码复制过去,根据业务方需要做简单的修改即可,不必再重新编辑。 再比如一个商业分析模块(BI),数据来源是财务系统和供应链系统,那么开发人员在做BI模块时,只需要了解需要输入什么数据、输出什么类型的图表即可,完全不用考虑这些数据从哪来,有什么意义。 以上就是“软件模块化设计”在软件开发领域最实用的两个意义,除此之外,还具有使系统结构清晰、代码简洁、良好扩展性、便于分离、适应业务变化等优点。 产品经理距离“软件模块化设计”最近的时候就是画原型图!比如Axure中的“母版”功能、“动态面板”、“框架”、页面分级编组、图层编组等等,我们可以仔细想想每次使用这些控件时,都是出于什么目的:
02 模块化设计对产品经理的帮助产品经理在互联网时代以前,主要归属于市场营销部,职能是快速响应市场需要,对产品盈亏负责;软件类产品的设计工作直接由开发部门负责。 进入互联网时代,尤其是移动互联网,产品版本迭代速度加快,开发部门越来越需要一个专门负责解读用户需求、研究用户体验,并将需求整理后传递给开发人员的职能角色。产品经理自此才逐渐成为互联网行业的一个重要角色。 产品经理与程序猿之间的这些渊源,决定了产品经理需要了解一些类似软件架构设计理念,或者是逻辑严谨的思考方式。一方面可以更友好、更准确地跟程序猿传达设计要点;另一方面也能够帮助自己处理“具象的、数量繁多的、无逻辑的、琐碎的”用户需求。 软件模块化设计有两个很重要的步骤——归类和抽象,完成了这两步才能确定最终要做哪些模块、哪些功能。 比如说,单选题、多选题、判断题同属于客观题,这叫归类;单选题是“拥有4个选项,答案唯一的题目”,多选题是“拥有4个选项,以“且”关系连接的多答案题目”,判断题是“拥有2个固定选项,答案唯一的题目”,这叫抽象。 产品经理在跟业务方沟通时,经常会遇到各种各样的专业名词、行业限定下的特殊场景,这些名词在业务场景中可能代表着不同的含义,但是在软件开发中却可以用固定的、已有的简单名词来表述。 对需求做归类和抽象,不仅仅是为了跟程序猿沟通,更重要的是帮助产品经理认识到需求的实质,也使自己的设计工作“不要重复造轮子”。 对需求完成归类和抽象后,必然面对“如何联系”这一问题——模块之间有无前后置关系,数据流向是怎样的? 比如说,经过归类抽象,我们决定开发“题库管理”“试卷管理”“教学管理”三个产品模块;这时就需要思考这三个模块之间的关系:
经过逐级演化,最终我们可以得出这三个模块之间的关系图谱。 经过一系列归类、抽象和关系确定,我们可以得到一张UML用例图、一张活动图,甚至状态图、时序图和数据库设计;这些流程图相当于一张标注过路线的产品地图,有了路线图就可以直接进入产品设计阶段了(UML图可以使程序猿直接进入开发阶段,不一定非得等到原型图出来)。 当业务方提出需求变更时,我们可以对照这些图例:哪些需求是原有需求的变种,哪些需求是真正的新增,这些需求是否在预期的开发路线上,是否能够在系统中实现,对系统的影响有多大…… 总之,当产品经理对产品有了模块化的概念化,会很轻松地应对来自客户的需求新增和变动。
03 模块化设计的5个显著特征前文通俗地还原了软件模块化设计的原貌,最后总结一下软件模块化设计的5个显著特征: 1. 层次分明可以简单理解为设计一个结构合理的树状菜单。 2. 抽象与细分抽象:只考虑要解决的问题(用户需求),不考虑实现方法; 细分:强调对需求的逐步分解,分解时仅较上一部分增加少量的细节。 例: 用户想要实现在线报销的功能,那我们就给他做一个“报销软件”,这个“报销软件”就是抽象出来的实体; 接下来要对“报销软件”进行第一次分解:报销信息填写、发票识别与验真、审批; 第二次分解“发票识别与验真”:发票信息录入、发票真伪性验证、发票是否已用验证; 第三次分解“发票是否已用验证”:历史已用发票查询、历史已用发票编号对比…… 3. 组成独立在软件工程领域也被成为“信息隐蔽”,意思是在设计和确定模块时,使一个模块内包含信息(流程或数据),对于不需要这些信息的其他模块来说是不能访问的。 也就是说,除了必要的接口,尽量减少模块间、分系统、子系统间的逻辑依赖,这样在后期维护升级时,就可以避免干涉其他不相关的部分。 例: (编辑:源码门户网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |