做了这么多年项目，我总结出一个规律：物联网项目延期，很少是因为技术做不出来。真正卡住项目的，是五个人为的断点，而且大多在立项阶段就埋下了。
这篇文章面向的是甲方 IT 负责人和项目经理。如果你正在筹备一个物联网项目，或者手上有个项目已经延期了，对照着看能省不少事。
断点一：需求写成功能清单，没写成场景
最常见的需求文档长这样：「需要设备管理、数据采集、告警推送、报表统计、可视化大屏」。
这份清单没法用来做项目。因为它没回答最关键的问题：谁在什么情况下用这个功能，用它做什么决定。
举个具体例子。「告警推送」这四个字，往下拆至少有十几个决策点：
- 什么条件触发告警？阈值是固定的还是按设备型号不同？
- 告警分级吗？一级告警推给谁，二级推给谁？
- 同一个设备反复触发，是每次都推还是合并？合并窗口多长？
- 推送给谁？短信、电话、微信、APP、还是只在平台上显示？
- 推了没人处理怎么办？多久升级？升级给谁？
- 告警恢复了要不要通知？
- 历史告警保留多久？
这些问题在需求阶段不明确，到了开发阶段每一个都要停下来确认。一轮确认三天，十几个问题就是一个月。
前置动作：需求阶段不要写功能清单，写场景。格式是「某某角色，在某某情况下，通过某某操作，达成某某结果」。一个场景一张卡片，甲方业务人员签字确认。
断点二：现场条件没勘察，方案照着模板做
物联网项目有极强的现场属性。同一个「智慧停车」方案，在地上停车场和地下三层车库是两个完全不同的项目。
现场勘察至少要确认这几件事：
| 勘察项 | 不确认会怎样 |
|---|---|
| 供电条件 | 设备装好了发现没电源，要么重新拉线（费用翻倍），要么改电池方案（续航不够） |
| 网络覆盖 | 4G 信号弱，设备频繁掉线，验收时被判不合格 |
| 安装空间 | 设备尺寸装不进去，或者挡住消防通道 |
| 既有系统 | 甲方已有门禁/监控/停车系统，需要对接，但接口文档拿不到 |
| 施工窗口 | 医院、学校、商场有施工时间限制，实际工期只有预期的一半 |
| 管线走向 | 强弱电分离、桥架容量、穿墙打孔审批，每项都能拖一周 |
我见过一个校园项目，方案做完报价 180 万，现场勘察后发现 60% 的点位没有预留弱电管线，需要重新开槽布管，最终造价涨到 260 万，工期延长两个月。
前置动作：报价前必须做现场勘察，输出勘察报告（含点位图、供电方案、网络方案、施工条件说明）。勘察费单独计，别免费做——免费勘察的结果一定是走过场。
断点三：设备选型只看参数，不看交付能力
设备采购是物联网项目里最容易埋雷的环节。选型时看的是参数表和价格，出问题时才发现供应商的交付能力跟不上。
需要重点确认的：
- 供货周期：参数表上写着现货，实际下单要等 45 天。工期就是这么拖没的
- 批次一致性：第一批 500 台能用，第二批固件不一样，协议对不上
- 技术支持响应：设备出问题，供应商多久能到现场？有没有本地服务团队？
- 协议开放程度：设备是不是只能用厂商自己的平台？能不能拿到原始数据？
- 停产风险：型号会不会半年后停产，后续扩容怎么办？
- 备件供应：质保期内的备件是免费换还是收费？备件库存有多少？
前置动作：设备选型阶段要求供应商提供三样东西——近两年的同类项目清单（可回访）、供货周期承诺书、协议对接文档。三样缺一样就换供应商。
断点四：验收标准模糊，最后靠吵架解决
「系统运行稳定」「数据准确」「界面美观」——这类表述出现在验收标准里，等于没有标准。
物联网项目的验收标准必须是可测量、可复现的。举几个可用的写法：
| 模糊表述 | 可验收的写法 |
|---|---|
| 系统稳定 | 连续运行 30 天，设备连接离线率 ≤1%，平台可用率 ≥99.5% |
| 数据准确 | 抽取 50 个点位，与现场仪表读数比对，误差 ≤2% |
| 响应及时 | 设备状态变化到平台显示，端到端延迟 ≤3 秒（P95） |
| 告警有效 | 模拟 100 次告警场景，正确触发 ≥95 次，误报 ≤5 次 |
| 并发能力 | 模拟 1000 台设备同时上报，平台无丢数据、无崩溃 |
这些指标要在合同里写清楚，包括测试方法、测试环境、判定规则。别指望交付时再谈——那时候双方立场已经对立了。
前置动作：合同附件里加一份《验收测试方案》，明确每项指标的测试步骤和判定标准，双方签字。这份文档比技术方案重要得多。
断点五：甲方没有专职对接人
这条听起来不像技术问题，但它是延期的最主要原因之一。
物联网项目需要甲方配合的事情特别多：确认需求、提供现场条件、协调施工、提供既有系统接口、组织培训、参与验收。每一件都需要有人拍板。
如果甲方派的是兼职对接人（比如某个科室的普通职员，手上还有别的活），结果是：
- 需求确认要等一周，因为他要往上汇报
- 现场协调要等两周，因为他调不动施工队
- 接口对接做不了，因为他拿不到既有系统厂商的配合
- 验收组织不起来，因为他不知道该叫谁
前置动作：项目启动会上明确甲方项目经理，要求是能调动资源、能拍板、有固定投入时间的人。同时在合同里写明双方的配合责任和响应时限（比如需求确认 3 个工作日内回复）。
五个断点，一个共同点
这五个断点看起来分散，本质是同一个问题：把物联网项目当成软件项目来做。
软件项目的边界是清楚的，代码写完就完了。物联网项目的边界是模糊的——它包含硬件、网络、施工、既有系统对接、现场运维，每一块都有自己的不确定性。
用软件项目的方法管物联网项目，必然在硬件交付、现场施工、系统对接这几个环节翻车。
一份可用的项目启动清单
把上面的前置动作汇总成清单，立项时逐项确认：
- 需求文档是场景卡片形式，甲方业务人员已签字
- 现场勘察报告完成，含点位图、供电、网络、施工条件
- 设备供应商已提供项目清单、供货承诺、协议文档
- 验收测试方案已作为合同附件，双方签字
- 甲方项目经理已指定，配合责任和响应时限已写入合同
- 既有系统对接方案已确认，对方厂商已承诺配合
- 分期交付计划已明确，每期的可验收成果已定义
七项都确认了再开工。少一项，延期概率就翻一倍。
已经延期了怎么办
如果项目已经在延期状态，建议做三件事：
- 先把可交付的部分交付掉：把项目切成若干独立可用的模块，先交付已经完成的部分，让甲方看到进展，也释放一部分付款
- 把争议点列成清单：所有扯皮的事项写成清单，逐项标注责任方和所需时间，双方确认。模糊的争议会一直拖，清单化的争议能谈
- 重新定义验收边界：如果原验收标准已经不可能达成，主动提出调整方案，用「当前能力 + 后续迭代」的方式重新约定，比硬扛到最后崩盘好
我们接手过几个延期项目做救火，多数情况下技术问题不是主要矛盾，把上面三件事做了，项目就能重新转起来。
聊聊你的项目
如果你正在筹备物联网项目，或者手上有项目卡住了，可以把项目背景、当前阶段、卡点发给我们。我们做过校园、水务、交通、园区几类项目，从立项到验收的坑基本都踩过，能帮你判断哪些是真风险、哪些可以放过去。