“之前在小报童写了SaaS产品架构付费专栏，后面因为创业去了，没时间继续完善，就搁置了。现在将专栏的内容发到公众号上与大家分享。如果觉得不错可以帮忙点个在看，转发一下。
”
以下是正文内容。
01
—
前言
正式开始我们的SaaS产品架构的设计之旅，我们是不是要马上开始画原型、写文档呢？显然不是！我们是从0到1打造一个产品架构，因此最重要的是决定做什么和不做什么。我们需要从支撑租户侧的业务应用为基础来看看我们平台侧各个模块的优先级。
02
—
如何决定优先级
需求优先级评估有很多种模型可以评估，比如RICE法则、KANO模型。租户侧（包括企业和用户）的业务需求是用这两种方法评估没问题。对于平台侧而言，用户是我们公司内部的同事，包括产品、开发、运营、实施、客户成功、客服、管理层等等角色。这么多角色，显然一开始我们无法满足所有的角色的需求。怎么确定需求优先级的原则呢？我的建议是在从0到1阶段，以支撑租户侧正常使用的必备需求优先。
我们可以参考KANO模型，将我们的模块分为必备需求、期望型需求和兴奋型需求，然后先做必备需求，再做期望型需求，最后做兴奋型需求。除此之外，作为平台侧，也需要考虑日常运营的效率，因此还需要考虑将提高产品开发、运营效率的需求列入进来，我们称之为保障型需求。
从次序上来说，我会建议先做必备需求，再做保障型需求，然后是期望型需求，最后才是兴奋型需求。之所以把保障型需求放在第二位，是因为SaaS产品的稳定性非常重要，一旦平台出现了问题，会影响所有客户的日常工作。因此，我们需要支撑开发和运营人员快速解决系统问题和客户问题，保障整个平台稳定运行。
对于期望型需求，通常会是业务部门根据自己需要，随着产品运营后才会逐步产生的诉求，因此可以放到后面逐步迭代实现。甚至，如果开发资源不足的情况下，也可以考虑一些临时的手段，比如报表类的可以通过SQL导出Excel表格，而不一定要开发相应的功能界面。
兴奋型需求其实在SaaS的平台侧不会太多，毕竟产品主要是给我们企业内部人员使用的。这块个人建议是能不做就不做，将有限的产研资源投入到解决租户侧需求上面去。
03
—
确定模块优先级
确定了决定优先级的原则后，我们就需要给每个模块进行需求分类了，即将我们的各个模块划分到必备需求、保障型需求、期望型需求和兴奋型需求中去，这样我们的优先级也就基本确定了。下面是业务层和中台建议的一个分类表。
我们虽然说了优先级次序是必备需求、保障型需求、期望型需求和兴奋型需求。但是实际不同需求上线的阶段也是不同的，比如在我们的产品还没什么用户的时候，做限流容错没什么意义。包括合同管理在MVP阶段也可以不做，因为前期客户不多的情况下，我们可以通过别的手段替代，比如可以用多维表格先记录合同信息。回头开发的时候再把数据导入系统就可以了。
也就是说，在SaaS产品从0到1的过程中，我们的产研资源要紧着用，资源要用在刀刃上。前期，产研资源不足的情况下，能够用其他工具过渡的可以优先选择过渡方案。
附以上各个阶段的解释说明：
MVP：最小可用产品阶段，以最低成本满足必备需求； PMF：产品-市场匹配阶段（Product-Market Fit），产品在种子客户中试用，并迭代解决使用过程中的问题。 GTM：产品核心功能已经可以面向市场推广，开始进行市场销售活动，有更多的客户订阅SaaS产品。 1-N：市场验证产品模式可行，投入更多资源进行市场覆盖，尽可能多地覆盖目标地区的目标客户。
