作者|赵云评论|千山现代管理之父德鲁克在谈到创新的本质时提到了两点：一是把贵的东西变便宜，让老百姓用得起；二是让门槛高的东西，门槛低，老百姓用得上。乍一看，低代码很适合这两者。试想一下，如果有这样一个神奇的工具，可以让产品经理根据需求在4小时内将一款产品“拖”到客户面前，那将是一个怎样的场景。1、低代码：让人找不到工作？但如果是一年前，低代码的“用户故事”风格会是这样的：一个传统行业的老板想出了一个低代码的开发平台，让产品经理在上面填写数据库字段。然后绘制bpmn（业务流程管理）流程图，拖拽前端组件，整个流程不用写代码，一个系统就完成了。上周可以上线一个项目，可以赚到百万元左右。工程师们见状，做好了逃跑的准备，看样子只是想实施一下。临走前不忘说一句：lowcode，yyds！低代码在当时吹得非常厉害：解放开发人员的生产力，就靠它了！然而，经过一年多的发展，low-code却给很多人带来了无数的尴尬时刻！从草根的“低代码”开发工程师，到系统设计的架构师，彻底沦为“吐槽”大会。产品经理：我是做产品还是做工具？架构师：本质上，这个东西是一锤子买卖，自己应对不了需求变化！这个系统根本无法扩展！开发工程师：简单的工具还好，遇到复杂的需要扩展就傻眼了。低代码工程师:天天用low-code打包的东西，更像是等死不改进！是大家对low-code期望过高，还是low-code本身就是一种“虚假需求”？二，虚假需求还是真实需求？真正的需求是产品持续发展的动力，那么低代码的“真正需求”在哪里呢?去年Gartner发布了一份低代码用例调查，排名靠前的是：表单和数据收集应用.协调业务流程的应用程序和程序内的工作流程，取代纸张、电子邮件或电子表格应用程序，并为当前的本机应用程序定制新的应用程序UI。回头看国内，不难发现目前低代码的应用场景不外乎几个方面：一是在数字化转型场景中，低代码在B端用户中的呼声更高。这个工具似乎是解决他们“最后一英里”问题的必要选择。传统行业的数字化往往缺乏技术人才储备。同时，系统和设备也封闭、陈旧，如奶茶店、服装店等。让他们专门招聘数字化的研发团队。矫枉过正。低代码是不同的。您可以通过拖放快速解决案件。当然，老板们会喜欢的。其次，对于初创企业来说，人员和规模都不大。要想快速运营公司，就必须快速搭建CRM、OA、项目管理、进销存等系统。这些系统看似非常成熟，但你需要找到足够多的熟练人员来快速交付是一个挑战。这时候，低代码就派上用场了。您只需找到熟悉业务的非技术人员，经过培训，即可快速构建企业需要的定制化应用。最后，对于大中型互联网公司来说，低代码也有发挥的地方。这也是一些开发者最担心的：低代码夺走了自己的需求。其实以现在的情况来看，还真是大可不必。众所周知，对于产品经理来说，需求可以分为重要的和紧急的。现在看低代码实现，往往是那些“紧急不重要”甚至“重要不紧急”的需求。为什么要交给研发？调度呢？将它留给低代码工具不是更好吗？此外，低代码很难开发复杂的系统。首先，内部是一个黑盒子，只有扩展是个问题。其次，low-code的粒度远没有高到CTO大笔一挥的程度。架构图中的哪个系统应该低代码实现，因为稳定性无法保证。所以专业的东西交给专业的工具。低代码不是来抢饭碗的，而是让技术人员腾出时间和精力去处理更有创意的事情。3.低代码只是开发者的一个选择在SoftEngineering的《人月神话》一书中，作者Brooks指出了软件开发的一个僵局：向落后的项目增加人力，只会让进度更加落后。为了更快地完成项目，开发团队会变得非常庞大，以至于所有的时间都花在了沟通和变更决策上，这使得项目无限期地结束。那么低代码会成为打破这种僵局的工具吗？当然。如果业务需求层面难以沟通，就让甲方爸爸自己搭建。相关代码模块化封装后，交给实际业务场景中的人员自行组装应用，既达到了快速响应业务需求、适应变化的目的，又给了业务人员更多的自由度，无需与开发人员沟通。沟通时间的同时让应用更贴近场景。因此，对于同一个“人月”，专业开发工程师和低代码构建工程师所扮演的角色是截然不同的。其次，开发人员还需要低代码工具来不断创新。确实，专业的开发人员拥有非常强大的技能。但它们也很少见。如果公司想继续提高效率，低代码工具是必须的。专业开发人员经常面临数据和流程碎片化的环境、长期积压的遗留系统以及臃肿的工作环境。他们无法利用新兴技术同时保持敏捷和无风险。利用单一云基础的低代码工具可以使开发人员加快他们交付的创新步伐。此外，低代码使开发人员（即使是那些没有技术技能的开发人员）的软件开发更加容易。得益于低代码开发平台，专业开发人员和非开发人员之间的协作成为了一个“融合团队”。目前在这方面做得好的是国外的低代码独角兽Mendix，专门为专业开发者提供低代码工具。4.低代码：一个骗人的神话？Brooks曾经以一种非常开玩笑的方式描述过：使用“人月”来衡量工作的规模是一个危险且具有欺骗性的神话。同样，用“多少代码”来衡量工具的能力也是一个骗人的神话。工匠以他们的工具而闻名。低代码的普及必然会造就一批低代码专家。但这并不意味着低代码的价值不如专业发展。低代码是否流行取决于市场上各个利益相关者的接受程度。目前市场上的反馈是：老板看了一定要用，用户试了就不想用。以中国为例。11月，众多巨头大秀低码肌肉：11月3日，在阿里云云栖大会上，阿里巴巴集团副总裁、钉钉总裁叶军宣布，低码在钉钉上的代码应用数量已经超过500万，低代码开发者数量已经超过380万。11月13日，腾讯升级旗下“微拍”，目前服务300万开发者，新小程序使用率70%；11月18日，华为AppCube全线产品全面升级，围绕低代码、零代码、数据大盘、数据看板三个方面进行了升级优化。在数字的背后，我们可以看到，虽然一直饱受争议，但低代码用户的数量确实在飙升。5、如何做低代码有为低代码平台的用户反馈并没有那么乐观，就像文章开头描述的不同岗位的使用体验：众说纷纭。low-code的“盲盒”，拆得好，效率高，拆得不好就不能用。根据TechRepublic的一项调查，受访者希望低代码平台能够提高生产力(15%)、减少应用程序开发时间(14%)并使手动流程自动化(12%)。技术和非技术团队可以通过实施以下一些建议共同努力来满足这些期望。这里有一些使用建议。1.打造平民开发者群体我们认为平台开发者是不以编码为生的人：产品经理、流程专家、业务分析师、设计师、MBA项目毕业生等。这些都是来自不同背景、不同观点的聪明人解决问题并找到解决方案。此外，这些人熟悉业务并与解决方案有密切联系。由于非技术团队成员可能是开发生态系统的新手，因此需要对他们进行培训以了解各种可能性以及如何最好地实施他们的最新想法。通过学习，没有经验的建设者可以获得进入新领域的信心。因此，公司需要为采用低代码解决方案制定明确的激励措施。这意味着要清楚低代码的好处和结果。为什么要鼓励公民开发者不断学习和尝试新工具？什么样的潜在结果会让工作生活变得更好？此外，需要提高整个公司对低代码带来的潜在机会的认识。老板必须确保向员工提供学习和发展资源，从而为进一步提高解决问题的能力打开大门。2.专注于具有战略意义的低代码项目许多业务团队经常被激励参与低代码项目。他们希望提供新产品和解决方案，并更快地将创意推向市场，或者他们需要为客户创造更强大、联系更紧密、定制化程度更高的体验。他们浪费了太多时间手动重新输入相同的信息和其他低效的模拟活动。现实中，很多低代码工程师熟悉业务，愿意学习可视化编程，可以为日常工作创建简单的用例。一开始，这些用户并没有考虑自动化或应用程序开发的确切用例。为了寻找创意，他们可以探索日常业务活动中的已知痛点和行业特定需求，或者他们可以从预建的内容市场开始，看看一些常用的解决方案。一旦他们有了想法列表，就应该有一个基于预测的业务影响的战略优先级排序过程。业务用户开始的另一种方法是参与概念验证(POC)原型开发项目，以转换已被IT分配为高度战略优先级的更复杂的流程或活动。POC原型是业务用户（例如设计师）与其他开发人员或项目团队分享他们对最终产品的愿景以验证需求的绝佳方式。日常问题和请求是低代码解决方案的理想选择。业务人员应该有权构建所需的扩展和应用程序。由于IT资源和专业开发人员供不应求，低代码工具允许任何人改进自己的工作流程和自动化手动工作，并在生成解决业务问题的工作原型时最大限度地提高速度、灵活性和创新。3.通过低代码学习资源适应新角色虽然低代码工具比编程语言更容易获得，但在开始之前需要学习它们，特别是对于刚接触软件开发的业务用户，否则第一个自动化和应用程序构建将是草率、不可扩展，甚至会产生IT风险。低代码课程为没有经验的用户打开了大门，让他们在开始之前获得基本的了解。它们涵盖概念性的事情，例如：识别用例以及如何确定从哪里开始的优先级，包括对软件结构、设计和逻辑流程的深刻理解，以及在施工开始之前规划用户体验。当然，在构建简单的培训案例时对能力进行全面的实践审查可确保通过实践经验获得产品知识。因此，对低代码技术感兴趣的个人越来越多地使用学习工具和课程。这些学习计划还将扩大低代码工具的使用范围。6、上一个疫情时代，经济可以放缓，但企业永远不敢放缓。只是，过去更多的增长是靠扩大规模来实现的，现在靠谱多了。是提高人的效率，还是提高创新能力。从这个角度看lowcode，没有别的，只是一个提高效率的工具。无论如何，对于用户来说，low-code只是一种工具，并不是某一类人的替代品。在低代码生态系统中，具有计算机科学和工程背景的开发人员将继续以代码优先的方式推动创新。但与此同时，低代码工具可以为他们带来效率优势，同时也为更多非技术员工参与开发过程打开了大门，从而增加了协作。同时，我们也应该看到低代码发展所暴露出的问题：人才的可持续培养、培训和激励机制的缺失、平民化发展的氛围。要构建正确的低代码工作流程，您必须首先了解工具的功能。如果你希望低代码在安全性、合规性和可靠性方面具有可扩展性、集成性并运行良好，你仍然需要共同努力来推动它。所以，放轻松。就像开车一样，你可以选择自动挡或手动挡。但自动挡注定是一种趋势。参考链接：https://stackoverflow.blog/2022/11/15/speeding-software-innovation-with-low-code-no-code-tools/
