看起来只是一个小小的改动，但是却要经过需求评审、产品设计、开发、测试、发布这么多环节，问题究竟出在开发速度还是软件交付方式？
一个小需求，实际要经过哪些环节？
其中前6步为一次完整交付流程，第7步为迭代闭环
对业务人员来说，需求可能只是“增加一个字段”，但对系统而言，这个字段还可能牵涉数据库、页面、接口、权限、报表以及历史数据等内容，因此不能只修改页面上的一个位置。一个需求的改动可能要经过7步。
提出需求
业务部门先说明需要解决的问题，例如增加字段、调整审批流程，或者新增报表；由于前期描述通常比较概括，后续还要继续确认具体的使用人员、业务规则以及希望达到的结果。
产品设计
产品人员需要把业务部门的想法整理成方案，内容包括页面、字段、流程、权限和异常情况等；
UI设计
UI设计人员根据已经确定的产品方案，安排页面布局、操作方式和显示效果。
系统开发
开发人员按照产品方案和页面设计，完成数据库、页面、业务逻辑、权限以及接口等方面的工作；表面上只是修改一个页面，实际可能还会影响其他功能模块和相关系统。
功能测试
测试人员要检查新功能是否能够正常使用，同时还要确认原有功能没有受到影响；如果测试中发现问题，还需要进行修改、重新测试和验证。
上线开发
测试通过后，系统需要完成数据备份、版本发布、环境配置等工作；如果系统涉及生产、库存或财务等业务，还要提前准备出现问题时的处理方案。
修改返回
上线后如需要增加新需求，需返回第一步。
传统开发的流程是从：需求→产品→UI→开发→测试→上线→修改。每一步都需要沟通、排队、返工，一个需求走十天半个月的很正常。
为什么小需求也会变成大周期？
企业软件的复杂度，会随着系统数量、业务流程、数据和组织规模不断增加。一个需求从“小”变“大”，通常有三个主要原因。
原因一：沟通成本
一个项目往往会涉及业务部门+IT部门+管理层+财务+人事+生产+销售+第三方供应商等多个部门，不同部门关注的重点不同，因此，一个需求往往不是一个人的问题，而是多个角色共同协作的问题。
原因二：技术债务不断积累
传统软件长期运行后，会积累老架构、老数据库、历史代码、文档缺失、人员流失等技术债务，导致系统越老改一个功能的成本越高。
原因三：系统之间存在大量依赖
企业通常同时运行多个系统，一个系统的改动往往会沿接口链路波及其他系统。因此，企业软件数量越多，系统间的依赖关系就越复杂。
一个需求的改动并不是我们表面上看的修改页面内容那么简单，“沟通协调+技术债务+系统依赖”三个环节叠加，小需求也就变成了大周期，因此，我们在前期的需求沟通中要全面表述需求，以减少后期返工。
低代码解决的，不只是“写代码更快”
很多企业在理解低代码时，容易陷入一个误区：“不用写代码，所以开发更快。”但如果只把低代码理解成“少写代码”，其实低估了它真正的价值。
表传统开发与低代码开发对比表
从开发链路、交付周期、需求变更等方式可以看到，低代码带来的改变，并不只是“少写一些代码”，而是重新解决了企业应用的开发与交付方式。它的价值主要体现在以下三个层面。
01价值一：减少反复需求沟通
在开发过程中业务员进行需求描述，产品人员进行需求整理，开发人员进行系统搭建，需求在转述过程中可能出现偏差。而低代码是让业务人员参与到系统搭建的整个流程中，更早的框架页面和流程，及时参与确认。
02价值二：让业务变成可使用的系统
低代码的特点是将表单、审批、流程、管理这些通用的能力做成可配置的模块，业务人员无需精通业务，只要有基础代码知识就能够自己搭业务系统，不用每次都从头开始搭建，可以更快的发现问题，解决问题。
03价值三：让系统更灵活
企业在管理系统中的流程并不是一成不变的，审批流程、业务要求都有可能修改，当遇到需要快速上线的情况下，低代码支持先上线后迭代。
所以，低代码的价值不只是“写代码更快”，而是应该在开发过程中做到：随业务变化及时调整、让不同系统互联互通、让业务人员参与系统开发的全过程中。
低代码正在成为企业刚需
上文讲了低代码在逻辑上的价值，那么这些价值是否被市场认可？我们来看一组最新数据。
（IDC）发布《2024下半年中国低代码与零代码软件市场跟踪报告》中国高新技术产业导报转载
“IDC数据显示，2024年中国低代码与零代码软件市场规模为40.3亿元，预计到2029年将达到129.8亿元，5年复合增长率达26.4%”这个趋势已经很明显了：低代码并不是短期概念，是企业真实在投入的方向。
需要说明的是：低代码并非万能，也不会取代程序员。不同场景各有适配的开发方式，未来的企业软件开发，将更多走向 "低代码 + 专业开发" 协同配合的模式。
