从项目到产品：软件需要从物理产品交付中学到什么？| IDCF

译者：无敌哥

原文地址: https://www.tasktop.com/blog/what-software-needs-to-learn-from-physical-product-delivery/ 

本文翻译仅供学习交流之用。原文作者 Mik Kersten ，出版了《从项目到产品》

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

这是一系列来自于Mik的博客，这些核心内容可以认为是 《Project To Product》的起源。对Mik来说，从项目到产品，是一个20年的旅程，开始于作为一个开源开发者的十年学习，并将这些学习应用到他过去十年与不同行业IT领导者的合作中。这些帖子代表了他一路上最有趣的学习和合作历程。这些文章最初发表在 IEEE 软件杂志的“ On DevOps”专栏中，目标读者是对软件体系结构进化感兴趣的读者。

这是我筛选出来的第一篇。如今，这本书的中文版《价值流动：数字化场景下软件研发效能与业务敏捷的关键》由张乐、姚东、李淳、吴非四位译者翻译，王勇审校出版问世了，让我们国内的读者也能在数字化转型的路上借鉴米克.科斯腾的流框架成功转身。

事实证明，这些都是当今最具创新性的软件公司已经采用的做法。现在是其他组织赶上来的时候了。

接下来的挑战是将物理产品开发的关键知识应用到软件交付中。Donald Reinertsen在他的开创性著作《The Principles of Product Development Flow》（https://www.amazon.ca/Principles-Product-Development-Flow-Generation/dp/1935401009）中，概述了其中的一些关键教训，他还指出了只考虑制造过程，而不考虑产品开发端到端过程的缺陷。如果我们以端到端的方式研究软件交付，或混合软件和硬件交付，我们将看到一些常见的应用原则。例如，需要将“交付”组织成一个“产品价值流”，并与客户拉动的价值流相一致，规模化交付的全部努力，都要确保价值的无中断流动。

只有抱着这种心态，我们才能看到软件交付的本质-----一个复杂的协作网络，通过众多专家之间的对话、编码和合作，创造出无形资产。这些协作线形成了一个复杂的网络，需要提供流程、反馈和可追溯性。

这项工作显示了与物质生产的主要区别。例如，没有线性或基于批量的装配线流程，因为与生产相关的所有步骤现在都可以通过 DevOps 方法自动化。我们剩下的类似于 Reinertsen 设想的产品交付艺术: 一个连接的价值流网络。正是这种思维方式决定了产品是如何生产的，并且很快将决定软件交付的未来。

注：本文是最初发表于2019年1月30日的《电子工程时报》的节略版。

这里截取一张原文作者 Mik Kersten（https://www.tasktop.com/blog/author/mik-kersten/） 一次演讲的照片，可以对比一下汽车生产与企业IT研发的区别。

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

• 02 从项目到产品：生产线类比的终结 | IDCF

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

• 04 从项目到产品：软件时代需要价值流架构师 | IDCF20世纪初开始的大规模生产，让我们见证了以工程（Engineering）为基础的组织已经掌握了复杂的产品交付。从那时起，产品的复杂性持续增长，近几年来，不断增长的电子和软件组件进一步推动了这一趋势。例如，在2000年，大约40%的汽车成本是在其电子系统。随着电子元件成为汽车体验的核心，这些系统中的软件也变得更加复杂。我们现在已经到了这样一个地步: 一辆汽车可以拥有几十个电子控制单元和超过2亿行的代码，这些代码的成本超过了引擎本身的成本。

• 

  （图表来源: 《从项目到产品》）

  问题在于，除了科技巨头之外，大多数大型组织在管理物理和电子产品交付方面要比在管理大型软件代码方面做得好得多。这方面的一个例子是，与软件相关的汽车召回率大幅上升，而且一直在稳步上升。2016年，软件缺陷造成的召回数量首次与电子元件相当。

  

  （图表来源: 《从项目到产品》）

  随着软件复杂性的增长，与软件相关的召回率可能会继续以令人不安的速度攀升。具有讽刺意味的是，上个世纪汽车工业用来掌握汽车生产质量和一致性的方法，比如精益生产，却没有充分应用于汽车上运行的软件。但与此同时，汽车正在变成带轮子的电脑。

  许多组织的DNA来自于物理产品交付，由于软件的特性和缺陷不是通过物理制造流程来传递的，因此，许多组织对待软件和 IT 系统的方式不同。但是

• 如果我们把产品开发和精益生产原则应用到软件产品中会怎么样呢？ 

• 如果我们在进入维护模式之前，不再将软件视为具有一年或两年时间框和预算的项目，而是专注于诸如生命周期成本和盈利能力之类的度量标准，那会怎么样？ 

• 如果我们以汽车制造商安排和优化其装配线的方式来组织我们的软件组织会怎么样？ 

• 如果我们衡量的是以客户为中心的产品指标，比如前置时间（Lead Time），而不是目前使用的众多敏捷和 DevOps 指标，又会怎样呢？ 

  事实证明，这些都是当今最具创新性的软件公司已经采用的做法。现在是其他组织赶上来的时候了。

  接下来的挑战是将物理产品开发的关键知识应用到软件交付中。Donald Reinertsen在他的开创性著作《The Principles of Product Development Flow》（https://www.amazon.ca/Principles-Product-Development-Flow-Generation/dp/1935401009）中，概述了其中的一些关键教训，他还指出了只考虑制造过程，而不考虑产品开发端到端过程的缺陷。如果我们以端到端的方式研究软件交付，或混合软件和硬件交付，我们将看到一些常见的应用原则。例如，需要将“交付”组织成一个“产品价值流”，并与客户拉动的价值流相一致，规模化交付的全部努力，都要确保价值的无中断流动。

  只有抱着这种心态，我们才能看到软件交付的本质-----一个复杂的协作网络，通过众多专家之间的对话、编码和合作，创造出无形资产。这些协作线形成了一个复杂的网络，需要提供流程、反馈和可追溯性。

  这项工作显示了与物质生产的主要区别。例如，没有线性或基于批量的装配线流程，因为与生产相关的所有步骤现在都可以通过 DevOps 方法自动化。我们剩下的类似于 Reinertsen 设想的产品交付艺术: 一个连接的价值流网络。正是这种思维方式决定了产品是如何生产的，并且很快将决定软件交付的未来。

  注：本文是最初发表于2019年1月30日的《电子工程时报》的节略版。

  这里截取一张原文作者 Mik Kersten（https://www.tasktop.com/blog/author/mik-kersten/） 一次演讲的照片，可以对比一下汽车生产与企业IT研发的区别。

  

  这是一系列来自于Mik的博客，这些核心内容可以认为是 《Project To Product》的起源。对Mik来说，从项目到产品，是一个20年的旅程，开始于作为一个开源开发者的十年学习，并将这些学习应用到他过去十年与不同行业IT领导者的合作中。这些帖子代表了他一路上最有趣的学习和合作历程。这些文章最初发表在 IEEE 软件杂志的“ On DevOps”专栏中，目标读者是对软件体系结构进化感兴趣的读者。

  这是我筛选出来的第一篇。如今，这本书的中文版《价值流动：数字化场景下软件研发效能与业务敏捷的关键》由张乐、姚东、李淳、吴非四位译者翻译，王勇审校出版问世了，让我们国内的读者也能在数字化转型的路上借鉴米克.科斯腾的流框架成功转身。

  #IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。