平民开发者≠技术差！真正发挥平民开发者的创造力，光有低代码还不够

[GrapeCityChina]

随着低代码的概念日趋火热，与之相关的“平民开发者”（ 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.

（ Gartner 对平民开发者的定义）

从这段文字中，我们会发现对平民开发者的定义中，完全没有技术能力相关的描述。一个人是否为平民开发者，与其技术能力无关。平民开发者与专业开发者唯一的区别在于前者向业务线而非 IT 线汇报。也就是说，在平民开发者这个概念上，Gartner 更加关注管理层面而非技术层面。

低代码究竟给谁用

关注企业信息化的从业者已经对低代码的概念烂熟于心。作为软件开发技术的发展方向，低代码技术通过可视化的技术手段，大幅降低了软件开发的技术门槛，让更多人能够参与到软件开发中，为企业快速构建个性化的软件应用。然而，真正引入低代码技术的企业面对的第一个难题，是低代码工具究竟该给谁用？以现有的 IT 团队为主，还是直接将软件开发的工作"下放"到业务团队？

平民开发者的概念，为我们探讨这个问题提供了一个框架。科技以人为本，一切技术的核心都是人。每当我们引入一项新的技术，除了该技术的特性之外，我们还需要从管理和岗位职责上进行梳理和分析。

众所周知，在现代企业管理中，一个员工的职务行为和思维逻辑与该员工的岗位定义和汇报路线直接相关，因为这两者决定了该员工的考核标准，并最终影响该员工的薪资待遇和职业发展。所以，当我们去探讨一项工作或者生产力工具如何在企业落地时，必须理清承接该工作的岗位，才能减少对现有组织架构的冲击，提升落地成功率。这也是 Gartner 提出平民开发者的概念，并且将其作为一个"用户画像"专门进行研究分析的主要原因。

平民开发者 vs 专业开发者，谁是低代码用户群体的主力？这个问题可以更直观的转化为另一个"更实际"的问题：企业应该让 IT 团队负责开发应用，还是让业务团队自行解决信息化的需求。

IT 团队 vs 业务团队

因为汇报的上级不是 IT 部门，平民开发者在进行软件开发时与专业开发者相比有 3 大挑战。管理层只有认清这三点，并针对其在组织和管理层面进行优化，才能让更多来自业务部门的平民开发者参与到软件开发过程中，最终达到"企业 IT 能力倍增"的目的。

软件质量：“短平快”优先于可维护性

相比于有明确发展规划和专项预算保障的 IT 部门，业务部门对信息化的要求通常与当前面临的问题紧密相关。有需要解决的问题，而且 IT 部门无法及时解决时，业务团队才会临时做出预算，为自己开发软件。

向业务部门汇报的平民开发者在软件开发上的投入更加碎片化，峰值虽然较高，但不可持续。而且，随着软件应用走上正轨，业务部门大概率会在第一时间将后续的维护工作移交给 IT 部门，即从平民开发者交接给专业开发者。如果在较短的时间周期内，平民开发者没有按照预期完成软件的开发和交付，业务部门就失去了将其留在自己团队的最大理由。该项目则很可能直接搁浅或移交给 IT 团队，进入开发队列。而对于平民开发者而言，项目已经失败了。

（某业务部门的软件采购与开发投入）

所以，大多数平民开发者会更关注如何以最快的速度将应用开发完成并投入使用，实现"能用"的基础目标，而不是将精力投入到软件质量和可维护性等方面。"短平快"成为平民开发者构建应用的关键词。相比之下，需要长期维护信息系统的 IT 部门中，专业开发者则必须将质量与可维护性（包含功能扩展、数据一致性、系统集成等）放在重要的地位，否则就是给自己和其他团队成员"挖坑"，难以持续发展。

学习偏好：对学习投入更加敏感

不可否认，平民开发者在技术能力上可能会比专业开发者稍微弱一些，但这更像是平民开发者运行模式的结果，而不是原因。

为了进一步达到“短平快”的目标，应对不可持续的软件开发工作，平民开发者通常对学习投入更加敏感。除非通过当前岗位之外的工作熟练掌握了某些软件开发技能，平民开发者在学习软件开发技术中投入的每一分钟，都会拖慢项目交付的速度，扩大项目失败的风险。这是很多平民开发者最不愿意看到的情况。

抛开项目本身，相比于 IT 团队中专业开发者完善的职业发展道路和持续的实战机会，平民开发者在软件开发技术上的学习显得更加没有"性价比"。因为，业务能力才是平民开发者最显著的优势，也是其最大资本；而开发能力，还不知道什么时候才会再次用到。如何让平民开发者也有通过学习不断提升开发能力的机会和动力，是摆在平民开发者领导面前的难题。

（专业开发者的晋升之路）

风险偏好：对运维风险更加敏感

从学习投入低、更关注短期效果两个特点，我们不难看出平民开发者构建的应用比专业开发者的质量风险更高一些。然而，业务团队对数据错误、系统可用性低、数据安全性差等系统运维风险的敏感性却不会因为开发者不同而展现出明显的差异。更麻烦的是，平民开发者本身处在业务团队，一旦他们构建的应用出现问题，所有损失将由该业务团队自行承担。在很多中大型企业中，这种风险不容忽视。

事实上，决定风险敏感度的首要因素是该软件的应用场景。在应用场景的类型上，企业上下对生产、销售、投资等核心业务系统的风险敏感度更高； OA 、人事等边缘应用的敏感度更低。而在数据操作能力上，负责人对仅读取数据的数据分析应用更加放心；而写入数据，尤其是向核心业务系统写入数据的 ERP 二开等应用要求更加严格。所以，让 IT 部门的专业开发者专注于核心业务场景、需要写入数据的场景，边缘应用请相关业务团队的平民开发者参与，是一个被广泛接受的"最佳实践"。

平民开发者的突围之路：自我驱动的创业型团队

综上所述，在低代码的使用者群体上，来自 IT 部门的专业开发者在学习成长、质量保证上比业务团队更有优势，更适合构建高价值的核心业务应用。海比研究在《 2021 年中国低代码无代码市场研究报告》中提到，使用低代码开发各类应用的使用者中，业务人员占比仅为 25%，其余则是来自于低代码平台厂商、合作伙伴和企业 IT 部门的研发人员，即专业开发者。

（低代码使用者以专业开发者为主，海比研究）

在今年秋季结束的 2021 企业级低代码应用大赛中，大量使用活字格低代码开发平台构建的企业核心业务应用得到集中展示。我们能够看到获奖作品全部来自软件公司或企业 IT 部门，充分印证了调研报告的结果。但是，平民开发者就只能做一些简单的应用，无法对企业创造更高价值吗？

我们认为，既然是固化的岗位定义造就了平民开发者和专业开发者的差异，企业可以从根源上打破这种藩篱，彻底解放平民开发者的生产力，即打造自我驱动的创业型团队。

一方面，管理层从公司整体而不是具体团队的业绩对员工进行考核，给勇于创新，加速企业数字化建设的平民开发者以足够的动力，与员工的自我驱动形成正向循环。另一方面，在公司层面形成人员在业务团队和 IT 团队流转的机制，甚至像创业团队一样淡化岗位区分，让平民开发者可以和专业开发者进行身份互换，确保平民开发者也有在专业开发者团队中学习新技术，持续"充电"的机会；专业开发者也能在业务工作中加深对企业业务运作的理解。

来自葡萄城的成功实践

作为全球领先的软件开发技术和低代码平台提供商，葡萄城已经将平民开发者引入市场运营的信息化建设，取得了让人满意的结果。来自市场团队的平民开发者，使用活字格自行开发了包括新手训练营运营系统等核心业务应用，将自身对用户运营流程、理念的深刻理解落地为服务内外部用户的软件系统。活字格覆盖软件开发全生命周期的设计理念和专业的系统架构，确保了这些软件系统的质量、性能和可维护性。每个月都有数百名用户通过葡萄城的新手训练营开启自己的低代码之旅。但是，他们中很少有人知道，报名参营、接收开课提醒、提交作业、查看点评时使用的线上系统，都是平民开发者使用活字格开发的。

（平民开发者构建的新手训练营运营系统）

葡萄城的实践表明，相比于公司 IT 部门或技术支持团队的专业开发者，平民开发者可以让定制化软件保持非常高的迭代频率，最大程度满足自身运营所需。值得一提的是，为了让"平民开发者构建核心业务应用"的模式持续健康运转，葡萄城市场部指派了专人深入学习活字格开发技能，并且固定投入一定比例的工时，专门用于开发和优化团队使用的软件系统，并且与研发部门保持紧密沟通，保持开发能力的常用常新。

最后，祝愿所有引入低代码技术的企业能够找到自己的落地方案，充分享受软件开发技术进步带来的红利，让企业的数字化进程再创新高。