想要做一个成功的SaaS产品，需要有足够多的用户需求样本数据以及对这些样本数据深入的挖掘、分析和抽象，以得到一份通用的，覆盖率大的应用场景数据。只有如此，才能够开发出一款具有价值的应用软件，才能贴合SaaS用户的实际需求。
Legendshop朗尊软件， 2016年开始全力投入开发自有的电商saas平台小羊云商， 用血汗和成本得出以下的一些经验累积：
避免“闭门造车”的严重错误，导致这一错误产生的原因是我们拿到的原始需求不够，仅仅凭借一两个客户的需求数据，并以此为蓝本展开系统的设计，实现了很多用户根本不需要的功能，最后导致系统的功能和用户的需求对不上号。当我们小羊云商花了1年多时间去实现一个自己认为很棒的功能时，客户不认可这样的设计给了我们狠狠的一剂耳光，痛并郁闷着。
客户需求数据过少，加之主观上的臆想，导致了系统中充斥着大量华而不实的功能。表面上看，系统的各个功能都比较高大上，但就是这样高大上的功能，却和客户的想法背道而驰。客户的想法是最实际的，华丽的功能在一定程度上太过于注重“表演”，而无法真正帮助客户解决实际的问题。
面对这样一个问题，就需要在提出一个好的创意时，需要再三的与实际的需求做比对，只有创意与需求能够契合在一起时，创意才能转化为有效的功能，才能起到锦上添花的效果。而解决这一个问题，需要将如下的几个工作落实到实处：
o 1、获取尽可能多的需求样本数据
o 2、对需求数据进行划分、得出需求场景
o 3、以场景建立用户故事，梳理业务逻辑
o 4、以业务逻辑为单元，评估系统规模，展开系统设计
o 5、建立有效的沟通机制，及时将设计原型与用户进行沟通，确定有效需求
下面，通过一张图来说明如何排除不务实的系统需求：
·
说明：
在第一步中，我们需要收集不同用户数量，不同知识结构、不同硬件环境以及不同资金支配能力的客户需求，这样才能从不同的维度去了解客户的想法和业务痛点。如用户量大的客户，更则种系统的整体协能力，以及业务的流程的连贯性和时效性。而用户量较小的客户可能则重于系统的高效和便捷程度。对于可支配资金，直接影响着系统在设计时的布局，如性能的分配和交互的体验度，以及后期定制收费标准。
第二步、建立场景是为了把庞杂的需求进行切割，建立科学的需求分类，减轻需求分析的难度和时长。将杂乱的需求按照类别进行深入分析，挖掘客户的业务痛点，为构建起用户故事提供素材和依据。
第三步中，分析的视角将从局部变为全局，通过第二步得到数据，建立起用户故事，以分析各需求之间的联系和各自的主线。
第四部是对需求进行统筹规划，将需求变成可用的业务逻辑，并对此业务逻辑进行技术可行性和风险评估，最后将此评估结果与客户需求进行比对和调整，确定最终的有效需求。
任何应用程序的开发，都需要考虑技术债务问题，即木桶定理。从项目开始提案开始，就犯了技术冒进的错误。选择了技术一系列比较新的技术框架和设计思想，如前后端分离设计，微服务化和容器化等较新的技术栈，以及项目开始实施前没有做好相关技术的培训工作，导致项目组成员的技术能力参差不齐，项目推进缓慢，接连踩坑，很多关键技术没有吃透，很多技术问题没有解决，导致应用系统性能脆弱，部署周期长，运维难度大，直至后面项目搁浅。
出现这样巨大的技术债务，是过于盲目的跟随市场技术浪潮，没有对自身团队技术能力做一个有效的评估所造成的。新技术固然有它超越现有技术的威力所在，但弊病也不少。首先是学习成本，需要花费大量的时间对整个团队进行培训，而培训并不是所有的人都能一个水平，从这开始，木桶的短板就开始产生了。由于技术掌握不牢固，开发工程中踩坑是避免不了的，这就导致项目进度急剧拉长，技术债务开始累积，最后的结果就是，产品千疮百孔，无法使用。
由于花费的巨大的时间去解决技术问题，从而忽略了一开始的运维问题（更多的是无暇顾及，先把产品搞出来再说）。很多时候，在开发调试阶段应用程序没有出现问题，一旦放到生产环境就开始问题百出。这是因为我们想当然的认为，新技术已经把所有的问题都解决了，抱着一种侥幸的心理，在匆忙之间将项目上线，从而忽视那些极为致命的问题，线上安全问题、性能问题、网络问题、环境问题、终端适配问题等等。
最终可以总结出这种的几个特点：
o 1、出方案靠拍脑袋，一锤子买卖。一拍脑袋，就这么定了，根本没有考虑后续的问题
o 2、实现过程拍胸脯，保证没有问题。过于自信，导致太过自负。对于架构师而言，没有问题就是最大的问题
o 3、出问题拍大腿，这么回这样。等到问题出现了，才恍然大悟，当初为什么没有想到会这样
o 4、程序崩溃拍桌子，坑爹的框架。没有认真的选择合适的技术栈来完成项目，从一开始的设计从确定了系统的先天性顽疾，并不是框架本身的错。
那么，该如何避免技术债务过大的问题呢？我的建议是杜绝设计上的冒进，不是新技术就一定好。可以采取小步快走，缩小升级范围，先将非核心功能进行改造，实现系统平滑过渡到新的技术框架，也让团队的成员有一个适应期，避免一次性集中踩雷的风险。与此同时，还需注意另外一个问题，系统重构不等于推翻重来。很多人会觉得推翻重来一定会比之前的设计好，在一定程度上可以将之前系统暴露的问题进行规避，但新的设计又会带来新的，更多的问题。所以，在进行升级过渡到SaaS产品时，一定要学会利用以后的成熟技术，减少升级的难度和成本，快速多批次的进行升级，这样，即便出现问题，也可以将问题控制在一个可以接受的范围，不至于蔓延至整个系统，甚至造成应用程序的不可用。
· 导致项目最终走向失败还有另外一个重要的原因，一口吃太多，嚼不烂。在确定需求的过程中，对于每一个租户提出的需求，我们采取了尽可能满足的方法，导致整个系统过于臃肿，杂乱，就好比一个万花筒。
· 按照这样一种方式，平台需要具备多端接入的能力，如PC、平板、智能手机等，以满足不同租户的要求，但有可能最终连PC端都没有实现好。好高骛远，往往就是走向失败的开始；量体裁衣，才是做系统设计的硬道理。体系太过于庞大，团队的技术能力无法覆盖一下子覆盖到这么大的面，而且核心的功能还未接受市场的检验，就同时要满足适配多端的能力，这无疑是在开玩笑，最终将会得到一个烂尾工程。即便项目完成，充其量也就是一个软件中的“玩具”。
· 因此，在软件开发之初，切忌好大喜功，一下子将全部的功能都纳入到实现的范围，需要识别出哪些是必须功能，哪些是核心功能，哪些是扩展功能。需要分清楚产品的愿景与产品实现的本质区别。愿景是对产品生态链的展望，而技术实现需要实事求是，根据现有的技术水平和用户需求，做出一个折中的方案，任何设计都有妥协，没有一步到位的软件产品，也没有最好的软件产品，只有通过一步步的优化设计，一步步的升级技术，才能做出更好的软件产品。这一点在研发SaaS平台时尤为重要，你不可能同时满足多个租户的需求，你需要甄别出最具代表性和最有价值的那一部分租户，你的研发方向也需要向这一部分租户靠拢，下面通过一张图来说明构建一个SaaS平台时，需求占比应该如何分配：
· 为什么会有这样的一个配比？首先，能够创造价值的租户，是能够向你进行付费使用软件的租户，对于这一部分租户提出的需求，你可以以定制软件的态度去对待，对于他们提出的要求，你需要想办法去实现。而具有发展潜力的租户，是那些有可能成为你付费用户的群体，你需要研究产品的核心功能是什么？，以及什么样的核心功能才能打动他们。而具有代表性的租户是指那些能够提出比较创新的，具有一市场价值的需求的群体，他们是产品发展的创新所在，可以考虑为这一部分群体单独扩展出他们想要的功能，以观察市场的对平台的反应。最后是基础租户，他们的需求都具有普世性，需要考虑一定量的通用功能为其服务。
· 最后，说一下其他看法，大部分的团队都会犯这样一个错误：当产品开发完成之后，再去寻找市场。可以思考这样一个问题，用户的需求随着时间的推移在发生改变，如果你不紧跟市场的动向，及时调整自己的产品功能，而是拿到一份需求后就开始闭门造车，当你的产品开发完时，就已经被淘汰了。为了避免产品没有市场，业务就必须优先于产品动起来。通过不断的获取用户的需求，提取有价值的需求数据，及时调整产品的方向，才能缩短产品功能与用户需求之间的差距。业务先行，在间接的帮助平台设计者完善和充实现有的功能，及时的发现平台隐藏的问题，并对此做出调整，在交付产品前尽可能的规避可能出现的故障，提高平台的服务能力。
· 对于今天的朗尊软件的开发团队来说，让软件使用者来适应你所设计的小羊云商新零售电商系统产品的时代已经不复存在。你需要主动的调整自己，从内到外多角度的看待问题，才能帮助你出色的完成软件的设计。在技术上，需要沉着冷静，实事求是的分析所面对的问题，需要懂得如何把控技术风险；科学有序的开展软件设计工作，断不可不顾现实情况，盲目跟风，技术冒进以及唯技术论的路子对待软件设计。在业务上，需要实时跟进需求的变化，具备敏锐的眼光去发现用户的痛点和难点，能够快速的对用户需求的变更做出合理、科学的反应。
· 小羊云商新零售电商saas系统产品应运而生， 并且一直在路上......