快速交付之后谁来持续支持产品

JED 2026年4月访谈深读｜用户反馈、采购节奏与小团队的保障能力

用户指出界面不好用，开发者当场理解并愿意修改，这种直接交流确实能缩短反馈距离。但从“可以改”到“稳定交付”，再到几年以后仍然有人维护，中间还有不同的问题。讨论国防技术的速度，不能只观察最显眼的那次演示。

JED四月号新设的“Across the Spectrum”栏目，以John Haystead对CX2联合创始人兼首席执行官Nathan Mintz的访谈开篇，原文位于第18—20页。[1] Mintz主张借鉴商业产业的迭代方式，同时承认复杂硬件和长期支持仍是难题。本文沿着这条张力展开：哪些时间可以减少，哪些工作需要重新组织，以及受访者的倡议能够得到什么证据支持。

一 受访者希望改变的是交付激励

原刊介绍，Mintz先后在Raytheon与Boeing从事射频系统相关工作，后来参与创立Epirus，又进入汽车雷达领域创办Spartan Radar。这些经历为他比较传统国防企业与新创公司的做法提供了背景。但访谈表达的仍是他的经验和判断，不是对整个行业的抽样调查。

文章把将软件开发速度与规模化交付相联系的新型承包商称为“neoprime”。这个称呼首先表达产业定位，不能单凭名称判断企业已经具备完整主承包能力，也不能与法规中的“非传统国防承包商”资格直接画等号。前者描述商业模式，后者有专门定义。

Mintz对传统结构的批评很尖锐：组织可能更关注维持规模和工作量，而不是尽快把成果交给使用者。其有价值之处，在于提醒读者观察激励如何影响行为。项目是否奖励交付，是否及时获得用户反馈，比企业把自己称作新型还是传统更值得追问。

但原文将成本增加与费用收益增长直接联系起来的说法，不能推广到所有成本补偿合同。FAR 16.306(a)对成本加固定费用合同的说明是，固定费用不随实际成本自动变化，工作范围发生变化时则可能调整。[3] 这里仅用条文纠正概括范围，不据此评价某家企业，也不把访谈当作合同操作指南。

将动机分析与具体制度分开，才能保留评论的锋芒而不丢失准确性。我们可以讨论程序是否造成了不必要的等待，却不能据一段采访认定所有承包商都通过超支增加利润。同样，商业企业也会面对供应、质量和支持压力，采用商业思维并不意味着这些约束自然消失。

二 三种时间不能放在同一把尺子上

图1　编辑把需求反馈、软件验证、生产保障分开说明。此图用于澄清时间口径，不是原刊流程图，也不代表各阶段必须顺序执行。

访谈最容易引人注意的数字，是Mintz对乌克兰约30天采办观察周期的描述，以及某些软件一天更新多次的观察。他据此主张，把部分交付安排压缩到五周或十周的节奏。三种说法放在同一段里很有冲击力，但它们没有测量同一件事。

30天是他对观察、判断和行动循环的概括；一天多次指部分软件层面的连续集成与部署；五至十周则是对交付节奏的主张。原文没有给出统一样本、起止事件或验收条件，不能把它们组合成一个适用于所有项目的效率提升比例。

编辑用图1作进一步区分。需求反馈时间回答“用户的问题何时被理解”；软件与验证时间回答“修改何时形成可确认的结果”；生产与保障时间回答“产品何时能持续供给和支持”。缩短其中一个环节有实际价值，但不能自动代表另外两个环节同步完成。

以一个民用仪器的假设为例，工程师当天改好了显示单位，可能解决了一个明确的问题；如果修改还影响报告导出，团队就需要确认两处表达一致。如果同时要换传感器，交付又会涉及采购、装配与验证。这个假设只说明变更范围不同，不能用来估计任何军用系统的具体工期。

原刊也保留了Mintz的自我限定：小型无人机载荷与协同作战飞机、大型卫星，复杂程度并不相同，快速模式能否同样扩展尚待观察。因此，真正值得学习的是尽早获得反馈和减少无效等待，不能从小载荷案例跳到所有复杂系统都应采用相同周期。

三 Project G.I.把成熟方案和使用者联系起来

图2　原刊第19页照片，署名US ARMY。按原刊图注，2025年6月，第75游骑兵团第2营人员在华盛顿州刘易斯—麦科德联合基地演训中准备放飞小型无人机。此图不是CX2产品测试或Project G.I.项目现场的证明；原刊图片分辨率为459×307像素。

Mintz在访谈中提到，CX2参与Project G.I.并与第75游骑兵团人员直接交流。使用者能够把界面需求交给开发团队，他以此说明减少沟通中间环节的价值。这些具体合作和界面调整经历，应当明确归于受访者叙述，不能只凭配图就当作独立核验的测试结果。

DIU于2025年6月2日发布的原始公告，能够确认该挑战的基本设计：较早引入最终使用者的测试、评估和反馈，关注成熟度较高、适合快速适应需求的方案。[2] 因而这一机制本身已经包含“方案较成熟”的前提，不是让任何早期想法在短时间内直接成为可用产品。

金额也需要说清楚。公告中的2000万美元是分布在三个设计参考任务中的奖金池，而非CX2单独获得的合同金额，更不能据此声称款项已经全部支付。原刊称其为一个2000万美元项目，导读时补回这一口径，有助于防止读者把计划规模误当成某家公司收入。

直接接触使用者可以减少需求被反复转述后的失真。不过，这种交流获得的是更清楚的问题，并不天然等于修改已经被验证。对“调整屏幕”的例子，是否影响其他使用者、是否改变信息含义、是否需要更新培训内容，仍是合理的后续问题。这里是编辑分析，不是对CX2流程的实际审计。

把试用意见尽早带回研发，与跳过所有验证，是两种不同的叙述。访谈强调前者的速度收益，阅读者还应关注修改之后留下了什么证据。一个简洁的演示可以证明某个功能能够运行，却不能替代对长期稳定性、不同版本兼容性和规模化支持的说明。

四 小团队真正需要扩展的是组织能力

Mintz提出的另一个问题，是十人的公司怎样承担过去由庞大组织完成的工作。他把可重编程软件、可适应硬件和新工具视为可能的帮助。这里的十人与一万人是说明差距的表达，不是经过测量的人员替代比例，更不能当作人工智能已经实现的生产率结论。

软件确实是他主张的重要载体，因为一部分功能可以通过修改已有产品持续变化。但从编辑角度看，可更新不等于能够永远更新。团队需要理解过去交付了什么、哪些版本仍在使用、哪些变化影响已有客户。否则，更快发布也可能意味着积累更多难以解释的差异。

假设一个小型工业软件团队只有一名熟悉关键模块的工程师，交付速度可能暂时很快；当这名人员离开或转向其他工作，维护能力便会受到影响。这个民用假设说明，“组织能力”包含知识能否被其他人接续，而不仅是当下能否写出新功能。

因此，减少文书负担要与删除必要记录分开。访谈批评过重的文档体系，并看好新工具用于配置管理和原型开发。能够省去重复录入、帮助团队理解版本关系的工具，与让所有知识只存在个人记忆中，并不是同一种效率改进。

对小团队来说，交付越成功，支持对象通常越多。新的客户反馈、旧版本问题和下一代研发会争夺同一批人员的时间。原文承认“板凳深度”问题尚需解决，这恰恰是访谈的重要信息：轻量化组织可以带来速度，但持续服务能力仍需要在成长中建立，不能只靠创业初期的投入强度维持。

五 硬件交付会把商业模式带到现场

Mintz明确说，硬件比软件更难，尤其是产品已经交到现场之后。他引用Tesla的车队、维护和销售模式作为商业类比，希望启发国防企业重新思考市场进入方式。这段话提出的是探索方向，没有提供足以证明汽车模式可以直接迁移到国防采办的对比研究。

硬件问题之所以更容易暴露在现场，是因为修改可能要求实物、运输、人员和停机窗口共同配合。这个一般性的编辑判断不需要假设某种具体装备的结构。哪怕一个修改只涉及可替换部件，也仍须有人取得部件、完成更换并理解其状态，无法仅用软件发布频率说明成本。

如果讨论“扩产”，也要区分样机重复制造、批次交付和长期补充能力。访谈称新型承包商正在扩大生产并争取规模化合同，这是受访者对产业趋势的观察；原文没有附完整合同清单或跨公司的产能数据，因此不宜把它转成所有新创企业已经跨过量产门槛的结论。

下面的比较表是编辑整理的阅读方法。它把不同证据对应的问题分开，而不是为企业设立统一评分表。看见一份合同、一段现场演示或一次软件更新时，我们可以先承认它们各自的意义，再追问尚未说明的后续条件。

表1 从不同证据理解交付进展

六 企业成长与资格定义需要分开阅读

访谈建议让报告、审计和合规要求更加适应企业成熟度，并批评一些创新者在扩大业务时遭遇制度负担。这个问题值得讨论，因为小团队的固定管理工作可能与研发争夺有限资源。但“非传统”在文中既有日常语言意味，也涉及特定资格，二者不应混用。

以美国法典2023年版第10编第3014条为例，其定义涉及企业当前及征集前至少一年期间内，是否承担适用完整成本会计准则覆盖的相关合同或分包，而不是直接按员工人数或营业收入划线。[4] 这一历史条文只用于解释概念差别，不代表对任何企业在2026年的资格判定。

因此，Mintz所说成长过程中失去资格，应保留为他的制度批评，不能简写成“公司变大便自动失去资格”。同样，建议改革不等于改革已经完成，认为合规负担过重也不等于这些要求可以被自行免除。把这些边界写清楚，能够使产业观察免于被误读为办事规则。

编辑更关注的，是文章提出的比例关系：投入到理解需求、制造、试验和支持的资源，是否被低价值的重复工作挤占。要判断具体项目，需要知道实际任务、要求和成本，不能只比较文件数量。少写一份重复表格可能减少负担，少留一份关键版本记录却可能增加未来维护困难。

这种分析也避免把规模大小变成价值判断。大型企业可以改进反馈方式，小型企业同样需要建立责任与支持能力。访谈提供了创业者对摩擦的观察，最终能否形成更好的交付方式，仍应由具体结果来说明，而非由企业自我归类来决定。

七 快速演进不能代替知识产权保护

最后一部分，Mintz把持续演进视为维持竞争力的重要方式。他认为，产品如果长期停留在最初形态，即使曾经很先进，也可能在真正使用时已经落后。这一判断回应了整篇访谈的速度主题，但原文同时明确承认知识产权、关键项目信息和政府保密信息需要保护。

因此，不能把“跑得更快”改写成保密措施没有必要，也不能把技术保护仅能争取时间的评论写成对所有保护措施有效期的实测结论。创新节奏与信息保护回答不同问题：前者关系到产品如何持续变化，后者关系到哪些信息需要受到控制，两者不能在文字上互相替代。

从编辑视角看，持续更新与可持续维护也应一起讨论。一个团队能否让未来接手的人理解今天的选择，能否解释不同版本为何变化，会影响产品能否继续进步。把关键知识都锁在个别人头脑中，即使短期发布速度很高，也未必建立了能够长期演进的企业能力。

这篇访谈最有分量的部分，是它一边推动交付提速，一边承认扩展到复杂系统与现场保障仍有困难。与其把它读成新企业必然替代旧企业的宣言，不如把问题落在一项具体承诺上：当产品交到用户手里之后，谁能持续理解问题、解释变化并提供支持。这个答案，决定快速交付能否成为长期有效的能力。

资料来源与说明

[1] John Haystead. A New Paradigm for Defense Technology Acquisition and Fielding. JED, April 2026, pp.18–20.

[2] DIU. $20M Project G.I. Challenge公告，2025年6月2日。

[3] 美国联邦采购条例FAR 16.306(a)，FAC 2026-01。

[4] United States Code, 2023 edition, Title 10, §3014.