都996了，需求还是没法按时交付，怎么办？

最新推荐文章于 2023-12-20 14:55:49 发布

六六子大顺1

最新推荐文章于 2023-12-20 14:55:49 发布

阅读量124

点赞数

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.youkuaiyun.com/cpongo6/article/details/88999655

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

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

$\"\"$

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

\n
“你在找什么？”警察问到。
\n“我的钥匙” 醉汉说。
\n警察快速扫视了一下：“没有啊，是丢在这吗？”
\n“不是！”醉汉回答。
\n“那干嘛在这找？”警察不解地问。
\n“只有这能看见啊！”醉汉不耐烦地说。
\n

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

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

$\"\"$

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

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

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

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

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

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

$\"\"$

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

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

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

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

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

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

$\"\"$

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

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

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

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

在这个案例中，我们看到有效的可视化要做到四点：

\n
用户价值驱动——需求反映用户价值，是流动的主线索；\n
前后职能拉通——以端到端的需求交付为线索，连接各个职能和环节；\n
左右模块对齐——保证任务向需求对齐，快速交付需求；\n
瓶颈问题即时可见。\n

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

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

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

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

\n
\n
业务需求。它们直接体现业务价值、贡献业务能力，如：用户对产品的需求、业务规划的需求，体验提升需求等。
\n\n
\n
支持性的需求。它们不直接体现业务价值，但帮助更快、更高质量和持续的交付价值，如：基础设施的建设和改进，持续交付管道和自动化测试的建设，技术架构的升级和重构，新的技术框架或算法库的引入等。
\n\n

$\"\"$

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

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

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

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

$\"\"$

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

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

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

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

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

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

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

$\"\"$

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

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

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