互联网时代研发效能的挑战和解决之道

最新推荐文章于 2023-10-30 16:38:08 发布

D_ZSX

最新推荐文章于 2023-10-30 16:38:08 发布

阅读量647

点赞数

分类专栏：管理文章标签：敏捷开发

本文链接：https://blog.csdn.net/zhaoshuangxiang/article/details/127301195

版权

管理专栏收录该内容

9 篇文章 0 订阅

订阅专栏

研发效能成为企业的核心竞争力

马云在第四届世界互联网大会指出：过去 20 年互联网从无到有，未来 30 年互联网从有到无，“无”指的是无所不在。未来，任何一家企业的业务都会构建在互联网的基础上。

软件正在吞噬世界。未来，企业的业务都将构建在软件和互联网的基础之上。软件交付能力成为企业的核心竞争力，研发效能成为企业的共同挑战。下图描述了这一挑战状况。

一方面：随着竞争的加剧，业务对研发效能的期望越来越高；另一方面：随着 IoT，以及互联网向产业纵深的挺进，产品和协作的复杂度越来越高，研发效能有下降的趋势。如何弥补期望和现实的差距，这是研发效能提升必须要解决的问题，关键是如何做到呢？

研发效能提升的三个核心思路

为了提升研发效能，我们首先要知道，是什么影响了研发效能——我们究竟面临怎样的挑战?

挑战一：局部效率不等于高效交付

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

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

挑战二：高效交付不等于业务成功

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

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

挑战三：高效交付不等于持续高效

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

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

下图总结了这些挑战和应对。我们的系列课程都将围绕它们展开，构建研发效能的提升的系统解决方案。

接下来，我们会大致介绍一下这三个方面的具体实践。

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

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

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

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

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

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

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

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

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

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

首先我们需要去规划和探索有效的需求。如何去探索呢？过去是以组织和资源为核心，一件东西只要生产出来就有人买，但今天选择权已经从生产方转移到用户侧，用户有越来越多的选择权，所有的公司都是围绕用户来做，这非常像地心说向日心说转移的过程。所以，我们要从以组织和资源为核心转变成以用户价值为核心。如何去做呢？

解决问题的框架如上图所示，整个过程还是比较复杂的，我们会分两个主题来讲，一个是精益创新实践，另一个是精益敏捷需求管理。

精益创新实践主题，关注在如何做价值分析和业务分析，业务分析后了解解决用户的问题是什么、业务目标是什么、解决问题的实现过程是什么样的、实现过程中有什么样的阻碍，这是价值和业务分析的过程。

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

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

很多人也经常会问，怎样把一个很大的需求拆分成一些小一点的需求，其实这也是在澄清和分析的过程。之所以没有去讲需求拆分，因为我们认为它是需求分析的副产物，当带着一个正确的价值观去做，比如要更快的交付时，真正的做到有效需求分析时，需求自然就拆分开来。不应该把需求拆分当成一个独立的话题，你会发现需求拆分在分析过程中自然而然的发生了。
一个莫比乌斯环。希望把这两个探索过程和持续交付的过程真正融为一个整体连接在一起，加快需求分析和探索、反馈的循环，减少其中的摩擦，这才能做到真正的以用户价值为核心规划和探索必要的需求。

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

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

我们可以有两条选择，如下图，一条红线，一条绿线。如果为了追求短期效率，一定会选择红线，就是说开发的越多，接下来做的就越慢，代码写的不好，后面的测试、持续交付又没跟上，所谓出来混总是要还的，前面欠的太多，就需要还债，甚至是利息，如果只是还债，可能就会把这条红线拉平。