编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

IT 的发展的历程，也是一部技术和业务相互接近和融合的历程，IT 的交付模式也需要随之进化。

最初 IT 是专业公司及专业人员的工作，IT 开发了什么，业务就用什么。再后来，IT 公司向业务靠拢，更多与客户互动和共创，很多业务公司也有了自己的 IT 开发部门。但，即使在组织内部，IT 也是成本中心，扮演乙方的角色。此时，IT 与业务是分离的，大部分 IT 交付是以项目的形式进行的。

项目的内核是：在特定时间内，以相对确定的预算和人力，交付预先规定的内容。项目追求确定性，注重计划和计划执行。在 IT 与业务分离的时代，这样划清边界，对双方都有好处。相应的，组织也可以按项目来预先规划、分配和执行 IT 预算，而这通常是以年度或至少以季度为单位的。

进入数字化时代，IT 成为业务的一部分。以项目为单位来规划和交付，越来越不能满足即时响应业务的需要。项目面向一次性交付的特点，也不利于资产（特别是软件资产）的长期积累和优化，不利于工程能力及基础设施的持续优化。

上图总结了项目导向的交付模式与产品导向的交付模式的区别。在 DevOp 是实施中，我们主张用尽量采取产品导向的交付模式。

在产品导向的交付模式下，组织应该把技术交付团队看成利润中心而非成本中心，面向产品和业务建设跨功能和相对稳定的产品交付团队，以业务价值和业务响应来衡量和激励产品交付团队。而团队则面向业务价值，持续地迭代和学习，并积累软件资产、工程和技术资产，提升自己的响应和交付能力。

下面我们将介绍产品导向的交付模式的基本要求。

关注长期效率和业务价值

产品导向的交付模式下，产品为长期的业务结果负责。相应的，衡量产品交付团队的标准应该支持业务的效果和效率。我们把产品开发的目标分为 3 个大类：

• 第一：直接服务于当下的业务。这一类目标最容易理解，技术的价值体现为直接的业务成果。此时，产品需求通常来自具体的客户诉求或业务的规划。以下是一些典型的例子：1）构建新的客户服务交付流程，以提高用户交付的效率；2）支持内容敏感的缓存和路由模式，以提高视频观看体验并减低带宽消耗；
• 第二：提前的产品布局。这一类目标并不直接服务当下的业务。它是基于对未来业务和技术方向的判断，做出的提前布局。比如：基于未来业务增长的预测，提前升级分布式架构；为 IoT 战略而做的预研和技术准备。这类目标也是业务驱动的，不过驱动它的是未来的业务。
• 第三：改进交付的效率和效能。除了产品交付本身，团队还要为交付效能负责，包括对业务需求的响应速度、交付的质量、创新的有效性等。比如，通过平台化的能力或业务中台的建设，以更小的工作量和更短的时间交付业务需求。比如通过工程能力的建设，建立系统集成和质量保障体系。

与项目交付不同，衡量一个产品交付团队不再是完成一次性的交付，而是长期的业务价值和效率。它体现为以上三个目标的综合。在设定产品交付团队的目标时，我们也需要按这三个类别来组织。比如团队的 OKR（objective key results 一种目标设定和管理的方法）应该从这三个方面来展开和设定。

把工作分给相对稳定的多功能团队

在人员管理上，项目管理会先规划预算、确定范围、做出计划，再按计划把人分配到项目中。项目结束时，人员被释放，准备进入下一个项目。这一模式下，人被当成可替换的资源。对于确定性高且响应速度要求低的业务，项目的人力配置方式有它的优势，尤其是加大了人员的使用效率。

数字化时代业务的不确定性越来越高，对 IT 的响应速度要求却越来越高，对产品的持续健康演进要求也越来越高。项目管理中的团队组建模式带来以下问题：1）由于每次都要先确定内容，再做出计划、组建团队，必然会延长需求的响应和交付时间，满足不了即时响应业务的需要；2）由于项目团是临时组建的，只对短期的交付负责，很难保证长期的业务结果，同时业务发对产品的长期演进和持续的交付效能负责。

从把人分到事情上到把事情交给团队

在 DevOps 实施中，我们倡导产品导向的交付。就团队组织而言，它的核心变化是：从把“人分配到事情上”转化为“把事情交给人”。更详细的描述是：项目导向的交付模式，把人作为可替换的资源，分配到预先确定范围的事情上；产品导向的交付模式，把事情（也就是动态产生的产品需求）分配给跨职能的交付团队。它的核心变化有两点：

第一，需求的处理方式。项目交付会预先和批量的确定项目的范围，不能即时灵活的响应业务的变化。产品导向的交付，应该持续的响应业务的输入，迭代的进行业务规划，并通过不同优化团队的需求交付价值流，做到持续和快速的需求交付。

第二， 团队的组织方式。产品交付团队是相对稳定的，对长期的产品演进、交付效能、业务贡献负责。为此，这个团队应该是 1）跨功能的，包含产品、开发、测试等角色。只有这样才能直接面向业务，完成产品需求的加氟，才能集体改进交付效能；2）被充分授权的，比如：在满足外部业务需要的情况下，被授权演进自己的协作方式、技术和工程实践。只有这样才能够；3）相对长期稳定的。长期的团队才能对长期的结果负责。

产品导向的交付模式中，产品交付团队是组织的核心，它是跨功能的、被充分授权，并相对稳定的。长期效能是产品交付团队的核心关注，而它很大程度依赖于上产品的演进和工程能力的建设，这是下一节的内容。

持续积累高质量软件资产和团队工程技术能力

理想情况下，随着产品开发的演进，产品提供的基础功能越来越完备，更多的原子功能被封装为软件的接口和服务，成为可复用的组件。这时，满足新的业务需求的成本应该更低。然而，很多时候事实却正好相反，随着技术开发的演进，软件的复杂度越来越高，可扩展和可维护性越来越差，团队对业务的响应越来越慢。

减少负责，积累高质量资产

上图反映了效率随时间变化的两种趋势。决定效率是持续提升还是下降，是我们在开发过程究竟是在积累资产，还是累积债务。

资产指的是今天积累的，会为未来收益的东西。在 IT 产品交付中，良好的资产主要包含：软件资产、工程
资产和组织资产，以下是常见的例子：

• 丰富和设计良好的原子服务；
• 持续逼近业务本质，且具备持续演进能力的领域模型；
• 与概念领域模型一致，且维护良好且有测试守护的设计及编码；
• 良好的工程实践和质量保障体系，如：持续交付流水线以及基于持续交付流水线的质量保障体；
• 良好的团队组织方式和协作机制及实践；

而债务指的是，今天造成的，将来要位置付出的东西。在 IT 产品交付中，以下是常见的债务：

• 糟糕的接口和服务设计，导致重用过程中的麻烦；
• 软件复杂度增加、设计欠佳，造成扩展和维护困难；
• 缺乏有效的测试守护的代码，导致回归测试工作量不断增加，软件质量劣化；
• 组织规模膨胀，协同复杂度增加；
• 缺少有效的工程实践，导致系统的集成、验证成本变大，质量却难以保证；

对待资产和债务的态度，是区分卓越和糟糕的重要因素。一个卓越的产品交付团队，应该不断的积累资产，并消除累积的债务。当然，这里说的并非 100%的避免债务。在特殊情况下，如响应紧急业务诉求是，引入再无在所难免。但，那必须是有意识的权衡，并且将来会有计划的去消除债务。

只有不断的积累资产，以及避免和消除债务，才能让交付效率持续提升，提高产品对业务的响应能力，并提升产品的业务价值。

业务驱动的协作和产品导向的交付相互契合

适配数字化时拥抱不确定性和持续创新的要求，IT 的协作模式和交付模式也需求要演进，我们提倡并践行业务驱动的协作模式和产品导向的交付模式，这两者是天然契合并可以无缝连接的。

协作模式应该是业务驱动的：

• IT 的工作一切源自业务，业务驱动各个职能和功能的协作和快速交付；
• IT 的工作必须回到业务，形成有效的学习闭环，支持业务的创新。

交付模式应该是以产品导向的：

• 从把 IT 看作成本中心，关注资源使用效率，到把 IT 看作利润中心，关注长期和整体的效益；
• 从面向短期的一次批量式性交付，到长期主义的持续交付和持续产品演进；
• 从把人看作可替换资源，为项目组建临时团队，到持续改进的相对固定的多功能团队；
• 从主要关注项目管理的流程资产，到关注架构设计、软件代码、工程能力、团队效率在内全方位的软件、工程和组织资产；

在上一章介绍协作模式时，业务层分解出的产品需求，直接交给产品交付团队，产品交付团队快速的完成产品需求并持续交付，这两个层次相互衔接，完成业务的快速响应、交付和反馈闭环，赋能数字化时代的高效创新。

总结

业务驱动和产品导向是适应数字化时代要求的协作和交付方式，是我们对 DevOps 实施的核心价值主张。同时，它们的有效实施离不开工程实践和能力的支撑，下一章我们将讨论 DevOps 的另一核心要素——持续交付的工程能力。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。