2026年，美国RISE8软件开发公司发布《软件工厂2.0》报告，指出了软件工厂1.0存在的问题，并提出软件工厂2.0作为解决方案。作者系公司创始人兼首席执行官布莱恩·克罗格（Bryon Kroger）和增长总监卡洛·维雷，前者曾担任美空军凯塞尔航线（Kessel Run）软件工厂首席运营官。
《软件工厂2.0》封面
1
概要
作者认为，软件正在重塑市场和战争形态。对于美军而言，被颠覆的代价是以生命和国家安全来衡量的，为此美国战争部（DoW）必须成为颠覆者。但是，当前模式并不奏效：94%的联邦IT项目进度滞后或超预算，40%的项目最终一无所成。如今，美军在软件方面具备作战优势，因此必须从根本上改变软件交付方式。软件工厂2.0重新定义了战争部交付任务软件的方式，将这种交付方式视为一种作战能力，而非成本中心。
软件工厂的定义：软件工厂是人员、流程和技术的结合体，为持续交付终端用户喜爱的高价值软件创造条件。它借鉴精益制造、现代DevOps实践和系统思维，最大程度提高流程效率、减少浪费。
软件工厂1.0的问题所在：尽管凯塞尔航线和小林丸的31区（Section 31）软件工厂早期取得了成功，但软件工厂1.0最终失败了，因为战争部通过以下方式系统性地削弱了其能力，包括：使命弱化、领导层更迭、繁琐的技术强制要求、自建平台的干扰，以及官僚主义导致倒退到传统的采购、层级制和决策模式。
软件工厂2.0旨在解决的问题：软件工厂2.0旨在重构制度，通过建立确保创始人模式延续性的制度，聚焦任务价值流，强制执行“未部署运行即未发生”的问责制以降低运营风险，可防止产生1.0面临的组织僵化问题。
三大核心要务：软件工厂2.0将需求制定、资源配置和采购统一为单一的、以成果为导向的敏捷模式，并与最新政策保持一致。这一新模式打破了传统孤岛，以最快的学习速度（而非完美预测）为优化目标。
软件工厂1.0的系统性失败提供了制度层面的经验教训。软件工厂2.0为构建未来数字化兵力提供了蓝图，通过使每个体系职能与任务价值流对齐，并强制执行基于成果的问责制，从而持续交付作战人员喜爱的、有影响力的软件。软件工厂2.0将支撑美军部队实现“今夜就战”。
2
软件工厂1.0存在的问题
软件工厂1.0证明，当免受官僚主义干扰时，美国战争部能够以任务所需的速度交付安全、高影响力的软件。凯塞尔航线和31区都以过去难以企及的速度，实现了任务效能。
（1）案例分析
①美国空军凯塞尔航线（2017-2019年巅峰期）
凯塞尔航线是美战争部首个软件工厂，专注于空中作战中心任务软件开发。
首创持续运营授权（cATO），成为战争部首个在保密IP路由网（SIPRNet）上实现面向作战任务的持续交付的机构；
完成了5个应用的部署，从概念到作战部署平均仅用124天；
将目标开发周期缩短85%（从38分钟降至6分钟）。
②美国太空军31区（2019-2021年巅峰期）
31区是美国太空军首个软件工厂，旨在为联合太空作战中心交付能力。
将8个应用投入运行平均仅用64天；
将合取分析从3小时缩短至15分钟。
（2）导致衰退的制度性原因
早期的成功未能抵御体制惯性。同样的可重复、可避免的模式削弱了两个软件工厂的能力：
使命弱化：团队被拉入无关任务（如F-35自主物流信息系统（ALIS）、五角大楼强制技术迁移、提供体系服务）；
领导层更迭：整个执行团队每2-3年轮换一次；
团队人员流动：派驻政府人员每1-2年轮换一次；
自建平台干扰：浪费5年以上时间和1亿多美元构建不如商用现货产品（COTS）的替代方案；
采购模式倒退：从基于成果的合同转向传统人员扩充合同；
政治干预：以预算存续而非任务需求为优化目标开展决策；
合同适配性差：使用缺乏现代软件交付专业知识的采购与援助服务（A&AS）承包商。
（3）经验教训
每一次失败都对应着一个教训，为软件工厂2.0提供参考：
一个组织一项使命：若分散到多个任务中，即使是高效的团队也会遭遇失败；
保持创始人模式的连续性：保留创始团队8-10年；
限制并聚焦建制开发：在军种全面投资建制开发商之前，依据结果导向型合同来利用承包商资源，并将建制开发聚焦于边缘创新，理想情况下使用成熟的商用现货平台；
租用>购买>自建：使用商用现货平台；专注于任务能力；
优化全价值流：交付、采购和运营必须作为一个整体运作；
任务优先的决策：衡量任务性能，而非IT指标；
任务成果优先：追踪任务有效性指标（滞后指标）和通过基于成果路线图的进度里程碑（领先指标）情况；
最大程度降低运营风险：尽早且频繁执行“未部署运行即未发生”问责制；
重构供应商选项：专门构建成果导向型合同。
软件工厂1.0的失败是制度导致的，未来的成功取决于重新设计制度体系。
3
软件工厂2.0简介
软件工厂2.0是一种以成果为导向的运营模式，旨在持续交付对任务产生影响的软件。其核心原则是以最快学习速度为优化目标，而非完美预测。在快速演变的威胁环境中，通过持续交付软件进行感知和响应的能力，比任何静态的预批准产品套件都更重要。软件工厂2.0的目的并非敏捷改革，而是围绕学习、去中心化和可衡量的任务影响进行制度重构。在一个向来由产出（如需求文档、预算拨款、合同授予）驱动的体系中，必须改变指标。
可通过以下方式来衡量软件工厂2.0是否成功：
持续交付：将各种变更情况安全、快速、可持续地应用到生产中的能力。通过DevOps研究与评估（DORA）进行衡量，包括部署频率、变更前置时间、变更失败率、失败部署恢复时间和可靠性；
高价值的软件：通过关键任务指标衡量任务影响；
用户体验：通过用户成果和净推荐值衡量。
如果未投产，就等于没有发生；如果未能改善任务，就等于没有奏效。降低风险的唯一途径是由目标用户按预期用途将软件投入运行。除此之外，其他一切都是风险。但要通过这些指标取得成功，需要在控制构建内容、资助方式和交付方式的各个系统层面进行改革。软件工厂2.0将通过需求制定、资源配置和采购三大核心要务解决这一问题。
（1）三大要务
为了在战争部范围内规模化交付软件，软件工厂2.0不仅需要改变软件构建方式，还需要改变体系界定、资助和采购软件的方式。高层领导可通过三大杠杆来实现持续交付和可衡量的任务影响。
1）全新的需求制定方法
战争部当前的需求流程奖励机制偏向预测能力而非自适应能力。多年度预测导致团队固守在不成熟的解决方案中，致使调整方向成本高昂且推进缓慢。
软件工厂2.0将需求重新定义为识别任务约束并消除约束的持续的过程。
以实时发现运营痛点取代多年度预测需求；
使用价值流映射（VSM）和领域驱动设计（DDD）定义任务存在的问题，促使团队能够独立运作，并执行用户旅程映射以深入理解人机流程交互。成果导向的合同需求必须由此衍生才有效；
将软件交付团队与任务价值流（而非系统或平台）保持一致，并授权团队在明确定义的任务领域内自主交付，瞄准任务影响指标；
以任务式指挥为核心构建软件组织；通过清晰的意图和约束（而非详细指令）下放权力。
这种模式不要求团队预测未来需求，而是要求他们找出导致任务推进缓慢的原因并解决。需求并非功能列表，而是已部署运行的软件可量化的成果。
实践案例：与其预测一个为期五年的“目标瞄准系统”的需求，不如识别其瓶颈（目标审批需要3小时），设定目标（将目标审批缩短至30分钟），然后授权团队解决问题。
在凯塞尔航线软件工厂中，这种方法在不到六个月内将目标开发时间从38分钟降至6分钟。
2）全新的资源配置方法
僵化的资金来源规则和多年度预算周期对团队的约束超过了代码本身。软件失败并非因为资金不足，而是资金分配方式导致的。
软件工厂2.0用基于能力的投资方式和以成果为导向的重新分配方式取代基于项目的拨款，根据成果而非预测为团队提供资金。
为持久的团队能力，而非个别需求提供资助；
采用三地平线模型平衡确定性与探索性投资：
-地平线1占75%：已交付的成熟能力；
-地平线2占15%：具备规模化发展条件的潜力原型；
-地平线3占10%：高潜力、颠覆性增长选项；
使用风险投资模式的季度增长委员会根据有效情况重新分配资金，终止无效项目；
这种方法通过防止投入过多资金研发尚未证明价值的软件来降低风险，并为下一次突破创造空间。
实践案例：以基于能力模式资助的小型高杠杆团队取代大额多年度拨款方式。与其为五年期的“太空域感知能力”拨款5000万美元，不如资助3个8人团队，每年700万美元。通过与任务影响挂钩的季度审查来决定是否扩大、维持或重新分配资金。
3）全新的采购方式
大多数软件采购仍遵循伪敏捷模式，即中间阶段采用敏捷方式，开始和结束阶段仍是官僚主义方式。传统合同结构单一、僵化、以合规为导向，与软件交付根本不匹配。
软件工厂2.0呼吁以成果为导向的采购，促使交付与任务能力保持一致，并能够针对用户不断变化的运行环境做出快速、灵活的响应。这需要：
使用满足以下条件的合同取代传统采购：明确定义并分阶段衡量关键任务指标的任务效能提升情况；在明确界定的任务领域内灵活执行合同（如合同选项）；
使用其他交易授权（OTA）、联邦采购条例第12/13部分和小企业创新研究第三阶段等工具支持快速采购；
围绕任务价值流及其领域驱动设计定义的界限（而非组织结构图）构建合同，并从中衍生需求和交付物（即交付物是首要任务指标改善的证据）；
优先采用交付团队模式而非人员增补，以建立所有权、连续性和产品成熟度；
在可行范围内尽可能优先使用商用现货构建和交付，使交付团队能够专注于任务价值而非无差异化的繁重工作。
目标是通过适应性、增量性、以能力为中心的交付方式来扩大影响范围并提高任务效能。
实践案例：签订附带选择权的合同，选择权与相邻任务领域的任务指标（成果）挂钩。当团队在最初几个领域展示出所界定任务指标的性能时，即授予后续合同以扩大范围。构建团队在边界内自主运作，通过文档完备的应用程序接口（API）而非承包商协调进行集成。独立替换失败的组件，而不干扰整个系统。
（2）任务导向的交付框架
软件工厂2.0通过去中心化的自主团队整合任务运营、以用户为中心的设计和软件交付方式，这些团队与明确影响指标的任务价值流保持一致，最终形成一种“未部署运行即未发生”的方法。该框架在决策制定、组织结构和技术架构三个层面实现去中心化控制。领导层将决策推向边缘，授权小型团队主导最终成果，并使用分布式服务取代集中式遗留系统。通过领域驱动设计，团队在界限内自主运作，实现灵活集成并使协调成本降至最低。
核心原则是由小型经授权的跨职能团队全面负责产品的全生命周期，从用户调研到生产运维均由该团队承担。政府牵头制定任务价值流战略，而承包商牵头针对界定的指标进行规划和交付成果。两者作为一个团队协同运作，与同一成果导向的路线图保持一致，并可追溯至团队层级的待办事项。
两个团队类型构成交付支柱：
价值流对齐团队在界限内构建任务能力；
平台团队提供实现持续交付的基础设施和服务。
两个核心组织单位负责完成以任务为导向的交付：
面向任务需求，价值流经理通过价值流映射识别任务限制并定义值得解决的问题（可能是能力开发文档任务）；
软件交付组织（软件工厂2.0）快速构建和部署解决限制的方案。
这种结构通过消除运营、采购和软件开发之间的隔阂来加速交付，实现更快的学习、更紧密的反馈循环和规模化的持续敏捷性。
4
重振软件工厂
软件开发如今是作战要务。软件工厂1.0证明，在美国战争部内部持续交付用户喜爱的高价值、安全的软件是可能的，而它的失败是执行方法所导致的。软件工厂2.0提供了正确的蓝图，使用体系重构取代流程改革，聚焦三大要务：
（1）围绕界限约束和关键任务成果重新定义需求；
（2）使资源配置与团队能力和演示成果保持一致；
（3）推行现代化采购方式，优先考虑持续交付方式并提升任务效能。
当与正确的组织机制相结合时，这种模式行之有效。任务导向的团队、基于成果的问责制和去中心化控制能够在整个价值流中实现更快学习和交付。
声明：本文来自防务快讯，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
