最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

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

  • 2019-01-17
  • 本文字数:4305 字

    阅读完需:约 14 分钟

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

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

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


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


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

“我的钥匙” 醉汉说。

警察快速扫视了一下:“没有啊,是丢在这吗?”

“不是!”醉汉回答。

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

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


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


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



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


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

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

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


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


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



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


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

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

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


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


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



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


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


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


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


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


  1. 用户价值驱动——需求反映用户价值,是流动的主线索;

  2. 前后职能拉通——以端到端的需求交付为线索,连接各个职能和环节;

  3. 左右模块对齐——保证任务向需求对齐,快速交付需求;

  4. 瓶颈问题即时可见。


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


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

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

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


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

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



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


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

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

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



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


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


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


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


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

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

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



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


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


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

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

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



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


  • 瓶颈 :某个环节流动不畅时,需求就会积压形成瓶颈。关注和解决瓶颈,价值才能够顺畅地流动。

  • 中断:指某个步骤供给不足,价值流动出现中断,它意味着上游可能存在瓶颈。

  • 需重点关注的需求:指涉及重大的商业利益或风险的重点需求,这是团队要特别关注,在看板应该重点标记。

  • 被阻碍的需求:指因为外部(如依赖)或内部(如设计问题)原因无法正常进展的需求。

  • 缺陷:缺陷是阻碍需求交付以及返工的重要原因,应该被凸显,并优先解决。

  • 即将或已经到期的需求:有明确的完成时间要求的需求,如果它们即将或已经到期,就应该被凸显,并给与特别关注。


通常,团队会在每日的站会上,检视需求流动的状态,以及流动过程中的问题,关注并即时解决这些问题,让需求更顺畅和快速的流动并交付。

好的工具让改进事半功倍 —— 云效看板的新功能全面落地了以上实践和原则

云效的看板服务,贯彻了上文提到的理念和方法,交互上也针对主要使用场景做了优化。我们来看几个实际使用的案例。



上图是优酷的一个项目团队看板的截图,它反映了端到端的价值流动过程,起到了拉通产品、设计、开发、测试等职能的作用。它支持对需求下属任务分组,并展开显示在同一泳道中,实践上很好的促进了平行功能团队(如:前后端、以及算法及相关依赖方)的任务向需求的对齐。


同时团队基于它形成了顺畅的协作和交付模式,做到了有效协作、顺畅交付和质量内建(在每个过程环节保证质量),通过它以及相关配套实践,团队的协作、交付质量和时效都有了本质提升。



上图是某中台技术团队的例子,他们基于团队看板暴露了需求的严重停滞,团队清楚看到了停滞带来的影响,分析了造成停滞的原因。前后四个迭代,每个迭代都发现并聚焦不同的问题,通过协作、需求、工程等方面的实践解决了这些问题,让需求的流动顺畅起来了,团队交付质量和效率以及团队对外的响应灵活性都显著提升。


在这个例子中,可视化让团队看到了问题和影响,并采取管理和技术的手段去解决这些问题,团队的持续发布和交付效率和质量都得到了明显改善。


云效的看板的功能是提升团队协作、改善研发效能的有力工具,值得大家去探索和使用。

总结:可视化端到端价值流动,照亮关键所在

“可视化端到端价值流动”是基础实践,它照亮研发过程改进的关键所在,为持续快速交付价值,为研发效能改进奠定基础。


总结:


  • 为了改进产品开发,我们必须让团队看到关键所在——需求的停滞。

  • 可视化端到端的价值流,照亮研发效能改进的关键。

  • 用户价值驱动,前后职能拉通,左右模块对齐,是可视化价值流动的基础。

  • 在可视化价值流动的基础上,做到问题和瓶颈即时和充分的显现和解决。




作者简介


何勉,阿里巴巴资深技术专家,国内最早的精益产品开发实践者之一,畅销书《精益产品开发:原则、方法与实施》作者。专注于精益产品交付、精益创业创新及精益产品设计等领域,帮助组织提升研发效能。


2019-01-17 17:079157

评论

发布
暂无评论
发现更多内容

实战分享 | 金融数据采集报送平台实践

葡萄城技术团队

TiCDC 源码阅读(四)TiCDC Scheduler 工作原理解析

PingCAP

数据库 开源 TiDB 源码解读

re:Invent 开发者最喜爱产品票选榜单出炉!快来探索高光产品~

亚马逊云科技 (Amazon Web Services)

开心档-软件开发入门之MongoDB 覆盖索引查询

雪奈椰子

mongodb Ppython 操作mongodb库 开心档

CompletableFuture实现异步转同步

FunTester

如何让OpenHarmony编译速度“狂飙”

离北况归

OpenHarmony

学习web前端培训怎么样?

小谷哥

选择前端培训怎么学?

小谷哥

冗余是什么意思?与双机热备有什么区别?

行云管家

高可用 冗余 双机热备

Studio One2023永久和谐版水果编曲工具使用教程

茶色酒

Studio One 5 Studio One2023

sun4.0泰山众筹模式项目系统开发技术讲解放哪(Demo)

I8O28578624

java开发培训机构怎样选择?

小谷哥

杭州银行牵手火山引擎数智平台,要既“好”又“快”地完成数字化升级

字节跳动数据平台

大数据 金融 银行

TAE-MatrixOne云原生事务与分析引擎

MatrixOrigin

数据库事务 云原生数据库 国产数据库 MatrixOrigin MatrixOne

杭州云堡垒机采购选择哪家好?为什么?

行云管家

云计算 网络安全 数据安全 云堡垒机

OpenHarmony标准系统内核学习【2】CPU轻量级隔离特性

离北况归

OpenHarmony

防sql注入原理浅析

追赶者

SQL注入

9种跨域方式实现原理

华为云开发者联盟

开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

火山引擎ByteHouse助力中国地震台网中心,快速构建一站式实时数仓

字节跳动数据平台

大数据 Clickhouse 数据平台

Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题

阿里巴巴中间件

Java 阿里云

邀请 | Flink Batch 社区开发者会议

Apache Flink

大数据 flink 实时计算

带你读论文丨S&P21 Survivalism: Living-Off-The-Land 经典离地攻击

华为云开发者联盟

人工智能 华为云 论文 企业号 2 月 PK 榜 华为云开发者联盟

如何使用 Terraform 在亚马逊云科技上创建 ShardingSphere Proxy 高可用集群?

亚马逊云科技 (Amazon Web Services)

数据库 负载均衡 存储

零基础自学网络安全/网络渗透攻防路线学习方法【建议收藏】

网络安全学海

黑客 网络安全 安全 信息安全 渗透测试

使用插件扩展服务网格

Flomesh

插件 服务治理 服务网格 Pipy

R2M分布式锁原理及实践

京东科技开发者

redis 框架解析 企业号 2 月 PK 榜 r2m 分布式锁原理

开心档-软件开发入门之MongoDB 创建集合

雪奈椰子

mongodb 开心档

前端培训学习前景怎么样?

小谷哥

一文搞清商旅酒店数据治理——酒店数据问题分析及治理方案

元年技术洞察

数据中台 数据 数据治理 企业数字化转型 商旅系统

一个成熟的WMS(仓库管理系统)应该具备的那些功能

SAP虾客

功能 WMS系统 成熟的WMS系统

个人总结18条心法奉上,手把手带你阅读开源项目的源码!

程序员小毕

源码 程序员 面试 程序人生 架构师

都996了,需求还是没法按时交付,怎么办?_DevOps & 平台工程_何勉_InfoQ精选文章