图片29
低代码非常适合开发典型的企业应用程序，具有开发人员启动快、开发效率高、沟通集成提升等明显优势，但不要认为低代码是银弹，解决了任何问题，主要有三个原因：
1)开发工具只能解决软件研发的一些问题。低代码作为一种开发工具，可以在需求明确时加快软件交付，也可以在总体方向明确但具体需求不明确时加快软件的迭代更新。但是，如果企业应用和企业管理模式、业务方向、业务流程、组织结构密切相关，与人密切相关，软件不知道如何解决这些问题，这不是开发工具可以解决的，请咨询或咨询。低代码就像一个特殊的士兵，作为一个士兵的战斗能力很强，但如果将军不好，战略战术不能打败，也不能赢。
2)缺乏权威的数据来提高低代码的开发效率，不要有太高的期望。业内有很多关于低代码开发效率的宣传，最多是10倍，这些没有根据。一些制造商和分析机构会发布效率提高数据，这似乎特别有效，但由于没有代码和低代码没有区分，这些数据是不可信的。由于无代码工具对特定类型的应用程序进行了高度优化，因此效率提高显然是正常的，但并不普遍。专业的低代码制造商不敢宣传效率提高多少倍，所以制造商的宣传效果越好，就越不可能成为一个专业的低代码平台。从我们的经验来看，用低代码制作一些小系统真的很快，但我认为不可能在规模增加几倍后。
3)典型的行业项目限制了低代码的价值。由于低代码平台的可视化和高效率，最适合业务和开发的密切沟通和合作，以及快速迭代。然而，目前，甲乙双方之间典型的项目系统要求双方提前签订详细的合同和SOW，这使得本可以快速开发的学生回到瀑布模式，因此很难反映低代码快速迭代的价值。项目系统存在的时间太长，暂时不会改变。
对于甲方来说，我认为首席信息官应该从试点应用程序开始。一般来说，要求他们的团队使用低代码的阻力会很大，但乙方可以使用低代码来降低报价。对于乙方来说，我认为在短期内很难销售平台。最好与甲方讨论个人外包模式，以避免项目系统的僵化。业业说低代码是高级外包是对的，尽管我认为低代码应该被称为低级外包更合适。
