学习中心> 阿里巴巴研发效能提升实践系列公开课> 正文

阿里巴巴研发效能提升实践系列公开课

7课时 |
2124人已学 |
免费
课程介绍

研发效能肩负着提升企业产品交付和创新能力的责任。然而,如果对研发效能是什么缺乏共同的认知,我们又如何去改进它呢?

本课程将从研发效能的定义和度量着手,逐渐深入解析来自不同业务部门提升持续交付能力的实践、方法和工具,同时还将分享如何基于持续交付能力,切实提升产品和业务创新的效率和效果。

讲师:何勉,阿里巴巴集团研发效能事业部资深技术专家,畅销书《精益产品开发 原则、方法与实施》作者,知名产品交付和创新方法专家。

 

相关的阿里云产品:云效

企业级一站式DevOps平台,支持公共云、专有云和混合云多种部署形态,
通过人工智能、自动化技术的应用提升开发者的研发效能,持续交付有效价值。

了解产品详情: https://www.aliyun.com/product/yunxiao

 

研发效能如何定义

 

目录

一、看待效率的两个视角

二、效率改进的路径

三、研发效能的定义和改进目标

四、总结

 

一、看待效率的两个视角

1.第一个案例/故事

 

“有一个女主人公叫Ellie,有一天在上班的时候,感到自己的胸部有些不适,她觉得自己的乳房可能长了肿块,然后她就去找她约的社区医生,去社区医生那里之后,社区医生给她一些建议,说大概存在危险,你可能需要去中院的胸科医院去检查,但是我建议你在去看胸科医院之前,预约那个真正的医生之前,先去做一个超声和影像的检查,具体来说就是彩超。然后她就听了医生的劝,做完彩超之后发现彩超那边先需要排预约排队,然后等做完彩超之后再去约胸科医院,胸科医院的医生又需要排队,看了医生以后医生说,这个影像资料显示它是有可能有问题,但具体的结果还需要做一个身体穿刺的检查,穿刺的检查就是所谓的组织活检,只相当于一个小的门诊手术;你需要再次预约,然后预约可能又等待了一段时间,比如说一两个星期,一两个星期以后穿刺检查等待结果,等待结果之后,然后等待结果出来再去找医生,让医生给出一个确诊。”

这个过程,从首次接触到确诊,在这个医院花费了42天。

2.第二个案例/故事

 

“这一个女士叫 Sara,遇到的就和Ellie相同的问题,但是他和同事聊天的时候同事就告诉她:如果你使用正当的渠道会有一个漫长的等待过程,这个等待过程是非常令人焦急的,你不如去看看新出现的一站式胸科诊所,于是 Sara就到了一站式胸科诊所,然后接待她的护士说:您这个情况,可以先不用到医生那边去,先做一个彩超检查,然后做完彩超检查我会带你到医生那边去。做完检查之后,结果已经查到了,就到了医生那边去,医生说这个需要做一个生理检查-穿刺检查,然后当时就在诊所做了穿刺检查,然后等穿刺检查出来以后告诉了 Sara结果。”

这整个过程,花费了两个小时。

3.结论

 

两个故事是两种截然不同的模式:一个花费了42天,一个花费了两个小时

从病人的角度来感受的话,这两者就是一个500倍的效率差距,这就引出了对待效率不同的两种视角:

 

涉及到两类角色:一类是医生(除了医生以外,还有检查设备等)称之为资源,他们负责注入价值(他们去接待病人,每一个环节都让他离确诊更进一步,就叫它自我价值);还有一类是病人,病人是接受价值(接受不停的诊断)称之为流动单元。流动单元是各个环节流动直至确诊。

所以对于开发团队、产品开发、软件开发,那么开发团队就是资源;而用户的需求在开发团队各个职能以及各个功能之间流动直至交付,他是一个流动单元。

这是一些抽象的结果。

4.第一家医院采取的战略

 

在第一种模式中,在Ellie这种模式中,如果把镜头对准医生,就会发现医生始终非常繁忙。怎么知道他非常繁忙,因为在后面总是有排队等待医生去确诊或者是去诊断的病人;如果把镜头对准检查设备,比如彩超设备或者手术台,都是始终有人在等待;如果把镜头对准病人,也就是流动单元,就会发现那些病人是走走停停,大部分时间但是在等待的。

这个时候在这里面追求的是什么?追求的是资源效率,也就是资源使用效率。

通过追求资源速率达到的是什么结果呢?最大化资源的使用率。

5.第二家医院采取的战略

 

如果把镜头对准病人,就会病人大部分的时间都在流动,很少处于等待的状态,即使是处于等待的状态也是短暂的等待;如果把镜头对准医生,医生可能会处于一个暂时的空闲状态,这取决于排班安排的合理不合理,但无论如何医生也有可能存在暂时的、短暂的等待或者短暂的空闲。

这里面要最大化的是什么呢?首先把焦点对准了边缘,是希望给病人提供最好的服务、最大化流动单元的流动速度。在这里面流动单元就是病人的流动速度,让病人尽量少的等待(从首次接触到确诊的速度最短)。

6.两种对待效率的方式

 

(1)一个追求资源效率,一个追求流动效率。

(2)它们的不同:

对于追求资源效率来说,焦点显示是资源、各个职能,资源和职能的使用率;目标是高的资源使用率;视角是局部的一个一个资源环节。

对于追求流动效率来说,焦点就是客户和价值;目标是高的价值和流动效率,也就是说这里面的病人从首次接触到确认的时间比较短,要确诊的时间短;视角是不能再是局部,必须是系统的、端到端的(端到端的整个流程,怎么把流程做到最优化确保对用户服务数做到最快)。

 

二、效率改进的路径

1.矩阵内容

(1)矩阵介绍

先画一个矩阵。在这个矩阵图中,横坐标是流动效率,纵坐标是资源效率。坐标的原点都表示低,也就是说最左边的是流动效率最低,最右边的是流动效率最高,最下面的是资源效率低,最上面的是资源效率高。

 

(2)第3象限

第3象限,也就是左下方的,在这里面是资源效率低,流动效率也低。来看一看网上流传的一幅图,在图里面是一人干活十人围观,这时候大家可以想象它的流动效率必然是低的,它的资源效率当然是低的,对用户的响应感觉它的流动效率也是低的。

(3)第4象限

第4象限,所谓的流动效率很高。这是其实画的是一个消防员,消防员的流动效率当然高,出了火情有了事情他第一时间去响应,所以一般称之为高流动效率;那它的资源效率也就是说比如说资源利用率高吗?显然很低。

消防员大部分时间处于空闲状态,因为他的流动效率要求太高了,必须有空闲的资源,随时等待(而且必须等待,因为不知道一个火情什么时候,发生需要多长时间)。所以它牺牲了资源效率来换取流动效率。

(4)第2象限

第2象限,也就是高的资源使用效率。比如说炼钢炉炼,钢炉一旦开启它的费用非常高,然后这时候相关的那些工件就要在后面等待保证及时的工艺(可以等待、可以排队;资源效率可以低,流动效率可以第,但是必须保证炼钢炉的技术供给)。

(5)第1象限

这里面画的是一个快递,快递显然需要高的流动效率(为什么?因为它完善的快)。这是有一个很好的服务来获取竞争优势。

(5)结论

但是光快不行,资源效率也很重要,希望资源使用率也尽量的高,这样能够降低的成本。当然达到这样的目标状态并不容易,其实不可能同时达到流动效率和资源效率的100%,比如说可能要为高峰期时段预留下资源,但是这个背后其实会有相应的机制,让达到资源效率和流动效率相对均衡且更高。
2.产品研发、产品开发、产品交付究竟希望像什么状态

 

其实图中已经画出来了,目标状态是资源效率和流动效率的相对均衡且更高。当然大家可以想象,这并不容易。

3.如何达到资源效率和流动效率的相对均衡且更高

(1)如何去改进

很多组织对自己的效率都不满意(尽管不是图中所说的这种状态),都觉得自己的效率还不够高,资源效率也不够,比如说表现出来的还有很多需求等在那里开发不完、流动效率也不够、对用户的响应非常慢、一个需求从开始到结束经历太长的时间。
这时候就要去改进,如果是图中这种状态,的改进往往就是让所有人都忙起来,让每一个部门都忙起来,这是一个自然的想法。但是不是要光忙起来,要设计、开发、测试、运维都忙起来。但是如果它们忙起来了以后,却缺乏了一个很好协调,让得到的是一个个效率的数据。

(2)仅仅聚焦资源效率的结果
这里看上去PT很忙,看上去每一个部门都很忙,但感觉对用户的响应却很慢,这个就称之为效率竖井。如果你仅仅是聚焦资源效率,就是仅仅看开发、看测试、看前端、看后端,就往往得到的是一个个繁忙的局部,但最后它的对外的响应却不一定很快。

(3)什么是效率竖井

 

①提升效率方法

在这里面产品的交付是需要经过一个一个的资源的阶段或者是职能的阶。,这里面的产品、设计、开发、验证,事实上可能会有更多,比如说前面还有业务、后面还有运营或者运维。

如果各个部门都很忙,他们去改变或者提升他们的效率最好的方法是各自按照各自的优先点来设定,然后各自更大批量的去做,因为大批量、大工业时代也就是说批量带来效率,瀑布式的方法的一批需求去开发完了、设计完了,至于这时候一批需求集中设计对于产品来说可能是相对比较高效的。

②开发阶段

它有不同功能模块的协作,比如说前端、后端、算法、或者对外的依赖,比如说对共享的依赖,对底层SDK的依赖等等。各个职能前后的协调才能交互需求。开发阶段是各个模块要互相协调、互相协作才能交互需求。

③用户的角度

从用户的角度来看,它提出需求到交付需求,可能它的时间并不那么理想。画了一个折线图,在这个折线图中,从单个需求的角度来看,在图里面红色的线下缘(下面的红色的线表示需求在等待,上面的绿色的线表现在需求在被处理),可能一个需求大部分时间在等待,只有一小部分时间在被处理。

什么造成了这个等待:可能是一个批量、一些需求-要等一批需求做完了,才能交给开发(开发要一批需求或者一批代码在一起才能集成或者说才能转给测试-测试要等一批需求集中上线),当然这不是理想的模式。还有另外一个可能是因为大家的互相等待,比如说前端等后端、开发的这一边等共享的那边,或者说交易的和物流之间有相互依赖。但是只有它们俩配合才能交互用户需求,它们之间互相等待。

造成的情况就是图中所发现的:一个需求、一个用户的需求或者业务的需求,大部分时间处于等待状态而处理的时间是很短,这就是流动效率很低需求在走走停停,走走停停。

用户感觉到的交互周期,以及这种需求确认到交付时间很长,这显然不是要看到的状态。这种状态下面它的资源效率不是很高因为互相的等待、依赖会带来带来各种协调的问题、返工的问题等等各种浪费。

所以说对于流动下列资源下列

(4)希望资源效率和流动效率的相对均衡且更高

①困局

 

如果仅仅局限于各个局部所开发的去改变、测试的去改变、运维的去改变,共享的去改变,或者是说各个模块前端后端分别去改变的话,那么一开始可能会带来,资源效率的提高,但是它是无以为继的、难以持续的,因为它会带来局部优化,局部优化会导致协调的困局。就是我这幅图中画的这条黄色的线,它一开始提高,但难以为继,还会因为其他的困局还会下降,所以这一条路径是行不通的。也就是说说的过度的局部优化会损害整体的效力并带来协调的困局。

②效率竖井的根本原因

 

也就是说各个环节和部门繁忙而高效,当然这里面繁忙而高效是打引号的。但总体的效率和对外的响应速度却很低。职员都很忙,但用户或者业务对此却很不满意,当如果去询问的话就会说是响应太慢了,而且最后的产出效率也不高。最终的产出指的是资源,效率竖井往往是因为局部优化导致的,它事实上是研发效能提升的困难的普遍症结所在。

③如何解决

 

  • 以用户价值为核心,打通端到端的价值交付流,改进流动效率
    第一步应该提高流动效率。为了着眼流动性,必须看整体,打通端到端的流程-比如说刚才的端到端例子里面,医院就是从首次接触到确诊的整个流程。那么对于开发,就是从需求到交付的整个流程,希望需求在其中顺畅的流动。

这就是在图里面讲的第1步:以用户价值为核心,而不是以内资内部资源为核心,这里与价值观、客户第一相吻合的;以用户价值为核心打通端到端的交付流程,改进需求的流动效率。这句话的好处:

  • 最直接的好处就是响应能力,在如今的互联网时代,响应能力是非常重要的;
  • 它必然要求系统改进、让相互协调一致、保证整体的协调。

所以先把端到端拉通(拉动了对象,让需求这里面顺畅的流动,保障整体的协调)。

  • 在整体协调的基础上,提升交付速度,同步提升资源效率和流动效率

在整体协调的基础上,提升交付速度,这时候的提升就是一个系统性的提升,而不是局部性的改进,这时候就能带来的同步提升,资源效率和流动效率。

(5)强调

要记住资源效率和流动效率之间的关系;也要记住最终都是为了一个均衡的资源效率和流动效率。

但是本小节强调的是路径问题,路径的第1点:如果一上来就看资源效率,就像很多团队所做的研发效能的改进,往往会造成困境、遇到陷阱,这就是之前所说的效率竖井的陷阱。

一定要从流动效率开始,保证端到端的协调、保证整体协调。在整体协调、系统改进的基础上再去改进交互效率。

 

三、研发效能的定义和改进目标

 

把过去从以局部资源效率为核心的改进变成以用户价值的流动效率为代价为核心的改进,也就是上图右边的从提出问题到解决问题的时候速度要快,当然这背后需要一系列实践,让系统能够端到端的拉通、更加顺畅的交付。但这个交付带来的响应速度,让对用户的响应更快,得到反馈的速度也更快(快速的反馈是创新的一个基础)。

总结下来就是以用户价值流动下列为核心,而非局部的改进,从而提升持续快速交付价值的能力。

研发效能的定义:持续快速交付价值的能力

研发效能改进的目标:以流动效率为核心,寻求系统而非局部的改进,提升持续快速交付价值的能力。

 

四、总结

1.资源效率和流动效率是关于效率的两个视角

2.以资源效率为核心的改进导致局部优化和效率竖井,无法持续

3.提升持续快速交付价值的能力

4.“以流动效率为核心,寻求系统而非局部的改进”,是研发效能改进的有效路径

 

 

我的学习进度
请登录后查看您的学习进度!
立即登录
本课程相关云产品