Saas.为什么要搞Saas，会遇到哪些问题，看看5年Saas开发踩过的坑

什么是Saas

原来一人一套系统，现在需要很多人共同用一个系统。

好处

成本，分摊到每套系统，成本较低。 无论表面有多少好处，本质都是为了省钱。

问题

为了到达不同客户使用同一套系统，就需要解决不同用户的不同需求

1. 需求不一样，一个要CRM，一个要ERP。 -- 没法解决，要解决也是将很多个系统做到了一块而已，这种需求做不成Saas。所以Saas需要固定在一个较为聚焦的需求上。 第二种法子呢，将所有的业务系统抽象，然后开发这么一个平台，然后在这个平台上开发。

2. 同一个系统如CRM，也有差异，如：不同学校学生的信息大体差不多，但也有差异，或者个性化要求； 审批流程或者某个事务处理的流程也不同；最后就是界面的不同，大家都穿一样的衣服，虽然能御寒，但不能满足美的追求。

3. 业务系统处理逻辑抽象，无非就是一个公文或者其他什么信息，经过一定的处理流程，辅助一些通知呀什么的，最后完成一项工作。抽象一下，公文或者信息可以抽象为一个“信息包”，对于一张表，或者一个实体。 这个实体经过一定的处理流程，如果是审批场景，就是审批流。 问题反馈，就是问题处理的流程，这个流程就是业务处理流程。

4. 有了这么一个平台，一些架子还是需要的，比如：登录，认证，菜单控制，数据存储，安全等方面要求等，消息通知，个人信息&维护等，以及支撑这些功能的架构，后续的业务系统需要在这个平台上开发，需要给人可插拔的赶脚，架构上也需要支持，代码也不能耦合。 架构的分离必然导致的团队的分离，就需要解决好两个团队的沟通协调。实际工作中需求一定输入到业务开发小组，但架构或者平台小组，处于技术上游，业务下游。 业务开发小组驱动这些处于技术上游的大爷们不是一件容易的事情，如果没有机制支持，最后会一团糟。

5. 在这个平台开发，比如需要最好规范，原来的开发是基于地平线，现在站在一定平台，如果这个平台不规范，那么开发会很累，且效率一定上不去。

实际应用类型

工具类Saas系统构建

客户不会有特性化需求，跟多用户组系统差不多。权限控制上区分就行。

业务初期或者业务比较固定

构建一个Saas平台初期， 或者 业务比较固定。 可以使用：可变字段+流程引擎+配置化界面解决。原因是刚开始构建一个平台资源不足，而且业务模式不确定，快速出一个MVP版本最重要。二一个业务模型固定，就可以将一部分固定的业务按照项目来开发，只将特性化部分进行配置化开发就行。

PaaS沉淀

如果完成初期的业务沉淀，和抽象工作，而且用户的特性化要求比较多，就需要腾出精力沉淀Common功能，比如：可变字段，可以裂变为：元数据完成数据存储，固定列表和详情解决数据CRUD，展示使用表单引擎； 流程也可以拆分为：处理审批业务的审批流程，处理业务流程的业务流。 页面也需要配置化，列表和详情需要固定，同时需要支持特性化界面开发的展示和通信问题。架构也需要跟着扩展，数据隔离方案变动， 文件系统适配，  功能权限控制，数据权限扩展等，以及性能上也需要支持。

基于PaaS的开发

需要沉淀一套标准的开发模式出来，这种模式类似现在基于Mysql，自己编写代码开发一样。现在是根据需求建表，拆分界面，各自开发，然后集成。 如果基于PaaS平台开发，就需要每个开发了解PaaS平台，可实际不现实，成本太高。 如果能沉淀一套基于PaaS的开发模式，就能基于PaaS上面开发，而不是了解PaaS的基础上添加代码。类似：高级语言把底层操作操作系统的细节屏蔽了，并输出一套标准的API来操作，如果没有这套API你怎么办，只能挨个看底层的代码，这是不可接受的。 这部分需要在架构上就支持代码的分离和该有的通信。

做Saas难不

很难，不仅仅在于对业务的抽象，技术实现，还需要考虑多团队协作的问题。

做软件抽象很重要，但这东西不好衡量(在面试的1~2H内)，而且管理上对面试者要求就不高，让他挑选一个很大牛，很难。

抽象在业务理解上具有同等重要的作用，只是日常业务系统比较简单，以为画画界面就算是需求分析，产品设计。这就是市场上大部分产品经理的质量，能具有从用户只言片语中准确理解到需求已经很难，再能从复杂的业务需求上抽象出问题的本质就更难，人也就更少了。

做Saas的技术架构需要全程陪伴，不像其他系统架构师根据经验搭建出来一套，开发再上面开发就行，这套架构可以说市场上大家都是这么搭建的。可Saas没有现成的经验可以参考，而且还需要从简单到复杂一点一点迭代(因为刚开始架构也没有那么高要求，但后续随着业务的抽象推进，架构也需要迭代，不同于普通系统可以留技术债，Saas如果架构不陪伴，普通开发可能需要话费几倍精力完成)。

技术架构不仅仅完成当前产品要求的功能，还需要主动引进一些技术组件，做出原型，讲给产品。让后续的设计是基于这个技术认知上来设计的。

管理上也是需要按照实际情况创新，普通的固定流程管理那一定不行。

做Saas对没步都提高了要求，更高的要求是，这几部分需要合力，任何一件事都需要考虑其他方面，一个人能都了解当然好，但可遇不可求。更多的是将几个架构，业务专家，项目管理，产品几方面放在一块讨论。

如果难点到此处也不算难，可以看出来，上面说的这些会重构公司现有的管理，战略等。也就是说：Saas是底层驱动的。这就跟现在中国的大部分公司实际情况相反了，咱们习惯了员工听领导的，做领导分配的工作，现在让领导根据中层研究的结果，同步公司的发展和战略，以及人事管理，绩效激励等制度，真的不容易。这点如果领导从“管理者” 没法过渡到“服务者”就没办法解决。及时当前公司制度合理，但迟早会更不上业务的发展，而且会严重迟滞员工的积极性。

最后一个难点是：甲方超强势，我要什么就得要什么，我说怎么做就得怎么做，否则怎么体现我是甲方呢？ 

总结

难点，痛点都是做Saas必须解决的问题

问题难不是问题，问题是许多公司就人认识不到这点，更别说解决了。