云栖君导读：研发效能的提升必须落实为团队需求、协作和工程技术等实践。接下来的几篇文章，我将结合不同BU的案例，介绍研发效能提升的具体实践。
本篇将从团队协作的实践开始，通过可视化端到端的价值流动过程，建立持续快速交付价值的基础。
为了改进研发效能，首先要知道从哪里开始。让我们将从一个故事讲起。
一. 不要做路灯下的醉汉 —— 效能改进从找到关键开始
酒吧门前的路灯下，一个醉汉踉踉跄跄地找着什么，警察远远地看着，十多分钟过去了，终于忍不住走上前去。“你在找什么？”警察问到；“我的钥匙” 醉汉说；警察快速扫视了一下：“没有啊，是丢在这吗？”；“不是！”醉汉回答；“那干嘛在这找？”警察不解地问；“只有这能看见啊！”醉汉不耐烦地说。
钥匙的英文是"Key"，也有“关键”和“答案”的意思。路灯照亮的地方，并非“关键”所在。在路灯下寻找不存在的钥匙，当然是愚蠢的。然而，在产品开发中类似情境却一再发生。
在产品开发中，光照亮的是各个局部，比如：各环节的产出怎么样，工程师是否在忙。然而，整体并不是局部的简单叠加。如果缺乏全局的协调，即使各个局部都很繁忙，整体的效率却不一定高。
上图列举了部分长期困扰我们的问题，如：团队协作问题、目标和进度对齐问题、环境稳定性问题、集成问题等。这些都是系统性的问题，根源不在局部，否则，以阿里工程师的能力和责任心，它们早就被解决了。
在错误的地方寻找不存在的钥匙，注定无功而返，甚至适得其反——局部优化损害整体效能，这是研发过程改进最大的坑。研发效能提升的关键究竟在哪里呢？
二. 关注停滞的需求——研发效能改进的关键所在
在《The Principles of Product Development Flow》一书中，作者Don Reinertsen指出：
产品开发的核心问题从来不是停滞的资源（工程师），而是停滞的价值项（用户需求）。
如下图所示，产品交付中的各类问题，都会导致需求停滞。比如常见的协作、环境、工程方法、质量等问题，都会表现为需求停滞，停滞的需求又从根本上损害研发效能，图中列出了其中的一些影响。
如果仅仅关注“停滞的工程师”，我们总有办法让各个资源环节忙起来，至少看上去忙起来，但它往往只是掩盖了问题。解决“停滞的需求”才是根本，为了让需求顺畅流动，我们必须解决各类根本问题，需求的顺畅流动又直接促进了效率、响应能力、灵活性、质量、创新以及士气的提升。
然而，停滞的需求是影响研发效能的关键所在，但是却很少被关注。因为它很难看见，是光未能照亮的地方。
三. 让光照亮关键——可视化端到端的需求流动过程
为改进研发效能，我们不能做路灯下的醉汉。而是要让光照亮关键所在，让需求的停滞以及停滞的原因即时显现，可视化需求端到端的流动过程是做到这一点的基础。
在产品开发中，可视化实践并不新鲜。很多号称应用敏捷开发的团队，都在做，比如：在白板上贴上不同颜色的即时贴，或者应用Jira，Aone等电子看板展示工作任务。然而，它们中的大多数只不过是展示团队工作的任务墙，并没有照亮产品交付的关键，对效能改进的作用有限。
什么才是有效的可视化呢？我们先看一个实体看板的例子。下图中，天猫新零售某产品技术团队的看板，它可视化了需求端到端的流动过程。
看板的中蓝色卡片是需求，对应可交付的用户价值。让光照亮关键所在，就是要可视化用户价值端到端流动和交付的过程。
需求在看板上从左至右流动，经过看板上的每个阶段，直至交付。从最左的“选择”列，决定做一个需求开始，直到上线结束。这是一个端到端的过程，拉通了产品、开发、测试、运维等各个前后环节。
单独看"开发中"这个阶段，需求被分解成为任务——图中黄色纸条。任务与其所属的需求处于同一行，我们称之为泳道。泳道的首列（蓝色纸条）是需求，下属任务（黄色卡片)按模块不同放在各自的列内，如前端、后端、以及外部依赖任务等。运行过程中，同一需求下属的任务尽量对齐进度，快速完成需求。所属的任务全部完成后，需求进入待测试，泳道清空，可以让下一需求进入。
以端到端的价值流动过程为基础，团队就能即时看到问题，如：需求是否顺畅流动，在哪里发生了停滞和积压，是否存在瓶颈。这就是所谓：光照亮了问题所在。
在这个案例中，我们看到有效的可视化要做到四点：1）用户价值驱动——需求反映用户价值，是流动的主线索；2）前后职能拉通——以端到端的需求交付为线索，连接各个职能和环节；3）左右模块对齐——保证任务向需求对齐，快速交付需求；4）瓶颈问题即时可见。
其中，第四点是前三点的结果。它们共同作用，让团队看到需求流动（也是价值交付）的端到端的过程，看到需求在流动过程中的状态、问题和瓶颈，奠定持续快速的交付价值，以及持续改进的基础。这就是让光照亮了关键所在。
接下来，我们按这四点，分别介绍可视化价值流动的操作实践。
3.1 业务价值驱动 —— 明确流动单元，建立端到端流动的基础
为了可视化端到端的需求流动，我们首先要明确流动的是什么。它大致可以分为两类：
1）业务需求。它们直接体现业务价值、贡献业务能力，如：用户对产品的需求、业务规划的需求，体验提升需求等。
2）支持性的需求。它们不直接体现业务价值，但帮助更快、更高质量和持续的交付价值，如：基础设施的建设和改进，持续交付管道和自动化测试的建设，技术架构的升级和重构，新的技术框架或算法库的引入等。
不同的产品和组织，对流动单元的分类不同。上表是某个产品交付团队的需求分类，它区分了需求的类别，其输入的规律及处理的规则等。
重点是：需求是价值的载体，是端到端流动和交付的基本单元，可视化的主体应该是从用户出发的需求，而不是组织内部的任务。
3.2 前后职能拉通 —— 确保价值流动过程的端到端
识别了流动的基本单元——需求，接下来要做的是：展现需求端到端的流动过程。
所谓“端到端”，必须从业务视角定义——从业务出发，到业务结束，形成闭环，上图表示了端到端流动过程中的标志性阶段。
前一个“端”是输入。典型的是从需求的选择开始，市场的潜在机会总是无穷的，团队从中选择某些机会，并决定投入，这是价值流的起点。“被选择”的价值项并不能直接进入开发阶段，它需要被分析和澄清，才可以输入给开发。我们称达到这一状态为“就绪”。"就绪"是一个重要的阶段，它决定开发团队的输入质量。
后一个“端”是输出，典型的是需求交付完成，如：在线应用的发布上线，商业软件的交付和实施。还做不到持续发布的团队，有必要区别“待发布”和“已发布”两个阶段，以清晰展示需求停滞在哪里。
选择、就绪、待发布和已发布是四个典型的状态。而中间细分的状态则根据团队的协作和开发模式而异。上一篇关于度量的文章中，反映流动效率的周期时间也是以这四个阶段为基准定义的。
这四个阶段设定了端到端价值流动的框架。以此为基础，团队还要设定流动的具体流程步骤，下一节中将展示具体的实例。
3.3 左右部门（模块）对齐 —— 让开发任务向价值交付对齐
可视化应该体现团队协作和交付价值的过程，下图中的看板再现了团队的前后职能，以及平行模块间协作交付价值的过程。
首先，它反映了环节间的协作。看板上的各个列，代表需求交付的环节。价值项沿各个列顺序流动，体现上下游之间的协作。它们中有些是工作列，如：分析、实现、测试等，价值项在工作列被处理；有些则是等待列，如待评审、就绪、待测试、待发布等。
其次，这一价值流也反映了环节内相关方的协作，如：前、后端的协作，内部团队与外部依赖方的协作等。图中，在实现阶段，一个需求被分解成不同模块以及外部依赖方的任务。需求及其分解出的任务被放在同一横向泳道之中，体现了它们的关联关系。所有下属任务完成了，需求才能移入下一环节——待测试列，它占用的泳道也被清空，等待下一个需求进入。
看板中的每个泳道容纳一个需求，团队的目标是尽快完成需求，而不是每个人手上有任务在做，它确保了任务向需求的对齐，这就是我们所说的“左右部门（模块）对齐”，对齐的对象是需求、是价值。
3.4 瓶颈和问题即时可见 ——暴露阻碍价值流动的因素
价值驱动、前后拉通、左右对齐，这三条原则让价值流动和交付的过程清晰可见。基于这一基础，团队就可以清晰的暴露需求交付过程中的问题和瓶颈。
上图中的看板展示了价值流动中最常见的问题，它们是：
瓶颈 ：某个环节流动不畅时，需求就会积压形成瓶颈。关注和解决瓶颈，价值才能够顺畅地流动。
中断：指某个步骤供给不足，价值流动出现中断，它意味着上游可能存在瓶颈。
需重点关注的需求 ：指涉及重大的商业利益或风险的重点需求，这是团队要特别关注，在看板应该重点标记。
被阻碍的需求 ：指因为外部（如依赖）或内部（如设计问题）原因无法正常进展的需求。
缺陷：缺陷是阻碍需求交付以及返工的重要原因，应该被凸显，并优先解决。
即将或已经到期的需求 ：有明确的完成时间要求的需求，如果它们即将或已经到期，就应该被凸显，并给与特别关注。
通常，团队会在每日的站会上，检视需求流动的状态，以及流动过程中的问题，关注并即时解决这些问题，让需求更顺畅和快速的流动并交付。关于基于看板的团队站会，我的同事舍卫有专文 介绍。
四.好的工具让改进事半功倍 —— Aone 看板的新功能全面落地了以上实践和原则
Aone的看板服务，贯彻了前文提到的理念和方法，交互上也针对主要使用场景做了优化。我们来看几个实际使用的案例。
上图是优酷的一个项目团队看板的截图，它反映了端到端的价值流动过程，起到了拉通产品、设计、开发、测试等职能的作用。它支持对需求下属任务分组，并展开显示在同一泳道中，实践上很好的促进了平行功能团队（如：前后端、以及算法及相关依赖方）的任务向需求的对齐。
同时团队基于它形成了顺畅的协作和交付模式，做到了有效协作、顺畅交付和质量内建（在每个过程环节保证质量），通过它以及相关配套实践，团队的协作、交付质量和时效都有了本质提升。
上图是某中台技术团队的例子，他们基于团队看板暴露了需求的严重停滞，团队清楚看到了停滞带来的影响，分析了造成停滞的原因。前后四个迭代，每个迭代都发现并聚焦不同的问题，通过协作、需求、工程等方面的实践解决了这些问题，让需求的流动顺畅起来了，团队交付质量和效率以及团队对外的响应灵活性都显著提升。
在这个例子中，可视化让团队看到了问题和影响，并采取管理和技术的手段去解决这些问题，团队的持续发布和交付效率和质量都得到了明显改善。我的同事 蔡春华 的文章介绍了其效能改进的实施过程，有兴趣的同学可以参考。
Aone 看板的功能是提升团队协作、改善研发效能的有力工具，值得大家去探索和使用。
总结：可视化端到端价值流动，照亮关键所在
“可视化端到端价值流动”是基础实践，它照亮研发过程改进的关键所在，为持续快速交付价值，为研发效能改进奠定基础。
总结:
为了改进产品开发，我们必须让团队看到关键所在——需求的停滞
可视化端到端的价值流，照亮研发效能改进的关键
用户价值驱动，前后职能拉通，左右模块对齐，是可视化价值流动的基础
在可视化价值流动的基础上，做到问题和瓶颈即时和充分的显现和解决
下一篇将介绍在可视化价值流动的基础上，如何让价值真正快速和高质量地流动起来。
作者介绍
何勉，阿里巴巴资深技术专家，国内最早的精益产品开发实践者之一，畅销书《精益产品开发：原则、方法与实施》作者。专注于精益产品交付、精益创业创新及精益产品设计等领域，帮助组织提升研发效能。
end
关于开源分布式事务中间件Fescar，我们总结了开发者关心的13个问题
更多精彩