一次架构SaaS平台项目失败的经验总结

2021-02-07    分类: 网站建设

前言: 笔者从2017年起开始着手将公司现有的软件系统改造成多租户模式,以降低整个系统的运营成本。但最后这个项目以失败告终。今天,我将对这个saas项目是如何走向失败,做一个分析和反思。

此前,我们花费了两年的时间研发了一套教学系统,考虑到用户的数量与营运成本,后期决定将这套单体的应用程序改造为基于saas架构的多租户应用程序。经过短暂的需求分析后,便开始了重构工作。经过一年的艰苦奋斗,saas化的产品不仅用户不能接受,就连我们自己也无法成功运营。其功能的完成度差强人意,运营的成本也没有比单体应用少,反而运营难度上升了。通过一段时间的整理与思考,总结了这一次saas化平台失败的原因。

一、不务实的需求

一个成功的saas产品,需要有足够多的用户需求样本数据以及对这些样本数据深入的挖掘、分析和抽象,以得到一份通用的,覆盖率大的应用场景数据。只有如此,才能够开发出一款具有普世价值的应用软件,才能贴合saas用户的实际需求。而在此次的saas化产品的过程中,我们犯了“闭门造车”的严重错误,导致这一错误产生的原因是我们拿到的原始需求不够,仅仅凭借一两个客户的需求数据,并以此为蓝本展开系统的设计,实现了很多用户根本不需要的功能,比如用户只想要一个文档存储的功能,我们实现了一个网盘的功能;又比如说我们没有考虑到中学禁止学生使用手机,而我们的系统功能很多是基于移动端进行设计的,最后导致系统的功能和用户的需求对不上号。当我们花了很长时间去实现一个自己认为很棒的功能时,客户不认可这样的设计给了我们狠狠的一剂耳光,痛并郁闷着。

客户需求数据过少,加之主观上的臆想,导致了系统中充斥着大量华而不实的功能。表面上看,系统的各个功能都比较高大上,但就是这样高大上的功能,却和客户的想法背道而驰。客户的想法是最实际的,华丽的功能在一定程度上太过于注重“表演”,而无法真正帮助客户解决实际的问题。

面对这样一个问题,就需要在提出一个好的创意时,需要再三的与实际的需求做比对,只有创意与需求能够契合在一起时,创意才能转化为有效的功能,才能起到锦上添花的效果。而解决这一个问题,需要将如下的几个工作落实到实处:

  • 1、获取尽可能多的需求样本数据
  • 2、对需求数据进行划分、得出需求场景
  • 3、以场景建立用户故事,梳理业务逻辑
  • 4、以业务逻辑为单元,评估系统规模,展开系统设计
  • 5、建立有效的沟通机制,及时将设计原型与用户进行沟通,确定有效需求

下面,通过一张图来说明如何排除不务实的系统需求:


说明:

在第一步中,我们需要收集不同用户数量,不同知识结构、不同硬件环境以及不同资金支配能力的客户需求,这样才能从不同的维度去了解客户的想法和业务痛点。如用户量大的客户,更则种系统的整体协能力,以及业务的流程的连贯性和时效性。而用户量较小的客户可能则重于系统的高效和便捷程度。对于可支配资金,直接影响着系统在二、技术债务过大

任何应用程序的开发,都需要考虑技术债务问题,即木桶定理。从项目开始提案开始,就犯了技术冒进的错误。选择了技术一系列比较新的技术框架和设计思想,如前后端分离设计,微服务化和容器化等较新的技术栈,以及项目开始实施前没有做好相关技术的培训工作,导致项目组成员的技术能力良莠不齐,项目推进缓慢,接连踩坑,很多关键技术没有吃透,很多技术问题没有解决,导致应用系统性能脆弱,部署周期长,运维难度大,直至后面项目搁浅。

出现这样巨大的技术债务,是过于盲目的跟随市场技术浪潮,没有对自身团队技术能力做一个有效的评估所造成的。新技术固然有它超越现有技术的威力所在,但弊病也不少。首先是学习成本,需要花费大量的时间对整个团队进行培训,而培训并不是所有的人都能一个水平,从这开始,木桶的短板就开始产生了。由于技术掌握不牢固,开发工程中踩坑是避免不了的,这就导致项目进度急剧拉长,技术债务开始累积,最后的结果就是,产品千疮百孔,无法使用。

由于花费的巨大的时间去解决技术问题,从而忽略了一开始的运维问题(更多的是无暇顾及,先把产品搞出来再说)。很多时候,在开发调试阶段应用程序没有出现问题,一旦放到生产环境就开始问题百出。这是因为我们想当然的认为,新技术已经把所有的问题都解决了,抱着一种侥幸的心理,在匆忙之间将项目上线,从而忽视那些极为致命的问题,线上安全问题、性能问题、网络问题、环境问题、终端适配问题等等。

这些问题归集到一起,主要问题出在架构师身上,导致可以终结出这种架构师的几点特质:

  • 1、出方案靠拍脑袋,一锤子买卖。一拍脑袋,就这么定了,根本没有考虑后续的问题
  • 2、实现过程排胸脯,保证没有问题。过于自信,导致太过自负。对于架构师而言,没有问题就是大的问题
  • 3、出问题排大腿,这么回这样。等到问题出现了,才恍然大悟,当初为什么没有想到会这样
  • 4、程序崩溃排桌子,坑爹的框架。没有认真的选择合适的技术栈来完成项目,从一开始的设计从确定了系统的先天性顽疾,并不是框架本身的错。

那么,该如何避免技术债务过大的问题能?我的建议是杜绝设计上的冒进,不是新技术就一定好。可以采取小步快走,缩小升级范围,先将非核心功能进行改造,实现系统平滑过渡到新的技术框架,也让团队的成员有一个适应期,避免一次性集中踩雷的风险。与此同时,还需注意另外一个问题,系统重构不等于推翻重来。很多人会觉得推翻重来一定会比之前的设计好,在一定程度上可以将之前系统暴露的问题进行规避,但新的设计又会带来新的,更多的问题。所以,在进行升级过渡到saas产品时,一定要学会利用以后的成熟技术,减少升级的难度和成本,快速多批次的进行升级,这样,即便出现问题,也可以将问题控制在一个可以接受的范围,不至于蔓延至整个系统,甚至造成应用程序的不可用。

最后就是关于运维的问题,在设计一套系统架构时,一定要提前预估它的运维工作量,如果解决系统的“后顾之忧”,运维所带来的技术债务不比开发过程的少,以这次项目为例,应用程序按照业务分成了若干个服务,每个服务对应着10到20个不等的运行实例,由于项目组无法拿出有效的容器化方案,以及部署环境不支持Docker容器技术,也没有持续发布应用实例的环境,最后只能人工手动维护200多个JAR包的运行实例,当出现应用程序不可用,或者宕机问题时,需要人工重启对应的应用程序,这是一个糟糕的设计,或者说是失败的设计,对于运维来说,这是一场灾难。由于先天性的不足,加速了产品走向奔溃的边缘。

三、一口吃成大胖子

导致项目最终走向失败还有另外一个重要的原因,一口吃太多,嚼不烂。在确定需求的过程中,对于每一个租户提出的需求,我们采取了尽可能满足的方法,导致整个系统过于臃肿,杂乱,就好比一个万花筒。

按照这样一种方式,平台需要具备多端接入的能力,如PC、平板、智能手机等,以满足不同租户的要求,但最终我们连PC端都没有实现好。好高骛远,往往就是走向失败的开始;量体裁衣,才是做系统设计的硬道理。体系太过于庞大,团队的技术能力无法覆盖一下子覆盖到这么大的面,而且核心的功能还未接受市场的检验,就同时要满足适配多端的能力,这无疑是在开玩笑,最终将会得到一个烂尾工程。即便项目完成,充其量也就是一个软件中的“玩具”。

因此,在软件开发之初,切忌好大喜功,一下子将全部的功能都纳入到实现的范围,需要识别出哪些是必须功能,哪些是核心功能,哪些是扩展功能。需要分清楚产品的愿景与产品实现的本质区别。愿景是对产品生态链的展望,而技术实现需要实事求是,根据现有的技术水平和用户需求,做出一个折中的方案,任何设计都有妥协,没有一步到位的软件产品,也没有最好的软件产品,只有通过一步步的优化设计,一步步的升级技术,才能做出更好的软件产品。这一点在研发saas平台时尤为重要,你不可能同时满足多个租户的需求,你需要甄别出最具代表性和最有价值的那一部分租户,你的研发方向也需要向这一部分租户靠拢,下面通过一张图来说明构建一个saas平台时,需求占比应该如何分配:


为什么会有这样的一个配比?首先,能够创造价值的租户,是能够向你进行付费使用软件的租户,对于这一部分租户提出的需求,你可以以定制软件的态度去对待,对于他们提出的要求,你需要想办法去实现。而具有发展潜力的租户,是那些有可能成为你付费用户的群体,你需要研究产品的核心功能是什么?,以及什么样的核心功能才能打动他们。而具有代表性的租户是指那些能够提出比较创新的,具有一市场价值的需求的群体,他们是产品发展的创新所在,可以考虑为这一部分群体单独扩展出他们想要的功能,以观察市场的对平台的反应。最后是基础租户,他们的需求都具有普世性,需要考虑一定量的通用功能为其服务。

四、业务于产品先行

最后,谈谈技术之外的一些看法。大部分的团队都会犯这样一个错误:当产品开发完成之后,再去寻找市场。我们在这个项目中,也犯了同样的错误。可以思考这样一个问题,用户的需求随着时间的推移在发生改变,如果你不紧跟市场的动向,及时调整自己的产品功能,而是拿到一份需求后就开始闭门造车,当你的产品开发完时,就已经被淘汰了。为了避免产品没有市场,业务就必须限于产品动起来。通过不断的获取用户的需求,提取有价值的需求数据,及时调整产品的方向,才能缩短产品功能与用户需求之间的差距。业务先行,在间接的帮助平台设计者完善和充实现有的功能,及时的发现平台隐藏的问题,并对此做出调整,在交付产品前尽可能的规避可能出现的故障,提高平台的服务能力。

总结

对于今天的软件设计者来说,让软件使用者来适应你所设计的产品的时代已经不复存在。你需要主动的调整自己,从内到外多角度的看待问题,才能帮助你出色的完成软件的设计。在技术上,需要沉着冷静,实事求是的分析所面对的问题,需要懂得如何把控技术风险;科学有序的开展软件设计工作,断不可不顾现实情况,盲目跟风,技术冒进以及唯技术论的路子对待软件设计。在业务上,需要实时跟进需求的变化,具备敏锐的眼光去发现用户的痛点和难点,能够快速的对用户需求的变更做出合理、科学的反应。

新闻标题:一次架构SaaS平台项目失败的经验总结
网站地址:https://www.cdcxhl.com/news/99637.html

成都网站建设公司_创新互联,为您提供品牌网站建设网站内链网站建设定制网站自适应网站外贸网站建设

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

成都定制网站网页设计