SoundCloud的产品开发流程

2017 年 5 月，SoundCloud 公司的 CTO Artem Fishman 在内部的工程师年度聚会上，分享了 SoundClou 在的产品开发流程上面临的挑战和应对办法，原文可以在这里找到。

Artem 表示，“我们面临很多产品压力，我们已经非常努力了，但是实际上却还是存在交付延期的情况，我想大家都已经意识到了这些问题，整个流程耗时太长”。

这是 Artem 通过与技术部门的一百多名员工沟通后得出的结论。综合来看，员工会从本质上和直觉上理解这些挑战，而这些都是由于产品开发队列过渡负荷的典型症状。

Artem 随后分为四个部分讲述了软件开发流程的最新进展情况。

• 第一部分分享了 SoundCloud 近期在评估和改进软件产品开发流程上所做的工作。
• 第二部分分享了所改进流程发现阶段的定义和度量办法，并衍生出了用于改进 SoundCloud 产品开发流程的相关策略，包括以下 5 点：
  ①公司应该承诺减少一次交付的产品数量；
  ②团队应该一次开发较少的产品特性；
  ③工程师应该一次完成更少的任务；
  ④工程应该减少代码清单数量；
  ⑤工程应该随着时间的推移，减少 bug 的数量。
• 第三部分分享了持续学习过程和改进流程的指导方针。
• 第四部分和最后一部分分享了努力的初步结果。

Artem 介绍，为了改进业务成果，企业定义了所需结果的评估指标，然后通过观察所采取的行动是否改善或恶化指标，反复达到该结果。SoundCloud 的流程优化小组成员使用生产时间和周期时间，作为产品开发中获得成功的两个重要指标。

这里提到的所谓生产时间是指产品开发和完成之间的时间。在 SoundCloud，这是产品所有者收到工作请求到工作完成之间的时间。周期时间是指产品开始生产到完成之间的时间。在 SoundCloud 中，这是从工程团队收到功能请求到软件部署给用户的时间。

保持生产时间和周期时间较短有四个优点。首先，可以比竞争对手更快地将产品交付给用户，增加了占领市场份额的机会。其次，减少积压的比率。由于新产品的需求变化迅速，最小的积压意味着更快地使用产品想法。再者，涉及到运输产品的规模。专注于缩短交付时间，激励团队提供最有价值的新产品，并对现有产品进行较小的改变，可降低大规模失败的可能性，并降低了失败项目过度投资的可能性。最后，SoundCloud 可以更快地获得产品开发信息。通过快速交付的办法，比竞争对手更快获得市场反馈信息，便于在开发周期的早期获得产品的反馈意见，即可通过对策略进行小幅调整，以此达到其预期的结果。

那么如何提高 SoundCloud 的生产时间和周期时间呢？有以下几个重要的变量。

①WIP 与贡献者的比率

工作进度（WIP）与贡献者的比率是衡量一个团队中平均贡献者多任务处理的标准。可以通过两种方式缩短循环时间，使得 WIP 与贡献者比率保持在 1.0 以下。首先，如果工程师一次开发一种产品，那么产品将比多任务并行执行时更快完成。假设一位工程师被分配了两个任务，每一个都需要两天的时间。他们既可以并行工作也可以一个接一个地工作。这两个选项的时间表如下所示。

在上面的这张表格中工程师并行工作，任务 1 在第 3 天完成，任务 2 在第 4 天完成。工程师交错工作越多，完成这两项任务所需的时间就越长。在极端情况下，每天的多任务处理，这两个项目可能直到第 4 天结束才能完成。

如果现在让工程师进行第一个和第二个工作，第一个工作在第二天完成，第二个工作在第四天完成。通过一次处理一件事，工程师就可以在不增加工作量的情况下完成一项任务！

将 WIP 与贡献者比率小于 1.0 比率的第二个原因是，这关系到个别成员的快速改变开发角色的能力。具体详情，请参阅下面介绍的团队工作流程的理想模型。

如上面这张图所述，软件工程是一种看不见的“U 形”流通池。

工程师需要快速地在计划、开发、审查和修复 bug 之间轮转工作角色。他们在软件开发过程中扮演了多种角色，这种协作模式类似于精细化制造过程中的 U 型流单元。

在 U 形单元格中处理任务是非常有效的，但如果任务队列过度负荷，那么情况就不会是如此了。如果需要进行的任务超过工程师任务进行的进度，任务将形成队列等待情况。例如，工程师开发代码时收到了新的特性请求，将形成一个功能请求队列。此外，他们很可能无法审查队友完成的代码，这会促进评审阶段的第二排队队列形成，因此无论是周期时间还是质量都会受到影响。工程师需要将角色切换到队列形成的位置，从而将任务推到队列中。同理，具有高 WIP 和贡献者比率的重载团队将不能处理传入的 bug 修复和特别请求。

②WIP 中的产品数量

“WIP 产品”是指正在进行的产品。PDKP 通过计算 Jira 项目中代表产品的问题数量，估算出 WIP 中的产品数量。对于大多数团队来说，这是“史诗”还是“故事”的选择问题。产品可以是内部或外部用户，减少 WIP 中的产品数量可以缩短生产时间和周期时间。假设我们有两个任务，每个任务需要四天，并且可以由两位工程师共享，而不需要额外开销。如下所示，这项工作有两个时间表：每位工程师需要完成一项任务，或者第先配对第一位，然后第二位。

在上面这张图里，第一项任务在两天内完成，第二项在四天内完成。我们已经提前两天发货了第一款产品，但没有添加任何工作。配对增加了一些开销，但是通过尽快获得产品信息往往是值得的。这些相同的原则适用于产品开发的规划阶段。

③库存

在企业内部，库存是产品的组成部分，它们是没有被组装成准备出售的产品，包括未部署的代码、RFCs 和未完成的 Jira 问题。代码量的增加是产品销售不佳的一个症状，对周期有负面影响。也就是说，存货越多，我们的用户所看不到的工作积累的时间就越多。一般来说，库存随着产品堆积时间的增长而贬值。

理想情况下，我们希望实现所谓的“单件流”，即所有代码清单都在积极进行的过程。这意味着每个团队最多应该只有一个产品，并且每位工程师正在进行的任务只有一个。

在软件开发中完成一个流程的挑战是，代码库存是不可见的。在一个生产实体商品的工厂里，库存是显而易见的，仓库里随处可见。在软件公司里，情况就不那么明显了。

软件库存与制造库存的方式是不一样的。出于这个原因，我们需要采取措施监控代码库存，并确保其及时交付。

④特征与工程师的比率

特征与工程师的比率衡量指的是团队每位成员平均持有多少特征。较高的比率与更高的错误报告率和维护开销有关，如果一个团队的比率异常高，公司应该考虑为他们提供更多的人员，或重新分配他们的职责，以获得更均匀的分配。

⑤错误

我们接触到的错误是通过 Jira 项目中“Bug”的问题类型数量来估计的，持续的 bug 会对生产时间和周期时间造成负面影响。如果工程师基于存在 bug 的代码基础上构建工程，那么最终的实现可能是有缺陷的，最糟糕的是可能会导致代码浪费，无法继续生产。

⑥按时完成已积压的工作

将一个团队的周期时间乘以待办事项列表中剩余的产品数量，就会降低团队完成待办事项的时间。

大量积压有三个负面影响。首先，它增加了我们的生产时间，过多提前计划会导致团队无法快速完成工作，并且需要从经理和工程师那里获得开发时间。其次，它降低了我们在未来改变计划的灵活性。一旦事情发生在待办事项列表上，团队就会觉得有责任交付于他们。最后, 它降低了积极性。

那么我们需要对此做些什么呢?

项目经理使用了一些方法论，鼓励团队在一段时间内减少产品的工作量，而工程师则在一段时间内完成较少的任务。值得一提的是，指导方针并没有建议团队更加努力。他们的目的是增加注意力，而不是总工作时间。

从 2017 年 3 月开始，PDKP 收集了来自 SoundCloud Jira 和 GitHub 组织的生产时间、周期时间、WIP、bug、贡献者和代码库存指标。到目前为止，已有 18 个工程团队配置了系统来收集生产时间和周期时间的指标，并在 SoundCloud 的 GitHub 组织中收集了开发所需的库存指标。所有的指标都聚集在 PDKP 仪表板和汇总表中，其指导思想包括如下几点：

①公司应该一次承诺减少产品数量

SoundCloud 可以通过减少其提交的产品数量来减少周期时间，并增加其在规划新产品时的灵活性。团队在完成待办事项的时候下限较高，这表示过度承诺是一个问题。

②团队应该一次开发较少的产品特性

如果工作可以并行化，团队应该一次完成一项工作，以完成最大化流程。在产品开发过程中，不可能有足够的调整时间，在任何给定的时间内，每个团队都需要不断前进。

③项目工程师应该一次完成更少的任务

理论上，工程师应该一次完成一项任务，直到完成为止。

在抽取的 18 个团队中，PDKP 报告显示 WIP 与工程师的平均比率始终高于 2.0。当然，在开发软件的时候同时做一件事是不切实际的，重要的是，充分利用工程师时间并不是一个一直有效的办法。排队理论的一个重要结果是，队列中并非所有节点都必须充分利用，而是以最大限度地提高队列的吞吐量。事实上，如果 SoundCloud 的工程师有一点空闲时间就好了。

④工程应该减少它的代码清单

SoundCloud 有着大量的代码清单，减少清单是我们改进度量的一个好方法。

SoundCloud 的团队通过减少库存，成功地增加了流量。内容 ID 小组在两个月的时间内减少了其库存，将开放 PRs 的每日平均提交数量从 46 个减少到不足 5 个，而这些提交的平均时限从 14 到少于 1 天。在此期间，团队的周期时间从 12 天下降到 3 天。

重要的是，代码审查不应该是仓促的行为，更确切地说，最好是在它到达审查阶段时仔细和彻底地审查代码，或者使用持续集成审查过程，将代码合并到主分支中，而不被代码审查阻塞。

⑤工程应该随着时间的推移，减少 bug 的数量

监视和减少团队系统中的 bug 数量对生产和周期时间有积极的影响。SoundCloud 目前正在实现一个标准化的 bug 报告过程。

过度负载的产品队列将从产品经理传导到项目经理和工程师，并且，请注意，过度负载的传导会引起单个工程师和多个工程师之间的调度问题。

产品和工程管理必须指引和支持改变其工作方式以改善流程，特别是一些已成为公司习惯的行为。

以下是针对产品经理的指导方针：

1. 公司应该承诺一次可以完成更少的产品。理想情况下，团队和产品领导层应该就每个团队的产品数量达成协议。
2. 团队应该在一段时间内减少产品特性。产品经理应该在一段时间内对每个产品进行优先级排序，一次一个特性，并鼓励团队尽可能快地交付产品。

以下是针对工程师经理的指导方针：

1. 工作团队应该在一段时间内减少产品特性。工程经理应该意识到在同一时间不要将不同的产品特性写到黑板上。他们应该鼓励团队同时专注于有限数量的特性，最好是一个。他们应该鼓励员工将产品特性划分为子任务，以便在团队中共享，以便焦点得以集中。
2. 工程师应该在一段时间内完成更少的任务——如果可能的话，工程经理应该让他们的团队了解流程管理，并鼓励他们专注于一项任务，直到完成为止。
3. 项目工程应该减少它的代码库存——工程经理应该检查他们团队的代码清单，并鼓励他们保持较少数量的清单。
4. 工程师应该减少 bug 的数量——工程经理应该监视他们团队积压的 bug，并安排他们修复 bug。

以下是针对团队的指导方针：

1. 工程师应该在一段时间内完成更少的任务——工程师应该学习流程管理的基本知识，并在可能的情况下专注于一个产品特性。
2. 工程师应该减少代码库存——工程师一旦进入审查阶段，就应该立即开始审查代码，并在工作受阻时通知其他人。
3. 项目工程师应该监控并减少 bug 的数量——工程师应该修复 bug !

简单地说，可视化控件作为 PDKP 的一部分内容，是为了帮助项目经理改进他们的产品开发流程。这些是在 PDKP 汇总表上显示的，如下图所示。

自从最后一支队伍在 2017 年 6 月 23 日加入 PDKP 项目以来，SoundCloud 的平均前置时间从平均 106.4 天减少到 64.7 天，平均周期时间减少了 52％平均 77.8 天到 37.2 天。

从 2017 年 6 月 23 日起的总领先时间指标。

自 2017 年 6 月 23 日以来的累计周期时间指标。

这种下降与产品和工程领导力相关，成功地将 SoundCloud 团队的 WIP 平均产品数量从平均每个团队 7.4 个产品降低到每个团队 3.1 个产品。

自 2017 年 6 月 23 日起，WIP 产品数量的总体指标在下降
最近，工程师管理人员和工程师团队成功地将我们的代码库存从平均约 1200 个提交减少到大约 500 个提交。

SoundCloud 仍然有很大的发展空间来提高其产品开发流程。具体来说，团队每次工作的产品数量，工程师每一次工作的问题数量，以及其代码清单的数量需要进一步减少。

团队工作的产品数量已经成功减少，但应该可以进一步减少。团队一次平均只能生产 4-5 种产品，虽然整个团队在同一个产品上同时工作并不是合理的，但每个团队的工程师平均数量略低于五（大约五），这意味着还有改进的余地。

工程师在 WIP 中的任务数量没有得到改善，应该减少。自 2017 年 6 月 23 日以来，平均工程师人数保持在 2 人左右，使这个数字接近 1 可能会降低我们的生产和周期时间。SoundCloud 的代码库存量也仍然是一个问题，进一步减少这个数字是减少我们的生产时间和周期时间的又一个大机会，也就是说，SoundCloud 公司已经大大改进了自身的产品开发流程。

总结

正如 Artem 所言，通过管理正在进行的产品开发过程来加快软件交付速度，而不是通过加班来实现交付目标。产品开发过程是指产品开发从想法提出到部署形成的过程，良好的流程意味着产品要快速、连续地通过开发周期。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。