产品经理如何基于需求迭代产品（下篇2）：产品的整体设计之业务层和系统层
上一篇：产品经理如何基于需求迭代产品（下篇1）：产品设计的高内聚低耦合
上篇所讲的高聚合低耦合的宗旨，就是要用在产品设计上。此处所讲的产品设计，不只是界面设计，还包括产品架构、系统架构、功能模块、实体结构、角色、逻辑等等。
本篇文章分为整体设计和局部设计两个部分。整体设计是指从零到一开发或者重构一款产品的全部流程，一共涉及业务层、系统层、逻辑层和交互层等四个层面。局部设计是指产品正常迭代或者设计产品某小块下的流程和核心，局部设计的流程是整体设计流程的子集，所以主讲局部设计的核心。
大家在看的时候，时刻要想着“高内聚低耦合塑造产品认知”的宗旨。
整体设计
产品的整体设计包括业务层、系统层、逻辑层和交互层等四个层面。基于需求提出业务方案，基于可行可落地的业务方案进行设计。
在实际过程中，并不会严格按照顺序一层层下来，因为方法是层级的，而灵感则是跳跃的。我一般是先从业务方案中抽象出实体、角色和逻辑，
整体设计
业务层：业务方案
业务层是指业务方案。业务方案就是业务层面的方案，要求业务方案是可行可落地的。新产品/新模块的业务方案一般由产品经理、领导或者业务方提出，代表着在产品经理、领导或者业务方的思考中是如何解决这个问题的。
只有可行可落地的业务方案才有意义，因为产品经理就是要把可行可落地的业务方案搬到线上，做成标准化的解决一类问题。如果业务方案的不可行，那么后续的产品设计也就无从谈起了。
如果业务方案已经落地且可行，例如在运营层面已经按照某规则人工实行了一段时间，效果不错。产品经理就需要把这个方案搬到线上，要基于业务方案设计功能，做成标准化的功能解决一类的问题，还要结合整体和未来的发展。
如果没有可行可落地的业务方案，产品经理不仅需要和各方沟通出一个或者多个解决方案，还需要通过落地执行或者设计MVP等方法去测试方案的预计效果和可行性。有多个就对比选一个最好的，这里的最好可以是效果或者性价比等，具体请视情况判断。
当公司发展到一定阶段，业务和系统必定有一个是纵向有一个是横向，多个业务纵向铺开后，需要横向的系统打通，主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。例如滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构，滴滴启动了中台战略整合业务系统，具体请见《从滴滴出行业务中台实践聊聊如何构建大中台架构》。
系统层：系统定位、系统架构、模块抽象、规划蓝图
系统层是指系统层面的一些东西，包括系统定位、系统架构、模块抽象、规划蓝图。人们看到体验到的产品都是露在外面的那一块，实际上还有很多系统在海平面以下，或大或小的产品背后总后好几套系统的存在。大的例如下图的唯品会，整个分为SAAS、PAAS和IAAS，每个里面有多个平台多个系统，才能支撑起唯品会的发展。小小的一款APP里的IM、推送等可能都是第三方提供的独立的系统。
唯品会的整体架构
系统定位
系统定位就是指确定系统要解决什么需求，先要有拆分出系统的需求，然后才有这个系统。系统定位必然是最先一步，并不是所有东西都要单独拉出个系统去做。观察大型系统的演进过程可以发现，绝大部分系统都是从初始的小功能到模块最后再到系统的（功能＜模块＜系统）。
系统化本身就是为了解决资源共享低、利用率低、不能集中处理等问题，系统也能降低整体耦合性，此时应该和架构师进行探讨，因为大部分都是技术层面的东西，要思考清楚哪些是系统哪些不是系统，所解决的需求是否重要是否急迫，并且对每个系统提出定位作为迭代方向，当然定位并不是一成不变的。
系统架构
确定了有哪些系统和对应的系统定位后，即可开始进行系统架构。系统架构强调的是系统和系统之间的联系，如果有多个系统还可以像唯品会一样平台化，便于理解也便于组织架构划分。
如果发现系统架构完成后，并没有把所有系统or模块包含进去，则要回到系统定位上重新梳理和思考，要把所有都包含进去。因为系统架构是解释系统之间的关系，绝对不能硬塞进一个模块。就像外出前收拾行李，把一堆东西塞进一个书包、一个旅行箱和一个编织袋，塞完了发现还剩一双鞋，得想办法塞到专门放鞋子得编织袋里面，但是编织袋已经满了也没法倒腾出空位，那就只能塞到旅行箱里面。
装满东西的旅行箱（来自百度图片）
系统和系统之间要协调配合，互相联系互相制约，就像运动系统、神经系统等八大系统使人体内各种复杂的生命活动能够正常进行。
模块抽象
平台、系统、模块和功能之间的关系应该是：平台包含系统，系统包含模块，模块包含功能。此处所讲的均不能只看做是前台的某个界面，均包含后台所对应的逻辑等，是一个立体的结构而不是前台的平面结构。平台、系统、模块和功能都是立体结构，只是粒度不同。而角色、实体和流程是平面结构，是不同角度下不同视野下的系统。
模块抽象就是指把不同模块都抽离出来，模块和模块之间互相独立互相依存，类似系统定位，划分了模块之后才能确定哪个系统包含哪些模块。
功能从场景和流程中抽象，模块从功能和实体中抽象。像唯品会等电商系统，会分商品模块、品类模块、订单模块、购物车模块、支付模块等等。一个模块包括前台的展示页面/组件+后台逻辑。模块的抽象是很自然的，因为本身系统的建立就有其内部的生态或者逻辑，就像人体的呼吸系统包含呼吸道（鼻腔、咽、喉、气管、支气管）和肺一系列器官以及内在逻辑。
规划蓝图
优秀的产品都是迭代和规划出来的，而不是一生下来就是。很多产品前期都是很简单很基础的几个模块，而且1.0版本用以快速试错的，如果模块很多体量很大就会浪费资源，要是失败了就得不偿失。
规划蓝图并不是计划蓝图，规划和计划的区别在于，规划是长远的（6个月以上）、不详细的、目标不精确的，计划则是短期的、详细的、目标精确的。例如，2018上半年要开发新版本就是个规划，而2018年6月前用户要自然增长100%通过优惠券、满减等手段则是计划。
在系统架构和模块抽象起来后，我会进行规划蓝图的工作。规划蓝图分两块，需求树和产品路线图，需求树是把所有需求（系统、模块、功能或者某些待解决的问题）放到树形图上，产品路线图则是把需求树上的需求经过筛减后按照产品阶段放置。
需求树示例
需求树，是为了梳理、分类需求，分析优先级和前后置条件。树根是实现整个系统所必须要的基础设施，树干是核心功能模块，树枝是可以进入的领域或者方向，树枝上也有功能模块。一开始先把核心功能、基础设施和方向领域确定好，然后用便利贴往上贴功能模块或者需求，最后按照越靠近主干越优先的策略调整便利贴的位置。期间整个团队都有一起合作，各抒己见，一起协商这些具体功能或者想法应该怎么发展，一起确定优先级。
需求树可随时补充，而且要定期把需求树上新增的需求删减、调整以放到路线图中。
产品路线图示例
产品路线图，是为了明确产品什么时候该做什么，是最多6个月到2年的产品路线，具体看公司规模、行业特点等。产品路线图可根据实际情况进行调整，但不是想要改就改的，产品路线图很严肃，不严肃的毫无意义，要遵守他。
路线图包括产品阶段、里程碑、需求。
产品阶段是指产品所处的阶段，会有初始、成长、成熟和衰退四大阶段，每个大阶段根据不同情况会有小阶段，视产品情况自行确定。处于不同阶段的产品都有不同的产品战略，要归纳出来，为需求的选择和实施方向提供思想支持。
里程碑主要是用来划分阶段的，例如找到第一个用户G点并形成可复制方案使得用户大规模增长，从初始进入了成长期；在新增和流失用户打平，做再多拉新活动ROI都会持续下降，从成长进入了成熟期等等。
基于产品阶段、阶段中的产品战略和需求树，把需求放到产品路线图中，最终形成产品路线图。离当前时间越近的要详细些，远的则大方向要清晰。
这些都是我自己的自我总结，也是我对世界的认知和总结，每个人的认知或多或少有所不同，希望能够帮助大家更好地认识这个世界。
Vency，两年经验产品经理，追求用户、技术、商业、社会价值的统一
下一篇《产品经理如何基于需求迭代产品（下篇3）：产品的整体设计之逻辑层和交互层》，敬请期待
