。

  。

  。

背景 ：2022年8月，在这家公司已经任职满两年。这两年我最大的成就就是基于Scrum模式推行了敏捷项目管理，并取得了一定的成果。但是，在推行了两年后新的问题也产生了。例如:

1，项目管理上，项目经理缺乏对项目团队每个环节的过程管理，尤其在过程指标上缺乏工具监控.

2，产品管理上，在软件成本管理与价值管理上双线失守，众多需求说不清楚价值是什么？更不知道ROI的如何计算.

3，软件开发上，程序员自测、问题修复以及软件发布，占用软件工程师非常多的时间.

4，质量测试上，软件质量一直无法提升，尤其是在测试手段上一直处于低效的人肉测试模式，bug漏测时有发生.

5，需求管理上，识别不了哪些是对系统有推进意义的需求，哪些是伪需求。需求的价值评判标准是什么？.

等等等待一系列问题.

我受到这些问题所困扰，而我下属有10个项目经理，对应10个项目团队， 以及10个以上软件产品，近百人团队也在这种Scrum模式下运作着.

这让我的敏捷项目管理模式已经出现了瓶颈，我甚至认为这只有敏捷的躯壳，压根没有敏捷的灵魂.

为此，我开始思考敏捷上的突破，这让我有机会接触了 DevOps ，从而知晓了《价值流动》这本书。尽管阅读了这本书并没有解决我众多的问题，但是这让我对 管理 的认知有加深了一层理解.

  。

正文 ：我们先来谈谈这本书讲了什么?

整本书在我看来就一个案例，即作者 参观宝马集团莱比锡工厂后，对生产流水线的高效运作从而映射软件工程的思考。探讨 项目制 与 产品制 思维方式上的差异，重点向读者解释了 流框架 的定义与运用.

再摊开来聊这些内容之前，我还得先阐述一下作者想表达的基本观点:

首先，作者认为 软件成本占比在企业运作中逐步提升，而且会持续下去 。这一点我非常认同，我甚至认为将来所有企业不论传统的农业、制造业，甚至服务业、金融业都将会成为科技公司，产生各式各样软件服务.

因此，作者得出数字化转型的三个“颠覆”:

1，基础设施颠覆——改变客户获得特定产品或服务的方式（产品营销方式）.

2，运营模式颠覆——依赖于借助软件来改变消费者与企业的关系.

3，商业模式颠覆——软件和技术对业务更根本的运用.

  。

在这三个颠覆的历史进程中，作者通过考察宝马工厂之后对比软件工程也有了三个顿悟:

1、由于软件架构与价值流脱节，随着软件规模的不断扩大，生产力反而会下降，浪费会增加.

2、脱节的软件价值流成为软件生产力规模化的瓶颈，软件价值流的脱节是滥用项目管理模型的结果.

3、软件价值流不是一个线性的生产流程，而是一个复杂的协作网络，必须要与产品对齐.

  。

这三个顿悟，我深有体会。我可以毫不思考的回答我就处于这三个困惑中，这也是使得我迫不及待往后阅读这本书，后续作者在面对这些复杂的场景中，也给予解决方案。答案正如书名一样《价值流动-Project To Product》 从 项目 到 产品.

在说清楚这个问题之前，先要搞清楚项目制的生产模式 与 产品制的生产模式 有什么区别。为此我特别做了一张表来说明:

  。

。	项目导向 。	产品导向 。
编制预算 。	为里程碑提供资金，在项目确定范围时已经预先设定。新的预算需要新立一个项目.	根据业务结果为产品价值流提供资金。按需进行新预算的分配。鼓励交付增量结果 .
时间跨度 。	项目的时间期限定义了终止日期。在项目结束 之后不再关注维保.	产品生命周期，包括生命周期结束 前的持续性的健康，维护活动.
成功 。	成本中心方式。以按时和按预算来衡量成功。开发资本化的结果是项目太大。受此激励的企业，会提前要求它们可能需要的一切.	利润中心方式。以业务目标和结果达成（比如收入）来衡量成功。聚集在增量价值交付和定期检验.
风险 。	通过强制提前进行所有的学习、需求编写和战略决策，交付风险被最大化.	风险分摊到整个时间跨度和每个项目迭代中。这创造了期权价值，比如，当发现交付假设错误时终止项目，或者当出现战略机遇时进行业务转身.
团队 。	给人安排工作提前为工作分配人员，人们通常会跨多个项目，项目人员频繁流失或重新分配.	把工作给到人工作被分配给价值流上稳定的、增量调节的、跨职能的团队.
优先顺序 。	由项目组合管理和项目计划驱动。聚焦需求交付。项目驱动的瀑布导向.	由路线图和假设测试驱动。聚集于特性和业务价值交付。产品驱动的敏捷导向.
能见性 。	IT是个黑例子。PMO创建了复杂的映射关系，晦涩难懂.	直接映射到业务成果，做到透明化.

  。

如何从项目制到产品制？作者设计了一套 流框架 （如下图） 。 在正式开始解读流框架之前，我想还是有必要先阐述两个问题:

1，什么是价值流？即：通过产品或服务向客户交付价值所开展的端到端活动集合.

2，什么是软件流动？即：沿着软件价值流产生业务价值这一过程中涉及的活动.

  。

  。

  。

  。

  。

简单解读一下，流框架是为了 实现价值流管理，连接IT和业务，并将传统企业转变为高绩效的技术公司提供了蓝图。整个框架分为四层:

最底层是： 工具网络 ，将设计、创建、发布和运维等连接起来，表示为集成模型，可以通过 连接指数 来衡量； 。

第二层是： 工件网络 ，将各种活动等连接起来，构建活动模型，可以通过 可跟踪指数 来衡量； 。

第三层是： 价值流网络 ，连接价值，构建产品模型，可以通过 对齐指数 来衡量； 。

最上面一层是： 价值流度量 ，有8个度量指标，从流动指标度量（流动速度、流动效率、流动时间、流动负载）到业务结果度量（价值、成本、质量、幸福），这些度量建立在流分布到度量之上，流分布会涉及特性、缺陷、风险和技术债务等分布.

  。

这里需要将 流动项、流动指标、业务结果（价值） 进行阐述.

流动项 是由干系人所拉取的、通过产品价值流来传递的 价值单元。 在流框架中有四大流动项.

	描述 。	交付物 。	拉动者 。	工件示例 。
特性 。	为推动业务结果而增加的新价值；对客户可见 。	新的业务价值 。	客户 。	史诗、用户故事、需求 。
缺陷 。	为修复影响客户体验的质量问题 。	质量 。	客户 。	BUG、问题、事件、变更 。
风险 。	致力于解决安全、隐私和合规风险 。	安全、治理、合规 。	安全及风险官 。	安全漏洞、监管要求 。
债务 。	软件架构和运维架构的改进 。	消除未来交付的障碍 。	架构师 。	添加API、重构、基础设施自动化 。

流动指标 是度量组织内每个价值流的指标，以便让组织拥有一种讲软件生产指标与业务结果相关联的方法.

	描述 。	示例:
流动分布 。	相互独立，完全穷尽，在一段时间内以特定的流动状态分配各大流动项 。	在一个特定的冲刺中，每个处于活跃工作状态的流动单元的比例 。
流动效率 。	在给定时间内完成的流动项的数量.	为特定发布而解决的债务.
流动时间 。	流动项从工作被接受后进入价值流到完成所花费的时间，包括活跃时间和等待时间 。	从接受新特性到向客户交付所花费时间.
流动负载 。	流状态为活动中或等待状态的流动项的数量 （即在制品，WIP) 。	流动负载超过一定的阈值会对速率产生不利的影响 。
流动效率 。	流动项处于活跃工作状态的时间占总消耗时间的比例 。	当依赖关系导致团队等待其他人时，流动效率会降低 。

业务结果指标 。

	度量 。	举例 。
价值 。	由价值流产生的业务贡献 。	收入、月度经常性收入、年度合同价值、月度活跃用户数 。
成本 。	业务的价值流成本 。	支持价值流的所有人员、运营和基础设施成本。分配给价值流的全职员工.
质量 。	有顾客感知到的价值流所产生的产品质量 。	逃逸 缺陷、提交的工单、续约率、扩展率、净推荐值 。
幸福度 。	价值流工作人员的敬业度 。	员工净推荐值、员工敬业度 。

  。

聊到这，有一个问题，我们已经有了如瀑布、Scrum、Less、SAFe、DevOps 那么多框架了，队为什么需要用这个新框架？其实流框架的收益至少有以下四点:

1，实时看到业务价值的端到端流动.

2，立即发现瓶颈，并利用它们对投资进行优先级排序.

3，基于每个价值流的实时数据对假设进行验证 。

4，为了最大化价值流支而重新设计组织架构 。

在我看来无论 从瀑布到 Scrum，从Scrum到DevOps, 其实都是对 技术人员的工作方式产生了重大影响。但它们过于以技术为中心，没有被业务涉众广泛采用。而流框架跨越了业务语言和技术语言，并支持从项目到产品的转换，流框架的作用是确保这些业务级框架和转换计划与技术框架相连接，需要 将 DevOps的三大原则“ 流程、反馈、持续学习 ”扩展到整个业务.

  。

至此，对于这本书所写的关键内容我就描述到这里.

  。

感悟:

对于《价值流动 Project To Product》一书我给出： 四颗星.

说说我的感悟:

1， 谈谈我对项目制和产品制的看法 。 一种管理模式的出现我从来不会认为有孰优孰略的看法，只是在不同场景下，不同模式的运用要去合理匹配。软件行业过去几十年的管理模式都是借鉴于建筑业、制造业。正因为软件本身变更成本低，且相比其他行业更容易产生变更。 这也导致了传统的瀑布型（预测型）管理模式，在逐步失效。而敏捷项目管理模式本身是基于软件产品而诞生的模式，所以更符合产品制的架构.

  。

那是不是就完完全全的按照产品制来做呢？ 还是那句话要因地制宜，至少在我所任职的这家制造业来说，不能完全的按照产品制来说。在2022年全年中，我们面对每个月200个需求的吞吐量，几乎每一位需求的提出者都认为 自己所提出的需求非常有价值。而我们的软件确实一个从无到有的自研模式，这导致我们一直被用户牵着鼻子走，最难受的我所任职的企业有多家子公司，同样的采购部，同样的采购系统，却面临着组织结构不一样，作业流程也存在差异，需要提供的数据看板也五花八门.

  。

这个时候，如何去衡量价值？又基于哪个据点去打造产品呢？ 我们在这一年中，几乎完成了用户提出的三千多个需求，为此我们明确的知道项目的范围已经蔓延，而且遏止不了这种趋势。我们可以自我安慰的说用户越来越需要我们，但是只有我们自己知道。我们交付了价值，却失去了范围。并且，用户是喂不饱的.

  。

有的项目甚至一年下来，都在完成业务部门以及终端用户提出的需求，既定规划的功能模块都没有按时上线，既没有完成价值交付，又失去了成本控制。一年下来，最后年终总结的时候居然写不出这一年究竟做了哪些能拿出的出手的成果，一看全年的工作全是那种加字段、做看板、流程优化。本身系统的推进，却落在身后好远，又只好把这些目标又放在了下一年.

  。

我曾经咨询过京东的老师，他给我分享了一下京东的案例。他们会采用了一种混合的模式，是使用项目只制模式下 套了一层产品制的方式。具体的方法大概就是，整个项目立项依然是采用PMP那套理念有整体目标，有里程碑计划，有项目范围、成本 以及质量要求。 然后基于里程碑计划 分拆目标到每个核心迭代。并以迭代方式进行成果交付，这样不是为迭代而迭代，每个核心迭代都是对齐项目范围的。至于非核心迭代则一般是处理用户需求 或 技术债务。 这样也保证了在完成用户需求的同时，业务需求，系统需求 也都能得到满足.

虽然，不能完全解决我的问题，但是也让我明白了从战略分解，到里程碑计划，到迭代目标。逐级对齐是如何去操作的，这已经让我又进一步了.

  。

2， 说说业务与IT脱节.

业务与IT脱节是作者三个顿悟的二条。不得不说我深受其绕，由于我所在的公司是传统的大型设备制造公司，而且是最复杂的非标离散型企业。对我这种互联网公司出身的人而言相当陌生，不仅仅是我即便是我们近百号的IT人员将近9成都不是制造业出身，业务知识的匮乏让我们这两年来一直期望有个业务专家来指导我们。就像人生希望有个导师来指引告诉我们什么是正确的道路，可哪有这种人，这不就是希望有个大牛告诉你买哪支股票会涨一样吗?

起初我们的IT组织架构设计是只有 项目部 、开发部 以及运维部。 是由项目经理设计产品，跟进计划。后来从项目部中分离了产品部，前置一个产品经理岗专注产品设计。由于新成立的产品部并不精通业务，最近又希望再成立一个流程组，基于产品经理再前置一个 流程专家。不管是项目经理，还是产品经理，又或是没有组建的流程专家，其实都不能解决问题。问题还是出在了体制上，我们尝试深入一线去调研，往往只是挖掘出单点的需求，对于整体的数字化流程转型，一直以来没有高层次的架构来支撑。对于这一点，我特地去调研了我所在城市的两家头部企业。他们的做法我觉得也可以借鉴一下.

  。

A企业的做法是，由业务部门提供产品设计，甚至系统的流程图、原型图都有业务部门通过评审并会议签字。再交由IT部门执行。即：业务部门承担系统业务设计工作。（这里只需要培训业务部门画流程图以及原型图） 。

B企业的做法是，将IT部门下放到业务部门，每组2-3名开发人员直接在业务部门打卡上班，一起参与日常工作。岗位编制也是在业务部门，是专门为业务改善而存在的IT人员，即每个部门有自己的IT人员，确保以IT思维对业务部门实施数字化改革.

  。

基于这两家企业是从顶层设计上解决业务与IT脱节的问题，其实在我所任职的企业可行性都不高。结合这个问题我思考了另外一种方式，那就是在项目立项之时，从业务部门抽调 “全职”业务部人员加入项目团队。 这不同于在项目组织架构中担任某一角色，而是全职在项目团队中参与项目实施。 也不同于从业务部门挖人到IT部门上班，项目结束时人员是释放回业务部门的.

  。

3， 讲讲价值流动以及透明化.

谈到价值流动以及透明化，这跟我最近读的几本书都或多或少跟这个有关系。 这使得我也意识到自己的另一外项能力的缺失，即“价值流图分析”。我再之前几本敏捷书籍中都有看到过价值流图。大体意思是分析业务流程，拟定观测指标，分析价值短板。 与之关联的也有从观测指标中提炼 关键指标 ，转换为绩效指标.

如果抛开价值流图不谈（毕竟我还没掌握这项能力）。 一个部门或者一个流程的运作，应该是有过程指标的，拿IT来说。 需求达成率、设计变更率、任务准交率、Bug漏测率等等。 通过过程中产生的数据提炼关键指标。这不就是数字化转型吗?

我们现在给业务部门的采购系统，仓库系统，都是通过各个指标来衡量降本增效。IT的降本增效呢？ 是否透明化出来。 如果像这本书的作者一样，拿一家企业来映射IT部门。我们有哪些指标是不透明的，有哪些价值短板是需要改善的。其实作者已经指出了软件团队 流动的是 特性、缺陷、风险以及技术债务。那么这些都已经透明化了吗？ 显然我还没有做到.

在我看来没有，单单特性 这一项就还差得远，至少如下:

1，需求等待时长：一个需求从 登记到设计 的等待平均时间是多久?

2，需求设计时长：一个需求从开设计到评审通过平均时间是多久?

3，需求开发时长：一个需求从开发到交付测试的平均时间是多久?

4，需求交付时长：一个需求从测试到上线发布的平均时间是多久?

围绕这 需求（特性）的流动 我就看不清楚，说白了也就是不透明。这种不透明让管理者非常没有安全感，组织改善，绩效评定，都失去了重要依据。这也使我理解了什么叫：数字化转型要为管理决策提供支撑.

不过很可惜，就像我上面围绕特性这一个流动项 做出的价值流 我都没有解决好，更别说 缺陷、风险、技术债务了。这里工具、流程、方法论都有所缺失，以至于我到现在还没想清楚怎么来改善这一问题，哪怕只围绕着特性 这一点来做价值流动 以及透明化.

  。

至此，就写到这里.

  。

  。

  。