📚 智能硬件PM学习日报 | 2026-09-12
🎯 今日主题：敏捷开发在硬件中的应用——「Agile-Stage-Gate 混合模型」
一、概念：为什么硬件不能照抄软件敏捷
2001年的《敏捷宣言》四条价值观（个体与互动高于流程与工具、可工作产品高于详尽文档、客户合作高于合同谈判、响应变化高于遵循计划）诞生在软件领域。软件改一行代码成本≈0，硬件改一个结构件可能意味着：模具报废（几万到几十万）、长交期物料重订（4~16周）、认证重测（SRRC/FCC/CE）。所以纯Scrum硬搬过来必然翻车。
行业给出的答案是 Agile-Stage-Gate（A-SG，敏捷—阶段门混合）：宏观用阶段门把关，微观用冲刺迭代。这与你已学的IPD其实是同一逻辑的两种表达——IPD的DCP决策评审点相当于Gate，TR技术评审相当于Stage内的检查。
｜层级｜机制｜硬件里对应什么｜
｜宏观｜Stage + Gate｜IPD的DCP/TR评审、立项、EVT/DVT/PVT放行｜
｜微观｜2~4周Sprint + 站会 + 回顾｜固件、APP、算法、结构子模块、仿真验证｜
二、核心要点（硬件的5条「本地化」改造）
- 重新定义"Done"：软件的Done=可运行代码；硬件的Done可以是"仿真跑通""3D打印件装配通过""单板点亮"。不必每个冲刺都交付整机——那既不现实也没必要。冲刺交付物按项目风险定制。
- 架构先行，但只到接口层：硬件敏捷的前提是模块化架构。先把模块接口（机械、电气、通信协议）冻结，各模块团队并行冲刺；不要试图提前设计完每个模块内部细节（巨大浪费），也不要跳过硬架构直接开干（前期快、后期崩）。
- 长交期物料必须提前锁定：敏捷的"响应变化"在硬件里有边界——模具、芯片、定制电机这类Lead Time长的项，要在冲刺规划前就做"提前采购决策"，否则迭代会断粮。
- 用仿真/打样替代"编译"：把软件的TDD、短迭代映射为数字仿真、热仿真、数字孪生、3D打印、快速手板。空间上，这是硬件迭代速度的唯一杠杆。
- 验证阶段不许"敏捷掉"：认证、可靠性与安规测试属于硬门禁，没有"迭代到差不多就上市"这一说。
三、实际案例
- 麦肯锡：某中国B2B供应商新建24个敏捷团队协作，两年内新品平均上市时间缩短20%；汽车/消费电子/医疗设备等领域的转型企业，部分行业上市时间提升达60%。
- 德州仪器（TI）：用Scrum加速定制IC开发。原交付周期12~36个月，团队采用跨职能团队、4周迭代、相对估算、每周2~3次站会、每迭代交付可用硬件、迭代回顾。难点正是"迭代周期短于制造周期"——他们的解法是让每个迭代交付可验证的技术成果而非成品芯片。
- Tetra Pak（2025，Cooper等人研究）：制造业公司如何把A-SG落地并持续演进其产品开发流程，验证了混合模型在成熟制造组织中的可行性（Robert G. Cooper的Agile-Stage-Gate系列研究）。
- 瑞典制造商案例：A-SG混合模式使开发提速约30%，同时团队士气与满意度上升——说明敏捷不只是效率工具，也是组织手段。
四、落到你的无人机/机巢场景
- 一个"无人机+自动机场"项目天然适合混合打法：飞控固件、地面站APP、云平台、AI识别算法走2周Sprint；机巢结构、自动换电/充换电机构、模具件走阶段门+长交期锁料；1.4GHz自组网图传、水域增强成像载荷这类新研模块，先并行做技术预研冲刺（Spike），命中后再并入主线。
- 平台化是敏捷的隐形前提：如果你能做成"一个飞行平台+多载荷接口"（警用五警种正好是这个需求结构），那么新增载荷就是一次"增量迭代"而不是一个新项目——这就是硬件敏捷最大的复利。
- 冲刺规划时别用"功能点"，用可验证的工程证据排序：仿真报告 > 手板实装 > 单板点亮 > 整机联调。谁先把不确定性打掉，谁排在前面。
💡 知识速览
- 敏捷 vs 阶段门，怎么选：需求不确定、软件/算法比重高 → 敏捷；资本投入大、认证/法规刚性、机械模具重 → 阶段门。成熟组织两个能力都建，按项目切片用，而不是二选一站队。
- 假设登记册（Assumption Log）：硬件版的"技术债"。把"电调在大电流下不降频""图传在1.4GHz城市环境下不丢包"这类未验证假设明确记账，每次冲刺挑1~2条去证伪——比"完成90%"这种进度汇报有用得多。
- 价值排序工具（MoSCoW）：Must/Should/Could/Won't，配合硬件冲刺使用。Must里只放"不做就通不过Gate"的项，避免把"想要的新功能"混进Must导致节奏失控。
- SAFe/LeSS的适用边界：规模化敏捷框架用Agile Release Train把多个Scrum团队串到一条价值流上，适合汽车、整机这类大系统；创业团队或单一产品线用纯Scrum+阶段门就够，上SAFe是过度工程。
- 敏捷的组织副作用：敏捷要求团队长期稳定（而不是随项目重组），这往往比流程本身更难——如果团队老是被抽调，先解决组织问题，再谈敏捷。
📌 今日金句
敏捷不是"更快地做完已经想清楚的事"，而是"更快地发现自己想错了什么"。硬件改不动的是模具，改得动的是判断——把判断放在便宜的时候做完。
📎 今日可做的3件事
- 挑项目里一条最贵的假设，写进假设登记册，并约定本周用仿真或手板去验证它。
- 检查当前项目里哪些模块的接口尚未冻结——那才是进度最大的隐藏风险，而非工时不够。
- 把正在推的研发项按"长交期物料"标一遍，凡Lead Time > 迭代周期的，本周先把决策做掉。
（资料源：McKinsey《敏捷不止于软件：加速硬件开发的组织转型》、Altium《大多数敏捷"大师"对硬件开发的误解》、PTC敏捷产品开发、Robert G. Cooper Agile-Stage-Gate 研究、Wikispeed/TI 案例；Google 直连在当前网络环境不可达，已改用可访问检索源。）