当组织的“改进”想法可以通过给已经在做的工作重贴标签而迅速采纳时，你可以很容易地看出，那不会取得多大的成果。这不是真正的变革，这只是重新包装。
表面上看，价值流管理的概念听起来很好：谁不想生成一个价值流？ 但通常情况下，最终，价值流管理与企业长期以来所做的事情没有太大区别：在大型企业中使用项目管理实践协调不同团队的工作。
价值流只是传统组织的一件外衣
传统组织是由“孤岛”或专注于单个相关技能集的部门组成，包括：应用开发、数据中心运营、质量保证、市场营销、业务管理、风险管理等等。
在这些组织中，“企业”有了开发新产品或改进现有产品的想法，就像流水线上的工人一样，在开发的不同阶段，来自不同部门的人围绕这个想法开展工作，直到在这条“流水线”的尽头下线可供客户使用的东西。
这种“流水线”模式的问题是，团队之间会为交接所累，对于所生产的产品的价值，团队得到的反馈极少，而他们却要据此来做决策（参见图 1）。
他们会以为“企业”知道客户想要什么，所以把重心放在尽量减少生产“价值”时所花费的时间和精力上。但是，由于缺少反馈，组织忽略了最大的浪费源：向客户提供不符合客户需求的东西。
因此，即使是一个经过优化的“价值流”，也往往只是以更快的速度产生浪费。
图 1：“流水线”模型 vs. 获得授权的自治敏捷团队
尽管这样叫，但价值流并不关注价值，而是把工作当成“生产线“来管理。每交付完一个“想法”，就开始关注下一个想法。几乎没有什么“学习”过程，因为想法是从“专家”那里自上而下地流向实施和交付这些想法的团队，后者往往很少甚至不对所交付的价值进行衡量，也很少甚至得不到反馈。当以这种方式实施时，价值流就不是敏捷的，因为他们从未收集和检查过反馈，也从未根据反馈调整其方法。
这个缺陷似乎很容易弥补：只需增加反馈。在每次发布时，衡量下客户的体验是改善了，还是没变化，还是变差了，然后将结果反馈到构思新改进的过程中。这样一来，价值流就真得成了一个循环，关于价值的实验在其中得到了检验。增加反馈循环是有帮助的，但前提是那些循环非常快；如果很慢，需要数月甚至更长时间才能获得针对最初想法的反馈，那么在改善所提供的价值方面，它们就没有多大效果了。
当价值流只是现有筒仓式组织的一件外衣时，从有想法到可以测试所经过的时间太长了，无法为快速测试想法带来真正有用的帮助。如果运行这些价值实验只需几天或一两个星期，那么组织就可以相对快速地决定什么东西有价值，但如果需要数月甚至更长的时间，那么组织就会浪费大量的时间和精力来构建客户既不想要也不需要的东西。
制造思维如何削弱了敏捷性
价值流概念与背后的敏捷和精益生产思维之间的矛盾，表现为多种不同的方式。制造的目标是按照标准规格生产出完全相同的标准产品副本，没有浪费或变化。它会将任何对可预测性的扰动视为需要消除的不良缺陷。精益生产是一种旨在最大限度地减少生产浪费的方法。
敏捷方法的目标是确定需要解决的问题，并针对这些问题制定解决方案。在解决这些问题的过程中，很重要的一点是消除浪费和障碍，因为那可以帮助团队集中精力，用一个精心构建的解决方案来解决正确的问题，但是有些东西，从生产的角度来看会被称为浪费，比如错误问题的解决方案，在团队构建、交付给客户并度量结果之前，是根本无法预见到的。从另一个角度来看，优化产品的构建方式并不能防止生产出对客户没有任何用处的产品。
制造思维完全符合传统组织的理念，即“专家”最擅长的是设计产品，他们以市场研究为基础，以自己的专业知识为依托。制造过程的目标是要完美地实现交给他们的产品定义。他们可能会调整规格，简化产品制造过程，但他们并不关心正在制造的产品是否正确。同样，这完全符合传统组织自上而下的控制理念。
敏捷方法所要构建的产品一般都是一次性的。其目标不是构建一个标准产品的副本，因为在构建的时候还没有完全理解客户的实际需求。其目标是要发现什么才是正确的产品。对于有些产品，一旦组织了解了客户的需求，就可能需要制造更多这样的产品，这时，敏捷实践就不那么有用了，制造流程则会更适用。
当客户的需求正在出现或快速变化时，自上而下的过程无法对反馈做出足够快的响应。更适合这种情况的流程是科学方法的一个变体——形成假设，实验检验，检查结果，并根据结果来调整方法。
价值流会削弱团队的权力
此外，价值流方法可能会削弱团队的权力，而这可能会导致团队成员的冷漠。研究表明，当团队有一个要实现的目标，可以自由决定向客户提供什么以达成这个目标，并自由决定如何工作以向客户提供解决方案时，他们的表现最好。在这种情况下，团队成员的自主性和目的性都很强，积极性也会很高。
当许多团队必须协同工作时，就像他们在价值流中所做的那样，不能简单地给他们制定一个宽泛的总体目标，然后由他们自己决定要交付什么以及如何交付。管理价值流的人定义解决方案并将工作分配给团队，尽管他们可以给团队留一些决定工作方式的空间，但前提是赋予团队的这种自由不会造成团队之间的冲突。 在现实中，处于价值流中的团队只是在执行工作任务，这导致他们的内在动机水平低于他们可以自由定义解决方案的情况。为了做好工作，他们可能仍然会表现出高水平的专业精神，但他们缺乏拥有解决方案时的目的感。
为什么组织会把自己困住？
对于上述情况，他们中的许多人都比我们更了解，但他们觉得自己无法做得更好。他们的“产品”很庞大，不可能由一个小型跨职能团队开发和交付，甚至不可能像 Nexus 那样少数几个跨职能团队协同工作。即使产品可以由一个小型跨职能团队开发，组织孤岛和技术专业化也会给组建跨职能团队造成障碍，因为没有一个具备合适技能的小团体可以开发产品。
当这种情况发生时，组织会尝试创建更大的团队，团队成员在团队之间共享。在协调由兼职成员组成的团队时，他们通常会使用价值流的概念，协调人们跨多个项目开展工作。组织被卡住了，因为他们的产品太大了，他们的组织太分散了，他们无法以其他任何方式工作。 虽然称之为价值流，但它并不能改变一个基本的事实，即他们必须简化产品和组织才能获得更好的结果。
价值流、产品和软件架构
通常，价值流并不能解决的一个根本问题是，组织的“产品”庞大而零散，这就需要一个庞大而且零散的组织来开发和交付。这些“产品”实际上是不同功能的大集合，对它们感兴趣的潜在客户群也可能非常庞大，而且需求也很零散。这些功能的范围往往涵盖了整个业务线，确实非常广泛。
这些“产品”的架构往往也庞大而零散，由许多不同的系统拼凑而成，这些系统开发了许多年，有时是几十年，用途也各不相同。它们的开发和维护由不同的团队负责，导致了一个筒仓式的组织结构。因此，根据定义，这些拼凑起来的“产品”的架构也是筒仓式的。
通常，为了将所有这些不同的系统和团队联系在一起，组织会成立程序架构团队，负责整个价值流团队的整体软件架构。程序架构团队需要协调价值流团队创建的各种软件架构，以消除冗余并推广通用架构元素。
当程序架构团队决定使用会产生浪费的 “预先”架构方法（由基于猜测而非事实的质量属性要求驱动的）时，他们将所有这些不同的架构组件联系在一起的努力往往会失败。结果，他们拖延了价值流团队的工作，提供了可能不符合这些团队要求的架构，而且很可能不得不反复重构。
或者，程序架构团队可能会决定，在比较好地了解了每个价值流的 QAR 后再创建程序架构，这会导致波及每个价值流的延迟，并且随着了解的 QAR 越来越多，可能还需要重构。无论哪种方式，程序架构团队的方法都会放大跨团队的依赖性，从而扼杀了自主性，造成延迟和工作浪费。
要想获得更好的结果，就要采取不同的方法
价值流管理方法的基本问题是，需要很长的时间才能获得有价值的反馈，因此，大多数的产品决策都是基于直觉，而直觉很可能是错误的，也无法通过更严格的价值流管理来解决。虽然反馈循环的速度可以通过专注于消除过程浪费来逐步改善，但通常，那并不足以实现一个组织需要的巨大改进。
为了解决问题，高管们经常寻找会引发急剧变化的短期解决方案，而管理咨询公司则非常乐意向他们推销这类快速解决方案。遗憾的是，他们所期望的结果几乎从来都没能实现。价值流无法解决的问题，其解决方案往往会引发急剧变化，甚至是革命性的，而时间跨度以年为单位。组织要收拾的烂摊子并不是一夜之间出现的，也就不是一朝一夕能解决的。
如果组织想让他们的业务变得更加敏捷、响应更加迅速，那需要一个过程。这个过程涉及到很多工作，需要准备很长的时间。简而言之，包括：
-
他们需要简化产品。如上所述，相对来说，许多组织的“产品”都很零散，没有重点，为许多不同的人做了大量的事，但通常无法满足任何特定群体的需求。通常，这涉及到一组应用程序，它们以某种方式支持某条业务线，但它们是零散的，而且不完整。在这种情况下，组织无法做到让这些大泥球快速响应不断变化的客户需求。
为此，组织需要围绕尚未满足的特定客户（当前或潜在客户）的具体需求来创新产品。组织不需要一下子就做到这一点，它应该将现有“产品”分解成更小、更聚焦的产品；这个过程非常有破坏性，会导致一团混乱，让所有努力都付诸东流。因此，组织要专注于特定的机会，把握契机，走上一条更好的路，而不需要试图一下子清理好整个大泥球。
-
围绕这些新产品，他们需要组建和发展充分授权的跨职能自管理团队。这样可以减少团队之间的交接，缩短决策延迟，这是妨碍价值流方法产生组织所期望的结果的两个主要因素。
对于这些充分授权的团队需要但不具备的技能，可以由专家提供支持，他们可以暂时加入团队，传授知识，或指导团队成员学习新技能。在这个过程中，要确保专家在团队需要的时候可以抽出时间，而不是像平常那样，让团队等待稀缺、昂贵的专家资源来提供帮助。这可能意味着要在短期内雇用更多的专家来支持团队，至少在团队自己能够应对之前。
-
他们需要逐步将遗留的单体应用分解成比较小的产品和支持平台。这涉及到一些技术和方法，帮助团队分解遗留应用，从“大泥球”中慢慢创建出可重用的服务，并针对这个过程中使用的模式和框架逐步创建出可重用代码的平台。 随着这些平台的发展，组织需要奖励对共享平台做出贡献的团队，避免团队出现只关注自己当前需求的自然倾向。这意味着要创造一种技术卓越、成功共享、崇尚专业精神的文化，超越团队并渗透到组织中。
-
他们需要衡量团队交付给客户的结果，并帮助他们提高交付价值的能力。这意味着团队必须经常向客户交付，度量结果，并通过检查结果和进行相应调整来改进。
-
他们需要将重复、单调、容易出错的手工任务自动化，让团队专注于交付价值，经常向客户提供有潜在价值的产品增量，持续不断地构建、测试和部署软件。如果团队不得不把精力花费在手工处理这些任务上，那么他们将无法足够快速地收集反馈信息，及时做出决策。此外，执行繁琐任务的人很容易犯错，造成浪费，而纠正错误时又会延误工作。将这些重复性的任务自动化有助于提高人们的工作效率，减少错误。总的来说，人们广泛将这类任务作为 DevOps 实践来讨论，没有它们，团队就无法运行有效的反馈循环。
当一个组织始终如一地以这种方式对待新出现的机会，并专注提高收集和响应客户反馈的速度时，它就会逐个产品、逐个团队地打造其敏捷性。这种稳定、一致的方法不是很快捷，但它可以不断地取得增量进展，随着时间的推移，带来明显的改善。
小结
做同样的事情却期待不同的结果，那是一种精神错乱，然而，组织却在不断地避免真正的变革，因为他们觉得这会耗费太长的时间，而且会有很大的破坏性。真正的变革是有破坏性的，与组织的文化背道而驰，而且可能持续很长的时间，但只进行表面的变革只会使组织面临更大的挑战，而这样的变革只会招致嘲讽。
通常，组织缺乏一个足够快的反馈循环来指导他们开展工作，使他们能够尝试新的想法并进行实验。此外，他们试图不惜一切代价避免失败，这使得他们不能进行有风险的实验。因为不能进行小而快的实验，所以他们会对那些最终未能达标的想法做过度投资，这使他们更不愿意进行实验了。
对于需要数百或数千人开发的大型产品来说，是没有办法做到敏捷的，因为这样的大型组织无法运行快速的反馈循环。解决办法不是创造一种伪敏捷，使传统组织变得稍微敏捷些；解决办法应该是打破传统的组织结构，大幅提高组织的敏捷性。
这个旅程的第一步是将复杂的产品分解成更简单的产品，与客户结果和细分市场相一致，并通过一个内部开发的公共平台相互连接。充分授权的跨职能自主团队将围绕这些产品开展工作，自行提供各种技术支持，这有助于消除团队之间的依赖关系，减少浪费。
原文链接：
