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必需处置的问题
问题难不是问题，问题是许多公司就人认识不到这点，更别说处置了。