6 个应用的人天账：估了 476，实际用了 278

一家商用车集团给 6 个应用逐个记两个数，常规开发估 476 人天，低代码实际花 278 人天，省约 4 成；中等复杂的材料技术平台省 3 成，简单的资产、人员管理系统省一半以上。本文把这两个数的统计口径拆开：估算按表单、流程、报表、接口四块分别给，实际人天含沟通、两轮调整与培训，并列出两种会把账算歪的估法。

先算账再决定要不要用

整车和商用车企业里，小应用要排队等信息部门，外围业务很多还压在 Excel 表格里。要不要上低代码，业务部门说得热闹，得先把账算清楚。

这家集团的方法不复杂：给每个应用记两个数，常规开发估多少人天，低代码实际用了多少人天。再按复杂度分开看，分成中等复杂、简单需求、紧急的小需求。

分开看是关键。把所有应用混在一起算平均值，简单和复杂的差别被抹平，结论就没什么用。

两个数的口径要先定死

估算由谁给，直接决定这笔账可不可信。这家集团是信息部门按老办法估：把应用拆成表单、流程、报表、接口四块，逐块估人天，不估整体。

实际人天要包含哪些活，也要提前说明白。需求沟通、上线后的两次调整、给使用者做培训，这些时间如果不计进去，低代码看起来会省得夸张。他们的口径是凡是这个项目里发生的人力都算，包括业务人员投入的时间。

口径先定，数字才有比较的价值。这一点比省了多少更重要。

# 估算侧：拆四块，不估整体
est_days = form_days + workflow_days + report_days + integration_days

# 实际侧：项目里发生的人力都算，含业务人员投入
actual_days = (config_days + requirement_sync_days + adjust_rounds_days
               + training_days + data_prepare_days)

# 提效幅度按应用逐个算，再按复杂度分层汇总，不直接看总平均
saving_rate = (est_days - actual_days) / est_days

adjust_rounds_days 明确取两轮调整。写成一轮还是三轮，两年后没人记得当初的口径，这份数据就没法纵向比较。

6 个应用的结果

复杂度	代表应用	提效情况	怎么理解这个数
合计	6 个应用	估 476 人天，实际 278 人天，省约 4 成	平均数，用来汇报，不指导具体场景
中等复杂	材料技术平台	省 3 成	复杂度高，提效幅度收窄
简单	资产管理、人员管理	省一半以上	表单加流程加报表，配置化程度最高

这 6 个应用都是在 Dolphin Code 低代码平台上做的。

省一半以上的都是结构简单、字段和流程都不特殊的应用，这类需求以前也要排队等信息部门，现在业务部门自己就能做。材料技术平台那类带业务规则和数据模型的，提效收窄到 3 成，因为难的部分在规则梳理，不在怎么写界面。

这笔账的适用条件

三个前提：应用数量要有 6 个以上，一两个应用的平均值没意义；估算方要熟悉企业常规开发成本，外部的乐观估算会把结论带偏；复杂度要提前分类，不要事后按结果倒推。

紧急的小需求这一类，账算出来往往更好看。常规开发排队两周，配置上线两天，省下的时间比省下的人天更容易被业务方感受到。

两种把账算歪的估法

一种是估算方按最理想情况给人天，没算上线以后的两轮调整和推广支持，常规开发的数字被压低，省下来的比例自然不好看。

另一种是只把配置时间算进低代码实际人天，需求沟通、数据准备、给使用者培训都不计。这种算法能算出很漂亮的倍数，第二年维护时才发现人还是那些人在做。

偏差	怎么发生	后果	对策
压低估算值	只算写界面和接口的时间	分母变小，提效被低估	估算按四块拆，缺块退回重估
少计实际值	只记配置工时	分子好看，第二年维护才暴露	含沟通、两轮调整、培训与业务人员投入
事后分层	按结果反推复杂度	结论跟着人走	复杂度在立项时定，并登记判定人

两种偏差都会把结论推向估算的人本来就想推向的方向。这也是为什么前面说口径比数字重要。

他们定的下一步

他们的结论是，中等复杂和简单的系统提效明显。下一步用配置加代码的方式，评审决定哪些场景写代码。

这一步走得对。低代码不是把所有需求都关在配置里，复杂算法、高频接口、需要精细交互的界面，写代码更合适。用评审机制决定每个应用走配置还是走代码，比争论哪种方式更好要实际。

场景特征	建议实现方式
表单、流程、常规报表	配置
复杂算法、批量计算	代码服务，配置层调用
高频接口、低延迟要求	代码，压测后再定
需要精细交互的界面	自定义组件

自己算这笔账要准备的四个格子

应用名称、常规开发估人天、低代码实际人天、复杂度分层。攒够半年再回头看，哪些场景该继续用低代码、哪些该写代码，数字会自己给答案。

口径检查清单

• 估算按表单、流程、报表、接口四块给出，缺块重估
• 实际人天含需求沟通、两轮调整、培训、数据准备与业务人员投入
• 复杂度在立项时分层并登记判定人，不允许事后按结果倒推
• 样本量不少于 6 个应用，单个应用不对外报平均提效
• 排队时长单独记录，紧急小需求的收益按周期而不是人天表达
• 每个应用的口径版本与统计日期一起留存，便于纵向对比
• 配置与代码的分工有评审机制和记录

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中公式用于说明统计口径，人天数据来自该集团的项目记录。