难以持续的SaaS产品选择重构还是重新开发？有没有解决办法

本来简单提一下这个话题，今天就和大家讨论一下。目前，中国绝大多数Saas公司都是由销售和客户需求驱动的。很难拒绝定制开发，也很容易成为项目；除非有强大的产品实力和商业洞察力的团队，否则经过几年的积累，产品将变得臃肿。一旦产品变得臃肿，就会遇到很多问题:维护成本越来越高；用户体验越来越差；积累的客户从资源变成绳索，调整难度和工作量越来越大。在这种情况下，处理一些新的市场竞争是非常被动的；在经验差之后，客户会慢慢流失，团队无能为力，陷入两难境地——这也是中国大多数B端产品企业的现状。在现有产品上重构还是新开发一套炉灶？此时，公司面临着艰难的选择，基本上所有的研发团队都会建议另一个炉子，从研发的角度来看，这是一种更简单、更有效的方式；不管原来的恶心代码，团队士气会更高。然而，从公司的角度来看，有几个因素需要考虑：1）新系统的开发成本和开发周期：从开发到少数客户在线使用，再到成熟稳定，新系统需要相当长的抛光周期。2)老客户的迁移成本:这个成本包括BD在迁移过程中的投资、实施、培训、售后费用，也包括客户投入的费用。3)在并行期间，涉及到一些bug或需求，需要双方都进行开发。4)人员需要两个团队来处理不同的产品线、开发、实施、培训和售后服务，招聘和培训将更加困难；另外两条产品线之间的产品也高度耦合，沟通工作量大。一般来说，B端产品的迁移成本非常高，客户改变使用习惯的成本也非常高；总有一些客户不愿意迁移。最终的结果是长期维护两个系统。没有经历过的人很难想象这样的成本和成本，迁移老客户，老客户；不迁移老客户，老客户在一定程度上被忽视和伤害，影响声誉。除非客户很少，或者可以基本保证所有成本相对较低的迁移，否则作者不建议开发一套新的炉灶，成本很高；除了所有成本乘以2，还有迁移和客户成本，每个客户的迁移和实施可能是一个复杂的项目。因此，与现有产品的重构相比，新开发的成本肯定会呈指数级增长；在这种选择之后，许多公司陷入了对新产品不满意、无法迁移旧产品的困境，浪费了大量的时间和资源。作者很少发现成功的案例。第一，重构的思路和原则，如果需要重构一个系统，我们该怎么办？笔者认为，我们可以参考以下思路和原则：1.准备人。正如我在前一篇文章中所说，人是事物成功的最关键因素。要做好自己的工作，有几个角色很重要，数据库架构师，解决方案架构师，功能架构师。不一定每个角色都需要一个人，但必须有人承担相应的角色；例如，数据库是B端产品的基石。一旦出现错误，调整成本非常高。数据库架构师需要了解数据库设计技术，了解业务发展和业务细节，并与一个或多个人进行前瞻性合作；解决方案架构师实际上需要一个人或多个人了解业务和技术。b端产品是一门交叉学科，单一了解业务和技术的人相对容易找到；了解业务和技术的人很难找到，目前在中国资源稀缺；一般来说，技术人员比商务人员更容易学习技术，公司应该选择合适的人来培养这个方向。假如短时间内很难有合适的人，最好有外部顾问来做一定程度的检查。2.设计理想的产品形式，确定产品重构的路径，设计最终的一般结构，主要是功能结构和系统结构；确定一些核心业务设计理念和原则，反复抛光，得到满意的答案。只有知道终点是什么，才能很好地思考最好的前进路径。3.对于产品重建，路径和优先级的选择非常重要。找到最合理、最省力的路径对团队来说是一个很大的考验。这里很难有一个固定的答案，但有一些原则内容可以遵循：1）优先调整基础核心结构重构的核心是正确的数据库结构、产品功能结构和页面结构；数据库、功能和页面结构实际上是找到最合理的方法，即在用户体验和产品增长之间找到平衡。一般来说，让用户在页面上看到足够少的内容是最好的体验；但产品增长，架构分类不好，最终功能或页面非常拥挤，无法扩展，因此需要在体验和增长之间找到最佳的平衡。对于一些核心数据库表，需要尽可能优先调整核心功能架构。在错误的数据库和错误的功能架构中完成的内容是无用的，或者需要重新开始。2)优先重建一些高频使用的核心模块，或者特别差的功能，这也是用户价值最大的，客户有足够的动力配合。3)优先重建新需求量大的模块。重建产品不是静态的。当我们进行产品重建时，我们肯定会面临大量的外部需求。对于新需求量大的功能模块，与其在错误的功能基础上花费大量时间做新需求，不如重新做。其实所谓的重构，往往是一个模块，一个功能重写，以敏捷、熟练的方式分解大风险。4.追求极端，不要重蹈覆辙。每次重建的机会都是重生的机会。不用说，每次重建一个模块，都是重生的机会；我们不能用一个坑填另一个坑。我们应该在开始之前至少设计85分。不要盲目追求速度。5.尽最大努力减法。每一次成功的减法都是对臃肿系统的胜利重建。在重建和重写过程中，我们必须尽一切努力减法；模块的减法、功能的减法，甚至一个字段的显示和检索条件，都会减到极致。良好的重建必须伴随着大量的减法。2、从客户的角度来看，每次重建后的升级都是对熟悉历史体系的人的折磨。如果折磨次数多，客户很容易崩溃。从用户体验和声誉的角度来看，迭代安排有以下建议：1。每次迭代升级，让客户不断尝到每次迭代升级，重建新版本体验需要大大超过原版本，或有新功能可以解决客户痛点，用户有动力升级。在设计和安排每个迭代计划时，要充分考虑用户升级的动力，否则会遇到很多阻力。2.在迁移升级过程中，尽量避免客户感知和培训，降低客户投资成本。每次重建后的升级往往伴随着数据迁移。不要给客户这个负担，实施团队帮助客户完成；此外，每次重建后的功能基本上不需要培训，客户基本上不需要投入培训成本。3.做好灰度测试，首先确认新功能可行，然后全面发布。每次重建时，灰度测试周期都需要一定的时间，这样一些典型的客户就可以先使用重建模块，以确保在完全发布之前没有问题，这样你就可以尽可能少地抛弃客户。每一次辗转反侧，都会带来不信任和不合作，产品口碑会变差。4.新客户只打开必要的功能，降低后续迁移的成本。这是一个小提示。对于旧产品中一些不必要的功能，在重建过程中，不要向不断增加的新客户开放，以免以后增加迁移成本。