激励程序员的基本原则 快乐的程序员效率更高

原文：Motivating Software Engineers101
作者： Tyler Hakes
译者： Roy

一些项目经理和管理人员可能会惊讶地发现，试图强制，哄骗和威胁工程师来编写更多的代码并不是一个吸引和留住优秀人才的有效策略。

许多公司过于重视使用外在因素来推动其工程团队的绩效。而在现实中，具有最大影响的往往是内在动机。

这里有一个秘诀：更快乐的软件工程师表现得更好。

这似乎是一个简单（甚至是显而易见）的结论。但是，不能否认这是事实。关于这个话题的多项研究证实，幸福感和满意度与解决问题的能力和工作的绩效直接相关。

如果你希望你的工程师们表现良好 —— 找到创新的解决方案，打造世界一流的产品，并且对所有事物看起来很开心（或者，如果你是一个关心别人福祉的人），那么你应该专注于为人们提供合适的环境。

这不仅仅是一种直觉。这是科学。

你需要创造一种文化，让工程师们真正在乎他们正在做的事情。

不是因为他们工作更快而被奖励，或者工作不够快，他们就被解雇。你需要具有内在动力并关心他们工作的工程师。

令人惊讶的是，如果你关注这个课题的研究结果，这并不是那么难做到的。

让工资不成为问题

你可能会认为，为你的工程师们支付高薪或奖金会使他们更快乐，因此更有动力。

那是不对的。

有一个叫做工作满意度的两因素理论。它说，影响专业人士的动机有两种主要因素：

1. 保障因素

2. 动机因素

保障因素是桌面上明确的利益关系。如果你不提供,你的员工会不快乐。他们是薪水、管理和工作条件之类的东西。

但是——这只是助推器——保障因素并不能直接提升动机。至少，在特定的条件下就会失效。顾名思义，动机因素是驱使参与和表现的因素。

动机因素不那么明显。他们更难以控制和量化，比如获得成就、认可和成长等。

对大多数软件工程师来说，薪水是一个保障因素。

是的，他们想得到很好的报酬。但是更多的钱不会带来更好的表现。工程师们常常寻求挑战、创造的自由和个人成长。他们想被工作本身所激励，而不是受外界因素的驱使。

被大量引用的丹尼尔·卡尼曼（Daniel Kahneman）的研究表明，总体的幸福感和满足感（与绩效和动机高度相关）在薪酬水平合理后会陷入停滞。有些人主要靠薪酬激励，但用高薪酬来保持一个有动力的团队，长期来看似乎是一个失败的策略。（请注意，在研究中发现的75,000美元左右的数字可能与软件工程师的薪酬不尽相同，他们可能会要求支付具有竞争力的市场薪资，那可比这个具体数字要高得多。）

如果你支付的薪资低于市价,那么即使他们喜欢他们的工作,你也很难保持工程师的积极性。所以薪资也是动机因素的一种拙劣的替代品。

与其试图用更高的薪水或更好的奖金来激励你的工程师，你应该确保你的工程师得到的报酬已经足够了，钱不再是决定因素。把它从桌上的选项中拿下来。

这并不意味着你必须支付最高的工资。这意味着给工程师们足够的报酬，让他们觉得自己很有价值，不想仅仅因为薪水而离开。

然后，把注意力放在与他们的幸福和动机有关的其他因素上。

管理过程，而不是人

软件工程师（如同设计师、作家和其他各种类型的战略家一样）主要关心如何解决问题。他们想分析一个情况，仔细考虑各种可能的解决方案，然后实施最好的那个。

总之，软件工程师们非常重视自主权。

但在实践中，这意味着管理人员应该接受培训,使其比员工更能管理流程。与其指导员工做什么和如何做，不如给他们挑战，给他们适当的时间和工具来解决这些挑战。

这种自由是几乎所有行业的专业人士都渴望的。毫不奇怪，过度的人员管理往往会降低绩效。

一项关于软件开发人员的研究显示了他们对一天中不同活动的感受。这可能并不意外:“编码”–或者，可能更准确地说，解决问题–排名第一，大多数开发者觉得这是富有成效的。

像会议、文档和电子邮件之类的东西，对很多开发人员来说都使他们分心，而他们正在集中精力解决手头的问题。

当然，这些活动通常是工作的一部分。有时候你确实需要开会来安排事情。

尽管如此，这也指出了管理层在塑造工作环境方面应发挥的作用。他们的目标不应该是监督个人的任务和工作习惯。相反，将重点放在创建系统和流程上，使开发人员能够以最专心的时间来工作。为成功而设置这些系统和流程。

给某人一个问题并且挑战他们去解决问题，比指导某人采取具体行动更有趣。它涉及到更高层次的思考，给他们一些寻找解决方案的机会，而不是简单地给出一个任务清单。

让他们给出自己的观点

大多数工程师不喜欢做填鸭式的工作。但他们也不喜欢在没有上下文的情况下接受挑战。

首先，它效率低下。解决问题的根本在于，尽可能多地使用上下文，这是能够提出最佳解决方案的先决条件。

但更重要的是，工程师们应该对自己所做的工作有一种主人翁意识。

不是每一个项目都是最令人兴奋的。不是所有的产品都是市场上最性感的新工具。但是，几乎每一个企业家都知道，如果这个问题让你第一眼就有强烈的感觉，那么解决它就可能会变得很重要，甚至会让人上瘾。

在实践中，这意味着要首先和员工讨论他们要做的工作，将它与公司更大的愿景联系起来。或者，它是如何帮助真正的用户解决实际问题的。

这难道不是重点吗？

如果你让你的工程师们参与讨论为什么他们要做手上的工作——这对公司意味着什么，为什么它很重要，以及最终决策是如何达成的——那么这就成了一个团队协作努力为解决问题而创造的东西。

至此，工作变得越来越不是一个工作，更多的是目的。

消除愚蠢的指标

许多经理和高管仍然——是的——仍然——坚持度量工程性的指标，比如工作时间、修复bug的数目或编写代码的行数（简直令人不寒而栗）。

也许一个专门创建时间跟踪应用程序的软件公司会质疑利用时间来度量绩效，这似乎很滑稽。但是，这是真的。时间跟踪最好用作一种机制，使开发人员能够衡量和改进自己，而不是作为公司评估绩效的一种方式。

如果你认为可以通过这些指标来激励工程师，那么你该醒醒了。

对于创造性的工作来说，这是一个非常糟糕的方法。 他们往往需要更多的“休息”时间来酝酿想法，测试，试错，并重新开始而不是在做传统意义上“实际的工作”。

是的，写一段具体的代码可能需要1个小时。但要到这一步，可能需要5小时甚至5天的时间。这些不是相互排斥的。

Box的前高级工程副总裁（现在的谷歌工程副总裁），Sam Schillace，在这件事上提出了一个有趣的看法。

他解释了Box如何根据各种价值观定义特定的绩效标准。这些价值观也定义了员工职位上工作的具体标准。

他们不是试图量化本质上无法量化的绩效，而是找到了一种使过程定性，具体和细分的方法。

你也应该这样做。

大多数开发人员不介意评估他们的表现并与他们的经理讨论。这让他们有机会反思自己的工作，并找到继续成长和提高专业技能的途径。

但是想这样做的话，需要制定有意义的制度。不幸的是，大多数公司都不擅长做这件事。因此，与其用一个基本上行不通的方式衡量工程师的绩效并打消他们的积极性，不如提供一个积极的反馈机制来帮助开发人员参与和根据内在的驱动力来提高绩效。

创造成长空间

许多公司把注意力放在日常工作和细枝末节上，以至于他们最终不会为他们的员工提供任何探索和个人成长的空间。

毫不夸张地说，大多数专业人士自然会寻找机会来提高自己的技能，发展自己的能力。

马斯洛(Maslow)的需求层次论是一个公认的模型，用来解释人们在生存的基本需求得到满足后的自然欲望。

毫无疑问，激励人的最主要因素是自尊和自我实现。

在实践中，这意味着创造一个环境，让工程师自我完善。这意味着他们有机会发掘自己的才能，发现自己的长处和短处。

一位著名的微软工程师，Scott Hanselman，通过创建他自己的马斯洛的层次结构解释了这一点，并特别概述了影响金字塔各个层面的因素。

这没什么可惊讶的，真的。一旦人们的基本需求得到满足，他们就会把注意力放在比自己更重要的事情上。他们想要被他们正在做的工作感到兴奋和动力。

我们的工作是给他们合适的环境来追求这些需求。

衡量满意度，然后改进

你可能会感到惊讶，但实际上你可以衡量你的员工满意度。

这应该是一个明显的步骤，因为大多数公司都在计量时间，增长，速度，速率，以及其他任何可以放在电子表格中的东西。但是，他们却不在乎任何真正的员工满意度，更不用说采取任何切实可行的措施了。

Redfin —— 一家技术驱动的房地产公司 —— 衡量他们工程师的幸福指数。首席工程师Dan Fabulich解释了该公司如何使用净推荐值（NPS），这是最常用来衡量顾客满意度的，作为自己员工的一个指标。

他写道：“对于衡量客户满意度，我们使用NPS已经取得了很棒的的结果。因此，我们自然而然地决定以同样的方式来衡量员工的满意度，同样的基本问题是:’你有多大可能建议在Redfin工作’？”

但比分数本身更重要的是调查所带来的洞察力。你可以了解你的员工目前的满意程度和理想程度之间存在什么样的障碍。

然后，你可以采取实际步骤来改进该部分工作环境。

转变观念

为了完成最佳工作，软件工程师们需要感到他们的工作被重视，被投资。他们在工作中需要一些掌声。

如果有一件事我们可以肯定的话，那就是激发员工的神秘方法并不适用于创造性职业。你不能给你的工程师提供胡萝卜，使他们的工作表现更好。你也不能指望他们在棍子的威胁下表演。

一次又一次的研究发现，创造性行业的人士在有自我意识、掌握能力和目标感的情况下会茁壮成长，这说明这3者都很重要。

因此，任何一家公司，试图通过陈旧过时的简单惩罚和奖励模式来运营，都是在给自己帮倒忙。他们在毒害自己的利益，赶走最好的人才，伤害他们的表现，而不是改善他们。

如果工程师们没有被他们的工作所激励，那么他们中途就已经离职了。