译者：无敌哥

原文地址: https://thenewstack.io/the-age-of-software-needs-value-stream-architects/ 本文翻译仅供学习交流之用。

原文作者 Mik Kersten 出版了《Project to Product》

本系列共四篇文章，分别是

• 01 从项目到产品：软件需要从物理产品交付中学到什么？|IDCF（点击查看）

• 02 从项目到产品：生产线类比的终结 | IDCF（点击查看）

• 03 从项目到产品：到底是什么应该流经软件价值流？|IDCF（点击查看）

• 04 从项目到产品：软件时代需要价值流架构师 | IDCF

---

“Every system is perfectly designed to get the results it gets.”

“每个系统都经过了完美的设计，以得到它所得到的结果。”

上面这句话，经常被认为是爱德华兹·戴明说的（但很多人也说过类似的），在今天的大规模软件时代跟大规模生产时代非常相像。随着公司努力与像亚马逊这样的颠覆者竞争，一个需要解决的问题是。谁将负责并构建加速商业价值流向客户的软件价值流？微软和亚马逊这样的科技巨头，对这个问题有一个明确的答案——那你的公司呢？

虽然传统上，很多公司为把重点放在企业业务运转的系统架构上，但在很大程度上忽略了用于软件交付系统的IT集成架构。尽管这些 IT 系统对于公司如何通过软件向市场提供价值是至关重要的。因此，在科技巨头和初创企业之外，许多组织并没有一个一致或集成的交付流水线，这个流水线被视为真正的产品，可以带来切实的商业成果。

此外，在交付速度方面，也缺乏对这些系统架构的重视。最令人担忧的是，仅有为数不多的企业 IT 组织设置了价值流架构师的角色，以实现这一至关重要的加速目标。因此，很多组织，投资雇佣开发人员和采用精益方法(如敏捷和 DevOps)，但在获得相应的工具和培训之后，却没有自动获得更多的价值，也就不足为奇了。

即使组织采用了DevOps和其他实践，许多组织仍在努力创建产品价值流的整体视图，从产品组合/功能的基本概念到交付再到客户反馈。之所以缺乏这种连续流和反馈循环的可见性，是由于反馈机制定义不清晰，以及组织无法建立并自动化一个能够预测和影响这些流程的平台。由于产品是通过DevOps流水线交付的，因此将资源集中到能够持续简化和提高整个组织交付速度的领域的能力，对于企业的适应性和成功至关重要。这就是价值流架构师的角色。

价值流架构师是影响者、顾问、优化者和架构师。他们与产品负责人（Product Owner）密切合作，产品负责人主要负责为产品团队承担的所有工作(特性、缺陷、风险和债务)提供资金并安排优先级，以优化、支持整个产品生命周期的团队的业务价值、质量、成本和快乐程度。例如，对于一家银行公司来说，产品可以是一种金融工具，如年金。对于汽车制造商来说，这可能是信息娱乐系统的创新。或者，它可能是一个面向信息技术的信息技术产品，如API，或者是由信息技术人员使用的规划、开发、测试、部署和支持工具组成的集成交付流水线。

价值流架构师角色需要包括如下几个确保成功的因素:

1）可视化

没有对每条业务线/产品的可视化，价值流架构师就像在真空中工作。重要的是，反馈机制的设计和实现要让架构师对整个软件开发和部署过程有一个360度的了解。这些反馈机制是任何价值流架构的核心组成部分。架构师利用这些系统，为软件组合的每个部分提供业务级的价值流可视化。

2）影响

价值流架构师需要组织的支持来推动价值流的每个组成部分的变化。

• 通过收集和分析反馈数据，从而驱动变更，应该采取价值流架构师向每个产品待办列表（PBL）中添加工作项的形式。这些项是架构师通过与团队合作，基于当前的Backlog和预期的业务结果指标，并在回顾中利用价值流指标和反馈而确定的持续改进想法。

• 价值流架构师影响并咨询集成交付流水线的负责人，以推动关于平台和工具的更高层次的决策。这些决策是作为跨所有价值流的组织核心能力来驱动的。

3）架构

业务价值交付的速度高度依赖于组织架构、软件架构和价值流架构的一致性。价值流架构师专注于定义和实现一个架构，该架构包括：

• 创建支持反馈机制的框架以支持反馈和流程。

• 可视化价值流中的每个关键流程。

• 了解当前的制约因素并找出瓶颈。

• 为每个产品的价值流创建目标架构。这项工作的副产品是每个价值流从其当前状态到其目标状态的差距，这些差距将是架构师理解每个价值流的能力和责任的关键。

4）指导和培训

从价值流的整体角度来看，价值流架构师将不断发现，价值流相关人员在培训和技能方面的不足，并将与IT领导合作，以弥补与给定团队之间的知识/技能差距。

随着价值流架构师在各个组织的定义越来越明确，影响越来越大，企业将拥有一项关键资产，它将确保每个系统都经过完美和持续的设计，以获得最重要的业务成果。在软件时代创新，不定义这些角色，类似于试图在没有明确定义工厂运营领导角色的情况下成为汽车生产的领导者。要创建一个交付工厂，使您的团队能够构建优秀的软件，首先要识别并授权您的价值流架构师。

注：这些文章最初发表在 IEEE 软件杂志的“ On DevOps”专栏中，目标读者是对软件体系结构进化感兴趣的读者。

这是一系列来自于Mik的博客，这些核心内容可以认为是 《Project To Product》的起源。对Mik来说，从项目到产品，是一个20年的旅程，开始于作为一个开源开发者的十年学习，并将这些学习应用到他过去十年与 不同行业IT 领导者的合作中。这些帖子代表了他一路上最有趣的学习和合作历程。

我们会持续放出 Mik Kersten 先生（https://www.tasktop.com/blog/author/mik-kersten/）的若干专栏文章。您如果想了解如何在规模化敏捷维度如何提升研发效能，如何实现从项目到产品的转化，也可以同步学习规模化敏捷SAFe框架。（识别二维码，回复“SAFe”即可报名参加）

Mik先生在2019年10月末的SAFe Summit曾做过一次演讲，《Keynote Project to Product From Flow Metrics to SAFe》，专门讲述了规模化敏捷SAFe如何通过打造企业的“第二个操作系统”（即你的新价值流网络）。