随着低代码技术的走红，“平民开发者”这个词也开始频频出现在人们面前。然而，不少人一提到平民开发者，可能就会联想到“技术小白”，从而推测低代码和无代码在企业中的应用轨迹。事实果真如此吗？让我们来一探究竟。

什么是平民开发者？

平民开发者，顾名思义，就是那些利用不被IT禁止的工具为自己或他人创建应用的员工。他们并不是IT或者技术部门的人，而是来自企业的业务部门。这个定义很有意思，因为它完全绕开了技术能力这个话题。换句话说，成为平民开发者和你会不会编程、懂不懂技术无关。

低代码的受众是哪些人？

低代码技术通过可视化手段，把软件开发变得像搭积木一样简单，从而降低了技术门槛。于是问题来了，这些低代码工具到底该给谁用呢？是专业的IT人员，还是直接交到那些业务团队的手里呢？

理解这个问题，我们需要从人本身出发。技术再先进，如果没法合理分工和管理，也很难发挥其应有的价值。在企业里，每个员工的考核标准、薪资待遇和职业发展路径，都是由他的岗位定义和汇报路径决定的。所以，当我们引入一项新技术时，必须理顺岗位职责，才能提高应用成功率。

平民开发者和专业开发者谁更合适？

这是个老生常谈的问题：到底是让IT团队搞开发，还是让业务团队自己动手呢？

挑战一：软件质量问题

业务部门通常解决当下的问题，而不是规划长远的系统建设。他们会基于当前需求临时做出开发预算，但这些投入常常是一次性的，没有长久计划。相比之下，IT部门则会关注系统的长期维护和扩展。如果一个项目不能在预期时间内完成，业务部门就会转移给IT团队。这意味着平民开发者在面对时间压力时，可能更关注“尽快能用”，而非代码的质量和可维护性。

挑战二：学习投入问题

平民开发者的技术能力可能不如专业开发者，但这更像是工作模式导致的结果。因为时间宝贵，平民开发者每多花一分钟学习，就可能拖延项目交付时间，从而增加失败的风险。此外，业务能力才是他们最大的资本，开发能力可能只是临时需要。

挑战三：运维风险问题

业务团队对系统运维和数据安全的要求并不比IT部门低。如果平民开发者开发的应用出现问题，损失由业务团队自行承担，这种风险在大企业中尤为重要。因此，企业通常让IT部门负责核心业务应用，而让平民开发者参与边缘应用的开发。

打破传统，让平民开发者和专业开发者齐头并进

那么，平民开发者只能做一些简单的应用，不能创造更高的价值吗？事实上，企业可以通过打造自我驱动的创业型团队，打破这种固化的岗位定义，为员工创造更大的发挥空间。

比如，公司可以从整体而非具体团队的业绩来考核员工，激励他们积极创新。与此同时，通过机制化的人员流转，让平民开发者和专业开发者在不同团队中工作，互相学习，提升自身技能。

成功实践：平民开发者的创业故事

在一些领先的公司中，平民开发者已经深入参与到了信息化建设之中，取得了令人满意的成果。比如有的市场团队的员工，利用低代码工具自行开发了运营系统，把他们对业务流程的理解落实到软件中，从而大幅提高了工作效率。

他们在开发过程中，不但频繁迭代，及时满足运营需求，还能通过专门的学习，不断提升自己的技术能力。这种由上至下的自我驱动机制，形成了平民开发者团队的良性循环。

总结

低代码技术为企业的信息化进程打开了一扇大门，而平民开发者是其中不可忽视的力量。无论是通过合理分工，提高效率，还是鼓励自我驱动，突破传统岗位的束缚，企业都可以从中受益匪浅。希望所有引入低代码技术的公司都能找到适合自己的落地方案，让企业的数字化之路更加顺畅。