纯软件的部分测通了，接上设备才发现问题一堆。这类项目延期，多半延在硬件这一环，而且延期的原因往往不在开发方和甲方的任何一个手上。
把硬件当成项目里的独立环节来对待，提前暴露问题，是减少这类延期的主要办法。
一、第一类麻烦，设备本身和驱动
同一个型号的设备，不同批次的固件版本可能不一样，通信协议有细微差别。软件按 A 批次的设备调通了，B 批次装上去不认。这种情况在采购分批到货时特别容易出现。
规避做法是在开发之前就把最终要用的设备确定下来，拿到实物。不要用样品调通了就开发，也不要拿到的是经销商演示机而实际采购的是另一个型号。
还有一类是驱动只支持特定系统或者特定位数。老设备配新系统，或者 64 位系统上装 32 位驱动，都可能出问题。选定设备之后，先确认它在目标环境下能装驱动、能跑通官方提供的测试工具。
二、第二类麻烦，数据格式和触发时机
软件和设备的对话方式要谈清楚。是软件主动去读设备，还是设备有数据了主动推给软件。前者叫轮询，实现简单但有时延，也可能漏掉瞬时事件。后者响应快，但需要设备支持，还要处理网络中断时的重发。
数据格式的细节最容易埋雷。比如重量读数，设备给的是一串字符，软件怎么知道哪几位是重量、单位是什么。再比如打印指令，不同品牌的打印机指令集不同，换一个牌子就要重写。这些都要在开发前拿到设备的通信说明文档。
触发时机也要约定。刷一次卡可能连续上报三条记录，软件是按一条处理还是合并。这类问题不提前约定，联调时会反复试错。
三、第三类麻烦，现场环境
实验室里一切正常，装到现场就出问题。常见的有几类。网络到不了设备所在的位置，或者信号不稳。设备所在位置没有电源插座，或者电压不稳。现场温度、粉尘、水汽影响设备工作。
还有一类是布线。设备和电脑的距离超过接口标准支持的长度，信号衰减导致时通时断。这种情况在串口设备上很常见，超过一定距离就必须加转换器或者走网络。
这些问题的共同点是，都需要在采购和施工阶段解决，软件层面无能为力。所以现场勘察要在项目早期做，把设备位置、供电、网络、走线路径都确认一遍，有问题提前改方案。
四、怎么把风险压下来
建议在项目计划里单独列一个硬件环节，包括设备选型确认、实物到位、连接测试、现场安装、联调五个节点，每个节点都安排时间，不要挤在项目最后。
同时准备备选方案。如果某类设备的对接实在走不通，有没有替代做法，比如改用人工录入加事后导入，或者换一个品牌的设备。有备选方案，就不会因为一个设备卡住整个项目。
最后一条，采购设备时把技术支持写进要求。让供货方承诺在联调期间提供技术配合，必要时到现场。这一条写不写，遇到问题时的效率差别很大。