前言
低代码平台是一个高成本投入项目，建设周期长，难度大，人员成本也高。然而低代码平台的工作，很容易出“成果”。但在我看来，很多“功能成果”，不过是“虚假的繁荣”。低代码团队的成果，不在功能堆砌而在真正的效益提升
低代码平台ROI相关因素及计算方式
ROI = (收益 - 成本) / 成本 × 100%。 对内的低代码平台的收益是节约的产线开发/维护成本，成本主要是人力和云资源，云资源费用暂且忽略不计。
因此有以下几个因素需要着重考虑：
1. 人力成本
平台开发者的薪资一般要高于产线开发的薪资。 假设：平台最低要求 p6 水平，产线最低可要求 p5，按市场薪资中位数计算，人力成本系数为 1.3
2. 开发难度
同样一个功能，平台开发通常需要考虑更多通用场景和合理的业务诉求，既包含配置时开发，也包含运行时开发，相比产线只需考虑当前需求场景，设计和开发难度更大。 假设：同一个功能，平台配置时开发额外增加 20%工作量，运行时每增加一个场景增加 10%工作量，平均考虑 3 个可复用场景，则难度系数为 1.5。
3. 产线开发复用情况
产线也通用具有抽象封装复用的能力，即便设计上没考虑复用，在开发中也能通过手动复制代码的形式节省开发时间。 假设：一个简单列表从0开发，算上自测联调，前后一共需要20个工时，之后类似一个列表，因为部分代码可复用，只需14个工时即可完成，那么复用系数是0.7 另外低代码平台配置本身也有耗时，但理想情况下，产线开发 8 小时的功能，平台可以在 10 分钟之内配置完成，因此我们忽略不计。
基于以上假设的数据：我们将原功能开发的工时看作收益，投入的人力看作成本， 功能被 2 次应用时，收益为，整体ROI为 :
可以推算出，功能的功能被应用至少 3 次，才能产生收益，应用三次时的收益为提效20%，可以说是很显著了。
其他成本
以上是仅从功能开发的角度看投入产出比，但还有很多其他影响因素：
1. 二开成本
在非理想情况下，可能需要二开。二开成本由产线负担，这点应该没有异议，但是糟糕的二开设计，可能导致产线在对接时花费大量的时间，如果二开量很多，那就有必要重新决策是否使用低代码。 假设二开设计不理想，每个二开点相对正常模式额外花费20%成本，那么可以计算出二开量达到一定规模后，低代码平台对产线的提效为负。
2. 平台负担的培训成本和产线负担的学习成本
对任何一个低代码团队，要维护一套高质量的文档，需要投入的时间和精力并不少，这里包括了详细的功能文档、典型案例，视频，工单汇总等。另外还要组织培训和考试。完善的低代码平台，如salesforce有palyground供开发者学习。但对于7人以下的小规模低代码团队，重点仍是典型案例的积累和培训宣讲，每年至少需要花费20人日维护各种文档和材料。 而平台的学习成本，在实践中，一般表现为项目周期中的低代码团队对接时间，可能是根据项目需求查阅文档，也可能是直接给低代码团队提工单解答。这部分成本难以量化，不过个人经历，这部分花费的时间只占5%左右。
3. 平台升级、技术调整而导致产线付出的额外工作
平台的不兼容改动或升级，往往需要让产线跟随升级和测试，这部分投入属于纯成本，应该由低代码团队承担。 实践中，低代码团队面对的场景需求复杂多变，应用产线多，技术决策风险大，因此一旦发现决策失误，应尽早纠正。
启示
对低代码平台的绝大多数功能来说，在产线中被应用三次，看起来并不难，但我统计了我们这几年所有应用，竟然有很多复杂功能，产线上一次都没有被采用。而在低代码的成果汇报中，这些无用功能在当年却也被当成了重要成绩，繁荣的数据背后是产线上刻薄的评价，很多时候我也有心无力。
因此我总结了这个效益计算方式，该方法只是抛砖引玉，仅仅希望能够破除一些数据迷雾。
