前言

to B类saas产品，低代码可以说是一个必选项，标准产品面对不同客户，必然需要进行各种定制，而低代码平台可以在很大程度上降低定制成本。

然而在项目实践中，低代码这个工具本身就会带来诸多问题，在很多情况下反而并不能提升项目组的效率。

灵活的样式和交互需求

某些甲方，对样式或者交互有强烈的需求，但大多数时候并非他们的需求能给他们解决某个问题，而是他们习惯了老系统的样式和交互，单纯不想改变操作习惯。

对平台来说交互都是统一规范，样式也只能在有限的范围内进行调整。平台有理，但如果甲方非常强势，项目经理往往被夹在中间左右为难。

因此如果甲方对样式和交互有明确的需求，平台无法满足的，应果断采取高度二开或者完全自行开发的方案，并按照这套方案重新评估项目成本。

对项目流程和分工协作的忽视

上了低代码后，很多项目组失去了应有的开发流程：评审——设计——开发——测试——上线，变成了这样一个流程：需求告知——配置——上线——需求变更——配置——上线。

以往代码开发，如果需求或者设计出错产生的返工代价很高，因此有经验的leader会非常看重评审和设计。

使用低代码后，原本coding的成本被无限降低了，需求改动变化也能很快响应，低代码平台的功能都经过了多个产线和项目的考验，对测试的需求也降低了。

然而真实情况是，低代码平台的能力，不一定能够满足项目上的所有需求，如何取舍变通，如何二开，都需要评估，各种交互细节需要确认，各对象字段/关联关系需要达成共识。在实践中，有不少项目，因为忽视了评审和设计，在对象和页面设计上反复修改，不断增加二开点，最终造成成本超支。

对平台能力不够了解，对客户需求不够细化

因为低代码提供的功能太多太复杂，以至于很多项目经历天真认为，低代码平台能便捷地满足所有需求。因此在和客户确认需求的时候，只谈个主流程。

比如某个项目，功能全部做完了才知道客户有一些平台不满足的细节要求，比如

越是大客户，数据展示上的特殊要求越多。这些功能点在甲方场景往往都是合理需求，但对平台来说，并不足以抽象出一个标准场景。如果项目这时候再去和低代码平台讨论方案，或者进行定制化开发，就会延长项目周期，增加项目成本。

对版本管理的忽视

这个版本主要是指，项目需求迭代的版本和功能颗粒度管理。

对三个月以上开发周期的项目，可以看成是长周期项目，项目必定会经过多次需求迭代。此时需求版本的管理就非常重要。

比如迭代1中10个功能已经上线，迭代2中10个功能正在开发，现在应甲方要求，需要对迭代1中的部分功能进行fix和回滚，并紧急上线几个新功能，除了需要平台提供版本管理的能力，自身也需要对迭代划分，需求的稳定性做预判。

实践中总会出现，项目方一股脑在某个版本里上大量功能，之后需要部分回滚时，既不知道该回滚哪个版本，也不知道这个版本里有哪些功能。这就好比在连续多次git commit中都提交大量功能，又不写commit备注，然后需要将部分代码回滚，这种情况再资深的程序员也要花费很多心思。

总结

解决问题的核心要素是人，其次才是工具。 低代码平台虽然能降低对编程能力的要求，但不影响对人的学习能力和管理能力要求。如果项目方既不学习低代码平台，又不关心流程管控，再好的平台也无法提效。