一转眼在低代码平台已经3年了。我对低代码的认知，也从好奇——不屑——怀疑——自豪——坚定——反思，经历了漫长了心路过程。
人比工具重要
这是我三年里最深的一点感悟。
作为一个面向复杂场景的低代码工具，虽然对使用者并没有很高的代码能力要求，但对使用者本身的素质要求并不低。
使用者不仅要学习低代码相关知识和配置方法，还要将业务需求与低代码能力快速匹配。
然而现实中，很多项目开发者们，既不清楚业务需求背后的客户诉求，也不关注需求细节，更不清楚平台配置能力，因此项目上开发，总会有一些反复：
图中的虚线就是项目开发中常见的反复原因。这些问题不仅严重降低了开发体验，也会拖慢项目开发速度，增加成本。究其根本原因，就是将对人的要求转移到对工具后，反而忽视了对人的筛选和培养。
重视过程而非结果
这一点是对平台的开发者而言：解决项目中的问题或满足他们的需求，有很多办法，不管是改变需求方案、提供二开接口或者开发相应配置，最终都能实现客户诉求。但对平台而言，更应该关注用户提出诉求到最终解决的过程。
用户提出诉求后，平台功能可能本身就支持，也可能并不支持。如果支持，我们应该思考：
- 平台功能宣讲是否到位
- 文档更新是否即使
- 功能描述是否通俗直接
- 项目对人员培训为何不到位
诸如以上这些问题没有解决，那么即使当下解决了用户的问题，依然还会有源源不断的问题过来。
如果平台不支持，我们应该思考：
- 用户诉求是否合理
- 能否作为标准功能实现
- 从该诉求出发，如何设计通用的二开接口
- 非标诉求背后的具体业务场景和需求设计的逻辑
- 过往类似或矛盾诉求背后的核心点
要解决用户当下的问题很简单，然而如何选择解决方式并不简单。有些看上去不合理的非标诉求，背后却有着符合公司业务特色的客户需求，也有一些看上去合理的诉求，却存在排他性的高风险设计决策。
这里可能有点难理解，举两个例子：
项目上要求实现单据号码和代码成对联查，在广泛场景中，这是一个非标需求，但在单据业务中，这是一个常见诉求，而公司就是主做单据业务的。
另一个例子是，项目上要求忽略空格和null，这是一个合理诉求，因为不管是空字符串还是null，对用户来说都是“无值”，然而这个诉求存在排他性——后来有别的项目要求能够输入和查询空格，于是一系列的约定和设计都遭到了调整。
对项目方来说，追求的就是任务完成客户满意的结果，但是对低代码平台来说，每一个设计每一次决策，都是促进平台发展的重要过程。
技术不是问题，态度决定高度
低代码开发难吗？我个人觉得技术上并不难，相比业务代码，平台的代码也就逻辑密集度更高一点罢了。平台本身就是有边界的，无论是人的能力，还是业务范围、适用范围，这一点大家都能理解，但是在这个边界内，平台能做到什么高度呢？
有一些现象我一直耿耿于怀：
- 当项目提出无法完全满足需求时：“我就是这么设计的，你就应该这么用”
- 当存需求存在关联分支场景时：“他就这个需求， 不考虑这些场景”
- 当改了核心逻辑提测时：“我只要点点没问题就行了吧”
- 当项目提了bug时：“这个bug只有他们特殊场景才出现，手动解决数据就行了”
- 当看到别的平台有优秀的功能时：“就照这个做，做得跟他们一模一样”
- 当提出一些非常有价值的技术方案时：“这个太烦了，做不了”
这些并不是平台的开发技术能力不足，完全是态度问题。傲慢与敷衍，是平台最大的蛀虫，所有虚有其表无人使用的功能，剥离外壳，一定能找到这样一条蛀虫。
坚守边界，共情难处
项目方给到平台的大多数压力，究其原因，都是项目方想要压缩成本，于是一些特殊场景和需求，也试图让平台承担。如果平台接下需求，那就转移了成本，如果平台拒绝了，那正好可以找到理由要到更多的排期。不管项目方怎么想，平台应该坚守自己的边界，接与不接，并不是看对方级别有多高，项目有多难多急，而是看有没有通用的价值。平台不能沦落为某个产线的项目管理工具。
但另一方面，平台需要推动项目拿到结果，这也是平台存在的价值。项目方的需求，并不一定要通过标准功能来实现。如果项目方缺人，平台可以借调；如果项目方二开难度大，平台也可以暴露更多细粒度的功能和接口；如果项目方与平台对接困难，平台也可以出人当半个顾问……有很多手段可以解决问题，不要局限在技术中，有时候非技术手段可能高效。
没有完美的工具，也没有解决不了的问题
三年低代码开发，如果做个一句话总结的话，这个标题就是我最想说的。
低代码平台，只是一个工具，这世上从来没有什么完美的工具，但有踏实聪慧，细致负责的人。
很多问题平台都解决不了，但脱离平台，我们依然能找到很多解决办法。
人，才是推动生产发展的第一要素。
