研发效能提高 36 计第二课：照亮问题，效能提高从可视化交付过程开始

摘要：互联网时代，业务与协做复杂度与日俱增，竞争日趋激烈，提高研发效能已成为软件行业的共同挑战。《研发效能提高和敏捷实施 36 计》是阿里云联合 Teambition 精心打造的系列课程，课程由何勉、张刚、张燎原等国内多位在研发效能领域拥有数十年经验的精益敏捷资深专家担任讲师；将从敏捷项目协做、敏捷需求管理、持续交付与工程实践、设计及代码实践、业务创新 5 大方面，首次系统分享阿里巴巴研发效能提高方法、解析阿里巴巴及业界优秀实践案例，并经过工具的直观演示，帮助企业研发管理者们突破研发效能瓶颈、通往业务成功之路。

“提高研发效能”是产品研发的共同目标。可是，应该从哪里开始呢？本次课程，是研发效能提高 36 计系列课程第二课，两位讲师将分享阿里巴巴的经验——从可视化端到端交付过程、暴露问题开始，开启研发效能提高之路。你将了解到：

可视化什么
如何有效可视化的四个步骤
检验可视化效果的三个标准

注：如下内容是演讲视频的精要整理，点击文末连接可前往课程信息合集页面查看往期视频、PPT 以及最新直播预告。

相信你们对可视化并不不陌生。不少敏捷团队，都会使用实体或电子看板来实现信息透明和可视化。至于效果如何，就褒贬不一了。认为有用并坚持的很多，认为是形式主义的也大有人在。

咱们认为，可视化是否有用，首先取决于：“可视化什么?”，

一. 可视化什么？——可视化照亮问题所在

故事发生在酒吧门前，一个醉汉正在路灯下面寻找什么。警察在旁边默默地看着他……，10 分钟过去了，警察忍不住走上前去。
“你在找什么？”警察问道;
“个人钥匙” 醉汉回答 。
“是丢在这吗？”警察看了一眼，并无发现钥匙，因而问到。
“不是” 醉汉回答。
“那为啥在这儿找？”警察不解地问道。
“只有这里能看得见啊”醉汉很不耐烦的回答。

光照亮的地方，并非钥匙（key）所在。英文中，“Key” 除了钥匙的意思外，还有 “关键” 或 “答案” 的意思。可以看见的地方，却不是 “关键” 所在，固然也找不到须要的答案。

研发过程中，咱们是否会范一样的错误？很不幸，不但会，并且还很是广泛。

对于研发过程，咱们容易看到是：人是否繁忙。咱们倾向从汇报线的角度考察各个职能部门的产出，如开发、测试、产品等职能的效率。

然而，致使研发过程的问题,如：集成、质量、进度对齐、需求沟通、环境维护及交付模等。这些问题的根源每每是系统性的，而非局部。它们不是光照亮的地方，也所以容易被忽略。

产品交付中的各种问题会致使需求的停滞，停滞的需求阻碍了价值的顺畅流动，从根本上损害了研发效能。

在软件产品的研发过程当中，其实根本问题历来都不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。

这也为研发过程的可视化提供了方向。研发过程可视化，就是要可视价值端到端的交付过程，让咱们看到价值流动的过程，以及流动过程当中的阻碍、停滞和问题。

可视化的核心是：“照亮问题所在”。

让咱们看一个例子。下图是阿里天猫新零售团队两年前的看板。这个看板从左到右分红了多个列，每列表明一个阶段。看板上蓝色的卡片是需求，它们从左到右，依次通过各个列，其中包括：选择、设计、待评审、待开发、开发设计、开发中、测试等阶段，一直到发布。

咱们看到，“开发中”这一列比较宽，它分红了若干个子列，最前面的这一列叫“需求”，用以停放需求卡片。其余的子列分别是“前端、后端、测试、依赖”，这些子列中的黄色卡片是需求拆分出来的下属任务。任务完成以后，就移到最后一个子列 —— “完成”列。

“开发中”的需求和其下属的任务处于同一行，咱们称之为“需求泳道”。某个需求下属的全部任务都 “完成”后，则需求开发完成,能够继续日后流动到“待测试”，任务则能够清理或折叠。泳道空出，能够准备让下一需求进入。

经过这个看板咱们能够看到需求流动的整个过程，看到需求被拆分红多个任务以及团队协做完成任务的过程。它帮助团队暴露和发现问题，促进团队更好地协做交付需求。为团队的高效协做和价值的顺畅流动奠基了基础。

以上是一个具体的例子，团队各自的状况不同，其可视化模式固然也不同。团队如何结合团队自身的上下文，设计本身的可视化方案呢？这是咱们接下来要介绍的。

二. 如何可视化——四个步骤实现有效可视化

为告终合团队具体的上下文，实现有效的可视化。在实践中，咱们总结了 4 个步骤。

第一步：用户价值驱动，识别有效的流动单元

咱们首先须要分析的是：团队或组织对外交付的是什么，从而识别有效的流动单元，明确可视化的主体。

下图的示例，来自一个真实团队。他们将流动单元分为四种类型。

1. 产品规划类需求：源自产品设计和规划，服务于长期的业务目标；
2. 用户平常需求：产品使用过程当中，来自用户或业务方的平常反馈和要求，开发团队须要及时响应,并按优先级排期开发；
3. 技术改进需求：为了可持续的交付，或技术领先而提出需求，如技术重构、开发测试环境改进以及关键技术的引入等；
4. 问题和缺陷：团队必须即时响应和解决的。

以上四类需求是这个团队须要交付的主体内容，也是看板上的流动单元。

你们能够根据本身团队特色，分析并分类需求，肯定看板上的流动单元。在此基础上，咱们才能够分析和建模价值流动过程，也就是接下来介绍的第二步。

第二步：先后职能拉通，定义端到端价值流

这里用不一样颜色的卡片表明了不一样类型的需求。如：绿色卡片表明用户需求，蓝色卡片表明技术改进需求。

团队须要分析和建模需求流动的过程。上图是其中的一个实例，需求从（被）“选择”开始，通过“分析”、“待评审”阶段到达“就绪”阶段（注：就绪指的是对开发团队而言的就绪）；再通过“实现”、“待测试”、“测试待发布”，最后到“已发布”阶段。这个端到端的过程就是需求交付的价值流。

端到端的价值流动过程,涉及不一样的职能，如产品设计、交互视觉、开发和测试等。为了提高流动效率，必须拉通组织中的各个职能，实现整个过程的可视化。

一些团队由于条件约束，没法当即作到全面的端到端拉通。条件容许，仍是要尽可能向两端扩展，才能实现真正的端到端的敏捷和精益。这也为团队的进化提供了方向。

先后职能拉通是快速交付的基础，除此以外，团队还须要关注环节内的协做，特别是不一样角色的协做，如：先后端开发团队的协做，与外部依赖方的协做等，它也是促进价值快速流动的重要方面，这就是咱们接下来要讨论的“左右模块对齐”。

第三步：左右模块对齐，体现环节的任务协做

环节内任务的协做，从需求的角度来看，反映的是需求的分解和合并。典型的一个例子是：实现过程当中，需求被拆分红不一样的任务，由不一样的职能（如前端、后端、iOS、Andriod、外部依赖方等）完成。

上图中间的“实现”阶段中，绿色卡片所表明的需求被拆分红多个任务（黄色卡片）。这些任务，分属后端、iOS 开发、安卓开发以及外部依赖等。团队的目的不是完成更多的任务，而尽快交付需求。

这就是咱们说的：左右模块对齐，也就是任务向需求对齐，尽早交付需求。它促进团队以需求交付为牵引，更有效的协做，并帮助团队发现影响需求交付的瓶颈。

识别有效流动单元，先后职能拉通和左右模块对齐。这三个步骤让需求交付过程清晰可见,并即时暴露流动过程当中的问题和瓶颈。

不过，为了让团队更有效协做，咱们还必须在此基础上，定义明确的需求流转规则。这也是咱们接下来要介绍的第四步。

第四步：明确流转规则，赋能团队本地决策、内建质量

明确流转的规则，就是定义需求向下一阶段流动所必须知足的条件。好比:达到什么条件才能从“待评审”进入“就绪”环节。团队应该定义明确的需求流转规则，并达成一致理解。

明确流转规则帮助团队作到内建质量。所谓内建质量，是让需求在每个阶段的质量，都获得有效地保证，避免问题在最后的阶段集中爆发，和避免没必要要的返工，这也是持续顺畅价值流动的基础。

如何定义规则呢？让咱们以“就绪”阶段的准入规则为例。

对开发团队而言，“就绪”是他们的输入，输入的质量很大程度上决定了输出的质量。IT行业里面有一句话：“Garbage in,Garbage out”——输入的是垃圾，输出的就必然是垃圾。

一般，咱们指望就绪后的需求可以顺畅地向后流动，而不是问题不断，走走停停。需求进入就绪队列时，问题尚未发生。按项目管理的术语，尚未发生的问题应该被称做风险。典型的有：业务风险——需求是否清晰并理解一致；关联风险——识别对外依赖和获得承诺；技术风险——方案基本可行。

在定义就绪队列的准入规则是，咱们应该考虑以上风险。因而，就有了下面的例子。就绪队列准入规则:

1. 开发、测试和业务共同澄清需求，并定义明确交互过程和验收标准
2. 大需求已拆分为工做量在两周之内能够完成和交付的需求
3. 已与业务关联方（若有）确认相关计划
4. 识别大的技术风险并定义应对方案
5. 涉及三个（含三个）开发人员以上的需求，指定好协调人，负责进度协调

上面以“就绪”列为例，定义了流转规则。基于相似的原则，团队能够定义其它环节的流转规则。

明肯定义的规则应该由团队定义，并共同拥有，团队对它们达成一致的理解和承诺，并基于它们协做和决策。它赋能团队更好的自主决策。一样重要的是,规则并不是一成不变，它是质量保证的重要手段,更是团队改进的基线。

总结 - 可视化价值流的基本步骤

简单回顾一下可视化价值流的四个基本步骤。
第一步: 用户价值驱动,识别有效的流动单元；
第二步: 先后职能拉通，定义端到端的整个价值流；
第三步: 左右模块对齐，反映环节内的任务协做；
第四步: 明肯定义流转规则，赋能团队实现本地快速决策，并保证内建质量。

三. 怎样确保可视化效果？——有效可视化的三个检验标准

如何结合团队自身的上下文，设计本身的可视化方案。每团队均可以去实践，相信会产出许多有特点的方案。

那又如何判断，产出的方案是否有效呢？我将基于在实际实施中的经验，给出三条原则，它对应三个问题。

问题一：能反映端到端的交付过程吗？

问题二：能即时体现影响价值流动的瓶颈和问题吗？

问题三：团队能依据可视化的信息协做和作决定吗？

对这三个问题的确定回答，一直是我设计看板系统的底线要求。事实也证实，作到以上三点，能够为价值的顺畅流动，奠基一个很是坚实的基础。至于如何使得价值流动得更快，就是水到渠成的事了，这部份内容会在后续课程中为你们介绍。

4、总结

不要作“路灯下的醉汉”， “让光照亮问题所在”。这是为了有效可视化,在思惟上所必需要有的转变。为了照亮问题所在，可视化的主体必须是需求、需求的流动过程、以及流动过程当中的问题和瓶颈。基于这一诉求，咱们分享了可视化的四个步骤和三个检验标准。但愿它们能帮助你和你的团队照亮研发效能改进的前路。

下面四幅招贴是对以上总结的形象表述。

最后，可视化是手段——让价值顺畅流动的手段，而非目的。下一讲，咱们将分享如何在可视化的基础上，加速价值的流动。

最新课程直播预告

直播时间：9 月 24 日 20:00 - 21:30

直播主题：第五课：【阶段小结】研发效能提高之路，从天文学的演进提及

直播内容：

研发效能提高是一个系统实践
可是，离开思惟方式的转变
一切实践都将无从落地
而思惟的转变历来不容易

互联网时代，提高研发效能，究竟须要怎样的思惟转变？本次课程将结合天文学演进历程的启示，总结研发效能提高的范式变化，并基于此造成完整的实践体系。

讲师阵容：
阿里云研发效能部资深技术专家、Teambition 客户成功首席顾问 何勉
阿里云研发效能部高级技术专家、Teambition 客户成功资深专家 张燎原

观看方式：
点击此处连接，预定本次网页版直播。

更多课程信息
点击此处连接获取更多课程信息、查看往期视频、PPT 以及最新直播预告。

---

本文做者：Teambition Developer

原文连接

本文为云栖社区原创内容，未经容许不得转载。