产品经理如何基于需求迭代产品（下篇2）：产品的总体设计之业务层和系统层

上一篇：产品经理如何基于需求迭代产品（下篇1）：产品设计的高内聚低耦合

上篇所讲的高聚合低耦合的宗旨，就是要用在产品设计上。此处所讲的产品设计，不仅是界面设计，还包括产品架构、系统架构、功能模块、实体结构、角色、逻辑等等。

本篇文章分为总体设计和局部设计两个部分。总体设计是指从零到一开发或者重构一款产品的所有流程，一共涉及业务层、系统层、逻辑层和交互层等四个层面。局部设计是指产品正常迭代或者设计产品某小块下的流程和核心，局部设计的流程是总体设计流程的子集，因此主讲局部设计的核心。

你们在看的时候，时刻要想着“高内聚低耦合塑造产品认知”的宗旨。

总体设计

产品的总体设计包括业务层、系统层、逻辑层和交互层等四个层面。基于需求提出业务方案，基于可行可落地的业务方案进行设计。

在实际过程当中，并不会严格按照顺序一层层下来，由于方法是层级的，而灵感则是跳跃的。我通常是先从业务方案中抽象出实体、角色和逻辑，

总体设计

业务层：业务方案

业务层是指业务方案。业务方案就是业务层面的方案，要求业务方案是可行可落地的。新产品/新模块的业务方案通常由产品经理、领导或者业务方提出，表明着在产品经理、领导或者业务方的思考中是如何解决这个问题的。

只有可行可落地的业务方案才有意义，由于产品经理就是要把可行可落地的业务方案搬到线上，作成标准化的解决一类问题。若是业务方案的不可行，那么后续的产品设计也就无从谈起了。

若是业务方案已经落地且可行，例如在运营层面已经按照某规则人工实行了一段时间，效果不错。产品经理就须要把这个方案搬到线上，要基于业务方案设计功能，作成标准化的功能解决一类的问题，还要结合总体和将来的发展。

若是没有可行可落地的业务方案，产品经理不只须要和各方沟通出一个或者多个解决方案，还须要经过落地执行或者设计MVP等方法去测试方案的预计效果和可行性。有多个就对比选一个最好的，这里的最好能够是效果或者性价比等，具体请视状况判断。

当公司发展到必定阶段，业务和系统一定有一个是纵向有一个是横向，多个业务纵向铺开后，须要横向的系统打通，主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。例如滴滴出行在短期内造成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构，滴滴启动了中台战略整合业务系统，具体请见《从滴滴出行业务中台实践聊聊如何构建大中台架构》。

系统层：系统定位、系统架构、模块抽象、规划蓝图

系统层是指系统层面的一些东西，包括系统定位、系统架构、模块抽象、规划蓝图。人们看到体验到的产品都是露在外面的那一块，实际上还有不少系统在海平面如下，或大或小的产品背后总后好几套系统的存在。大的例以下图的惟品会，整个分为SAAS、PAAS和IAAS，每一个里面有多个平台多个系统，才能支撑起惟品会的发展。小小的一款APP里的IM、推送等可能都是第三方提供的独立的系统。

惟品会的总体架构

系统定位

系统定位就是指肯定系统要解决什么需求，先要有拆分出系统的需求，而后才有这个系统。系统定位必然是最早一步，并非全部东西都要单独拉出个系统去作。观察大型系统的演进过程能够发现，绝大部分系统都是从初始的小功能到模块最后再到系统的（功能＜模块＜系统）。

系统化自己就是为了解决资源共享低、利用率低、不能集中处理等问题，系统也能下降总体耦合性，此时应该和架构师进行探讨，由于大部分都是技术层面的东西，要思考清楚哪些是系统哪些不是系统，所解决的需求是否重要是否急迫，而且对每一个系统提出定位做为迭代方向，固然定位并非一成不变的。

系统架构

肯定了有哪些系统和对应的系统定位后，便可开始进行系统架构。系统架构强调的是系统和系统之间的联系，若是有多个系统还能够像惟品会同样平台化，便于理解也便于组织架构划分。

若是发现系统架构完成后，并无把全部系统or模块包含进去，则要回到系统定位上从新梳理和思考，要把全部都包含进去。由于系统架构是解释系统之间的关系，绝对不能硬塞进一个模块。就像外出前收拾行李，把一堆东西塞进一个书包、一个旅行箱和一个编织袋，塞完了发现还剩一双鞋，得想办法塞到专门放鞋子得编织袋里面，可是编织袋已经满了也无法倒腾出空位，那就只能塞到旅行箱里面。

装满东西的旅行箱（来自百度图片）

系统和系统之间要协调配合，互相联系互相制约，就像运动系统、神经系统等八大系统令人体内各类复杂的生命活动可以正常进行。

模块抽象

平台、系统、模块和功能之间的关系应该是：平台包含系统，系统包含模块，模块包含功能。此处所讲的均不能只看作是前台的某个界面，均包含后台所对应的逻辑等，是一个立体的结构而不是前台的平面结构。平台、系统、模块和功能都是立体结构，只是粒度不一样。而角色、实体和流程是平面结构，是不一样角度下不一样视野下的系统。

模块抽象就是指把不一样模块都抽离出来，模块和模块之间互相独立互相依存，相似系统定位，划分了模块以后才能肯定哪一个系统包含哪些模块。

功能从场景和流程中抽象，模块从功能和实体中抽象。像惟品会等电商系统，会分商品模块、品类模块、订单模块、购物车模块、支付模块等等。一个模块包括前台的展现页面/组件+后台逻辑。模块的抽象是很天然的，由于自己系统的创建就有其内部的生态或者逻辑，就像人体的呼吸系统包含呼吸道（鼻腔、咽、喉、气管、支气管）和肺一系列器官以及内在逻辑。

规划蓝图

优秀的产品都是迭代和规划出来的，而不是一辈子下来就是。不少产品前期都是很简单很基础的几个模块，并且1.0版本用以快速试错的，若是模块不少体量很大就会浪费资源，要是失败了就得不偿失。

规划蓝图并非计划蓝图，规划和计划的区别在于，规划是长远的（6个月以上）、不详细的、目标不精确的，计划则是短时间的、详细的、目标精确的。例如，2018上半年要开发新版本就是个规划，而2018年6月前用户要天然增加100%经过优惠券、满减等手段则是计划。

在系统架构和模块抽象起来后，我会进行规划蓝图的工做。规划蓝图分两块，需求树和产品路线图，需求树是把全部需求（系统、模块、功能或者某些待解决的问题）放到树形图上，产品路线图则是把需求树上的需求通过筛减后按照产品阶段放置。

需求树示例

需求树，是为了梳理、分类需求，分析优先级和先后置条件。树根是实现整个系统所必需要的基础设施，树干是核心功能模块，树枝是能够进入的领域或者方向，树枝上也有功能模块。一开始先把核心功能、基础设施和方向领域肯定好，而后用便利贴往上贴功能模块或者需求，最后按照越靠近主干越优先的策略调整便利贴的位置。期间整个团队都有一块儿合做，各抒己见，一块儿协商这些具体功能或者想法应该怎么发展，一块儿肯定优先级。

需求树可随时补充，并且要按期把需求树上新增的需求删减、调整以放到路线图中。

产品路线图示例

产品路线图，是为了明确产品何时该作什么，是最多6个月到2年的产品路线，具体看公司规模、行业特色等。产品路线图可根据实际状况进行调整，但不是想要改就改的，产品路线图很严肃，不严肃的毫无心义，要遵照他。

路线图包括产品阶段、里程碑、需求。

产品阶段是指产品所处的阶段，会有初始、成长、成熟和衰退四大阶段，每一个大阶段根据不一样状况会有小阶段，视产品状况自行肯定。处于不一样阶段的产品都有不一样的产品战略，要概括出来，为需求的选择和实施方向提供思想支持。

里程碑主要是用来划分阶段的，例如找到第一个用户G点并造成可复制方案使得用户大规模增加，从初始进入了成长期；在新增和流失用户打平，作再多拉新活动ROI都会持续降低，从成长进入了成熟期等等。

基于产品阶段、阶段中的产品战略和需求树，把需求放到产品路线图中，最终造成产品路线图。离当前时间越近的要详细些，远的则大方向要清晰。

这些都是我本身的自我总结，也是我对世界的认知和总结，每一个人的认知或多或少有所不一样，但愿可以帮助你们更好地认识这个世界。

Vency，两年经验产品经理，追求用户、技术、商业、社会价值的统一

搜索关注公众号 Vency不二或者vencybu2，向你们分享我或系统或粗放的深度思考

下一篇《产品经理如何基于需求迭代产品（下篇3）：产品的总体设计之逻辑层和交互层》，敬请期待