02-无人售货柜多端项目研发痛点SaaS/工控固件/小程序版本协同难题三端并行的真实场景无人售货柜这业务看起来就是一个柜子一个小程序实际研发起来你会发现它横跨了三个完全不同的技术域端技术栈跑在哪谁负责SaaS后端Java SpringCloud云服务器后端组安卓工控固件Android RK3399/STM32柜内主控板嵌入式组微信小程序uni-app / 原生小程序用户手机前端组三端背后是三个团队、三套发版节奏、三种测试环境、三份接口文档——这就是无人售货柜项目的协同噩梦。痛点一需求不同步三端各做各的典型场景产品经理跟前端说这版小程序加个商品搜索功能跟后端说接口下个迭代再给跟嵌入式说固件先不改凑合用旧的搜索。结果就是——小程序搜了半天没数据返回因为后端接口还没上固件里的离线商品列表还是上上版的搜出来的商品柜里根本没有。根因需求在三端之间没有统一源头。每端拿到的是产品经理口头传达的二手需求口径不一致。CMMI3里对应的是需求管理REQM 需求开发RD。解决思路是一条需求三端共享同一个需求条目ID拆成三端各自的子任务状态联动更新。后端没做完小程序这条需求状态就不能标完成。痛点二接口定义不一致无人售货柜的接口数量不少随便列举几类商品同步接口后端→固件开门授权接口小程序→后端→固件支付回调接口支付平台→后端柜门状态上报接口固件→后端库存盘点接口固件→后端这些接口如果各自维护在不同地方——后端用Swagger、嵌入式用Word文档、小程序用飞书笔记——一定对不上。真实事故后端把goodsId改成skuCodeSwagger更新了但嵌入式那份Word还是旧的固件请求过来全是404。排查两天才发现是字段名对不上。根因没有统一接口契约管理没有基线变更不通知。CMMI3里对应的是配置管理CM。解决思路接口定义统一在一个地方维护Swagger或YApi每次接口变更走变更流程通知三端负责人确认变更记录入版本库。痛点三测试环境混乱三端测试环境互相耦合后端有dev/test/staging三套环境固件固件版本号自己一套烧录到不同柜子小程序有体验版/审核版/正式版排列组合一下——固件v2.3配后端dev环境可能跑通配后端staging就挂。因为后端staging那天正好在测新接口把旧接口改了。最痛苦的是联调前端等后端接口、后端等固件数据、固件等后端协议确认三方互相等联调窗口卡死。根因环境管理没有基线谁什么时候改了什么没有记录。CMMI3里对应的是项目监控PMC 配置管理CM。解决思路建立联调基线概念——每周固定一天做联调联调前锁定三端版本号联调期间不许任何端私自改代码改了必须走变更。痛点四发布节奏冲突三端发版节奏天然不一致端发版周期审核依赖后端1-2周一次无审核部署即生效固件1-3月一次烧录到柜子需现场升级小程序2-4周一次微信审核1-7天典型冲突场景小程序提交了扫码开门新功能审核审核期间后端把开门接口改了固件还在用旧版协议。小程序审核通过上线那一刻——用户扫码固件不响应后端返回参数不兼容。事故。这种三角错位在无人售货柜项目里几乎每个迭代都上演。根因发布没有统一规划三端各按自己的节奏走缺少跨端发布协调机制。CMMI3里对应的是项目策划PP 度量分析MA。解决思路每个迭代开始时排三端发布日历明确哪天锁定基线、哪天联调、哪天灰度、哪天全量三端对齐后再各自开工。痛点五版本回滚灾难后端出问题回滚很快——上上个镜像拉起来就行。固件出问题回滚——派人到现场重新烧录一台柜子半小时全国几千台柜子……小程序回滚——重新提审核等几天。所以固件和小程序天然惧怕回滚这倒逼一个要求发布前必须充分验证而充分验证的前提是三端联调到位。根因没有质量门禁PPQA没有统一的发布前Checklist。引入CMMI3轻量管理的必要性把上面五个痛点归纳一下痛点CMMI3对应过程域需求不同步RD REQM接口不一致CM测试环境混乱PMC CM发布节奏冲突PP MA版本回滚灾难PPQA你看五个痛点正好对应CMMI3的五个核心过程域——这不是巧合是CMMI3本来就是为多项目协同设计的。小团队不做CMMI3也行但你不做这些事痛点会反复发生每次救火花的精力比做流程还多。CMMI3轻量化的本质就是把救火式研发变成防火式研发。下一篇开始我们逐个过程域展开从需求管理讲起结合无人售货柜业务给出可落地的模板和流程。