正式定档!QCon 北京站改期为2024年4月11-13日,地点:北京·国测国际会议会展中心 >>> 了解详情
写点什么

都 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:079130

评论

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

千万不要往 Shell 里粘贴命令!

大道至简

命令行

自动化测试框架类型,你知道几种?此处介绍5种比较常见的

软测小生

软件测试 自动化测试框架 软件自动化测试

架构师训练营第一周课后作业

李日盛

LeetCode题解:98. 验证二叉搜索树,递归中序遍历过程中判断,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

DDIA 读书笔记(2)数据模型的存储与检索

莫黎

读书笔记

GitLab用户切换引发的某程序员“暴动”,怒而开源项目源码

小Q

Java git 学习 开发 代码仓库

架构训练营第一周学习小结

李日盛

typora增强-mac

老菜鸟

Typora

mPaaS x Menxlab | 1024程序员节:Talk is cheap,Show me the AppID

蚂蚁集团移动开发平台 mPaaS

程序员 开发者 mPaaS 1024

攻克金融系统开发难点,借助SpreadJS实现在线导入Excel自定义报表

葡萄城技术团队

SpreadJS 在线导入excel

全面到哭!BAT内部Java求职面试宝典,必须人手一份!

Java架构之路

Java 程序员 架构 面试 编程语言

数据结构与算法系列之链表操作全集(一)(GO)

书旅

数据结构 数据结构和算法 Go 语言

学了那么多 NoSQL 数据库 NoSQL 究竟是啥

哈喽沃德先生

数据库 nosql 非关系型数据库

JavaScript 类型 — 重学 JavaScript

三钻

Java 大前端

面试官的灵魂一击:你懂 MySQL 事务日志吗?

Java架构师迁哥

架构师训练营 1 期 -- 第五周作业

曾彪彪

极客大学架构师训练营

机器学习是什么?

马同学

学习

学习总结

饺子

spring-boot-route(二十二)实现邮件发送功能

Java旅途

Java Spring Boot 发送邮件

架构必修:领域边界划分方法--职责驱动设计(RDD)

马迪奥

架构 领域 架构师 RDD

Microsoft Azure机器学习采用NVIDIA AI为Word编辑器提供语法建议

1分钟带你get React setState 面试要点

Leo

面试 大前端 React setState

趣味科普丨一文读懂云服务器的那些事儿

华为云开发者联盟

镜像 服务器 服务

vivo 商城前端架构升级—前后端分离篇

vivo互联网技术

Java 大前端 前后端分离

AI让远程交流“更清晰”:GAN消除视频通话中的抖动

吃透阿里大佬整理的Java面试要点手册,成功五面进阿里(二本学历)

Java架构追梦

Java 学习 架构 面试 核心知识点整理

架构师训练营第五周学习总结

尹斌

数据湖探索DLI新功能:基于openLooKeng的交互式分析

华为云开发者联盟

数据 处理

解析 CloudQuery 审计分析功能

BinTools图尔兹

数据库 sql 安全 工具软件

iOS性能优化 — 一、crash监控及防崩溃处理

iOSer

性能优化 ios开发 Crash 监控及防崩溃处理

ArCall功能介绍手册

anyRTC开发者

ios 音视频 WebRTC RTC 安卓

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