英国365上市(集团)有限公司

首页 / 培训赋能中心 / 信息化项目造价知识 / 信息化项目初步设计,到底应该设计到什么深度?
信息化项目初步设计,到底应该设计到什么深度?
更新时间:2026-09-23 13:54:36

很多信息化项目的初设有几十上百页,看起来很专业;可一到招标,供应商还得重新问需求;一到建设,又要重新做详细设计;一到验收,才发现当初根本没写清“做到什么算完成”。

问题可能不在于初设写得少,而在于——深度到底用什么来衡量?

01PART

初设最尴尬的问题:写浅了没法用,写深了又越界

建设单位做初步设计,最常被问的一句话就是:

“到底要写到多细?”

有人认为,既然只是“初步”设计,功能模块列出来、架构图画出来、设备数量算出来就行。

也有人认为,既然初设要拿去批概算、做招标,就应该把功能、接口、数据库、性能参数全部设计清楚。

这两种理解,都有问题。

《国家政务信息化项目建设管理办法》要求项目建设单位严格按照批复的初步设计方案和投资概算实施建设。换句话说,初设一旦批复,就不再是一份“汇报材料”,而开始成为后续建设和投资控制的依据。

但国家层面的管理办法并不会告诉建设单位:功能到底拆到第几级?接口写到系统级还是字段级?数据库做到主题库还是表结构?性能写“满足并发要求”还是必须给具体数值?

于是现实中出现了一个很尴尬的状态:

同样叫“初步设计”,有的还是可研的深度,有的已经快写成详细设计了。

02PART

实践中,初设到底应该做到哪一步?

四川省审计厅在2024年度省级预算执行审计中发现,3个部门的7个政务信息系统“未完成合同任务即通过验收并付全款”。

当然,不能简单把问题归结为“初设写得不好”。但它至少提醒建设单位:

如果设计阶段没有把“建设任务—采购内容—交付成果—验收证据”串起来,项目做到最后,专家到底依据什么判断“完成了”?

再看实践。

湖南省在省直单位政务信息系统项目管理办法中,专门附有初步设计方案和投资概算编制规范,要求初设明确系统功能、信息量、性能等指标,并进一步设计信息资源、数据库、应用系统、接口、软硬件配置等内容,同时形成投资概算。

这说明,初设至少要详细到足以支撑两个问题:这个项目究竟要建什么、要花多少钱。

四川省级政务信息化项目管理办法也明确,自行建设项目应编报可行性研究报告和初步设计方案(含投资概算),并组织评估论证后审核批复。初设已经不只是描述“准备建什么”,还要支撑项目审批、投资控制和后续建设。

但如果只看到这里,又很容易走向另一个极端。

安徽的政务信息化项目管理规则明确提出:对于定制化软件,在可研或初设批复后,还应先组织详细设计,再进行开发建设;详细设计包括系统架构、业务流程、数据库、接口、功能规格说明书等。

这实际上说明:

初步设计并不是越细越好。

如果初设已经把接口字段、数据库表结构、异常处理、页面交互全部设计完,它实际上已经开始替代“详细设计”了。

所以真正的问题不是:

“初设到底要不要详细?”

而是:

“初设究竟应该跨过哪一道线?”

03PART

初设至少可以分成三个深度

与其纠结初设“到底要写多细”,不如换一种判断方式:看它到底达到了哪一个深度层级。

1.概念级:能看懂要建什么,但还不能直接采购

很多初设停留在这个层级。

功能写“用户管理、业务管理、统计分析”;接口写“实现与相关业务系统对接”;数据写“实现数据汇聚共享”;性能写“满足高并发需求”;验收写“系统功能满足建设需求”。

比如:

“建设综合业务管理模块,实现业务申请、审核、查询、统计等功能,并与相关系统实现数据共享。”

看起来没问题。

但真正到了报价环节,A厂商可以理解成30个功能点,B厂商可能理解成100个;有人认为要对接2个系统,有人认为要对接10个。

这种深度可以用于讲方案,却不足以形成清晰的建设边界。

2.可招标级:初设最应该达到的深度

这里可以引入一个更直观的判断尺度:

“可招标阈值”。

判断初设够不够深,不看写了多少页,只问一句:

把这份初设同时交给三家没有参与前期设计的供应商,他们能不能在不大量找建设单位“补需求”的情况下,对建设范围形成基本一致的理解,并报出可比较的价格?

如果不能,就还没有跨过“可招标阈值”。

这个层级至少应该做到:

功能可独立识别、估算和验收,并写清角色、主要业务规则和输入输出;接口明确对端系统、数据方向、对象和频率;数据明确来源、数据域、规模及迁移要求;性能给出并发、响应时间、可用性等可量化指标;设备和资源明确数量、关键参数及测算依据;验收能够逐项对应建设内容。

比如,同样是“事项申报”,如果进一步写明支持暂存、提交、补正、撤回,明确业务校验、并发用户、响应时间以及结果推送对象,功能就能估价、接口能划界、性能能测试、验收能取证。

对于定制软件部分,如果需要进一步梳理功能清单、识别功能点并测算开发工作量,也可以借助“软件造价喵”工具进行辅助。平台已整合10年行业基准数据及70余项国家、行业、省市级软件和信息化项目造价标准,可用于功能点识别、清单梳理和造价测算,提高前期测算和复核效率。

3.可实施级:已经接近详细设计,不一定都该放在初设

再往下,就进入可实施级。

功能细化到完整用例和异常流程;接口明确URL、字段、编码、鉴权、错误码;数据形成逻辑模型甚至物理表设计;部署明确服务器节点、网络端口、中间件和资源配置;验收进一步形成测试用例和预期结果。

这些内容当然更清楚,但对大多数定制软件项目,初设未必应该直接做到这一层。

因为过早把技术细节全部锁死,不但增加前期设计成本,还有可能限制后续技术方案竞争。

所以,可以把初设的边界概括为一句话:

合理下限,是达到“可招标级”;合理上限,是不要无原则侵入“详细设计级”。

图片

04PART

判断初设够不够深,不妨试试“验收链路法”

比起从“应该写哪些章节”正着检查初设,还有一种更实用的判断方式:

站到项目验收那一天,倒着检查。

对主要建设内容,依次追问:

建设目标 → 业务场景 → 功能/数据/接口 → 技术指标 → 交付成果 → 验收证据

比如初设写:

“建设数据共享交换能力。”

那就继续往后追:

共享什么数据?和谁共享?通过什么方式?频率是多少?承建单位最后交付什么?建设单位拿什么证明已经实现?

只要其中有一环回答不了,这个需求大概率还没有设计到位。

财政部《政府采购需求管理办法》要求采购需求清楚、准确,对能够量化的指标尽可能量化,并要求验收标准覆盖采购需求中的客观、量化指标。初设如果最终要向采购需求传递,就不能在两者之间“断链”。

沿着这个思路,还可以进一步归纳成一个“三维深度矩阵”:

业务维解决“到底要干什么”;技术维解决“做到什么指标”;交付维解决“最后凭什么证明干完了”。

很多初设的问题不是没有“技术架构图”,而是第三维——交付维几乎是空白的。

图片

05PART

建设单位最容易犯的几个误区

一是把篇幅当深度。一百页背景、现状、政策依据,并不会让项目更容易招标。

二是功能只写模块名称。“综合管理、智能分析、一屏统览”不是工作量边界。

三是接口大量使用“等”。“对接××、××等相关系统”,这个“等”字,将来很可能就是变更。

四是性能全是形容词。“稳定、高效、安全、快速”无法测试,也无法验收。

五是设备有参数,却没有测算依据。为什么需要8台服务器而不是4台?如果回答不了,预算就容易变成“设备清单×单价”。

六是设计时不考虑验收。前面写“提升监管能力”,后面却没有指标和证据证明目标是否实现。

七是认为越细越专业。如果初设已经锁死数据库表、接口字段甚至页面控件,建设单位反而应该问:这些内容现在真的已经确定了吗?

八是初设、招标文件、合同各写各的。前端设计、中端采购、后端验收一旦断开,很多边界争议就会被留到项目后期。

06PART

建设单位拿到初设,可以先做这几项检查

第一,做一张“目标—建设内容”对应表。每个目标都能找到具体建设任务。

第二,做一张功能清单。每项功能至少能够独立理解、估算和验收。

第三,锁定接口边界。对端、方向、数据、频率、责任和前置条件至少写清。

第四,把数据单独设计。明确数据从哪里来、怎么治理、如何更新、向谁共享。

第五,把形容词换成数字。“高并发”换成并发量,“响应快速”换成响应时间。

第六,检查设备和资源测算。硬件、云资源、软件授权都应该回答“为什么需要这么多”。

第七,提前想验收。每一项主要建设任务,都要能回答未来拿什么证据证明完成。

第八,做一次“陌生供应商测试”。找一个没参加前期方案讨论的人看初设,如果他不断问“这个到底是什么意思”,说明设计深度还不够。

第九,主动留下详细设计空间。把“建设边界必须明确”和“实现细节允许优化”区分开。

第十,最后才看预算。预算不是初设的起点,而应该是需求、规模和技术方案推导出来的结果。

///LAST初设真正要设计的,不只是系统

过去,行业中经常把初步设计理解成:

“把可研再详细一点。”

但从项目管理角度看,更值得关注的是另外一种理解:

可研解决的是“这个项目值不值得建”;初设真正要解决的,是“建设单位准备用什么边界,把这个项目交给市场去建”。

因此,初设真正重要的,不是画出了多少张架构图,而是完成了一次关键转换:

把建设单位脑子里的需求,变成市场主体能够共同理解的采购边界;再把采购边界,变成未来能够被验收、审计和追责的交付边界。

如果一个项目直到验收的时候,大家还在争论“这个功能到底包不包含”“这个接口到底算不算建设内容”,真正的问题,可能并不是出在验收那一天。

很多争议,在初步设计的时候就已经埋下了。

所以,一份真正好的初设,不是让专家评审的时候觉得“写得很专业”。

而是几年以后再回头看,依然能够回答三个问题:

当初为什么花这笔钱?

这笔钱到底买了什么?

最后怎么证明这些东西真的交付了?

这三个问题都能回答,初设才算真正写到了“深处”。

最后也留两个问题:

你们的信息化项目初设,目前一般要求功能拆到什么程度?模块级、功能级,还是已经做到详细规格说明?

你更赞同“初设尽可能做深,避免后期扯皮”,还是“初设只锁定建设边界,把技术实现留给详细设计和承建单位”?

这个问题,不同的建设单位、设计单位、造价单位和承建单位,答案可能会非常不一样。


微信联系
添加微信咨询
TOP
软件造价喵
立即登录
AI询价喵
立即登录
XML 地图