2019.04.04 丨 msup

都996了,需求还是没法按时交付,研发效能提升的关键在这里

2019.04.04 丨 msup

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


导读:在产品开发中,很多管理者往往关注的是各环节的产出以及工程师的忙碌程度,阿里资深技术专家何勉认为,这些局部的优化往往是研发效能改进过程中最大的坑。产品开发的核心问题从来不是停滞的资源(工程师),而是停滞的价值项(用户需求)。如果仅仅关注“停滞的工程师”,我们总有办法让各个资源环节忙起来,至少看上去忙起来,但它往往只是掩盖了问题。停滞的需求才是影响研发效能的关键所在。以下是他的详细分享。


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



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



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

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

“我的钥匙” 醉汉说。

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

“不是!”醉汉回答。

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

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

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

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


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

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



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


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

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

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


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

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



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


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

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

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


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

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

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

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

在这个案例中,我们看到有效的可视化要做到四点:1)用户价值驱动——需求反映用户价值,是流动的主线索;2)前后职能拉通——以端到端的需求交付为线索,连接各个职能和环节;3)左右模块对齐——保证任务向需求对齐,快速交付需求;4)瓶颈问题即时可见。

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

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


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


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

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

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


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

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


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

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


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

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

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

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

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


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

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


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

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

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


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

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


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

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

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

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

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

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

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

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


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


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


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

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

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

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

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



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


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


总结:

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

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

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

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


相信读完此文,大家对研发效能提升有了更深刻的定义和想法,4月20-21日、5月25-26日云效团队成员章屹、苗媛媛将分别于深圳、北京为我们一同分享《企业数字化转型面临的研发效能挑战—阿里DevOps体系和实践》课程,关于如何按时完成的需求相信他们一定会给到你答案,点击此处,即可报名此课程


亮点&收获


亮点:


  • 阿里DevOps体系化方法和实践,集阿里巴巴多年先进的管理理念和工程实践。

  • 高匹配度的客户案例,分享案例来自阿里内部产品线和行业标杆客户案。

  • DevOps沙盘实战,利用工具实战一站式研发生命周期管理服务,体验阿里巴巴交付方式。


收获:本课程从一个完备的精益和敏捷产品创新和交付方法体系,帮助学员掌握和系统应用,提升组织“顺畅、高质量交付有用价值的能力”,助力企业数字化转型和业务成功。



课程大纲



面向人群&目标收益


面向人群:


  • 互联网行业:业务负责人,产品经理、研发中心CTO、技术经理 、架构师

  • 数字化转型类的企业:业务负责人,产品经理、研发中心CTO、架构师

  • 中台业务建设的企业:业务负责人,产品经理、研发中心CTO、架构师


目标收益:


  • 熟悉如何研发效能如何度量、提升研发交付效能

  • 如何进行业务问题分析、产品方案设计、建立快速反馈来保障业务效果

  • 熟悉如何打通和管理产品交付的价值流,从而快速和持续的功能交付

  • 了解和学习阿里研发效能提升的组织管理和实践方法。在实际场景中体会如何来确定有用的用户价值、设定正确的业务目标、解决产品与资源的缺口矛盾、做到按时交付有用的价值和最小的闭环。以及围绕上述目的,产品与技术团队的职责与考核如何设定以及如何借助工具完成

  • 熟悉如何构建完整、流畅的创新循环,形成完整互联网产品的创新和交付模式

  • 了解和学习DevOps落地的问题及解决方案,通过实际的案例掌握DevOps

媒体联系

票务咨询:赵丹丹 15802217295

赞助咨询:郭艳慧 13043218801

媒体支持:景    怡 13920859305

提交需求