saas成功案例(saas的缺点及解决),本文通过数据整理汇集了saas成功案例(saas的缺点及解决)相关信息，下面一起看看。

记得SaaS平台项目失败后的一个反思前言：作者从2017年开始将公司现有的软件系统改造成多租户模式，以降低整个系统的运营成本。但最终这个项目以失败告终。今天，我将对这个SaaS项目是如何失败的进行分析和思考。

之前，我们花了两年时间开发教学系统。考虑到用户数量和运营成本，我们后来决定将这个单一应用程序转换为基于SaaS架构的多租户应用程序。简单的需求分析之后，重建工作就开始了。经过一年的努力，SaaS的产品不仅用户无法接受，就连我们也无法成功运营。其功能的完成并不尽如人意，运营成本并不比单个应用少，但运营难度有所增加。通过一段时间的整理和思考，本文总结了SaaS平台失败的原因。

一、不务实的需求

一个成功的SaaS产品需要足够多的用户需求样本数据，并对这些样本数据进行深度挖掘、分析和抽象，从而获得一个覆盖面较大的通用应用场景数据。只有这样，才能开发出具有普遍价值的应用软件，满足SaaS用户的实际需求。在SaaS产品的生产过程中，我们犯了一个“闭门造车”的严重错误。这个错误的原因是我们没有获得足够的原始需求。我们只用了一两个客户的需求数据作为蓝本来设计系统，实现了很多用户根本不需要的功能。比如用户只想要一个文档存储功能，我们实现了一个网盘功能；比如我们没有考虑到禁止中学生使用手机，我们的很多系统功能都是基于移动端设计的，最终导致系统功能与用户需求不匹配。当我们花了很长时间才实现一个我们认为很棒的功能时，客户对这个设计的不认可给了我们一记耳光，痛苦和沮丧。

客户需求数据太少，加上主观想象，导致系统中大量华而不实的功能。表面上看，系统的各项功能都比较高，但就是这么高的功能，与客户的想法背道而驰。客户的想法是最实际的，华丽的功能在一定程度上过于注重“性能”，并不能真正帮助客户解决实际问题。

面对这样的问题，需要一次又一次地将一个好的想法与实际需求进行比较。只有想法和需求能够契合，想法才能转化为有效的功能，才能做到锦上添花。为了解决这个问题，我们需要执行以下任务：

1.获取尽可能多的样本数据。2.划分需求数据，得到需求场景。3.用场景搭建用户故事，梳理业务逻辑。4.以业务逻辑为单位，评估系统规模，开发系统设计。5.建立有效的沟通机制，及时与用户沟通设计原型，确定有效需求。接下来，使用图表来解释如何消除不切实际的系统需求：

描述：

第一步，需要收集不同用户数量、不同知识结构、不同硬件环境、不同资金控制能力的客户需求，从不同维度了解客户的想法和业务痛点。比如用户量大的客户，可以提高系统的整体协同性，以及业务流程的连续性和时效性。但是，用户数量较少的客户可能更关心系统的效率和便利性。对于可支配资金来说，直接影响到系统在设计时的布局，比如性能的分配，交互的体验，后期定制的收费标准。

第二步，设置场景，对复杂的需求进行切割，建立科学的需求分类，降低需求分析的难度和时长。按类别深入分析杂乱的需求，挖掘客户的业务痛点，为构建用户故事提供素材和依据。

第三步，将分析的视角从局部转变为全局。通过第二步，会获得数据，建立用户故事，从而分析需求与其主线的关系。

第四部分是对需求进行整体规划，将需求转化为可用的业务逻辑，并评估这种业务逻辑的技术可行性和风险。最后，将评估结果与客户需求进行比较和调整，以确定最终的有效需求。

二是技术欠账太大。

任何应用开发都需要考虑技术债，也就是木桶定理。从项目建议书一开始，我就犯了技术超前的错误。选择了一系列比较新的技术框架和设计思路，比如新的技术栈，比如前端分离设计、微服务和容器化，以及项目实施前相关技术培训的缺失。导致项目组成员技术能力良莠不齐，项目进展缓慢，而且很多关键技术没有理解透彻，很多技术问题没有解决，导致应用系统性能弱，部署周期长，运维困难，直至后续项目搁浅。

如此巨大的技术债务，是盲目跟风市场技术浪潮，没有对自己团队的技术能力进行有效评估造成的。虽然新技术有超越现有技术的力量，但它也有许多缺点。首先是学习成本，整个团队的培训要花很多时间。然而，并不是所有的人都能被训练到相同的水平。从这一点开始，木桶的短板开始显现。由于技术掌握不牢，在开发项目中踩坑在所难免，导致项目进度急剧延长，技术欠账不断积累。结果产品千疮百孔，无法使用。

由于花了巨大的时间解决技术问题，忽略了初期的运维问题(花的时间比较多，所以要先把产品弄出来)。很多情况下，应用在开发调试阶段没有问题，一旦投入生产环境，就开始有问题了。这是因为我们想当然的认为新技术解决了所有的问题，抱着侥幸心理，匆匆忙忙的把项目上线，从而忽略了那些极其致命的问题，比如上线安全、性能、网络、环境、终端适配等等。

这些问题凑在一起，主要问题出在建筑师身上，由此得出这个建筑师的几个特点：

1.拍脑袋做个计划，一锤子买卖。我一拍脑袋就定了，根本没考虑后续问题。2.为了确保没有问题，已经用尽了实施过程。过度自信导致过度自负。对于建筑师来说，没有问题就是最大的问题。3.如果出了问题，就会这样。问题一出现，我恍然大悟。当初怎么没想到会是这样？4.程序崩溃，框架被坑。没有认真选择正确的技术堆栈来完成项目。设计从一开始就决定了系统的先天弊病，这不是框架本身的错。那么，如何才能避免技术债过多的问题呢？我的建议是杜绝设计上的冒进。如果不是新技术，那就好。可以采取小步骤缩小升级范围，先改造非核心功能，实现系统向新技术框架的平稳过渡，让团队成员有一个适应期，避免一次性踩雷的风险。同时需要注意另一个问题，就是系统重构不等于推翻重来。很多人会觉得会比之前的设计好，一定程度上可以避免之前系统暴露出来的问题，但是新的设计会带来新的更多的问题。因此，在升级到SaaS产品时，一定要学会利用未来成熟的技术，降低升级的难度和成本，快速批量升级。这样即使出现了问题，也可以把问题控制在可以接受的范围内，不至于蔓延到整个系统甚至让应用无法使用。

最后是关于运维。在设计一个系统架构的时候，一定要提前预估它的运维工作量。如果解决系统的“后顾之忧”，运维带来的技术债不亚于开发过程。以这个项目为例。应用程序根据业务分成若干服务，每个服务对应10到20个运行实例。因为项目组拿不出有效的容器化方案，而且部署环境不支持Docker容器技术，也没有持续发布应用实例的环境。最终，JAR包的200多个运行实例只能手动维护。当应用程序不可用或关闭时，需要手动重启相应的应用程序。这是一个糟糕的设计，或者说是一个失败的设计，对于运维来说是一场灾难。由于先天不足，产品加速到崩溃的边缘。

三、吃成大胖子。

导致项目最终失败的还有一个重要原因，那就是一口吃多了不会馊。在确定需求的过程中，我们采用了尽可能满足每个租户需求的方法，导致整个系统过于臃肿和凌乱，就像一个万花筒。

这样平台就需要具备多终端接入能力，比如PC、平板、智能手机等。满足不同租户的要求，但最后我们连PC都没实现。志存高远往往是失败的开始；量身定制是系统设计的硬道理。系统太大，团队的技术能力不可能一下子覆盖这么大的区域，核心功能还没有经过市场的检验，无疑是个笑话，最终会导致一个烂尾工程。即使项目完成，充其量也只是软件上的“玩具”。

所以在软件开发之初，切忌喜出望外，要将所有功能一次性纳入实现范围。需要明确哪些功能是必须的，哪些是核心功能，哪些是扩展功能。要分清产品愿景和产品实现的本质区别。愿景是产品生态链的展望，而技术实现需要实事求是，根据现有技术水平和用户需求做出折中方案。任何设计都有妥协，没有一步到位的软件产品，也没有最好的软件产品。只有一步一步优化设计，一步一步升级技术，才能做出更好的软件产品。这在开发SaaS平台时尤为重要。你不可能同时满足多个租户的需求。你需要确定最有代表性、最有价值的租户，你的R&D方向也需要更贴近这群租户。下图说明了在构建SaaS平台时应如何分配需求比例：

为什么会有这样的比例？首先，能创造价值的租户是能付钱让你使用软件的租户。对于这些租户的诉求，你可以用定制软件的态度来对待。对于他们的诉求，你需要想办法实现。而有发展潜力的租客，就是那些可能成为你付费用户的群体。你需要研究的产品的核心功能是什么？以及什么样的核心功能能打动他们。有代表性的租户是指那些能够提出相对创新的、有市场价值的需求的群体。他们是产品开发的创新，可以考虑为这部分群体拓展他们想要的功能，观察市场对平台的反应。最后，基本租户，他们的需求是普遍的，需要考虑一定数量的通用功能来服务他们。

4.商业先于产品。

最后说说技术之外的一些看法。大部分团队都会犯这样一个错误：产品开发完成后，再去找市场。我们在这个项目中犯了同样的错误。想想这个问题。随着时间的推移，用户的需求也在发生变化。如果你没有跟上市场的趋势，及时调整产品功能，那么你在得到一个需求之后，就会开始闭门造车。你的产品开发出来的时候，就已经被淘汰了。为了避免产品没有市场，生意必须局限于产品。只有不断获取用户需求，提取有价值的需求数据，及时调整产品方向，才能缩短产品功能与用户需求的差距。业务第一，间接帮助平台设计人员完善和丰富现有功能，及时发现平台隐藏的问题，并对其进行调整，从而在交付产品前尽可能避免可能出现的故障，提高平台的服务能力。

摘要

对于现在的软件设计师来说，让软件用户去适应你设计的产品的时代已经一去不复返了。你需要主动调整自己，由内而外的看待问题，才能帮你出色的完成软件设计。在技术上，我们需要冷静而现实地分析我们面临的问题，知道如何控制技术风险。为了有序地开展软件设计工作，我们不能无视现实，盲目跟风，在技术上冒进，用技术官僚的方式对待软件设计。在业务上，我们需要实时跟进需求的变化，有敏锐的眼光去发现用户的痛点和难点，能够快速对用户的需求变化做出合理科学的反应。

发帖人：http 0.18766474642 s0://0 www . toutiao . com . 536333436

更多saas成功案例(saas的缺点及解决)相关信息请关注本站，本文仅仅做为展示！