文档章节

记一次构建SaaS平台项目失败后的反思

 乱世当空
发布于 07/15 21:11
字数 4029
阅读 4619
收藏 136

记一次构建SaaS平台项目失败后的反思

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

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

一、不务实的需求

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

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

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

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

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

记一次构建SaaS平台项目失败后的反思

 

说明:

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

第二步、建立场景是为了把庞杂的需求进行切割,建立科学的需求分类,减轻需求分析的难度和时长。将杂乱的需求按照类别进行深入分析,挖掘客户的业务痛点,为构建起用户故事提供素材和依据。

第三步中,分析的视角将从局部变为全局,通过第二步得到数据,建立起用户故事,以分析各需求之间的联系和各自的主线。

第四部是对需求进行统筹规划,将需求变成可用的业务逻辑,并对此业务逻辑进行技术可行性和风险评估,最后将此评估结果与客户需求进行比对和调整,确定最终的有效需求。

二、技术债务过大

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

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

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

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

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

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

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

三、一口吃成大胖子

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

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

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

记一次构建SaaS平台项目失败后的反思

 

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

四、业务于产品先行

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

总结

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

文章转自:https://www.toutiao.com/i6699138217674801667/

作者:ramostear

© 著作权归作者所有

粉丝 13
博文 25
码字总数 59322
作品 0
黄浦
高级程序员
私信 提问
加载中

评论(19)

玖伍陈海天
玖伍陈海天
我现在就是用的sass模式,现在正在重构拆分为单用户版本。
无敌菌君
无敌菌君
摸石头过河,被人带到马里亚纳海沟去了
为猪欢呼
好文章,如果能加上使用了什么具体技术的话,看起来会更有感受。
GGGGeek
GGGGeek
不支持docker?开始怎么想的?200多个jar手动部署?我觉得你们项目leader有很大的问题,而且项目一开始就200多个jar?你们做的是堪比淘宝的项目吗?
Dandelion_
Dandelion_
失败经验比成功经验更有用,收藏了
街拍转发器
街拍转发器
我其实喜欢看别人的失败的经验,因为失败的经验才更有帮助 。
ZigzagV
ZigzagV
有参考意义
二号铺
二号铺
saas是啥
WunHwan
WunHwan
很好的文章,学习了
xiaoyu123
xiaoyu123
实事求是,转变的困难和准备不足(不仅仅是资源,还有心理上的准备)。
JEECG Framework 3.4.3 GA 版本发布

JEECG 微云快速开发平台 (JEECG开源平台 - 云平台SAAS企业应用在线开发与微信移动应用) JEECG Framework 3.4.3-GA版本发布 ——————————————————————————————...

Jeecg
2014/02/16
4.6K
12
闲说CRM的三个境界

一 前言 人有分不同风格,企业也有不同风格,这个CRM行业的相关企业也不可避免的也带有不同风格,因为风格不同,各自的运营和境界也不同。其实,为什么说起这个话题,是因为在国内做CRM要耐得...

叶开
2009/10/27
0
0
400余份阿里珍贵技术资料限时免费下载(持续更新中)

400余份阿里珍贵技术资料限时免费下载(持续更新中) 2017年,你是否有一个小目标,打算在新的一年事业更上一层楼、代码写的更优美、对互联网生态拥有更多宏观的战略性了解? 小编精心挑选2...

阿里云官方博客
2017/03/16
3.6K
7
探究SaaS带来的商业模式创新机会

2008年,SaaS无疑成为中国软件产业一股不容忽视的热潮。SaaS在给用户带来新的软件交付模式的同时,正在引导软件产业的商业模式变革,形成一个完全不同于以往的新型软件产业链,同时它也正在打...

刘古权
2018/06/26
0
0
记一次扯到蛋的教训

上周五的时候我对某个项目做了一个更改,将里面的构建脚本由maven换成了gradle。原因之一是因为maven的配置太繁琐,由于其引入了lifecycle的机制,导致其不够灵活,而gradle作为用groovy写的...

无敌西瓜
2013/11/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
6
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
8
0
详解箭头函数和普通函数的区别以及箭头函数的注意事项、不适用场景

箭头函数是ES6的API,相信很多人都知道,因为其语法上相对于普通函数更简洁,深受大家的喜爱。就是这种我们日常开发中一直在使用的API,大部分同学却对它的了解程度还是不够深... 普通函数和...

OBKoro1
昨天
7
0
轻量级 HTTP(s) 代理 TinyProxy

CentOS 下安装 TinyProxy yum install -y tinyproxy 启动、停止、重启 # 启动service tinyproxy start# 停止service tinyproxy stop# 重启service tinyproxy restart 相关配置 默认...

Anoyi
昨天
2
0
Linux创建yum仓库

第一步、搞定自己的光盘 #创建文件夹 mkdir -p /media/cdrom #挂载光盘 mount /dev/cdrom /media/cdrom #编辑配置文件使其永久生效 vim /etc/fstab 第二步,编辑yun源 vim /ect yum.repos.d...

究极小怪兽zzz
昨天
6
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部