2.1 流动框架

概述与动机

流动框架（Flow Framework）是Mik Kersten创建、发表于其2018年著作《Project to Product》中的一个管理与结构模型。它的存在，是为了回答一个纯粹的流水线指标无法回答的问题：不仅仅是代码从提交到生产环境移动得有多快、多安全，还包括流水线中究竟流动着什么样的价值，以及这种组合是否反映了业务的真实战略。该框架把软件交付当作一条价值流，即把一个想法转化为客户所获价值的端到端活动序列，直接借鉴了精益制造中价值流映射的传统。

本书用流动框架作为第2部分的组织结构。主题 2.2 介绍其四种流动项，主题 2.3 与主题 2.4 介绍其五个流动指标，主题 2.8 把这些指标追溯回它们在经典精益价值流映射中的起源，主题 2.10 则把DORA指标作为一个更窄、以流水线为焦点的参考框架来涵盖，本部分不再以它为主导。这是一个刻意的选择，而不是对DORA研究的否定。DORA以真正的统计严谨性衡量系统的吞吐量与稳定性，但它对业务负责人真正最关心的那个问题保持沉默：在工程组织本季度交付的一切之中，有多少是新的客户价值，又有多少被悄悄地消耗在修复缺陷、管理风险或偿还债务上。流动框架的存在，正是为了让这种组合变得可见。

对大团队而言，这种区分不是学术性的。一个运营着几十条价值流的平台组织，可以拥有出色的DORA数字（快速、频繁、稳定的部署），而其实际的产品产出却在悄悄漂向几乎纯粹的维护工作，这是一种只衡量流水线机制的仪表盘所无法看见的模式。必须向以业务术语而非流水线术语思考的利益相关方证明工程投资合理性的企业与政府组织，需要一套能把交付活动与战略意图连接起来的词汇。这正是本框架所提供的。

核心原则

价值流是衡量的单位，而不是团队或流水线。 它从一个客户或业务需求出发，一路延伸到交付的结果，跨越工作实际跨越的任何团队边界。
流动项让”是什么”可见，而不只是”多快”。 主题 2.2 的四个类别（功能、缺陷、风险与债务）把一个隐含的优先级决策，变成了一个明确、可衡量的决策。
流动项之间的容量分配是零和的。 花在一种项类型上的容量越多，其他类型可用的容量就越少；该框架让这种权衡变得可见，而不是任其隐含。
五个流动指标回答的是业务问题，而不只是工程问题。 它们的设计初衷，是呈现给非技术利益相关方，而不是留在工程团队内部。
价值流管理应当是持续的，而不是一次性的映射练习。 静态的价值流图会过时；该框架的设计，是从团队已经在使用的工具中直接埋点。

建议

在埋点之前先映射你的价值流

在采纳任何流动指标之前，先走一遍一项工作从一个业务需求被识别，到客户获得价值的实际路径，为每一个阶段、每一次团队之间的交接命名。这就是经典的价值流映射练习，改编自精益制造，而跳过这一步，是流动框架的采纳产出无人信任的数字的最常见原因：针对一个从未被审视过、只是非正式理解的流程所计算出的指标，很少与实际发生的情况相符。

把流动指标与团队已经在使用的工具连接起来

流动框架是为持续的、自动化的价值流管理而构建的，而不是为周期性的人工映射练习而构建的。把流动项的跟踪直接集成到工作已经流经的工具中（Jira、Azure DevOps、GitHub）而不是构建一套需要团队手动更新的并行跟踪系统。一个流动项的状态应当随着底层工单或拉取请求的移动而自我更新，这正是主题 1.5 为本书中每一个指标所推荐的、埋点优先于自我报告的同一门自律。

直接向业务利益相关方呈现流动分布，而不只是向工程领导层呈现

这个框架被错失最多的一个机会，就是把它当作一个内部工程工具来对待。流动分布（投向功能与投向缺陷、风险和债务的工作比例（主题 2.3））的设计初衷，正是要成为你与产品和业务领导层之间的一场对话，因为它把一个隐含的优先级决策（多少容量投向新价值，多少投向维持系统运转）变得明确、可协商，而不是被想当然地假定。

把四种流动项当作一门真正的分类法，而不是一种形式

要求每一份工作在纳入时就被分类到四种流动项类型之一，而不是事后追溯分类。事后应用的分类，或者因为”这基本上就是个功能”而松散应用的分类，都会侵蚀整个分类法的价值，因为其全部意义所在，正是对容量究竟去了哪里的一份诚实、一致的记录。

在组织发生变化时重新审视你的价值流图，而不是按固定日程

价值流图会在团队边界、工具或产品本身发生实质性变化的那一刻就过时，而不是在某个随意设定的年度节奏上过时。把一次重组、一次重大的工具迁移，或一次重大的产品转向，当作重新走一遍价值流的触发条件，因为针对一份过时的地图所计算出的流动指标，会悄悄衡量错误的东西。

权衡取舍：利与弊

方案	优点	缺点
只用流水线指标（DORA，主题 2.10）	简单、经过充分验证、从现有CI/CD数据埋点成本低	对正在交付什么样的价值保持沉默
完整采纳流动框架	把交付与业务战略连接起来；让价值组合可见、可协商	需要一份诚实的价值流图与一贯的流动项分类自律
静态、一次性的价值流映射	便宜，作为一场工作坊练习运行起来很快	很快就会过时；产出的是一张快照，而不是实时指标
持续的、与工具集成的价值流管理	实时、始终最新的数据；能跨许多条价值流扩展	需要前期真正的工具集成工作

核心张力是业务可读性与埋点投入之间的张力。流水线指标之所以便宜，是因为流水线已经产生了这些数据；而价值流指标需要一份对整个流程的诚实地图，以及一种纪律严明的、在纳入时就分类的习惯，这是流水线指标从未要求过的。解决之道是从一条价值流开始，而不是一次性覆盖整个组织，把它正确地映射出来，然后才把流动项跟踪集成进现有工具，而不是试图对所有团队同时进行一次大爆炸式的推行。

与团队讨论的问题

我们现在能为我们最重要的产品画出一张准确的价值流图吗，还是我们会在好几处交接上靠猜？ 大多数组织其实从未端到端地走过这条路径。诚实地尝试这项练习，记录下每一处大家对实际发生的事情意见不一致的地方，因为这种分歧本身就具有诊断价值。
如果我们把上个季度团队交付的一切都分类为功能、缺陷、风险与债务，结果会让我们的产品领导层感到意外吗？ 大多数团队从未把这种划分明确化，而答案往往会揭示出一种此前在简单的”已交付故事点”计数中不可见的维护负担或债务问题。
我们是否有一种真正与工具集成的方式来跟踪流动项，还是这需要有人手动分类和重新分类工作？ 人工系统在真实工作量下会很快衰败；与工具集成的系统则不会。诚实地评估你们实际上准备维持的是哪一种。
我们的价值流图上一次变化是什么时候，我们是否已经更新了指标以反映这一点？ 重组和工具迁移会悄悄使价值流图失效，而很少有组织会在那种情况发生时记得重新审视它。
我们的流动指标是否曾直接呈现给业务或产品利益相关方，还是留在工程内部？ 这个框架相对于纯流水线指标的最大优势，正是这场对话，而跳过它，就等于放弃了这个框架的大部分价值。
要在纸面上不做任何不诚实的事情就操纵我们的流动项分类，需要什么？ 走一遍在交付压力之下，一个团队可能如何悄悄把债务或风险工作重新贴上功能标签、以显得更有产出，并讨论一下你们现在是否会察觉到这种情况。

行业视角

初创公司。 对一个人人早已把整个流程烂熟于心的五人团队而言，完整的价值流图通常是杀鸡用牛刀。在这个规模上有用的习惯，只是在规划对话中大声说出四种流动项类型的名字，这样债务和风险工作就不会在功能截止日期临近时悄悄从视野中消失。

小型企业。 在你已经使用的任何轻量级跟踪工具内部采纳流动项分类（一列标签或一个自定义字段）而不是使用任何专门的价值流管理产品。一致分类的自律，远比其背后工具的复杂程度重要得多。

企业。 这正是该框架发挥价值的地方，因为一个跨众多产品线运营着几十条价值流的大型组织，没有其他可靠的方式能在同一处看清工程能力究竟是如何在功能、缺陷、风险与债务之间被分配的。投资于工具集成；人工替代方案经不起真实规模的考验。

政府。 当诚实的答案是越来越大比例的容量投向了安全修复或遗留债务时，流动分布能让公共部门工程组织为”为什么没有交付更多新功能”这个问题，给出一个站得住脚、业务可读的答案。让这种权衡变得可见、明确，而不是默默承受压力，往往是这个框架能为政府技术领导者提供的单一最有用之物。

案例

企业。 一家大型保险公司的理赔平台组织，基于其冲刺速度报告，曾相信自己主要在交付新功能。第一次价值流映射与流动项分类练习揭示，债务和风险工作，其中很多是来自一个十年历史核心系统的未记录技术债务，实际上消耗了接近一半的总工程容量，而此前从未有任何报告揭示过这一事实，因为那部分工作一直被并入笼统的”工程任务”之中。把这种划分呈现给高管委员会，首次为该平台的历史争取到了专门的债务削减预算，而不是让债务工作继续悄悄地与每一个功能请求竞争。

政府。 一家国家税务局的数字服务部门，用价值流映射诊断了为什么一项旗舰级面向公民的功能，尽管冲刺完成率一直稳定，却”进行中”了超过一年。地图揭示，这条价值流实际上跨越了五个独立团队，其中有三次组织架构图未能反映的交接，而流动项分类显示，该功能的实际工程时间，只占其总流动时间的一小部分，其余时间被各团队自身指标都看不见的团队间交接延迟所消耗。该部门针对这条特定产品线，围绕价值流而不是组织架构图进行了重组，在两个季度内大幅缩短了流动时间。

商业理由：动机、投资回报与总拥有成本

采纳流动框架的回报，是对一个纯流水线指标无法回答的问题给出一个站得住脚、业务可读的答案：工程能力是否按领导层所相信的那样被分配。上面的保险案例，揭示出近一半的容量投向了此前不可见的债务工作，这是一个组织一旦真正诚实地对其工作进行分类之后就会出现的常见模式，而这种可见性，往往能解锁一笔投资，是一句含糊的”我们需要更多时间处理技术债务”的请求永远无法解锁的。

总拥有成本主要集中在两处：最初的价值流映射练习，需要真正的引导时间才能做得诚实；以及为让流动项数据保持最新、无需人工维护所需的工具集成。这两项成本，一旦做好，都是一次性的或低维护的，这使得该框架的维持成本，远低于其采纳成本。

反模式与陷阱

把价值流映射当作一次性的工作坊，从不重新审视： 地图会在组织发生变化的那一刻过时，针对一份过时地图计算出的指标会衡量错误的东西。
构建一套并行的、人工维护的流动项跟踪系统： 在真实工作量下会很快衰败；应当集成到现有工具中。
事后而不是在纳入时对流动项分类： 本主题核心的操纵向量。在交付压力之下，一个团队可以悄悄地把债务或风险工作事后重新贴上功能标签，以在只看到流动分布图表的利益相关方面前显得更有产出，而从未有人做出一个明确、可见的决定去这样做。护栏是要求在纳入时就分类，在结果尚未知晓之前，并定期抽查一批已分类的项目，核对其底层变更实际做了什么，这正是主题 1.2 对本书中每一个指标都要求的同一种审计自律。
只把流动指标留在工程内部： 放弃了该框架的主要优势：与业务利益相关方共享的词汇。
映射组织架构图而不是真实的价值流： 隐藏了往往是延迟最大来源的跨团队交接。
在一条价值流上验证之前就在全组织范围内采纳该框架： 冒着在无人信任的指标上投入大量资金的风险，因为底层地图从未被确认过准确。

成熟度模型

第一级，启动： 不存在价值流图；工作以通用工单的形式跟踪，没有流动项分类。
第二级，发展： 一条价值流已被映射，流动项被非正式地分类，但跟踪是人工的，应用也不一致。
第三级，标准化： 流动项分类已集成到现有工具中，并在主要价值流的纳入阶段被一致地应用。
第四级，管理： 流动分布与业务利益相关方定期审查，价值流图随组织变化被积极地保持最新。
第五级，协奏： 组织利用流动数据在各条价值流之间刻意地分配工程投资，并能指出因为该框架让此前不可见的权衡变得可见而做出的具体战略决策（一笔债务削减预算、一次团队重组）。

讨论思路

我们今天能不靠猜测，为我们的旗舰产品画出一张准确的价值流图吗？
一次诚实的流动项分类，会揭示上个季度有百分之多少的容量投向了债务和风险，而不是功能？
我们的流动指标目前是否触达业务利益相关方，还是留在工程内部？
我们价值流中最大的、组织架构图未能反映的跨团队交接是什么？

要点回顾

来自Mik Kersten《Project to Product》的流动框架，衡量的是什么样的价值流经交付流水线，而不仅仅是流水线本身运行得有多快。
该框架的衡量单位是价值流，而不是团队或流水线，在为任何事物埋点之前，先诚实地把它映射出来。
在纳入时而非事后进行流动项分类，是防范本主题核心操纵向量的护栏：悄悄把债务或风险工作重新贴上功能标签以显得更有产出。
把流动指标与现有工具连接起来（Jira、Azure DevOps、GitHub），而不是一套经不起真实工作量考验的并行人工跟踪系统。
直接向业务利益相关方呈现流动数据；这场对话，而不是一个内部工程仪表盘，才是该框架相对于纯流水线指标的主要优势。

参考文献与延伸阅读

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016.