产品经理如何基于需求迭代产品(下篇2):产品的整体设计之业务层和系统层

1,951 阅读10分钟

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


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

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

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


整体设计

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

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


整体设计


业务层:业务方案

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

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

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

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

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


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

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



唯品会的整体架构


系统定位

系统定位就是指确定系统要解决什么需求,先要有拆分出系统的需求,然后才有这个系统。系统定位必然是最先一步,并不是所有东西都要单独拉出个系统去做。观察大型系统的演进过程可以发现,绝大部分系统都是从初始的小功能到模块最后再到系统的(功能<模块<系统)。

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


系统架构

确定了有哪些系统和对应的系统定位后,即可开始进行系统架构。系统架构强调的是系统和系统之间的联系,如果有多个系统还可以像唯品会一样平台化,便于理解也便于组织架构划分。

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


装满东西的旅行箱(来自百度图片)

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


模块抽象

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

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

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


规划蓝图

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

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

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



需求树示例


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

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



产品路线图示例


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

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

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

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

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



这些都是我自己的自我总结,也是我对世界的认知和总结,每个人的认知或多或少有所不同,希望能够帮助大家更好地认识这个世界。

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

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

下一篇《产品经理如何基于需求迭代产品(下篇3):产品的整体设计之逻辑层和交互层》,敬请期待