如何从产品架构层面去定义一个SaaS产品？
老王前段时间去面试了一家做SaaS产品的公司，虽然后来没什么消息，但是面试过程中面试官问的一个问题让老王印象深刻，回来之后在网上也查了不少相关的内容，今天想试着总结并重新回答一下这个问题——“如果给你做一个SaaS产品，如何从产品架构层面去设计？”
图1 what
当老王听到这个问题的时候，腹诽了一下，确定这个问题的每个字我都认识，每个词组单独拉出来我也能清晰的理解，但是组合起来就有点费解了。所以老王委婉的说道：“不好意思，能再解释一下吗？”
面试官可能看出了我的疑惑，不知道要回答些什么，然后说，“就是让你负责做一个SaaS你都会做些什么，比如有哪些模块？”这么一说，老王就懂了，这里要注意，参加面试的朋友遇到开放式命题的时候，第一点要表述的一定是设定场景。
这里有两个好处：第一是尽可能设定自己熟悉的场景，避免犯错；第二是面试官如果觉得这个场景过于简单，会给出他想要的场景，这样就能更加清楚的了解面试官希望你回答的范畴在哪。
老王设定的场景是比如说我们做的是一个电商场景的SaaS，这个产品类似于有赞，那么经过了一系列需求收集分析后，针对电商场景，简单的划分为前台用户端，后台商家端。（做电商的朋友不要喷我哈，我知道并不是这么简单的两个，里面涉及的非常多，包括仓储、物流、支付、分单等等，但是面试嘛，说多错多。）
图3 用户前台和用户后台
用户端的核心业务流程就是浏览商品>下单>支付>发货>收货>评价>订单完成，商家端的核心业务流程有几个，分别是用户管理、商品管理、供应商管理、营销活动、订单、支付、快递、财务、数据报表等等。
好嘛，面试官听完之后又问道：“那你是依据什么构建的这个产品框架的呢？或者说基于什么原因这么划分模块？”，老王心想说凭借的是我多年的购物经验啊，回归到现实工作中，如何划分这些模块的依据或者来源大致可以分为：竞品分析；需求分析；流程梳理。
图4 三种方法
通过竞品分析，我们能知道在一般情况下别人是怎么做的，我们不能说他都是对的，但是必定有其道理，如果只是去看别人有什么你就要有，那这是不可理喻的，要分析他为什么要这么做，找到一个根本原因或者依据，而不是一句“存在即合理”就解释了。
在产品的实际工作中，很多产品经理要做的产品都已经珠玉在前了，重新制造一个轮子并不能说它一定是毫无意义，但是绝大多数企业确实是毫无意义甚至还不如前者。美其名曰借鉴，其实就是抄。当然抄也不是全都照搬，也会根据实际的业务情况、资源配置等等因素去权衡，优化或删减，从而达到既符合企业定位、满足市场需求的同时，又能为产品节省资源。
需求分析，这也是我们常说的，但是在需求分析的过程中我们可以做很多，其中用户访谈，是我认为做SaaS或者做定制化产品很常见的。
比如在做财务系统时，与财务总监、会计、出纳沟通，甚至还需要与CFO、法务沟通，在了解财务的工作内容的时候，就可以通过他们的一些工作习惯和认知，去定义或划分功能模块。这也与尼尔森的“一致性原则”中与用户预期保持一致性相同，甚至也可以说这是与现实映照。
流程梳理，其实这也是需求分析中的一个必然步骤，之所以拉出来说，是因为在做SaaS的时候，有些业务的模式的创新性导致没有一般等价物作为参照，我们需要根据实际商业模式去设计适合他的业务流程和规范，并且为之提供切实有效的系统作为商业开展的保障。在梳理整个业务流程的时候，有哪些场景、哪些角色、哪些流程对应的都需要什么，抽象出来，一目了然。
比如审核，一般SaaS产品都会有工作台，有审核模块，将用户可见、参与的审核信息聚合统一处理，并且大一些的SaaS组合产品会将流程引擎与审核中心独立成SaaS产品给各业务引用，这都是在流程梳理时，通过抽象聚合出来的。
当然，上述并不是我在面试的时候所叙述的，都是后来我回来琢磨的时候想到的，当时我说了一个非常糟糕，乃至于面试官都忍不住笑了，我说：“这都是顺其自然的啊，通过需求分析挖掘出所需要的内容，自然而然就划分了。”
现在想想，真的是太年轻啊，一点产品思维都没有体现，一丢丢的逻辑性都没有。
当然，我上面说的全是一家之言，完全是废话，也是后话。让我再次重申这个问题：“如果给你做一个SaaS产品，如何从产品架构层面去设计？”这里面有两个名词：SaaS产品，产品架构。不知道SaaS产品为何物的，请出门百度，或者以后老王再单独总结归纳一下。
这个“产品架构”让我费解了好一阵，并且网上查了好一阵也没有得到一个清晰的界定，什么是产品架构？所以我们把这个词拆分一下“产品”和“架构”。一般提到架构，相信你一定听说过架构师，老王也有幸认识一位架构师，虽然接触的时间不长。
那么什么是架构呢？百度词条显示：
架构，又名软件架构。软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图，软件架构描述的对象是直接构成系统的抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。
翻译成一个词就是高屋建瓴，大白话就是从整体上，将软件高度抽象成组件，通过架构图直观的去表达所规划软件的各个组件以及各个组件之间的关系，并传达软件的业务流程、数据流转。在老王看来，从商业的角度来说，制定一个商业模式也算是一次架构，从企业角度来说，部门的设立与调整也是一次架构。
看一下老王虚构的一个架构图，想来你能有一个较为清楚的认知了。
图7 三层架构图
那么产品架构是什么呢？
这里我们只讨论互联网以及软件产品经理的思考，斯以为，从整体上规划产品，将具象化的产品功能或业务高度抽象并清晰的表达，从产品设计上高度契合软件架构所要达到的效果。软件架构的非功能性特征包括：可靠性；易用性；可扩展性；强壮性；灵活性；性能等等。那么，在做产品规划与设计时，也必须时刻关注这些非功能性特征。
在我们了解了这些之后，再来看这道题就变成了：从整体上规划、设计一个SaaS产品，将具象化的产品功能或业务高度抽象并清晰的表达。虽然分析到这个地步了，但是貌似也没有拿出一个实际有效的答案，属实有点尴尬。在老王看来，这个时候画一个产品架构图来就最好了，但是面试嘛，更多的是口头表述，那老王就抛砖引玉一下吧。
尊敬的XXX公司面试官您好，针对这个问题，我想首先拟定一个场景，我们假定要做一个电商SaaS产品，那么作为SaaS产品，一般是要具有一些行业通用性，假设我们已经做过了用户调研、竞品分析、需求分析，得出了以下几个需求：1.用户购买商品；2.商家管理商品并且需要给用户发货；3.用户收到货物会评价等等。
那么，在经过上述分析之后，我们可以得到一些内容：这个产品至少有三个角色，用户，商户，公司，也就至少有三个终端，我们分为用户前台、商户后台、公司运营平台。那么前台都需要些什么呢，需要商品展示、支付、订单查询、评价，甚至是商品的分类和搜索，未来可能还有会员体系等等。
商户后台，根据需求，需要用户管理、商品管理、订单管理、评价管理、供应商管理，未来还会有营销、财务、数据、仓储、物流等等等等，这些模块或者系统来支撑商户后台。公司运营平台也会有客户管理、订单管理、财务管理等等一系列模块或系统。
以上其实就是一种产品架构，这是从功能模块来划分的，当业务进一步做大的时候，技术得到了一定的发展，就需要从产品、服务和技术层面去规划产品架构，这个就类似于编程中的MVC框架，对应的产品表现层、服务逻辑层、数据服务层。（这里大家的叫法和用法都有所区别，不过都是对应MVC中的model-view-controller这种结构）
至于划分依据，有几个方面：
- 竞品分析，根据该领域头部玩家的经验，在其基础上去优化沉淀自有品牌的优势；
- 需求分析，在于客户或行业资深专家的沟通中，不难发现一些行业规律，依照行业规律划分也是符合用户行为习惯的；
- 流程梳理，在梳理的过程中根据流程的必要性，以降低耦合为目的去划分和提炼必要的模块和功能。
相信大部分产品经理其实很少正经做产品架构，日常的工作更多的是接到需求，分析需求，然后设计产品。但殊不知又时刻与产品架构保持联系，因为你的每一次新增、改动都会影响整个产品的架构。
建议你可以试着做一个产品架构，不一定从无到有，也不一定要面面俱到，只要将现有的产品或者模块遵照MVC的三层关系，去抽象并且清晰的表达你所做的产品与其他产品或模块的对应关系和一来关系，就可以了。
老王在一份短暂的工作经验有幸接触了产品架构，其目的是要求产品经理必须清楚自己所做的产品在事业部所有产品的架构中所处的位置，以及与各个产品的依赖关系、数据流转。产品架构图不仅仅是这些作用，对于产品经理来说，还可以让你从宏观的视角看清楚模块与模块之间、产品与产品之间、系统与系统之间的关系，更可以让你的领导以及运营和市场的同事清晰的知道你的产品规划。
综上就是老王因为这个面试问题而去了解的产品架构的相关内容，写这篇文章的主要目的是为了自省，如果对你有所帮助，那是在是意外之喜。
作者：老王，一个不愿意透露体重的90后产品经理，公众号“老王修炼指南”唯一作者。
本文作者 @老王指南
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
