最近出版的《价值流动：数字化场景下软件研发效能与页面敏捷的关键》一书针对数字化颠覆时代的业务和技术问题，提出了流框架（Flow Framework），从一种全新的角度来查看、度量和管理大规模软件交付，力求帮助组织少走弯路，确保整个组织齐心协力，从项目到产品，始终聚焦于价值流的软件大规模交付，为企业的研发数字化转型提供指南针。
数字化转型已经成为传统企业加速的必由之路，也是我国经济转型升级的重要国策。国务院国资委办公厅于2020年8月21日下发了 《关于加快推进国有企业数字化转型工作的通知》，当前，我国正处在经济结构的转型关键期，数字经济是中国实现高质量增长的重要推动力，传统行业的数字化转型势在必行，而国有企业早已身在其中，数字化转型将进一步促进国有企业的飞跃发展，也将极大提升自身竞争力，并逐渐成为这场伟大变革的焦点和主战场。
企业在数字化转型建设过程中，并非一帆风顺，成功转型的企业只有少数，大多数企业经常会遇到以下问题，给企业高管带来了许多困惑：
作者Mik Kersten给我留下印象最深的就是他在本书中定义的流框架，该框架起源于精益思想的五大原则：按照产品精确定义价值；为每款产品定义价值流；保持价值连续流动；客户从生产商拉取价值；追求尽善尽美。
价值流包括交付软件产品相关的每个人、每个流程、每项活动和每款工具，是由向客户交付业务价值所需的所有活动、干系人、流程和工具组成。
其中的顶层的价值流指标连接了业务成果与流指标，业务成果被抽象成四个方面的内容：价值、成本、质量和幸福感，体现出降本增效的常见目标，以及从外部用户与内部用户能够感知的质量和幸福感，流指标服务于业务成果的产出，其中的流分布工作项（特性、缺陷、风险和债务）反映了IT系统交付的内容。
价值流指标下有三个网络：价值流网络、工件网络和工具网络，分别代表产品的发布、交付的工件和使用的工具，可以用对应的三个指数来衡量企业的数字化水平。
流框架
价值流网络的对齐性指数：表示连接到产品价值流的工件容器相对于工具网络中所有工具容器的比率，显示了每个价值流提供多少业务价值，可以度量组织已经接入价值流中正在进行的工作，以及哪里可能有瓶颈和机会，能够通过该指数可以优化价值流。对齐性指数越高，业务结果的体现越清晰可见。
工件网络的可追溯性指数：衡量与工件类型相关工件的连接广度与深度。较低的可追溯性指数是因为工作中未连接的部分没有被流动指标所跟踪，对相应的干系人是不可见的。可追溯性指数越高，流框架向业务提供的输入信息就越可靠。该指数以工具网络的工具与集成模型之间的映射关系为基础，所以它也指征了价值流网络中可追溯性的自动化程度。
工具网络的连通性指数：表示工具网络中已连通和未连通的存储库的比率，用于度量工具网络，是量化流动指标置信度的关键指标，衡量的是信息在价值流中端到端的流动程度。
03
转型目标难以标定：
通过战略定位
确立价值主张和业务成果
组织在市场中至少处于价值链的一环，如何提供业务成果给用户是商业模式设计的核心环节，在精益画布中确定了价值主张就选择了市场的细分赛道，无论提供哪一类服务或产品，都需要对用户产生价值，并反映在财务指标上，对应流框架中价值流指标的成本和价值。
IT系统支持业务运营，可采用战略一致性模型进行分析和策划关键的数字化转型要素。
数字化转型路线
战略一致性模型（Strategic Alignment Model，SAM）抽象了各种数据管理方法的基本驱动因素（Henderson和Venkatraman，1999），模型的中心是数据和信息之间的关系。信息通常与业务战略和数据的操作使用相关。数据与信息技术和流程相关联，这些技术和过程支持可访问数据的物理系统。
围绕这一概念的是战略选择的4个基本领域：业务战略、IT战略、组织和流程以及信息系统。信息系统的业务成果数据可以用于指导数字化转型方向，确定基于价值导向的业务转型或组织变更。
04
转型需求难以界定：
运用价值流网络分析
挖掘研发数字化转型需求
虽然许多组织都经历过数字化转型，以应对单一的竞争威胁或市场变化，但数字化转型并不是一次性的活动。《MIT 斯隆管理学院评论》 指出：“数字化转型最恰当的定义就是持续适应不断变化的环境。”它的目标是建立技术和运营基础，以最恰当的方式不断发展和响应不可预测、持续变化的客户期望、市场状况以及当地或全球的事件。
价值流网络定义了每一个产品或产品线的业务价值，通过对齐性指数监测有助于不断识别和消灭整个组织的浪费来源，用于优化价值流本身，推动产品投资决策，满足用户期望。IBM指出，数字化转型就是为了满足这些不断提升的期望。
通常，组织的切入点是可以解决特定问题的转型计划，例如：
添加 AI 和自动化能力，更好地为客户服务，开展更高价值的工作。他们创建智能化工作流程，以简化运营模式，提高生产力，帮助员工更快做出更明智的决策。
数字化转型实施各种技术和最佳实践，旨在快速创建产品，打造全新客户体验，建立新型业务模式，以响应竞争威胁、市场趋势和客户期望的变化。
在该过程中，可对原有技术进行现代化改造，以便能够在现代基础架构中运行，并与现代应用实现互操作。它将弹性融入系统和流程中，并吸收消化来自并购的应用和数据。
数字化转型帮助企业尽可能广泛地采用来自生态系统合作伙伴、行业解决方案领军企业以及多个云服务提供商的解决方案和服务。
05
转型方案难以选定：
通过可追溯性分析
找到研发数字化转型切入点
数字化转型范围覆盖构想、创建、发布、运营阶段，组织在选择转型方案时，往往面临多项选择和多种组合，因此需要分析我们的瓶颈在哪里，我们的主要浪费体现在哪一个阶段。
价值流管理是一种基于精益理念的方法论，通过价值流动分析，采用流指标和工件网络的可追溯性指数进行数据统计分析，找到流动时间最长的研发活动，流动效率最低的环节往往就是我们数字化转型过程中需要采用技术赋能的环节，并且能够系统地进行分析，而不是局部优化。
此外，这种分析活动需要不断往复进行，通过帕累托原则，找到20%影响80%的环节进行持续改进，实现迭代式研发数字化转型。
通过建立工件和工具网络分析流动孤岛与瓶颈
按照精益的思想：“任何消耗资源，不产生价值的都属于浪费”。
常见的IT研发过程浪费有以下七大类（引用自CSDN）：
1. 额外的功能特性
根据Standish Group的调查报告，传统的软件开发过程制造了大量人们不需要的功能特性（7% always used，13% often used，16% sometimes used，19% rarely used，45% never used）。每个功能的实现，都要经历软件开发的整个生命周期：需求分析、设计、编码、测试、发布和维护，这需要耗费大量的人力、物力和财力，如果最终人们将不会用到这些功能，那么所有的投入都变成了浪费。而这还没有考虑过多的功能特性带来的系统复杂度所增加的开销。所以额外的功能特性是软件开发过程中最大的浪费。
在Lean Thinking这本书里面，Mary Poppendieck把制造业的七大浪费之一“在制品”对应于软件开发中的需求列表，她这种判断所处的环境是软件需求被写得非常细致，细致到可以直接用于编程的程度，同时这些细化了的需求又不会立马被拿去实现，相反它们会在需求列表中等待相当长的一段时间。当然，毫无疑问这是软件开发中的“在制品”之一，然而我认为这并不是全部在制品。另外还有一些常见的现象是大部分“已编码完成”的功能不得不等待很长一段时间才会被测试，而被测试了的功能会等待相当长一段时间才拿去被客户验收，这些通通都是软件开发过程中的在制品。它们是第二大的浪费。
类似的，这种浪费在Lean Thinking中被识别为对需求的过多细化以及不必要的文档工作，我也认同这种说法。同样我也认为这种说法并不全面，因为额外的步骤（过度处理）不仅仅存在于需求中，还存在于代码中。不少程序员会在代码中去做很多“预防性”工作，譬如预见可能发生的变化或者可能出现的情况，为了为这些变数留有余地，结果通常是在代码中写一些额外的代码。这种做法一方面增加了不必要的复杂性，另外一方面如果“可能的”情况永远没有发生，这些代码就成了负债。设计模式的出现可能会让这种问题缓解很多，然而我们还是要处处留意在开发过程中是否进行了过度的处理。
在软件开发过程中，经常要找客户确认或者澄清需求，要向开发者传达设计思路和技术要点，要找团队成员了解项目进展情况，要彼此反应遇到的问题以及解决办法等等，总而言之就是干系人之间彼此需要大量的沟通，所有这些沟通都是信息传递的过程，所以及时准确地传达信息是非常重要的。与此同时，开发团队经常面临的境地是很难找到客户进行需求沟通和确认，或者不得不花费很多时间和精力去寻找各种需要的信息，也经常遇到由误解造成的尴尬和浪费。团队用在寻找信息上面的时间，并不直接创造软件的价值，所以是一种浪费，应当努力去减少。我在一些社区中也看到有些人把上下文切换定义为七大浪费之一，仔细思考之后，我认为上下文切换的过程其实也就是及时找到另一类信息，并且进入状态的过程，所以它跟寻找信息的含义是一致的。
Bug创造价值么？不，没有Bug才是客户所期望的。Bug产生开销么？是，发现Bug、报告Bug、定位Bug、修复Bug、验证Bug等都要花费开销。Bug是可以避免的么？大多数Bug都是可以避免的。所以软件中的缺陷真是彻头彻尾的浪费，如果能采取适当的措施减少Bug的出现，那必定会节省下来很多用来处理Bug的时间，然后把这些时间用在有价值的事情上面，这一正一负会产生巨大的差别。
等待也包括让客户等待。无论是客户的等待，还是开发团队内部的互相等待，都是没有价值的事情。等待也会推迟问题的暴露和解决时间，所以减少等待就是减少浪费。
据研究一个人若表达能力尚可，大概能表达出70%左右的意思，若对方理解能力尚可，大概能理解70%~80%的意思。若真如此，设想信息从一个人手里传递到另一个人手里，然后再传递到下一个人手里，再往下传，还剩多少了？工作的交接也是一样的道理，经手的人越多，需要交接的地方越多，花费的代价就越高。所以减少交接就是减少浪费。
06
转型效果难以评定：
启用基于业务成果的流框架指标
定期评估研发数字化转型效果
业务成果是数字化研发价值的承载本体，通过检测流框架定义的价值流指标变化可以用于评估转型效果，为成功、改进或退出提供决策支持。
业务价值监测
云加速Vone价值流交付与管理平台，致力于帮助我们的客户消除浪费，提高数字产品交付的效率，通过产品、服务赋能客户研发效能提升。
业务价值监测
