本文作者：丰宪飞
本文来源：小飞哥笔记（gh_c522412ef030）
---BEGIN---
我之前的一篇文章中讲到过，
一款Saas产品，产品架构搭建的好坏，对结果的影响截然不同。
如果Saas产品架构搭建的不好，那么带来的直接结果就是：
1.客户在完成某一个具体任务的时候，在整个操作的过程中，有一堆不相关的功能出现在客户的操作页面里，导致客户无法高效率的完成工作；
2.没有一个框架性的产品架构指导，后面遇到的新需求，新功能，有可能会被后来的产品经理任意归类，或者新建一个归类来解决新问题，最终产品越做越乱；
3.随着需求越来越多，需要开发的功能就越来越多，功能的耦合度也越来越高，然后开发难度就进一步增大，经常会面临重新搭建架构的局面。
反之，
如果架构搭建的好，那么带来的好处至少有以下几种：
1.对客户来讲，看到的页面都是简洁的，能高效的完成任务，给客户带去价值；
2.架构搭建的好，客户用起来好用，就会有更多的客户愿意用，给公司带来了更多的商业价值。
3.不用由于架构搭建不合理而带来的重构烦恼，以后的新需求、新功能基本上都能在架构内找到合适的位置；
4.公司能够花费更低的成本来实现不同客户的不同需求。
可见，架构搭建的好坏，对业务的影响是比较大的。
那么，
如何才能把一款Saas产品的产品架构搭建好？
这里，我们先对架构做一个定义。
百度百科对“架构”的定义，里面有很多技术语言方面的解释，理解起来也比较麻烦。
于是，我根据自己的理解，做了一个新的定义。
架构的定义是指：
“根据架构搭建者对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度进行分类整合，
并梳理出分类整合好的各个模块之间的逻辑关系，最终形成一个产品来解决某一类问题”。
这就是产品架构。
这句定义里有三个关键点：
1.对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度进行分类整合；
2.并梳理出分类整合好的各个模块之间的逻辑关系；
3.最终形成一个产品来解决某一类问题”。
通过对这3个关键点的理解与运用，对如何能搭建好一个Sass产品架构，你会有一个整体的认识。
接下来我一个一个的讲。
01
解决某类问题
先从第三个关键点开始聊，对于Saas产品来讲，
搭建好的产品是用来解决问题的，而且还是某类问题。
这个“某类问题”就是战略问题。
战略对于产品，或者说对于产品经理来说，最重要的作用就是：
知道要做什么，不做什么，很清晰或者大概范围的知道要解决的问题的边界在哪，然后在这个边界范围内去定义产品，设计产品，给客户带来价值，从而也给公司带来商业价值。
02
功能分类整合
战略问题梳理好以后，接下来就到第二步：
通过对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度进行分类整合。
如何对Saas业务进行理解？
宏观上，可以从行业定义的理解、行业的市场规模、行业发展所处阶段、外部经营环境的分析（PEST）等维度来理解业务；
中观上，可以从产业链上下游分析，企业竞争格局的分析、资源集中度、进入门槛的分析、标杆企业商业模式分析、Saas竞品分析等维度来理解业务；
微观上，可以从服务企业经营的业务，相关角色，工作流等角度来理解业务。
关于对业务理解的问题，我这里讲了一个思考框架。
更详细的业务理解问题，改天我会单独写一篇文章来深度讲解。
如何找用户需求？
方法有很多，
比如：
1.可以通过用户访谈的形式找需求；
2.可以通过用户调查的方式找需求；
3.可以通过深入一线，观察、学习的方式找需求；
4.可以通过会议沟通的方式来找需求；
5.可以通过竞品分析的方式来找需求；
6.等等。
如何把功能按不同维度进行分类整合？
这里就是在做分类整合时的核心思想就是，一个大分类里要用来解决一类问题。
比如，
一款给餐饮商家用的Saas系统，后台包括的功能模块有：商品、订单、数据、营销、店铺、财务等模块，
不管是现在还是未来，
遇到商品需求功能，就要把功能归类到商品模块；遇到营销需求功能，就要把需求归类到营销模块；而不是没有标准，乱放。
通过对业务的理解，找到了用户需求，并把用户需求转换为功能，并对功能进行分类整合后，最终就会得到了一个功能结构图。
例如，
下图就是某景区Saas产品通过以上方法梳理得到的功能结构图：
PS：为了方便理解，以上一二级模块细节内容有所删减。
03
模块之间的逻辑关系
通过上一部分，
我们已经找到了要做的功能，并把功能进行了分类整合，形成了一个又一个的模块。
此时还不算完成产品架构的整体思考，因为一个又一个的产品模块独立着，没有连接在一起的效果就是：并不能发生什么效果。
只有把各个模块有效的连接在一起才能实现目标，解决问题。
这时，
需要梳理出分类整合好的各个模块之间的逻辑关系；
如何梳理各个模块之间的逻辑关系？
可以用数据流转过程来梳理。
比如，
还是以文章中提到的景区Saas产品为例：
1.景区想要卖票，那首先应该在门票管理模块上传门票，管理门票；
2.上传的门票信息会进入店铺中，供游客查看、购买；
3.游客通过店铺购买完门票以后，就会生成订单信息，进入订单模块；生成财务信息，进入财务模块；生成数据信息，进入数据模块。
最后，
通过数据连接，就能把各模块之间的逻辑关系梳理清楚了。
最终形成的产品架构图如下：
PS：为了方便理解，以上的逻辑思考图，有所删减。
这里补充个话题聊一下：
“关于搭建产品架构时，我们是否有相似的解决方案可以参考？”
虽然说，每家公司的每条业务根据行业、机会、自身能力等情况的不同，梳理出来的战略基本上都不一样，搭建出来的产品架构也就不一样。
但是，
我们把这些所有的不一样，给抽象思考，分类整合一下，基本上可以发现所有公司做的Saas产品，基本上都属于两大类（以下分类目的，是梳理出产品要解决的问题大概属于什么类型，然后我们在搭建产品架构时，可以找到类似的解决方案来参考）：
1.业务垂直型；
2.行业垂直型。
PS：随着创业公司业务的发展，这两大类会有合二为一的情况存在，也就是Saas产品里包含了多个垂直行业的多个业务场景的多个解决方案。
第一类，业务垂直型：
业务垂直，可以这样理解，Saas产品要解决的问题是一家公司商业系统中的某个系统，也可以这样讲，要解决的问题是一家公司价值链的某个环节问题。
可能理解起来比较抽象，这里我举两个例子讲讲。
比如：
在制造行业，一家公司的商业系统会是这样的，研究开发——采购——制造——营销——销售——服务；
在广告行业，一家公司的商业系统会是这样的，购买媒体——开发客户——商品企划书——企划销售——广告制作——实施、评论。
这两个案例就是制造行业和广告行业商业系统情况的一个介绍（或者是制造行业和广告行业价值链相关环节的一个介绍）。
做Saas创业的公司，
会把整个大的商业系统中的某一个或多个小系统单独提取出来，给出相应的Saas产品解决方案，这就是业务垂直型。
现在比较通用的业务垂直型Saas产品，解决的业务问题，大概都有：
1.CRM；
2.人力资源；
3.ERP；
4.推广营销；
5.财税；
6.OA；
7.等等。
如果，你解决的是业务垂直型相关的业务，那么每一个业务垂直型相关的问题，你都可以找到相关的书籍、竞品等来看，看看类似的产品是如何搭建架构的，可以学习，参考。
第二类，行业垂直型：
行业垂直型，就是你公司Saas产品要解决的问题是某个垂直行业相关的问题。
比如：
1.零售；
2.餐饮；
3.旅游；
4.教育；
5.医疗；
6.物流；
7.等等。
解决行业垂直型问题时，可以通过以下两个框架去思考：
行业产业链+企业价值链。
首先进行行业产业链的思考，可以得出的结果是，能清楚的知道公司要解决产业链里哪个经营主体的业务问题。
知道要解决哪个经营主体的问题后，接下来要思考的是，要解决经营主体哪个或者哪几个价值链环节的问题。
