使用价值系统图式衡量软件交付中的价值流

全文

1 引言

软件团队受到密切的度量:速率(velocity)、吞吐量、交付周期、部署频率和变更失败率都会被自动收集。然而,这些数字留下了一个问题:团队交付了什么价值,交付给了谁,又付出了多少损失的代价?

本文提出一种回答该问题的方法,即使用价值系统图式(Value System Schema,VSS),这是 Æilus 方法论的建模符号体系,并通过发布于 aeilus.tech 的 VSS Editor 实现。本文是"Æilus for Business"系列的第五篇。本文使用该系列第一篇论文"Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners"(Bolshakov, ÆVRI, 2026)中定义的词汇,不再重复这些定义。将价值作为可度量货币(Æ)的形式化论述见"Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective"(Bolshakov, ÆVRI, 2026)。

本文描述交付型组织如何构建其价值系统的图式,如何将计划价值与已实现价值关联到各个发布版本,如何定位流动阻力和泄漏,如何评估共享的技术节点,以及如何以明确的角色和节奏运行这一循环。本文依据 VMT 公理 A1、A2、A4、A5、A6、A7、A11 和 A13,以及定理 T3、T4、T5、T6、T8、T9、T15、T16 和 T17。本文不包含实测数据。第 9 节中的示例是合成的。

2 交付指标度量什么,不度量什么

交付指标描述工作的运动。速率统计已完成的估算工作量;吞吐量统计已完成的条目数。由 Forsgren、Humble 和 Kim(Accelerate, 2018)推广的四项关键指标,即部署频率、变更交付周期、服务恢复时间和变更失败率,描述了交付管道的速度与稳定性。该研究将这些能力与组织绩效联系起来,本文对此并无异议。本文的主张更为狭窄:这些指标描述的是管道,而不是流经管道的价值。

由此产生三个缺口。

• 工作量不等于价值。一个速率很高的迭代可能交付了无人使用的功能。用产品价值系统(Product Value System)演示文稿的话说,"功能不是价值"且"指标不是价值":功能是对价值的一种假设,指标是对价值的一种解释。
• 速度不等于方向。较短的交付周期只是更快地交付了一个错误的假设。
• 稳定不等于没有反价值。较低的变更失败率无法说明延迟、困惑、用户侧返工,或由一个完全按设计运行的变更所造成的信任损失。

从价值管理理论(Value Management Theory,VMT)的角度看,这一缺口是结构性的。价值只存在于已定义的价值系统之内,并由其行动者来解释(A1、A2)。价值在消费的那一刻实现(A6),而计划价值与已实现价值通常并不相同(A4、T3)。管道指标是在消费之前、在发送方一侧收集的,因此它们至多描述计划价值的交付。当这类指标成为目标时,就会出现 Goodhart(1975)所描述的效应:团队开始优化计数器。VMT 以系统的语言陈述了同样的风险:局部优化并不能保证全局改善(T5)。

3 价值系统图式符号体系

3.1 符号体系的要素

在 Æilus 方法论中,价值系统图式是第一个核心工件:它是对价值系统、其行动者、价值流、转换器和关键交换的形式化描述,用于确定系统边界并防止出现不可见的外部依赖。VSS 可以在转换器层级或系统层级绘制。

VSS Editor 于 2025 年 12 月发布在 aeilus.tech 上,是一个基于浏览器的此类图式可视化编辑器。其符号体系只有少量要素。

• 转换器(Converters)。转换器(converter)是 Æilus 对图式中转换器角色的称呼:它是一个功能块,例如团队、服务或子系统,接收价值要素,对其进行转换,并产出新的价值要素。转换器是价值被创造、放大或毁灭的地方。
• 价值流(Flows)。价值流是转换器之间,或转换器与外部世界之间的有向连接。它承载以 Æ 计的一定量的价值或反价值。价值流分为外部流入(价值进入系统)、外部流出(价值离开系统)或内部流(转换器之间的价值)。
• 输入与输出。外部流入和流出标记价值进入和离开的位置。它们共同定义了系统边界。
• 价值要素。要素类型描述究竟是什么在流中移动:客户价值、收入、成本、风险、技术债务等。在已保存的图式中,每个要素都有种类(价值或反价值)、符号、数量和单位(Æ)。
• 反价值。反价值代表损失和负面影响:延迟、返工、缺陷、官僚主义、风险、倦怠、无效劳动。在图式中,它是带有负号的显式要素,而不是价值的缺失(A5)。

3.2 作为机器可读模型的图式

编辑器将图式保存为结构化的 JSON,包含节点(转换器)、价值流和要素。因此,图式可以与产品一起进行版本管理,之后还可由分析工具读取,以比较每条价值流的计划量与已实现量。此类分析被宣布为未来工作,在此不作假定。

3.3 图式不是什么

VSS Editor 明确不是 KPI 仪表盘、BI 工具、仿真引擎,也不是财务会计的替代品。它将清晰性置于计算之前。由此建议的建模顺序是:先界定边界,仅添加主要转换器,用命名的价值流将它们连接起来(先命名后数字,先方向后精度),然后标出反价值,这一步往往能带来最多的洞察。

4 谁的价值:系统及其边界

在说明所度量的是谁的价值之前,价值的度量是没有意义的(A1、T1)。所选择的边界也会在现实毫无变化的情况下改变结论(T15)。因此,本文在进行任何度量之前先固定价值系统。

此处建模的价值系统是产品组织内单个软件产品的产品价值系统。按照产品价值系统演示文稿,其行动者包括产品职能、开发团队、运维、生产环境中的产品、用户,以及作为用户回馈价值之接收方的公司。财务是外部的赋能流入(薪酬)。

度量两种已实现的解释:由用户或其可观察行为所解释的用户价值,以及由公司作为回流(收入、留存、成本或风险的降低)接收方所解释的公司价值。计划价值是发送方在发布之前的解释。除非明确扩展,同一发布版本对合作伙伴或监管机构的价值处于边界之外。

5 从产品假设到已实现价值:价值循环

产品价值系统演示文稿将产品工作框定(frames)为一个循环,其中价值假设被创建、实现、验证和维持。以图式的语言来说,该循环包含以下转换器和价值流。

1. 投资流向产品职能。产品职能将资源和用户信号转换为承载计划价值的假设。
2. 产品职能流向开发。假设成为带有计划价值的待办事项。演示文稿陈述了两项期望:假设的计划价值在构建期间不应降低,且交付的价值与计划价值不应相差太大。
3. 开发流向运维。开发消耗工作量并产出可运行的变更,同时产生反价值(技术债务、缺陷、延迟)。
4. 运维流向生产环境。变更成为运行中的软件;发布错误和停机以反价值的形式出现。
5. 生产环境流向用户。价值只在使用中实现(A6),因此这是可以观察到已实现价值的第一个点。
6. 用户流向公司。用户回馈收入、留存和信任。作者于 2022 年 1 月发布的频道帖子称之为闭合的价值流:交付给客户的价值与回流的价值相平衡,回流通常(但不仅仅)是金钱。

该循环使转换公理(A7)具体化:每个转换器实现其所接收的内容,并为下一个转换器产出新的计划价值。它还说明了为什么管道指标只覆盖第 3 步和第 4 步。价值被计划、实现和回流的第 1、2、5、6 步位于管道之外。

该演示文稿还列出了内部和外部产品中可观察的要素类型。价值要素包括节省的时间、更少的运营错误、现金流、风险降低、更低的认知负荷、可预测性、新能力和信任。与之对应的反价值包括损失的时间、返工、不断增长的运营成本、技术债务、不可预测性、手动变通办法、信任丧失和客户服务质量下降。这一类型划分是交付领域价值要素登记册(Value Element Registry)的起点。

6 每次发布的计划价值与实现价值、阻力和泄漏

6.1 以发布作为比较单位

比较单位是发布,当发布较小时则是待办事项。对于每一项,该方法在 Æ 中记录:

• 计划价值:发送方的估计,在开发开始之前记录,并且只能通过明确且有记录的决定进行更新;
• 实现价值和实现反价值:接收方在发布投入使用并经过约定的观察期之后作出的解读;
• 回溯价值:在二阶效应(支持负荷、客户流失、技术债务)显现之后进行的再次评估。

该演示文稿建议分阶段引入:首先为每个待办事项记录计划价值,然后为每个已发布事项记录实现价值和反价值,最后记录回溯价值。没有计划价值,就没有可衡量的差距;没有实现价值,计划就仍然只是一个假设。

6.2 交付中的流动阻力

流动阻力(flow resistance)是计划价值与实现价值之间的差距,加上流中出现的反价值。VMT 认为非零差距是正常的(T3),但同时认为阻力会随历史累积(T4),并降低实现未来价值的能力(T6)。在交付中,价值会在实现环节(范围被削减、对假设的误读)、发布环节(缺陷、回滚)、采用环节(用户找不到或无法使用该变更)以及因延迟而损失。依据延迟成本概念(Reinertsen, 2009),延迟被建模为延迟的流上的反价值,而不是一个单独的指标。

如果每个流都带有各自的计划量和观测量,该模式就能显示损失发生在哪个转换器中。这正是 Æilus 工件集中流动阻力登记册和计划与实现价值差距报告的用途。

6.3 泄漏

泄漏(leakage)是指离开系统的实现价值持续超过进入系统的价值(A11)。在产品价值系统中,常见两种形式。第一种是用户受益,但回流未能覆盖使能性流入。第二种是团队在构建假设期间消耗投资,而这些假设却从未被实现。在这两种情况下,吞吐量看起来都可能很健康;该模式能同时显示这两种情况,因为流入和流出位于同一边界上。

7 共享节点:跨所有流的评估

软件系统中的某些转换器不产生用户能够指认的价值,但每条价值流都要经过它们。作者 2025 年 9 月的频道帖子以及相关的 aeilus.tech 文章以授权为例:它本身不产生价值,但没有它,每个场景都会停止。API 网关或 CI 流水线也属于同一类。

如果孤立地评估,这样的节点只显示成本而没有产出,容易招致削减成本。在该模式中,它同时出现在许多流上,其效率只有通过它所支撑的所有流的总价值才能清楚显现。因此,该方法为共享节点指定:

• 经过它的流的集合,从该模式中读取;
• 它给每条流增加的反价值(延迟、中断、登录失败、集成缺陷);
• 它的消耗价值(团队投入、基础设施)。

它的效率是其所有流上的交付价值减去反价值,再与消耗价值相比,遵循同一篇文章中的过程效率定义。共享节点的退化绝不是局部事件;它是增加到其所服务的每条流上的阻力。定理 T8 增加了一个可持续性论据:当某个转换角色无法履行时,稳定性就会丧失,而该角色的冗余会提高稳定性。

8 团队负责人的收益

作者 2022 年 2 月的频道帖子列出了该方法给团队及其负责人带来的好处。用本文的术语重述如下:

• 作为反馈的交付价值。对于任何时期,团队都能看到自己交付的价值,以 Æ 计量并经接收方确认,而不是速度这种间接信号。
• 独立于过程方法论的有效性度量。无论采用何种实践,度量都是每单位消耗价值所对应的实现价值,并且实践是依据其对该度量的影响来选用或淘汰的(P7)。
• 对业务的透明度。技术工作通过其所支撑的流变得可以解释。
• 基于价值的待办优先级。优先级可以由计划价值、其置信度及其延迟成本得出,而不是取决于嗓门最大的利益相关者。
• 作为反价值的延迟成本和生产错误。业务方可以展示当变更延迟或有缺陷时价值如何下降,团队也能看到其工作的有用性如何取决于时机和生产质量。
• 共享资源的论据。在管理员和 DevOps 工程师被共享的情况下,基于价值的优先级可以解释为什么一个团队的工作被推迟而让位于另一个团队的工作,双向皆然。

只有当实现价值由其接收方验证时,这些收益才成立。如果团队自己估计并确认自己的价值,该度量就会变成又一个自我报告的计数器,此时适用 T17:来自有影响力来源、但未被实现所确认的解读会累积反价值。

9 一个合成产品的实例化模式

本节描述的是一个合成的、示意性的产品。它不是案例研究,不描述任何真实的组织,也不包含任何实测数字。

该合成产品是一个订阅制网络应用,小型服务企业通过它接受客户预订。其价值系统遵循第 4 节中定义的边界。两个共享节点,即授权服务和 API 网关,为所有面向用户的流提供服务。财务部门提供使能性流入。公司获得订阅收入和留存作为回流。

该模式在 VSS Editor 中分四步构建:带有一个外部流入(投资和薪资)的边界以及流向用户的外部流出;七个转换器;以其所承载的价值要素命名的流;以及反价值要素。在第一次估计会议之前,数量保持为空。

考虑一个假设的版本发布:一项旨在减少爽约的提醒功能。开发之前,产品负责人按要素记录计划价值(节省的时间、减少的漏订、对留存的预期影响)。在约定的观察期之后,产品分析和一部分业务用户样本提供实现价值,团队则记录实现的反价值:延迟发布、一个导致重复发送提醒的缺陷、API 网关上的额外负载。二者之差就是该版本的阻力。该缺陷和网关负载同样位于服务其他场景的流上,因此也要归入共享节点。一个季度之后,回顾价值记录留存是否真的发生了变化。在实际应用中,各项数量将来自下文所述的会议。

10 如何运行

10.1 谁来估计,谁来验证

2025 年那篇文章中的 Æilus 规则很简短:一个流程的输出价值必须由消费它的人来评估,并且应由另一个人检查该评估。应用于交付,这就形成了清晰的分工。

• 计划价值由发送方估计。对于假设,这是产品负责人,他担任产品转换器的价值变换器负责人(Value Transformer Owner,VTO)。对于开发转换器,则由团队负责人担任 VTO。
• 实现价值由接收方解释:用户(通过产品分析或网页分析观察),以及回流流程中的公司。该演示文稿提出,作为临时措施,在建立直接验证之前,由产品分析代表用户一方。
• 对该解释的验证由第二方完成:负责系统级可持续性的价值系统负责人(Value System Owner,VSO),或者针对关键流的流负责人(Flow Owner)。
• 方法论的完整性由 Æilus 主管提供支持(在演示文稿中,是由项目经理担任的 Æilus 倡导者),他负责编制价值交付报告、计划与实际对比报告以及流动阻力报告。

10.2 节奏

Æilus 并不规定日程。与该方法论推荐的活动相一致,交付团队的最小节奏如下。

• 每次待办事项梳理:利用要素登记册,为新条目分配计划价值。
• 每次发布,在观察期之后:记录并验证实现价值和反价值;通过一次简短的价值回顾会讨论差距。
• 每月或每季度:针对图式(包括共享节点)进行流动阻力评审;为此前发布的条目记录回顾价值。
• 每季度或发生结构变化时:对边界、转换器和依赖关系进行价值系统评审,并更新图式文件和版本。

10.3 纪律

每个工件都需要有负责人、更新循环和决策目的;否则它会通过维护成本和虚假的信心产生反价值。对于本方法,决策目的包括待办事项优先级、共享资源的分配、发布时机以及对共享节点的投资。只有在团队实现计划价值的能力得到确认时,才允许增加计划价值(P9)。计划价值的增长快于实现价值,正是 T16 所描述的失效模式。

11 局限性以及实证研究所需的条件

本文是概念性的,尚未在测量数据上检验。由此产生若干局限。

• 估计质量。Æ 中的价值是解释,其可靠性取决于估计者及其校准。
• 部分可通约性。节省的时间、收入和信任只是部分可通约的(A13)。要用同一种货币来表达它们,需要价值聚合策略,本文假定了该策略,但没有对其加以定义。
• 归因。实现价值往往源于多个版本和外部因素;图式展示结构,但无法分离出某一个版本的贡献。
• 隐藏的流。如果图式无法解释所观察到的系统稳定或衰退,则说明存在潜在的流,或者边界有误(T9)。图式是关于结构的假设,必须加以修订。
• 方法的成本。不产生任何决策的会议会使方法本身变成反价值。

实证研究至少需要:若干交付团队应用该方法的时间足够长,以便记录回顾价值;在数据收集之前就商定稳定的要素登记册和聚合策略;由接收方而非团队对实现价值进行独立验证;并行收集传统的交付指标,以便考察这些指标与实现价值之间的关系;以及对有图式和无图式情况下所做决策的比较。只有这样的研究才能表明,基于价值的优先级排序是否会改变所交付的价值,以及在何种条件下会改变。

12 结论

交付指标描述的是工作如何在流水线中流动,而不是它为接收方带来了什么变化;在 VMT 之下它们也做不到这一点,因为价值依赖于情境,只在使用中实现,而且计划价值与实现价值会出现偏离。价值系统图式(Value System Schema)在 VSS Editor 中的实现,使软件团队能够绘制从假设到实现价值再回到公司的产品价值循环。按每个版本记录计划价值、实现价值和回顾价值,就把该循环变成了一种测量:阻力和泄漏变得可见,共享节点在其服务的每一条流上得到评估,团队负责人则获得所交付的价值、基于价值的优先级以及延迟和错误的成本作为反馈。只有在说明系统边界、由接收方验证实现价值、并且每个工件都服务于某项决策的情况下,该方法才能保持诚实。它在实践中是否会提升所交付的价值,是一个实证问题,本文对其加以界定,但并不作答。

参考文献

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (in Russian). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.