智能停车项目周期怎么估算？哪些环节最容易影响进度

相机已经认出车牌，出口却算不出费用；司机付了款，道闸没有收到放行结果；现场断过一次网，恢复后同一辆车多出两条记录。智能停车项目的工期，往往就耗在这些“只差一步”的问题上。

道闸、相机和余位屏可以很快装到现场，一辆车从入口被识别，到出口算清费用、完成支付、抬杆离场，却要经过现场设备、网络、停车平台、支付渠道和运营规则。任何一段没有接稳，现场看起来已经完工，项目仍然不能交付。

红数科技给这类项目排期时，先确定交付边界：是改一个停车场，还是做多场统一运营；是复用厂家平台，还是新建业务后台；只管进出和收费，还是包含车位引导、预约、会员、充电、发票、监管数据和无人值守。范围没有落到一辆车的完整进出过程，单报一个“30 天上线”，参考意义很有限。

先用项目范围判断大概周期

下面的时间从需求和现场条件确认后开始计算，指项目达到试运行或约定验收条件的日历周期参考。土建审批、设备定制生产、道路占用审批、大规模供配电改造等工作，如果尚未完成，应在这张表之外单独计算。

这不是国家标准规定的固定工期。现行的 GB/T 42442.1-2023、GB/T 42442.3-2023 和 GB/T 42442.2-2024 分别给出了智慧停车的总体、平台和数据要求，解决的是系统建设与数据交换应遵循什么要求，不会替某个具体项目规定多少天交付。项目规模相同，现场已经具备施工条件与边营业边改造，日历周期也可能差很多。

一份可以执行的排期，通常会把工作拆到下面这些结果，而不是只写“开发中”“施工中”：

这些时间不能机械相加。软件开发、设备到货和现场施工可以并行，入口没有网络、支付商户号未开通、设备接口没验证，却都会挡住后面的整体验证。更接近真实项目的算法是：日历周期等于关键路径上的工作时间，加上外部等待、问题整改和复测时间。

现场条件往往最早拖住计划

停车场不是空房间。商业综合体不能随意封闭出入口，医院早晚高峰不能停工，老旧小区还可能只有一进一出。施工安排如果只按安装人员需要，不看真实车流，计划做到第二天就会变。

现场勘查至少要把车道宽度和转弯半径、相机安装位置、强弱电路径、网络覆盖、排水与基础、岗亭和安全岛、限高、消防通道、照明以及可封道时段查清。地下车库还要特别看弱光、逆光、坡道和通信信号。图纸只能说明原本怎样设计，线缆是否还能用、管道是否堵塞、原设备拆除后基础能否复用，往往要到现场才知道。

如果项目要边营业边改造，应该先保留人工通道和离线放行办法，再分车道施工。为了赶工同时拆掉所有旧设备，看上去省了两天安装时间，运营中断、车辆拥堵和投诉带来的处置时间通常更多。

设备能识别车牌，不等于系统已经联通

智能停车里最常见的误判，是把相机演示成功当成接口联调完成。相机识别车牌只是第一步。平台还要知道识别发生在哪条车道、是哪台设备、抓拍时间是否准确、车辆方向是什么，并把同一辆车的入场和出场记录对应起来。

设备品牌、型号和固件版本都可能改变接口表现。文档里写了车辆事件，不代表实际报文一定包含图片地址、车牌颜色、置信度和方向；平台下发开闸后，设备是立即回复、执行后回复，还是只在下一条状态里体现，也要用真实设备验证。厂家云接口、设备直连协议和旧平台数据库对接，是三种完全不同的接入路线，工期不能按“都是一个接口”估算。

红数科技更倾向于在项目第一周选一进一出两条车道做小范围验证。先跑通识别、入场、计费、支付、出场和记录查询，再批量安装。接口问题在这时暴露，只影响两条测试车道；等几十个点位装完才发现协议版本不一致，返工会同时落在设备、网络和平台三边。

收费规则写得越笼统，后面的返工越具体

“按小时收费，会员有优惠”不能直接拿去开发。免费时长从入场算还是支付后重新算，跨日怎样计费，同一天多次进出是否合并，封顶金额按自然日还是连续 24 小时，军警车、月租车、商户券和充电减免谁先谁后，都要有明确口径。

正常车辆还算简单。无牌车怎样入场，车牌污损或识别错误由谁改，跟车入场后出口找不到记录怎么办，支付成功但道闸没有抬起怎样复核，车辆已经离场而支付回调稍后才到，是否还能生成第二笔订单，这些异常才是联调和试运行最花时间的部分。

支付页面能拉起，也不代表账已经对上。停车业务至少要核对入出记录、计费明细、停车订单、支付渠道单据和退款记录。接入电子发票、先离场后付费、聚合支付或多运营方分账后，参与方更多，结算时间点也会改变。收费和优惠规则若在开发后期才确认，改的往往不是一个金额字段，而是订单状态、对账方式和客服处理流程。

多系统对接最耗的常常是等待时间

停车平台可能还要连接物业会员、商场积分、医院预约、充电桩、城市停车监管平台、地图服务和电子发票。每多一个系统，不只是增加一个接口，还增加了一名资料提供方、一个测试环境和一轮问题确认。

GB/T 42442.2-2024 已经对智慧停车数据提出要求，GB/T 42442.3-2023 对平台技术提出要求；较早的 GB/T 29745-2013 仍是现行的公共停车场（库）信息联网通用技术要求。实际项目还要服从当地平台的数据目录、编码规则、更新频率和接口安全要求。国家标准能提供共同基础，不能替代当地接口文档。

第三方最影响进度的情况，不一定是接口难，而是测试账号没开、白名单没加、字段口径没人确认、对方只在固定时间配合。软件人员可能只需要半天修改，项目却为一次联调窗口等一周。正式计划里应该把外部资料、账号、负责人和最晚到位日期列出来，不能全部藏在“接口联调 5 天”这一行里。

验收口径晚定，试运行就会反复补题

项目验收不能只看道闸会不会抬。正常进出当然要测，重复车牌、跟车、无牌车、网络中断、停电恢复、支付超时、重复回调、人工改牌、免费放行和设备离线也要有预期结果。无人值守项目还要验证远程坐席看得到什么、能做什么，人工放行后是否留下人员、时间和原因。

有些指标必须先约定条件才有意义。车牌识别率受车速、光线、车牌状态、安装角度和测试样本影响；出口通行效率也会受到支付方式、司机操作和前车停留影响。只在合同里写一个数字，不写测试场景和样本，到了现场很容易出现双方都认为自己达标的情况。

试运行应让真实车辆和真实班次参与。连续跑几天，核对高峰排队、余位变化、优惠使用、交接班、退款和日结数据，很多在实验室里看不见的问题才会出现。发现问题后还要留出修正和复测时间，不能把“开始试运行”直接当作“项目已验收”。

排期前把这些资料准备齐，日期才有依据

• 停车场平面图、出入口数量、车道照片、现有设备和网络供电情况。
• 设备品牌、型号、固件版本、接入方式、接口文档和可用测试设备。
• 临停、月租、会员、优惠、封顶、跨日、退款和特殊车辆的收费规则。
• 支付、发票、物业会员、充电桩及监管平台的账号、文档和对接负责人。
• 哪些时段可以封道施工，现场由谁配合车辆测试和设备复位。
• 首期必须上线的功能、不在本期范围内的内容，以及每项验收用例的通过条件。

前期资料齐全，不代表现场不会再出问题，但能把问题从“等到联调再说”提前变成有人负责、有日期可追的事项。红数科技出正式排期时，通常会设置三个比“完成百分比”更有用的节点：样板车道完整跑通、全部车道和平台联通、试运行问题关闭。设备到场很多、页面完成八成，都不能替代这三个结果。