没法跟员工面对面的时候，该怎么评估他们的工作？

疫情改变了人们工作的方式，越来越多的人采用远程、分布式办公。新的工作方式下，管理者该如何评估员工的工作？旧有的模式还是否能适用？GitHub 的研究与战略副总裁 Nicole Forsgren 博士是迄今为止规模最大的DevOps研究的首席研究员，她基于公司的实验和长期观察，给出了新办公模式下评估员工生产率的新思路和方法。

提高生产率意味着什么? 在疫情期间，许多员工选择远程办公，管理者们开始考虑对员工实行考核——工作时长、目标或其他指标。然而，这种做法可以追溯到100年前两次工业革命时期，在机器革命和电气革命中，生产率是一种评估产出的指标，助推了经济发展。通过合理运用这种评估方式，我们创造出了汽车、机器和零部件。

如今，这种评估思维模式已经不仅仅停留在经济层面，企业甚至国民经济（通过GDP评估）都依赖知识和数字技术的效率支撑我们所有的体系，无论是医疗保健体系、银行体系还是零售体系。然而，这种思维模式并不是只考虑效率，它涉及到多种维度。以拍照片为例: 过去拍照片非常昂贵且稀缺（用胶卷，而不是数码相机)，所以拍摄和打印的照片数量可以被当作评估生产率的一个维度。但是，当每个人都可以用手机拍出高级照片，且能立即查看，并几乎免费地存储照片时，提高生产率便不再意味着拍更多的照片，而是发掘海量照片背后所蕴藏的机遇——例如，在医学领域，利用照片（通过机器学习）进行早期癌症诊断。

现在，如果我们用产出来评估相机的生产率，便不会得到任何有关消费者幸福感的信息，更不用说GDP了。经济学家哈尔•瓦里安(Hal Varian)多年来一直在鼓吹这种所谓的“生产率悖论”，现代经济研究和价值创造的前沿人士也在宣扬这一观点。当前，人们对远程、线上、分布式工作的接受度越来越高，我们如何评估工作(以及它背后的体系)这一问题意味着我们必须改变之前评估和思考生产率的方式，最终超越过去的模式。

如果领导者和管理者想要决策或了解他们的体系(或员工)中正在发生的事情，他们必须使用更好的指标。评估指标很重要，它决定了我们的工作重心和行为。如果只使用一个或几个基于活动的指标来衡量员工所做的事情——如代码行数、提交的数量、私有存储库的数量，那你并不知道到底发生了什么，你所了解到的内容并不足以支撑你做出明智的决策。

要理解、提出并完善复杂的多维体系，我们必须要运用多维的指标。

评估职场生产率的框架

即使是最先进的人工智能系统也需要人类的参与——借助人类的创造力、智慧或他们愿意拿出几个小时对图片进行分类的意愿，从而获得更好的搜索结果或预测算法。如果我们忽视了体系内员工的健康，带来的后果便是他们会疲劳和倦怠。如果体系过于简单，比如管理者只看重某一个指标，这个体系非常脆弱。如果体系比较复杂，一旦出现故障，那必定是一个混乱不堪的局面。

仅从工作场所进行了解或评估是不够的，因为它不能告诉我们如何进一步改善。远程办公也是如此：从我们使用的工具中记录或传输的信息可以告诉我们团队提交代码的速度有多快，或者测试套件运行的速度有多快(或慢)。但是孤立地来看，这些数据并不能告诉我们是什么拖慢了我们的团队，不能帮助我们理解我们的开发环境，或告诉我们哪些因素能提升测试执行和运行时间。

一个比较全面的生产率框架必须包括多个维度，包括满足感和幸福感（Satisfaction and well-being）、表现（Performance）、工作流(Activity)、沟通与协作(Communication and collaboration)、效率和流程(Efficiency and flow)，这几个方面可以概括为SPACE。虽然我在这里重点关注的是开发人员和IT人员的生产率(10多年来我一直在不同类型的企业关注这一方向)，但是开发人员的工作是创造性的工作，所以这个框架的很多内容也可以应用于开发人员之外的人。

“满足感和幸福感”指的是人们对自己的工作或工作中采用的体系的满足和快乐程度，以及工作对他们的影响。从本质上来看，这些信号与我们所讲的生产率是紧密相连的，多项研究表明，满足感与产出是息息相关的，而且可能是增加工作(如产出和创新)和减少工作(如倦怠及其对工作的影响)的首要指标。但这些指标不仅仅是关注一个人有多快乐，满足感和幸福感关乎个人及团队如何携手合作创造价值；关乎我们在技术背景下如何更好地使用我们的体系。例如，为开发人员创造良好的环境可以让公司更快地开发和交付软件，包括为客户和终端用户开发新功能，进行关键的数字基础设施，为系统中的安全漏洞打补丁，都能更快地完成。

“表现”考量的是结果——系统或过程执行得如何——包括质量、速度和影响等指标。我们在考虑生产率时经常会忽视这几个指标，但是，如果我们想要使用数据来决策或改进，这项指标对于理解我们的工作努力是否达到预期的效果至关重要。

“工作流”考量的工作过程中的一系列事情。这些是最常见的生产率指标，因为它们经常被使用，也是我们最熟悉的，也最容易自动化。然而，仅根据“提交”/“完成”/“点击”的数量，不可能完全捕捉到工作的多维度和复杂性。我们的体系存在着盲点和不一致性，因此在这些简单的、自动计数方面做得也不是尽善尽美。

“沟通和协作”是关于人们和团队如何一起工作的，这可能是这个框架中最容易被忽视的部分。（与此相关的是，职场人类学家先驱露西•萨奇曼(Lucy Suchman)对“无形的工作”的早期研究也强调了挖掘潜在工作实践的重要性，因为人们的工作方式及其工作对提升团队效率的作用并不总是显而易见的）。在传统的生产率指标中，沟通和人际关系通常不被考虑在内。沟通和协作还需要包含易于使用和共享的系统文档，以及模块系统设计和可搜索性，使开发人员能够查找、共享和重用代码。

“工作效率和流程”评估的是工作过程，可能包括系统内的时间或速度、移交的数量、中断及待在“流程内”的能力。效率也与上面列出的所有其他方面密切相关：例如，流程的完善与满足感的提升息息相关。当我们考虑其他因素时，平衡效率变得至关重要。例如，通过减少中断次数、最大化编码时间优化单个流程的做法可能会阻碍其他人的工作并中断整个团队的流程，因为他们需要等待编码或设计评审。又或者，最大化系统的流程可能会走上某个极端，这会使团队选择在默认情况下将所有代码推向生产，而不考虑测试或发现的缺陷，增加了客户发现错误和bug的数量。

所有上述指标都应该根据团队/组织的优先级或需求的变化进行定制和更改。仅仅采用同一组标准的指标可能会比较方便，但是如果你的数据并不能帮助你做出重要的决策,或如果将开发人员引入错误的轨道，那么这些指标就像其他任何标准一样对你无任何益处。

远程开发、协作和生产率

在疫情期间，知识工作者(主要是开发人员)是如何处理这些度量的呢？疫情和在家办公的封锁模式提出一个前所未有的机会——去评估人们在高度不确定以及远程的环境下如何工作。去年，我和 GitHub 合作的研究表明，与前一年相比，开发人员的工作时间更长了，编写的代码也更多了，这些团队跨越了世界上的四个时区——英国时区、美国东部时区、美国太平洋时区和日本标准时区的。

通过“推送窗口”——第一次和最后一次推到开发人员的主分支或存储库之间的时间作为工作时间的粗略估算，我们发现，与前一年相比，跨越所有时区的开发人员的工作时间都更长了，许多开发人员每天多工作10-20分钟，然后在2020年6月至7月期间，每天多工作60-80分钟。

换句话说，随着疫情的蔓延，人们做的工作越来越多。

为了看看这是否只是开发者在适应新的工作程序和日程安排时分散了他们的工作，我们使用推送数量作为粗略的估算标准，查看了他们做了多少工作。这一次，我们看到与前一年我们跨时区的研究相比，工作基本上是一致的，有些明显的上升，之后趋于稳定——但我们没有观察到任何显著的下降。

但这项工作并不是孤立进行的，研发就意味着协作。即使在我们的日常生活被打乱的这一年里，开发人员合作得更多、更快。开发人员协作的主要方式之一是通过pull request（拉请求）。合并一个pull request是把一组开发人员拉到一个项目中，检查变更，讨论代码，有时会跟进额外的代码提交，最终合并pull request。为了代说明理这个协作过程，我们评估了团队合并pull request所花费的时间，并与前一年进行了比较。

已经习惯于远程工作和协作的开源团队，在4月份时，其合并代码的速度比去年同期快了3.5个小时，2020其余月份的速度也比去年快1-7个小时不等。在更传统的工作环境中工作的团队，其协作速度也更快了，4月份的合并时间提高了约1小时，之后从慢2个小时跳到了快5个小时，与前一年相比，大多数时间段都是提高的。

乍一看，我们可能会抛开这一数据，高喊：“生产率提高了！”

然而，我们也知道，一直顶着高压工作是不可行的。《2021年工作趋势指数》(2021 Work Trend Index)的最新发现表明，“高生产率掩盖了劳动力背后的疲惫”，该指数是基于微软对31个国家3万多人的研究，以及对微软365和领英(LinkedIn)的数万亿生产率和劳动力信号的分析得出的。该报告还指出，今年全球超过40%的劳动力正在考虑离开自己的雇主。

如果我们不认真考虑重新评估生产率问题的标准——从而得到更有针对性的解决方案——那么以后也就不用再考虑生产率的问题了。

远程工作教会了我们一些东西。一方面，我们学会了如何采用全新的工作方式(许多公司几乎一夜之间就这样做了)：我们可以与来自任何地方的人建立团队，使用技术支持灵活的解决方案。各组织正在借鉴开源的剧本——分布式开发的原始场所，大家不在同一个组织中，也不在同一个地点——并重新利用这些剧本进行快速、高信任度的协作工作。我们可以推进到云端，优化快速的工具和直观的开发体验，使他们能够提出解决方案——他们甚至可能意识不到自己是“开发人员”，因为低代码和无代码工具的出现方便每个人使用。

另一方面，我们需要在评估过程中考虑到这一点。要完成知识和数字经济的复杂工作，并不仅仅是坐在椅子上，参加Zoom会议，或者编写更多代码。它涉及创造力和解决问题的能力；能合作又能专注；平衡个人和团队需求得到最好的结果。我们的大多数评估体系还没有成型，有些东西最好是通过询问人员而不是工具来评估——因为只有人员可以告诉你搭建系统是什么感觉，而且只有人员可以发现系统中的盲点。

远程工作真正强调了生产率是因人而异的——在转向居家工作的过程中，有的人很成功，有些人则很不顺利。

生产率因人而异

到目前为止，我都是从经理或企业角度强调如何最好地评估生产率的。但也有通过个人视角的观察，在最近Eirini Kalliamvakou和我进行的一项研究中，我们询问了开发人员一些问题，例如是否关心生产率，以及我们如何帮助他们提高生产率。

经过一年的持续观察，我们发现，他们不相信“生产率”这个词，并希望项目和数据是保密的。但他们都想对自己的工作有进一步认识，让自己拥有更多“好日子”的方法。在为期两周的研究中，我们邀请GitHub开发者在一天结束时对他们的工作进行简单快速的调查(基于SPACE机制)，并将其与他们的相关数据进行匹配，向他们展示了改善每日工作的方法和建议。我们总结了以下几点:

• 按照工作流是关键，外部干扰会扯后腿。小干扰或没有干扰能够让开发者度过美好的一天的概率是82%，但如果一天中频繁被干扰，那么这一天拥有好心情的几率将降至7%。

•  会议有利有弊。协作改善了我们的工作，但太多的会议可能会适得其反；如果每天开2-3次会议，目标达成的概率会降低60%。

• 每天反思两分钟，日子越过越轻松。开发人员报告说，每天的反思是一个很好的新习惯，通过观察给定的范例，他们可以清楚地知道自己应该改变什么。

其他研究发现，善于反思的开发人员可以提高他们的产出和幸福感，而且与每天开工前设定目标相比，每天收工后的反思往往没有太多压力。简单快速的日常调查和反思在提供准确数据的同时，将干扰降到最低，这也说明了个人指标的力量。

当员工在家办公时，管理者虽然眼不见，但绝对会心里挂念员工，他们会用亲身经历来安慰自己，自己的团队正在工作，正在努力寻找沟通工作和进展的方式。他们以前的“监控”方法不奏效了。

但这些旧方法一开始就是有用的吗?评估工作时间或其他工作指标并不能反映个人或团队的生产率——事实上，研究表明，这些幼稚的指标可能会被用来欺骗管理层。我们可能拥有先进的技术，但我们需要正确的使用方法。

我们的技术发生了变化；现在是时候改变评估职场生产率的游戏规则了。

注：本文转载自网络，如有侵权，请联系删除