企业官网建设流程全解析

「AI 低代码一分钟」系列 第 12 篇｜阅读约 7 分钟
摘要：一家商用车集团给 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 个应用都是在 Dolphin Code 低代码平台上做的。

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

四、这笔账的适用条件

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

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

五、两种把账算歪的估法

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

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

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

六、他们定的下一步

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

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

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

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

口径检查清单

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

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