记一次构建SaaS平台项目失败后的反思（收集的客户需求太少，且没有区分重点，闭门造车。技术演变要渐进）
记一次构建SaaS平台项目失败后的反思
前言： 笔者从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平台时，需求占比应该如何分配：
为什么会有这样的一个配比？首先，能够创造价值的租户，是能够向你进行付费使用软件的租户，对于这一部分租户提出的需求，你可以以定制软件的态度去对待，对于他们提出的要求，你需要想办法去实现。而具有发展潜力的租户，是那些有可能成为你付费用户的群体，你需要研究产品的核心功能是什么？，以及什么样的核心功能才能打动他们。而具有代表性的租户是指那些能够提出比较创新的，具有一市场价值的需求的群体，他们是产品发展的创新所在，可以考虑为这一部分群体单独扩展出他们想要的功能，以观察市场的对平台的反应。最后是基础租户，他们的需求都具有普世性，需要考虑一定量的通用功能为其服务。
四、业务于产品先行
最后，谈谈技术之外的一些看法。大部分的团队都会犯这样一个错误：当产品开发完成之后，再去寻找市场。我们在这个项目中，也犯了同样的错误。可以思考这样一个问题，用户的需求随着时间的推移在发生改变，如果你不紧跟市场的动向，及时调整自己的产品功能，而是拿到一份需求后就开始闭门造车，当你的产品开发完时，就已经被淘汰了。为了避免产品没有市场，业务就必须限于产品动起来。通过不断的获取用户的需求，提取有价值的需求数据，及时调整产品的方向，才能缩短产品功能与用户需求之间的差距。业务先行，在间接的帮助平台设计者完善和充实现有的功能，及时的发现平台隐藏的问题，并对此做出调整，在交付产品前尽可能的规避可能出现的故障，提高平台的服务能力。
总结
对于今天的软件设计者来说，让软件使用者来适应你所设计的产品的时代已经不复存在。你需要主动的调整自己，从内到外多角度的看待问题，才能帮助你出色的完成软件的设计。在技术上，需要沉着冷静，实事求是的分析所面对的问题，需要懂得如何把控技术风险；科学有序的开展软件设计工作，断不可不顾现实情况，盲目跟风，技术冒进以及唯技术论的路子对待软件设计。在业务上，需要实时跟进需求的变化，具备敏锐的眼光去发现用户的痛点和难点，能够快速的对用户需求的变更做出合理、科学的反应。
