本文主要是介绍一家之言：真正发挥平民开发者的创造力，光有低代码还不够，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
随着低代码概念日趋火热，与之相关的“平民开发者”（Citizen Developer，也称公民开发者）也受到了更多人的关注。然而，在大多数语境中，平民开发者会与技术基础差划上等号，甚至以此来推演低代码和无代码在企业中的发展路线和应用前景。事实真的如此吗？
平民开发者的定义
平民开发者的概念最早被业界广泛接纳，是源于国际知名咨询公司Gartner的研究报告。翻阅Gartner官网提供的词汇表，我们可以发现其定义如下：A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.
从这段文字中，我们会发现对平民开发者的定义中，完全没有技术能力相关的描述。一个人是否为平民开发者，与其技术能力无关。平民开发者与专业开发者唯一的区别在于前者向业务线而非IT线汇报。也就是说，在平民开发者这个概念上，Gartner更加关注管理层面而非技术层面。
低代码观察员：这是我第一次看到“平民开发者”最初的概念定义。做人群细分时，从管理和组织角度出发，而不是技术，确实很Gartner。
低代码究竟给谁用
关注企业信息化的从业者已经对低代码烂熟于心。作为软件开发技术的发展方向，低代码技术通过可视化的技术手段，大幅降低了软件开发的技术门槛，让更多人能够参与到软件开发中，为企业快速构建个性化的软件应用。然而，真正引入低代码技术的企业面对的第一个难题，是低代码工具究竟该给谁用？以现有的IT团队为主，还是直接将软件开发的工作“下放”到业务团队？
平民开发者的概念，为我们探讨这个问题提供了一个框架。科技以人为本，一切技术的核心都是人。每当我们引入一项新的技术，除了该技术的特性之外，我们还需要从管理和岗位职责上进行梳理和分析。
众所周知，在现代企业管理中，一个员工的职务行为和思维逻辑与该员工的岗位定义和汇报路线直接相关，因为这两者决定了该员工的考核标准，并最终影响该员工的薪资待遇和职业发展。所以，当我们去探讨一项工作或者生产力工具如何在企业落地时，必须理清承接该工作的岗位，才能减少对现有组织架构的冲击，提升落地成功率。这也是Gartner提出平民开发者的概念，并且将其作为一个“用户画像”专门进行研究分析的主要原因。
平民开发者vs专业开发者，谁是低代码用户群体的主力？这个问题可以更直观的转化为另一个“更实际”的问题：企业应该让IT团队负责开发应用，还是让业务团队自行解决信息化的需求。
IT团队 vs 业务团队
因为汇报的上级不是IT部门，平民开发者在进行软件开发时与专业开发者相比有3大挑战。管理层只有认清这三点，并针对其在组织和管理层面进行优化，才能让更多来自业务部门的平民开发者参与到软件开发过程中，最终达到“企业IT能力倍增”的目的。
软件质量：“短平快”优先于可维护性
相比于有明确发展规划和专项预算保障的IT部门，业务部门对信息化的要求通常与当前面临的问题紧密相关。有需要解决的问题，而且IT部门无法及时解决时，业务团队才会临时做出预算，为自己开发软件。
向业务部门汇报的平民开发者在软件开发上的投入更加碎片化，峰值虽然较高，但不可持续。而且，随着软件应用走上正轨，业务部门大概率会在第一时间将后续的维护工作移交给IT部门，即从平民开发者交接给专业开发者。如果在较短的时间周期内，平民开发者没有按照预期完成软件的开发和交付，业务部门就失去了将其留在自己团队的最大理由。该项目则很可能直接搁浅或移交给IT团队，进入开发队列。而对于平民开发者而言，项目已经失败了。
所以，大多数平民开发者会更关注如何以最快的速度将应用开发完成并投入使用，实现“能用”的基础目标，而不是将精力投入到软件质量和可维护性等方面。“短平快”成为平民开发者构建应用的关键词。相比之下，需要长期维护信息系统的IT部门中，专业开发者则必须将质量与可维护性（包含功能扩展、数据一致性、系统集成等）放在重要的地位，否则就是给自己和其他团队成员“挖坑”，难以持续发展。
学习偏好：对学习投入更加敏感
不可否认，平民开发者在技术能力上可能会比专业开发者稍微弱一些，但这更像是平民开发者运行模式的结果，而不是原因。
为了进一步达到“短平快”的目标，应对不可持续的软件开发工作，平民开发者通常对学习投入更加敏感。除非通过当前岗位之外的工作熟练掌握了某些软件开发技能，平民开发者在学习软件开发技术中投入的每一分钟，都会拖慢项目交付的速度，扩大项目失败的风险。这是很多平民开发者最不愿意看到的情况。
抛开项目本身，相比于IT团队中专业开发者完善的职业发展道路和持续的实战机会，平民开发者在软件开发技术上的学习显得更加没有“性价比”。因为，业务能力才是平民开发者最显著的优势，也是其最大资本；而开发能力，还不知道什么时候才会再次用到。如何让平民开发者也有通过学习不断提升开发能力的机会和动力，是摆在平民开发者领导面前的难题。
风险偏好：对运维风险更加敏感
从学习投入低、更关注短期效果两个特点，我们不难看出平民开发者构建的应用比专业开发者的质量风险更高一些。然而，业务团队对数据错误、系统可用性低、数据安全性差等系统运维风险的敏感性却不会因为开发者不同而展现出明显的差异。更麻烦的是，平民开发者本身处在业务团队，一旦他们构建的应用出现问题，所有损失将由该业务团队自行承担。在很多中大型企业中，这种风险不容忽视。
事实上，决定风险敏感度的首要因素是该软件的应用场景。在应用场景的类型上，企业上下对生产、销售、投资等核心业务系统的风险敏感度更高；OA、人事等边缘应用的敏感度更低。而在数据操作能力上，负责人对仅读取数据的数据分析应用更加放心；而写入数据，尤其是向核心业务系统写入数据的ERP二开等应用要求更加严格。所以，让IT部门的专业开发者专注于核心业务场景、需要写入数据的场景，边缘应用请相关业务团队的平民开发者参与，是一个被广泛接受的“最佳实践”。
平民开发者的突围之路：自我驱动的创业型团队
综上所述，在低代码的使用者群体上，来自IT部门的专业开发者在学习成长、质量保证上比业务团队更有优势，更适合构建高价值的核心业务应用。海比研究在《2021年中国低代码无代码市场研究报告》中提到，使用低代码开发各类应用的使用者中，业务人员占比仅为25%，其余则是来自于低代码平台厂商、合作伙伴和企业IT部门的研发人员，即专业开发者。
但是，平民开发者就只能做一些简单的应用，无法对企业创造更高价值吗？我们认为，既然是固化的岗位定义造就了平民开发者和专业开发者的差异，企业可以从根源上打破这种藩篱，彻底解放平民开发者的生产力，即打造自我驱动的创业型团队。
一方面，管理层从公司整体而不是具体团队的业绩对员工进行考核，给勇于创新，加速企业数字化建设的平民开发者以足够的动力，与员工的自我驱动形成正向循环。另一方面，在公司层面形成人员在业务团队和IT团队流转的机制，甚至像创业团队一样淡化岗位区分，让平民开发者可以和专业开发者进行身份互换，确保平民开发者也有在专业开发者团队中学习新技术，持续“充电”的机会；专业开发者也能在业务工作中加深对企业业务运作的理解。
低代码观察员：作为一个从业十几年的专业开发者，在面对业务部门自建IT系统时，应该保持一个开放的心态，提供必要的支持。让IT部门成为业务部门的咨询顾问，也许是一个好思路。
最后，祝愿所有引入低代码技术的企业能够找到自己的落地方案，充分享受软件开发技术进步带来的红利，让企业的数字化进程再创新高。
这篇关于一家之言：真正发挥平民开发者的创造力，光有低代码还不够的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
