研发效能提高 36 计第一课：互联网时代研发效能的挑战和应对之道

简介： 《研发效能提高和敏捷实施 36 计》是阿里云联合Teambition打造的系列课程，课程将从团队和项目协做、需求分析和管理、以及业务创新、以及设计编码等 5 个方面，详细介绍研发效能提高的方法、实践和工具，并解析阿里巴巴的实践案例。

前言

互联网时代，业务与协做复杂度与日俱增，竞争日趋激烈，提高研发效能已成为软件行业的共同挑战。《研发效能提高和敏捷实施 36 计》是阿里云联合 Teambition 打造的系列课程，课程将从团队和项目协做、需求分析和管理、以及业务创新、以及设计编码等5个方面，详细介绍研发效能提高的方法、实践和工具，并解析阿里巴巴的实践案例。

本课程是这个系列的开篇，主讲人——阿里研发效能资深专家何勉、张燎原，围绕影响研发效能的三个核心问题，分享了研发效能提高的实践体系。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在互联网开发当中，咱们应该避免效率竖井，可是每每有时因为意识和方法作的不够好，依然存在这样的问题。效率竖井是效能提高的最大限令和误区。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

咱们能够有两条选择，以下图，一条红线，一条绿线。若是为了追求短时间效率，必定会选择红线，就是说开发的越多，接下来作的就越慢，代码写的很差，后面的测试、持续交付又没跟上，所谓出来混老是要还的，前面欠的太多，就须要还债，甚至是利息，若是只是还债，可能就会把这条红线拉平。

团队的高效交付，是应该创建在持续的基础上的。“以长期效率为核心”传递给你们的信息是不要积累债务，而要积累资产，这个资产既包含工程技术的资产，也包含代码的资产。

工欲善其事，必先利期器，咱们要不断的提高工程能力，好比说工具、平台、还有一些好的实践，甚至员工技能的问题。好比说持续交付实践，好比说环境和相应的基础设施建设，可以经过持续集成部署的方式，让代码快速的流动，安全放心的发布软件，发布上机后，安全运维能确保服务的稳定性。

另外一个重要的观念，就是软件资产，经过领域分析、领域建模，发现一个领域资产，而后去沉淀它，让资产盘活、增值，因此这里面讲到设计和代码实践时，资产的评估、评价和优化会是一个比较新鲜的内容。

总结

以流动效率为核心提高团队的持续交付能力；以客户价值为核心规划和探索有效的产品；以长期效率为核心沉淀优质软件资产和工程的能力。这三个核心构成了咱们的研发效能过提高之道。

咱们的研发效能课程将分红 5 个模块。它们分别是：精益创新实践、精益敏捷需求管理、精益和敏捷协做、持续交付实践、设计和代码实践。这五个实践构成完总体系，一方面作到高效交付；一方面实现业务价值，实现从业务到交付的全栈敏捷。

36计系列课程五大主题分享会持续半年的时间，下图是这个体系的概述。

 

本文做者：KB小秘书

原文连接

本文为云栖社区原创内容，未经容许不得转载。