研发效能合理提升之道

:-}

核心思路

局部效率 不等于 高效交付

今天,不管是创业公司还是 BAT 这样的大公司,每个人都很繁忙——至少是看上去是繁忙的。但用户关注的并不是,组织内部繁忙与否,他们在乎的是:需求是不是快速、有效地被满足。对应组织能力就是:需求顺畅和高质量的流动,直至交付。我们称之为(用户价值的)流动效率。

“局部效率不等于高效交付”这是研发效能面临的第一个挑战。为此,我们必须:以流动效率为核心,提升团队的持续交付能力。

高效交付 不等于 业务成功

除此之外,高效交付一定会带来业务的成功么?显然不是,我们还必须保障交付的是有用的需求,而不是高效交付一堆垃圾。只有保证交付的是有效价值,才能助力业务成功。

“高效交付 不等于 业务成功”这是研发效能面对的第二个挑战。为此我们必须:以用户价值为核心,规划和探索有效的产品。

高效交付 不等于 持续高效

第三个方面。仅仅短期高效是不够的。随着时间的推进,一个优秀的组织应该不断积累自己的软件资产,如:技术和业务中台;工程基础设施和能力,如:良好管理的开发、测试环境,持续交付设施等),交付效率持续提高。然而现实中,很多团队的情况恰恰相反,他们积累的不是资产,而是债务——糟糕的设计、劣化的代码、工程能力的缺失,都会让效率不可持续。

“高效交付不等于持续高效”这是研发效能面对的第三个挑战。为此我们必须:以长期效率为核心,沉淀优质软件资产和工程能力。

具体实践

以流动效率为核心提升团队的持续交付能力

典型的效率竖井,即我们常常说的 silo。什么叫效率竖井呢?在产品开发过程中,企业通常是按职能组织团队的,如业务部门、产品部门、开发部门、测试部门及运维部门等,每个职能都可以说自己很高效,从各自的视角去提升效率,看上去每一个职能都很繁忙,看似高效。但是从用户/客户的角度去看,用户关心的是需求是以多快速度交付到他的手中,满足他“所想即所得”的述求。我们看单个需求在研发过程流动的整个周期,从需求提出到完成的整个时间线上,我们分别用红线表示等待时长,绿线表示被处理的时长,红长绿短。为什么会这样呢?

刚才讲效率竖井,如果追求效率,你会如何做呢?可能一些团队会选择攒一批需求,对某个职能来说,批量去做该职能的事情,从直觉上来说是最快的,如产品同学批量去做需求分析、开发同学攒一批需求,一起完成开发。但如果从单个需求的视角来看,问题是什么呢?单个人一段时间只能处理一个需求,其它需求就会处于等待,等待不仅仅是因为批量,还可能是各部门的协调问题,可能是时间上没有对齐,可能一个人做完的东西不是另一个人立即需要的,一人做了 A,一人做了 B,时间上没有对齐。此外,还有一些重要的原因,比如流程的要求,例如要批量做测试,就会造成等待。这种等待从用户角度来看是实实在在的等待;从业务响应的角度来说,它降低了响应;从效率的角度来说,这种等待会导致很多工作的重启,问题延后的发现,不仅降低了流动效率,也降低了资源有效的效率。

在互联网开发当中,我们应该避免效率竖井,但是往往有时由于意识和方法做的不够好,依然存在这样的问题。效率竖井是效能提升的最大限令和误区。

有时面对效率竖井也很无奈,由于组织结构导致了这样的状态。在一些互联网企业,这样的链条不会太长,一些传统型企业的链条则可能更长,有十多个职能。当然,互联网行业也在发生变化,以前没有面临这些挑战,现在也在面临着新的挑战,由于技术变复杂了,有些行业类型的产品的交付链条也在变长,有时候也很难适应,所以这是传统软件开发和互联网软件开发面临的共同挑战。那么我们如何去应对挑战呢?

要把以局部资源效率为核心变成以用户价值流动效率为核心。局部效率看单点资源是否被充分利用,即每个人忙不忙。而流动效率不再指人,是指用户的价值、用户的需求的从起点到终点的流速。当换一个视角时,方法体系也会被重构,所以要以流动效率为核心来提升团队的持续能力交付,用这个视角来重新组织、构建和度量整个研发的过程。

缩短交付周期不仅仅是提升快速交付价值能力,也快速的得到反馈(后续还会讲到快速反馈),可以更好的调整和探索,这就需要看的是系统而非局部的改进。局部是看各个职能模块,系统是看端到端整个完整链条。

为了提升持续、快速交付价值的能力,这需要精益和敏捷协作实践,包括:第一部分端到端的拉通和可视化,即可见到用户需求的交付过程,它有没有走走停停,如果发生了等待是什么原因,只有可见才能管理这个过程;第二部分是怎么管理价值的流动,即可控,控制不是控制人而是流程,目的是让价值的流动更加顺畅;第三部分要讲流动的度量、反馈和持续改进,度量和反馈永远是个热门话题,却又永远也不简单,其中有很多陷阱和误区,我们试图去破解这些陷阱和误区,度量的目的是帮助改进而不是责备谁,它能回答流动效率怎么样,可以在哪些方面改进。

以流动效率为核心提升团队的持续交付能力,把每个人的工作变成一个整体的有效快速交付就够了吗?高效交付不等于业务成功,我们还要以用户价值为核心规划和探索有效的产品。

以用户价值为核心规划和探索有效的产品

从业务目标或者用户目标出发做出两条路,这两条路哪个更重要?有强烈的价值主张的一定是用户目标更重要。一定是从用户目标开始,因为只有解决了用户问题,才能实现你的业务目标。基于它去分析业务,做出迭代规划,后续还会讲组织好这些需求怎样传递给开发。

接下来在精益需求管理主题中,再看如何设计需求,然后做出迭代规划,如何在快速交付情况下把需求交给开发之前保证质量,不仅仅是要把需求写好,更要让开发真正理解需求。所以讲需求分析和澄清,沟通过程很重要,信息不仅要准确地表达,还要无损地传递。

很多人也经常会问,怎样把一个很大的需求拆分成一些小一点的需求,其实这也是在澄清和分析的过程。之所以没有去讲需求拆分,因为我们认为它是需求分析的副产物,当带着一个正确的价值观去做,比如要更快的交付时,真正的做到有效需求分析时,需求自然就拆分开来。不应该把需求拆分当成一个独立的话题,你会发现需求拆分在分析过程中自然而然的发生了。

一个莫比乌斯环。希望把这两个探索过程和持续交付的过程真正融为一个整体连接在一起,加快需求分析和探索、反馈的循环,减少其中的摩擦,这才能做到真正的以用户价值为核心规划和探索必要的需求。

总结一下,以用户价值为核心,规划和探索有效产品,就是把问题给定义出来,再找到一条路径走过去,解决这个问题。

以长期效率为核心沉淀优质软件资产和工程能力

如果为了追求短期效率,开发的越多,接下来做的就越慢,代码写的不好,后面的测试、持续交付又没跟上,所谓出来混总是要还的,前面欠的太多,就需要还债,甚至是利息,如果只是还债,赶工节约的时间早晚会补回来。