售货机软件系统周期怎么估算，哪些环节最容易影响进度?

售货机软件问工期，最容易得到的回答是“两个月左右”。这个数字有时能用，有时会把项目带进麻烦里。若设备厂家已经提供稳定的控制协议和样机，首期只接一种机型、一个支付主体，功能也收得住，两个月做出试点版本并非没有可能。可要是机器还没定，货道控制靠现场试，支付、退款和库存规则边做边改，同样两个月，可能只够把主流程跑起来。

红数科技估算这类项目时，先不数页面，而是先拿一笔真实交易往下走：顾客选商品，系统锁定货道，付款完成，机器执行出货，传感器返回结果，订单改成完成，库存减少，经营后台和补货端都看到同一条记录。中间任一步失败，后面由谁判断、怎么退款、能不能重试，也要说清楚。工期就在这些动作里，不在原型图上。

先说结论：常见周期大致落在哪

下面的区间用于项目立项前估算，不是脱离需求就能承诺的固定交付日期。计算口径包含需求确认、设计、开发、联调、测试和小范围试点；不包含硬件重新开模、控制板重做、支付主体审批长期等待以及大规模铺机施工。

同样是 100 台机器，未必比 1 台多开发十倍；如果 100 台使用同一机型、同一套配置，增加的更多是容量、监控、批量配置和运维验证。反过来，只有 1 台机器，但控制板资料不全、每个指令都要到现场试，它也可能成为整个项目里最慢的一台。

工期不是一条线，几组工作会同时进行

售货机软件通常至少有四部分。机器端负责商品展示、选择、支付提示和出货控制；云端保存设备、货道、商品、订单、库存、支付和告警；运营后台负责定价、上下架、点位与人员权限；补货人员还需要在手机端完成开门、盘点、补货和异常上报。若企业已有 ERP、仓库系统、会员体系或财务系统，数据还要在几套系统之间来回核对。

因此，比较靠谱的排期不会写成“页面设计完再开发，开发完再联调”。界面、后台和设备接入可以并行，但有几道关口必须按顺序过：

• 1—2 周把首期范围、机型、角色、订单状态和验收口径定下来；
• 1—3 周用真实样机验证开机、心跳、选货、出货、结果返回和故障码，不等整套系统做完才碰机器；
• 4—7 周并行完成机器端、云端、运营后台和补货端的首期功能；
• 2—3 周专门跑支付、退款、断网、超时、卡货、重复通知、库存不一致等异常；
• 2—4 周放到少量真实点位试运行，观察网络、温度、补货动作和机器长期在线后的问题。

这些数字可以交叉重叠，不能简单相加。真正需要防的是前一项没有结论，后一项已经大面积铺开。比如订单状态还没定，机器端、后台和报表各自先写一套，等联调时才发现“付款成功”和“出货成功”被当成了同一件事，返工会同时落到三端。

最容易影响进度的，是下面几件具体事情

样机晚到，或者设备协议只有一份说明书

设备厂家给出接口文档，不等于接口已经能用。项目至少要确认控制板版本、通信方式、指令格式、超时时间、故障码、出货检测方式以及远程升级能力。同一个“出货成功”，有的设备表示电机转过，有的表示传感器检测到商品掉落，两者对应的退款规则完全不同。

最稳妥的做法，是正式排期前拿到量产版本样机，先做一个很薄的技术验证：连续下发指令，模拟断网和重连，故意制造空货道或卡货，看机器返回什么。这个验证多花几天，通常比项目后期带着整套系统到现场猜故障省时间。

把支付成功当成交易完成

顾客付了钱，机器不一定已经出货；机器出了货，支付通知也可能因为网络延迟晚到。系统需要分别保存支付状态、出货状态和退款状态，还要能识别重复通知，避免同一笔订单重复出货或重复退款。

微信支付和支付宝都要求商户侧按各自接口规范处理签名、证书或密钥、异步通知与查询。这里不只是“接一个二维码”。商户号、应用、回调地址、证书配置、测试资金和财务核对都要有人提前准备。技术开发做完后才开始申请账户，日历时间往往会空耗在等待和补资料上。

商品、货道和库存的关系没定

运营人员习惯说“这台机器还有 12 瓶水”，系统却必须知道是哪一个商品、哪个规格、放在哪台机器的哪个货道，补货前后分别是多少。换货、移货、临时下架、盘亏和过期报损也会改变库存。

商品编码越早统一，后面的订单、库存和报表越省事。GS1 对 GTIN 的定义是用于唯一标识贸易项目；企业是否直接采用 GTIN，要看现有商品体系，但“一种可售规格只有一个稳定编码”这条原则最好在开发前定下来。否则，同一瓶饮料在采购表、后台和机器端出现三个名字，联调时很难判断究竟是哪条数据错了。

异常处理到测试阶段才讨论

正常购买通常很快能跑通，真正占测试时间的是不正常的时候：付款后断网、设备忙、货道空、商品卡住、顾客重复扫码、支付平台重复通知、运营人员补货时机器离线。每一种情况都要落到可执行的结果，不能只显示“操作失败”。

至少要回答四个问题：订单最终是什么状态，库存扣不扣，钱由系统自动退还是进入人工复核，后台留下哪些日志。涉及账户、支付、设备控制和管理后台时，安全测试也不能排到上线前一天。OWASP ASVS 的用途正是为现代 Web 应用和服务提供可验证的安全要求清单，它适合转成项目自己的检查项，而不是原样贴进验收表。

试点点位没有真正参与验收

办公室里的稳定 Wi-Fi 不能代表商场地下层、医院走廊或工厂车间。真实点位还会带来弱网、断电重启、屏幕反光、温度变化、补货时间受限和人员交接。测试人员可以模拟其中一部分，但不能替现场运营人员判断补货顺不顺手、告警有没有人处理、退款记录财务能不能看懂。

首期最好先选少量有代表性的点位，连续跑过一个完整补货和对账周期。这里发现的问题往往不大，却很实在：货道编号与机身贴纸对不上、补货端需要多点几次、机器重启后订单恢复不完整。它们若在批量铺机后才出现，修复本身未必慢，逐台确认和协调现场才慢。

怎样把周期估得更接近实际

先把“上线”说清楚。能演示购买流程、能在一个点位试卖、能让运营团队日常补货，以及能批量管理几百台设备，是四个不同的完成状态。双方若使用同一个词、心里想的却不是同一件事，任何工期数字都不可靠。

接下来不要先列功能名称，先列首期必须跑通的场景。至少包括一次正常购买、一次出货失败退款、一次断网恢复、一次补货盘点和一次日终对账。每个场景写清参与人、设备、前置条件、数据变化和最终可核对的结果，需求是否缺口会很快暴露出来。

对机型协议、支付接入、外部系统这些不确定项，单独安排前置验证，并给出截止日期。验证通过后再锁定详细计划；验证没有通过，就明确更换方案、缩小首期范围或延后，而不是把未知风险悄悄塞进开发工期。

项目计划还应区分“工作量”和“日历时间”。支付平台开户、样机运输、现场施工和第三方接口确认不一定占开发人员很多工时，却会让项目停在那里。红数科技在给出正式排期时，会把这些外部等待单列出来，再根据未验证事项的多少留出风险时间。常规项目可先按基础周期的 15%—25%预留；机型和接口尚未定型时，单纯加缓冲不够，应先完成验证再报价、排期。

立项前能准备好的资料

如果准备启动售货机软件项目，下面这些资料比一套很完整的效果图更能缩短周期：

• 确定首期机型、控制板型号、通信协议、SDK、故障码和至少一台可长期联调的样机；
• 明确商品、规格、货道、价格和库存的对应关系，准备一份真实商品数据；
• 确认支付主体、商户号、应用、退款权限、结算账户和对账负责人；
• 写清出货失败、重复支付、退款失败、断网恢复和人工复核的处理口径；
• 列出必须对接的 ERP、WMS、会员、发票或财务系统，并确认由谁提供接口和测试环境；
• 选好试点点位、网络条件、补货人员和验收人员，提前约定什么结果算首期通过。

资料不必一次做到漂亮，但关键决定要有人负责，缺失项要有明确时间。售货机项目真正可控的标志，不是计划表排得多紧，而是每一笔钱、每一次出货、每一件库存发生变化后，都能在系统里找到同一份说得清、对得上的记录。

参考资料：

• 微信支付商户文档中心：Native 支付产品介绍、支付回调和查单实现指引，核对接入准备、支付通知与主动查单要求。
• 支付宝开放平台文档中心，核对当面付、交易查询、退款和异步通知要求。
• GS1：Global Trade Item Number（GTIN），核对贸易项目唯一标识的定义。
• OWASP Application Security Verification Standard，核对 Web 应用与服务的安全验证要求；当前页面提供 ASVS 5.0.0。