从推动到拉动：研发效能提升的第一性原理

点击链接了解详情

img

导语 | 随着企业业务的快速发展，产品迭代速度越来越成为企业发展制胜的关键因素。在业务迅速扩张之下，企业研发团队的规模也在不断壮大。如何有效管理研发团队，又该如何提升企业研发效能，让企业在市场竞争中立于不败之地成为了一堂“必修课”。今天，我们特邀了 Agilean 首席顾问、腾讯云 TVP 吴穹老师 ，他将为我们带来软件研发效能提升的经验分享。

作者简介

img

吴穹，腾讯云 TVP，Agilean 首席顾问，敏捷创新管理专家。北京大学软件工程博士，拥有超过20年行业经验，长期为平安、招行、建信金科等公司提供敏捷咨询服务。1998年创建 Rational 中国，后被 IBM 收购。曾任 IBM Rational 全球产品经理，IJI 大中华区总经理。善于从组织、部门、团队等不同层级着手，助力大型组织在实战中重塑敏捷、催化创新。

不可见的拥堵阻碍了研发效能提升

近几年，各大企业的研发团队规模呈现出了高速增长的趋势。然而，随着团队规模的扩大，却更常出现诸如交付慢等一系列问题。为什么人多了，事情反而慢了呢？

在我看来，当前众多大型组织中软件开发交付慢背后的本质问题是拥堵。

我们可以通过一张图来解释软件开发的拥堵状态。在地图导航中，如果一条路线交通状况良好，有着快速的流动和少量等待，那么这条路线的拥堵程度就相对较低；相反，如果线路等待时间长、流动性差，那么拥堵程度就相对较高。对应到软件研发领域，需求就类似路上跑的车子。需求流动快，就通畅；反之，流动慢，就是拥堵。

img

许多在大型组织中，需求的端到端流动效益通常只有 1% 到 5%。这表明很多需求在研发过程中大部分时间都待在原地不动。这好比你开车上路已经一小时了，但事实上车子真正在移动的时间只有 5 分钟。同时，这种拥堵状态也难以自我改善，就像道路堵塞若不加以干预则会越来越拥挤。许多组织都在拥堵状态中，员工常常感到自己非常忙碌，不断地被高并发和各种事情占用，但回过头来却发现自己其实什么都没做。如果你发现自己很忙碌，且无法专注于某项工作，很可能正处于拥堵状态。

img

在软件开发过程中，存在许多不确定性和意外情况，流动效率 100% 的情况不现实。业界认为开发到测试阶段比较理想的流动效率水平是 40%。

此外，“端到端时效”也是衡量开发效率的一个关键指标。以我们 Agilean 知微这个小型团队为例，从需求讨论到设计、编码、测试、上线的整个流程，P85 时效约为 70 天。而从需求确认到上线，Agilean 知微团队的 P85 时效约为 40 天。对于大型企业来说，需求从确认到上线的时效能做到 70 天就已经相当不错了。

在这个行业中，我们已经经历了两到三次研发效能“运动”。在我看来，合理的研效提升实践能够提高效率，但不当的方法则可能会适得其反。相对价值而言，衡量速度是更容易的。如果整个组织为了提高效率而不顾价值，可能会导致公司在错误的方向上一路狂奔。因此，行业需要对团队效能建立合理的预期，明确交付价值，而不是盲目追求效率。

软件研发拥堵的成因

造成软件开发拥堵的因素有很多，但限期排期机制和滥用工作流是两个最为主要的原因。

img

这样的场景在软件开发领域非常常见：业务让你评估一个需求，你告诉他需要 20 天完成；第二天又来新的需求，然后你再次评估并告知预期。

业务往往会认为需求评估是零成本的，“只是让你估个时间而已”，带着这样的想法，不断往研发推需求。但实际上需求评估是有成本的，需要考虑需求、关联系统分析和排期等因素。研发常常会在这种推动式流程下，下意识过度承诺，到最后连自己也分不清到底承诺了多少需求。本来一个需求确实只需要 20 天就能完成，但是当团队同时要处理多个需求，原本承诺的 20 天也就无法达成了。

推动式的流程会不断拖累研发效率，就像是贴在汽车后保险杠上的标语一样，“越催越慢，再催熄火”。开发团队在很忙的情况下，还要经常被打扰：“这个东西怎么样？什么时候做完？再评估一下，那个进展怎么样？” 导致交付速度越来越慢。

另一方面，是工作流的滥用。在工作流的建模思维影响之下，组织总是企图精确地描述整个软件研发活动。如果想忠于现状会过分复杂，如果试图简化，又无法落地，结果陷于两难。流程无法真实反映工作过程，更不用提管理好工作了。此外，在推动思维的影响下，企业里面常常会要求每个环节步骤精确、自动地指定下一步负责人，但是现实情况无法落地。最后只好开会指定一个专门的负责人，人工地进行任务分发，结果可想而知，这个人就成为了瓶颈，所有事情都卡在他这里了。若要改善这种情况，必须从流程上进行改进。

如何疏通拥堵

在研发流程层面，我们需要建立拉动式流程。建立拉动式流程，关注需求优选，缓解拥堵。一个有序、可信的协同机制是拉动式流程落地的关键，版本火车就是一个经过验证可落地的可靠实践。

在工具层面，我们认为应该将价值流和工作流结合起来。传统组织内，往往只有工作流，而工作流更适用于确定性很高的任务类型。软件开发工作过程本身，很多环节并不那么明确，比如一个需求是否需要单元测试取决于其复杂程度。在有些模糊的问题上，很难精确描述。如果工具里面拿着标准的工作流来管理不确定的研发流程，不仅管不好，甚至会带来阻塞。

价值流可以视为工作流的某种程度的抽象。更适合管理具体流转过程不确定的工作任务，比如需求、研发。

img

我们认为「价值流+工作流的双流模型」才是出路。未来的交付流程核心可能是很多条价值流，这些价值流可能会衍生出多条工作流。类似一个鱼骨结构，价值流是鱼的主骨刺，表示任务的当前状态。至于具体的操作，则体现在许多旁枝的工作流上面。在这种结构下，以高效完成任务为目标，不同团队可以使用他们更为适应的工作流，但不影响任务流转状态的真实性。

img

我们最近也在思考整个 BizDevOps 的平台规划全景图。对于小型团队而言，可能只需要一个工具就能够解决问题。但是在大型组织中，各个领域都在建设自己的工具体系，存在各种不同的工具选择。在这样的背景下，实现工作流层级的标准化有极高的成本。我们认为构建统一的价值流层，在工作流层允许多样化，实行价值流和工作流的分层管理，应该是大型组织 BizDevOps 建设的一个较好选择。

img

工作流层由于其工具选择的灵活性，不同企业间的差异会非常大。价值流层的工具作为工作流的抽象，标准化是十分困难的，应当具备足够的定制化能力。同时，为了适配不断变化的工作流，价值流层也应具备足够的灵活性。

Agilean 知微的建模思路是通过零代码的配置方式来帮助企业应对这种管理复杂性。Agilean 知微目前已经成功集成了腾讯云 CODING 体系，这意味着企业管理组织所需的灵活性和复杂性，以及标准执行过程的高效，这两方面的需求都可以得到满足。

研发效能管理最佳实践案例

以国内某个金融组织为例，通过梳理组织阵型、拆分交付过程、构建研发价值流，借助 Agilean 知微进行组织线上化，并对需求进行端到端全流程在线管理，将所有的流转数据都沉淀下来，在效能大屏形成结构化的数据统计图，为不同层级的管理者提供了差异化的观察视角，并且支持演进。当然，这一过程中，也需要辅助以相应的敏捷实践和活动。

经过一年的努力，上述企业的研发交付时效提升了 30%，需求吞吐量提升了 35%。

img

总而言之，从推动到拉动是提高研发效能的第一原则。我们需要从上游向下游推动需求的流程，转变为下游向上游拉动需求的流程，以缓解拥堵，加快交付。在这个过程中，可以使用“需求前置时间”和“流动效率”这两个关键指标来评估拥堵的改善情况。在此之外，还可以引入版本火车机制建立有序、可信的协同机制，并使用看板透明研发现状、管理需求流动，进一步减少研发过程的等待和拥堵。

img