都 996 了，需求还是没法按时交付，研发效能提升的关键在这里

2019 年 1 月 21 日 DevOps时代

云效鼓励师导读：在产品开发中，很多管理者往往关注的是各环节的产出以及工程师的忙碌程度，阿里资深技术专家何勉认为，这些局部的优化往往是研发效能改进过程中最大的坑。 产品开发的核心问题从来不是停滞的资源（工程师），而是停滞的价值项（用户需求）。 如果仅仅关注“停滞的工程师”，我们总有办法让各个资源环节忙起来，至少看上去忙起来，但它往往只是掩盖了问题。停滞的需求才是影响研发效能的关键所在。以下是他的详细分享。

注：本文是阿里“研发效能提升系列”的第2篇，第1篇“研发效能的定义和度量”敬请期待【下周三】的钉钉群直播（关注云效公众号回复“进群”）。

为了改进研发效能，首先要知道从哪里开始。让我们将从一个故事讲起。

一. 不要做路灯下的醉汉 —— 效能改进从找到关键开始

酒吧门前的路灯下，一个醉汉踉踉跄跄地找着什么，警察远远地看着，十多分钟过去了，终于忍不住走上前去。

“你在找什么？”警察问到。

“我的钥匙” 醉汉说。

警察快速扫视了一下：“没有啊，是丢在这吗？”

“不是！”醉汉回答。

“那干嘛在这找？”警察不解地问。

“只有这能看见啊！”醉汉不耐烦地说。

钥匙的英文是"Key"，也有“关键”和“答案”的意思。路灯照亮的地方，并非“关键”所在。在路灯下寻找不存在的钥匙，当然是愚蠢的。然而，在产品开发中类似情境却一再发生。

在产品开发中，光照亮的是各个局部，比如：各环节的产出怎么样，工程师是否在忙。然而，整体并不是局部的简单叠加。如果缺乏全局的协调，即使各个局部都很繁忙，整体的效率却不一定高。

上图列举了部分长期困扰我们的问题，如：团队协作问题、目标和进度对齐问题、环境稳定性问题、集成问题等。这些都是系统性的问题，根源不在局部，否则，以阿里工程师的能力和责任心，它们早就被解决了。

在错误的地方寻找不存在的钥匙，注定无功而返，甚至适得其反——局部优化损害整体效能，这是研发过程改进最大的坑。研发效能提升的关键究竟在哪里呢？

二. 关注停滞的需求——研发效能改进的关键所在

在《The Principles of Product Development Flow》一书中，作者Don Reinertsen指出：

产品开发的核心问题从来不是停滞的资源（工程师），而是停滞的价值项（用户需求）。

如下图所示，产品交付中的各类问题，都会导致需求停滞。比如常见的协作、环境、工程方法、质量等问题，都会表现为需求停滞，停滞的需求又从根本上损害研发效能，图中列出了其中的一些影响。

如果仅仅关注“停滞的工程师”，我们总有办法让各个资源环节忙起来，至少看上去忙起来，但它往往只是掩盖了问题。解决“停滞的需求”才是根本，为了让需求顺畅流动，我们必须解决各类根本问题，需求的顺畅流动又直接促进了效率、响应能力、灵活性、质量、创新以及士气的提升。

然而，停滞的需求是影响研发效能的关键所在，但是却很少被关注。因为它很难看见，是光未能照亮的地方。

三. 让光照亮关键——可视化端到端的需求流动过程

为改进研发效能，我们不能做路灯下的醉汉。而是要让光照亮关键所在，让需求的停滞以及停滞的原因即时显现，可视化需求端到端的流动过程是做到这一点的基础。

在产品开发中，可视化实践并不新鲜。很多号称应用敏捷开发的团队，都在做，比如：在白板上贴上不同颜色的即时贴，或者应用看板展示工作任务。然而，它们中的大多数只不过是展示团队工作的任务墙，并没有照亮产品交付的关键，对效能改进的作用有限。

什么才是有效的可视化呢？我们先看一个实体看板的例子。下图中，天猫新零售某产品技术团队的看板，它可视化了需求端到端的流动过程。

看板的中蓝色卡片是需求，对应可交付的用户价值。让光照亮关键所在，就是要可视化用户价值端到端流动和交付的过程。

需求在看板上从左至右流动，经过看板上的每个阶段，直至交付。从最左的“选择”列，决定做一个需求开始，直到上线结束。这是一个端到端的过程，拉通了产品、开发、测试、运维等各个前后环节。

单独看"开发中"这个阶段，需求被分解成为任务——图中黄色纸条。任务与其所属的需求处于同一行，我们称之为泳道。泳道的首列（蓝色纸条）是需求，下属任务（黄色卡片)按模块不同放在各自的列内，如前端、后端、以及外部依赖任务等。运行过程中，同一需求下属的任务尽量对齐进度，快速完成需求。所属的任务全部完成后，需求进入待测试，泳道清空，可以让下一需求进入。

以端到端的价值流动过程为基础，团队就能即时看到问题，如：需求是否顺畅流动，在哪里发生了停滞和积压，是否存在瓶颈。这就是所谓：光照亮了问题所在。

在这个案例中，我们看到有效的可视化要做到四点：1）用户价值驱动——需求反映用户价值，是流动的主线索；2）前后职能拉通——以端到端的需求交付为线索，连接各个职能和环节；3）左右模块对齐——保证任务向需求对齐，快速交付需求；4）瓶颈问题即时可见。

其中，第四点是前三点的结果。它们共同作用，让团队看到需求流动（也是价值交付）的端到端的过程，看到需求在流动过程中的状态、问题和瓶颈，奠定持续快速的交付价值，以及持续改进的基础。这就是让光照亮了关键所在。

接下来，我们按这四点，分别介绍可视化价值流动的操作实践。

3.1 业务价值驱动 —— 明确流动单元，建立端到端流动的基础

为了可视化端到端的需求流动，我们首先要明确流动的是什么。它大致可以分为两类：

1）业务需求。它们直接体现业务价值、贡献业务能力，如：用户对产品的需求、业务规划的需求，体验提升需求等。

2）支持性的需求。它们不直接体现业务价值，但帮助更快、更高质量和持续的交付价值，如：基础设施的建设和改进，持续交付管道和自动化测试的建设，技术架构的升级和重构，新的技术框架或算法库的引入等。

不同的产品和组织，对流动单元的分类不同。上表是某个产品交付团队的需求分类，它区分了需求的类别，其输入的规律及处理的规则等。

重点是：需求是价值的载体，是端到端流动和交付的基本单元，可视化的主体应该是从用户出发的需求，而不是组织内部的任务。

3.2 前后职能拉通 —— 确保价值流动过程的端到端

识别了流动的基本单元——需求，接下来要做的是：展现需求端到端的流动过程。

所谓“端到端”，必须从业务视角定义——从业务出发，到业务结束，形成闭环，上图表示了端到端流动过程中的标志性阶段。

前一个“端”是输入。典型的是从需求的选择开始，市场的潜在机会总是无穷的，团队从中选择某些机会，并决定投入，这是价值流的起点。“被选择”的价值项并不能直接进入开发阶段，它需要被分析和澄清，才可以输入给开发。我们称达到这一状态为“就绪”。"就绪"是一个重要的阶段，它决定开发团队的输入质量。

后一个“端”是输出，典型的是需求交付完成，如：在线应用的发布上线，商业软件的交付和实施。还做不到持续发布的团队，有必要区别“待发布”和“已发布”两个阶段，以清晰展示需求停滞在哪里。

选择、就绪、待发布和已发布是四个典型的状态。而中间细分的状态则根据团队的协作和开发模式而异。上一篇关于度量的文章中，反映流动效率的周期时间也是以这四个阶段为基准定义的。

这四个阶段设定了端到端价值流动的框架。以此为基础，团队还要设定流动的具体流程步骤，下一节中将展示具体的实例。

3.3 左右部门（模块）对齐 —— 让开发任务向价值交付对齐

可视化应该体现团队协作和交付价值的过程，下图中的看板再现了团队的前后职能，以及平行模块间协作交付价值的过程。

首先，它反映了环节间的协作。看板上的各个列，代表需求交付的环节。价值项沿各个列顺序流动，体现上下游之间的协作。它们中有些是工作列，如：分析、实现、测试等，价值项在工作列被处理；有些则是等待列，如待评审、就绪、待测试、待发布等。

其次，这一价值流也反映了环节内相关方的协作，如：前、后端的协作，内部团队与外部依赖方的协作等。图中，在实现阶段，一个需求被分解成不同模块以及外部依赖方的任务。需求及其分解出的任务被放在同一横向泳道之中，体现了它们的关联关系。所有下属任务完成了，需求才能移入下一环节——待测试列，它占用的泳道也被清空，等待下一个需求进入。

看板中的每个泳道容纳一个需求，团队的目标是尽快完成需求，而不是每个人手上有任务在做，它确保了任务向需求的对齐，这就是我们所说的“左右部门（模块）对齐”，对齐的对象是需求、是价值。

3.4 瓶颈和问题即时可见 ——暴露阻碍价值流动的因素

价值驱动、前后拉通、左右对齐，这三条原则让价值流动和交付的过程清晰可见。基于这一基础，团队就可以清晰的暴露需求交付过程中的问题和瓶颈。

上图中的看板展示了价值流动中最常见的问题，它们是：

瓶颈：某个环节流动不畅时，需求就会积压形成瓶颈。关注和解决瓶颈，价值才能够顺畅地流动。
中断：指某个步骤供给不足，价值流动出现中断，它意味着上游可能存在瓶颈。
需重点关注的需求：指涉及重大的商业利益或风险的重点需求，这是团队要特别关注，在看板应该重点标记。
被阻碍的需求：指因为外部（如依赖）或内部（如设计问题）原因无法正常进展的需求。
缺陷：缺陷是阻碍需求交付以及返工的重要原因，应该被凸显，并优先解决。
即将或已经到期的需求：有明确的完成时间要求的需求，如果它们即将或已经到期，就应该被凸显，并给与特别关注。
通常，团队会在每日的站会上，检视需求流动的状态，以及流动过程中的问题，关注并即时解决这些问题，让需求更顺畅和快速的流动并交付。关于基于看板的团队站会，我的同事洪永潮有专文介绍。