想要提高开发人员的工作效率吗？流量才是最重要的

👋🏽欢迎光临“一砖一瓦”。如果你喜欢这篇文章，请与你认为也会喜欢的人分享我的时事通讯。👇🏽。

我最近在下面看到了这条推文，这条推文肯定能让我产生共鸣。据我所知，每一家初创公司都面临着工程人才的严重短缺。但是，招聘是走出这个难题的唯一途径吗？

我记得几年前在一次年度规划会议上，我介绍了工程组织的招聘计划，当时是40左右。该计划要求大幅增加员工人数，以努力跟上对新功能的需求。首席执行官看了看我的演示文稿，问我是否因为“最大限度地发挥了当前团队的生产力”而招聘，而这个问题的答案几乎总是“不”，这确实引发了一场健康的对话。您如何衡量软件工程组织的生产率，雇佣员工是提高生产率的唯一途径吗？我相信这两个问题的答案都是a)很复杂，b)绝对不是这个顺序。

值得一提的是，这个生产力问题并不是我的经验所独有。Strike在2018年进行的一项研究-开发人员系数-显示，开发人员生产率的问题是普遍存在的，也是许多公司面临的主要挑战之一。

“虽然许多人认为缺乏开发人员是主要问题，但这项调查了6个不同国家的数千名C级高管和开发人员的研究发现，如果企业想要更快地行动，开发新产品，并利用新的和新兴的趋势，就需要更好地利用现有的软件工程人才。”“。

衡量软件工程组织的生产力是困难的，但也不是不可能的。多年来，我见过(并使用过)一些糟糕的度量标准，下面我给出几个。

代码行(LoC)因为软件工程师主要关注的是编写代码，然后测量他们在一段时间内写了多少行代码，这应该是他们生产力的一个指标。这不能超过事实。这是一个糟糕的度量的第一个也是显而易见的原因是没有一行代码的标准化定义。其次，代码库大小的增加并不意味着什么。事实上，通常情况下，缩小代码库才是您真正应该做的事情。例如，您可能正在重构编写得很差的代码，这可能会导致较小的代码库。我记得有一次我被要求向潜在投资者提供这个指标。当我向投资者展示我们的代码库在过去一年里缩水时，他们有点不知所措--尽管我们提供了许多关键功能。我们去掉了大量的死代码，并重构了相当多的代码库，结果代码库在一年多的时间里保持不变。

解析的票证数量。这是我多年来见过的另一款。虽然它不像本地的那么可怕，但它也存在缺乏标准化的问题。票证是什么并没有统一的定义。比较两张票也不容易。

积压的大小。这个度量的理论是，不断增加的积压是开发团队跟不上需求的迹象。此度量的问题在于，积压代表开发团队在整个时间内可以构建的所有内容的可能性。任何人(可以说只是PM，但请原谅我)都可以创建一个票证，并将其添加到积压中。这并不一定意味着这张票子会得到实施。优先事项会改变，商业环境也会改变。总会有一部分积压工作永远不会出现。我个人参与了不少于3次吉拉的“清理”，即在某个日期之前创建的票据被简单地删除或移到一个积压的墓地。

所有这些指标的问题在于，它们既没有洞察力，也没有可操作性。代码行数的增加并不意味着什么。这可能是因为合法的原因，比如添加了一个新功能，或者是由于编写不当的代码而出现问题的迹象。仅仅看指标并不能知道潜在的原因。因此它是没用的。充其量，它会让您产生一种错觉，认为您是数据驱动的，并且拥有跟踪组织的指标。我把这些称为虚荣心的衡量标准。

我最近遇到的一个概念是流。MIHály Csíkszentmihályi撰写了大量关于流动状态及其与幸福和充实生活的关系的文章。根据维基百科的说法，

“…。心流，又称区域，是指一个人在进行活动的过程中，完全沉浸在一种精力充沛、全身心投入、乐在其中的操作心理状态。

从那以后，我开始相信，为了最大限度地利用我们的工程团队，你必须为他们提供一个培养这种流畅感的环境。于是，你想要衡量的就是所有阻碍流动的元素。导致流的最关键的因素之一是不间断的时间，在我的经验中，这是阻碍工程生产力的主要障碍。

让我举一个例子来说明这一点。我将做一个有点简单化的假设，即您的普通工程师将时间花在以下活动之一。她进行编码/设计、进行面试、参加会议、响应升级、进行功能规划和优先级排序，或者无所事事。后者通常是等待代码生成、测试运行或被某些外部依赖项阻止的功能。

下图显示了一个典型的软件工程师--让我们称她为Urszula--是如何消磨时间的。厄斯祖拉的时间经常被打断，她很少有机会拥有一大段不间断的时间。她经常被迫参加会议。在其他日子里，她把大部分时间花在面试应聘者上。每隔一段时间，她就会被拉进一场客户升级，这要求她放弃自己正在做的任何事情。

在理想的世界里，Urszula的一天应该如下所示。早上快速地与她的团队同步，然后不间断地花时间构建软件。

为了让Urszula的日子看起来像我们上面描绘的最理想的一天，我们将不得不消除所有在非最佳日子中出现的分心和障碍。提醒一下，这些活动从会议、面试、规划、遗留代码到闲置，应有尽有。下面是我多年来学到并应用的一些解药，它们可以帮助你克服这些障碍。

无论您是构建一个全新的产品，还是构建在现有技术之上，您都必须处理遗留代码。答案是确保您开发的任何代码都经过了适当的测试，这说起来容易做起来难。对质量的严格关注使您能够灵活、快速地开发出高质量的软件。好的测试还提供了很多好处，包括。

虽然本文不是关于测试的，但我将提供几条我认为是良好测试卫生必备的两条指导原则。

首先在可能的最低级别进行测试。也就是说，尽可能使用单元测试，必要时使用小型集成测试，绝对必要时使用大型集成测试，最后使用完整系统测试。较低级别的测试有助于定位缺陷并加快解决速度-当测试失败时，错误代码将被限制在较小的一组行中。它们的运行速度也更快，因此可以提供快速的反馈，并使我们工程师的工作效率更高。

其次，确保您的测试是可重复的。编写不可靠且经常以非确定性方式失败的测试是没有意义的。您希望测试是可预测的。当它们失败时，它们指示您的代码中存在错误。

我一直在关注的一个反模式是，听到开发人员说“针对此代码编写自动化测试太难了，我们将不得不手动/混乱地测试它”。这几乎总是表明分解较差的代码。一段分解得很好、设计得很好的代码应该总是可测试的，更重要的是，它使在上面构建软件变得容易。分解良好且经过良好测试的代码是处理遗留代码(至少是您自己的遗留代码)的最佳解毒剂。

测试不是免费的。您将不得不投资于编写单元级和系统级测试。您还必须投资于支持这些测试的底层基础设施。这项投资绝对物有所值。它将在更高的生产率和更满意的客户方面支付10倍的红利。由于升级较少，后者还会带来更高的工作效率。

让我们面对现实吧，不管你如何努力将干扰降到最低，中断都会发生。因此，您应该通过为您的团队构建减震器(或中断)来计划如何处理这些问题。我发现很难计划的中断是客户升级和面谈。您不太可能提前知道下周将处理多少客户升级。同样，面试往往会起伏不定，尽管至少在短时间内，它们比升级更容易预测。

为了帮助处理这两个中断，我一直依赖于建立两个(志愿者)团队。一个团队将处理升级问题。另一个是处理采访。分配给这些团队的任务是临时性的，升级团队的任务持续90天，面试任务持续一周。

升级团队将与我们的支持组织合作处理任何关键客户升级。原则上，这个团队不应该泄露给一般的工程人员，如果这样做了，我们就会衡量并理解为什么支持或升级团队不能在不通过组织泄露问题的情况下解决这个问题。将升级传递给开发团队的一个附带好处是，它如何在考虑到调试能力和可观察性的情况下推动更好的质量、测试和构建。这反过来会导致更高质量的代码、更少的升级和更高的生产力。

为了进行采访，我安排了多个采访组。每个小组都由工程师组成，他们可以处理每周的面试负荷。如果你是这支球队的一员，你会提前知道你的一周是非常容易被打断的。此外，我与我的招聘团队合作，尝试将大部分面试安排在一周中的一两天，以帮助建立中断时的可预测性。

一般而言，如果您必须处理中断，请尝试将其隔离为尽可能少的个人/团队。建立你的干扰减震器。

我最近偶然发现了Basecamp的ShapeUp框架，并决定在KheIron尝试一下。此框架概述了在承诺开发功能之前需要如何塑造和推介这些功能。

成型阶段通过在范围、高级设计、成本和收益方面添加足够的上下文来充实功能。然后，在选择部分/全部功能并将其分配给开发团队进行实施之前，对所有形状的功能进行推介。分配给所选功能的最长时间是6周，不能保证一旦分配到6周周期结束，该功能就可以获得进一步的资金。一旦6周的周期结束，开发团队就进入了2周的冷却周期，在此期间，他们可以完成以前项目中的任何挥之不去的工作，探索新的想法，等等。与此同时，在此期间，将形成下一组功能，其中几个将被选择用于下一个6周的周期。

这个框架提供了一些我认为值得努力尝试的好处。第一个问题是它如何将规划、范围界定和风险评估(形成)与发展脱钩。这两个活动可以并行完成，如下图所示。之前优先考虑的功能的开发由开发团队完成，而下一步工作的制定则由产品经理和高级工程师处理，通常是技术主管。这还有一个额外的好处，那就是使开发团队不必考虑下一步要做什么--这是塑造者的工作。

另一个好处是将承诺的时间上限设为6周，不保证在分配的周期之后进行进一步投资。这将风险限制在不超过6周，并迫使开发团队持续评估新风险、调整范围、评估权衡，最终目标是在周期结束之前完成其功能(或功能子集)。

我们在KheIron的第一个6周的周期正在进行中，所以时间会告诉我们这个框架的潜在好处是否实现了。就目前而言，它看起来相当有希望！

我再怎么强调这件事的重要性也不为过。投资于持续改进您的基础设施，特别是围绕帮助工程师提高工作效率的工具，这一点至关重要。它通常是软件开发组织中最不受关注的领域之一，尤其是在公司成立初期。拥有一个维护和增强工程师使用的系统和工具的基础设施团队还允许您扩展您的工程团队。如果没有对您的基础设施进行适当的投资，那么随着您的团队的发展，它可能会成为一个瓶颈。最终成为瓶颈的最常见领域是构建和测试时间。这些往往与我们团队中的工程师数量呈线性增长。它们通常表现为让您的工程师无所事事地等待测试结果出来。

你不会真的知道的。试金石是你的团队是否达到了他们的目标，是否感到精力充沛和投入。软件开发是一个创造性的过程，它不像在流水线上构建小部件。

以下是我认为可以很好地反映流量和生产力的一些指标。

CI/CD时间：这衡量构建、测试和潜在地部署软件所需的时间。这段时间的增加并不一定是问题的迹象，但是，它确实需要被证明是合理的，并且必须被理解。根据我的经验，通常不会测量这个周期时间，直到它变得有问题，并且您的开发团队开始抱怨构建时间太长。量一下这个，然后监测一下。了解是什么导致了更改，并迅速对反模式采取行动。

周期时间：此度量度量从开始工作到交付工作的时间量。定义和标准化您所说的“开始”和“交付”是至关重要的。可以说，起点是在规划和范围确定阶段。交付期间是指功能可供您的客户随时使用，即已发货/已发布。如果你使用的是ShapeUp，这个时间应该是6周的倍数。

采访指标：采访时间/周/工程师和漏斗指标。如果你有一个低效的面试结构，后者对帮助你理解这一点很重要。例如，如果您注意到很少有候选人通过您的技术筛选，这可能表示需要调整您的筛选。

升级度量：即使您有一个处理升级的缓冲团队，您也希望测量您得到的升级的频率和数量。更重要的是，您应该找出每次升级的根本原因，并且只有在测试中添加了足够的测试后才关闭它。升级是一个测试鸿沟--弥合它。

参与度：每季度调查一次你的团队是衡量他们参与感和幸福感的绝佳方式。处于这种流程状态并交付高质量软件以取悦客户的团队应该感到高兴，反之亦然。

Shape：Development：这是我添加到我的剧目中的一个新项目，它的目的是测量在6周周期内形成的项目与选择进行开发的项目的比率。当比率为>；1时，这意味着你所做的工作超过了你所能交付的工作，通常情况就是这样。但是，如果这个数字变得不合理地高，这意味着您的团队人手不足，需要更多的开发人员。请记住，在每个周期的末尾，您都要从一系列成形的特性开始-这样您就不会积压越来越多的东西。

最后，提高团队的生产力和招聘并不是正交的活动。你可以两样都做。一定要知道，如果你在生产率方面有很多事情要做，那么你只会通过招聘而不解决潜在的生产率问题来加剧问题。

这种流动和进入区域的感觉既是艺术，也是科学。当你有心流的时候，你就会知道。我曾经和一位销售副总裁共事，他过去常常告诉我“我们还没到那个阶段。”埃里克知道他的球队什么时候进入禁区，就像开足马力一样。可以说，销售团队更容易了解这一点，因为他们有更多的定性指标要跟踪(销售数字)，但这种处于区域中的感觉太真实了。

所以，尽你所能让你的团队进入这个区域，并留在那个区域内！

谢谢你的阅读！如果你喜欢这篇文章，请订阅我的时事通讯👇🏽。我试着每周发表一篇文章。