点击上方“
CSDN
”，选择“置顶公众号”
关键时刻，第一时间送达！
作者： Tyler Hakes
译者： Roy
一些项目经理和管理人员可能会惊讶地发现，试图强制，哄骗和威胁工程师来编写更多的代码并不是一个吸引和留住优秀人才的有效策略。
许多公司过于重视使用外在因素来推动其工程团队的绩效。而在现实中，具有最大影响的往往是内在动机。
这里有一个秘诀：更快乐的软件工程师表现得更好。
这似乎是一个简单（甚至是显而易见）的结论。但是，不能否认这是事实。关于这个话题的多项研究证实，幸福感和满意度与解决问题的能力和工作的绩效直接相关。
如果你希望你的工程师们表现良好 —— 找到创新的解决方案，打造世界一流的产品，并且对所有事物看起来很开心（或者，如果你是一个关心别人福祉的人），那么你应该专注于为人们提供合适的环境。
这不仅仅是一种直觉。这是科学。
你需要创造一种文化，让工程师们真正在乎他们正在做的事情。
不是因为他们工作更快而被奖励，或者工作不够快，他们就被解雇。你需要具有内在动力并关心他们工作的工程师。
令人惊讶的是，如果你关注这个课题的研究结果，这并不是那么难做到的。
让工资不成为问题
你可能会认为，为你的工程师们支付高薪或奖金会使他们更快乐，因此更有动力。
那是不对的。
有一个叫做工作满意度的两因素理论。它说，影响专业人士的动机有两种主要因素：
-
保障因素
-
动机因素
保障因素是桌面上明确的利益关系。如果你不提供,你的员工会不快乐。他们是薪水、管理和工作条件之类的东西。
但是——这只是助推器——保障因素并不能直接提升动机。至少，在特定的条件下就会失效。顾名思义，动机因素是驱使参与和表现的因素。
动机因素不那么明显。他们更难以控制和量化，比如获得成就、认可和成长等。
对大多数软件工程师来说，薪水是一个保障因素。
是的，他们想得到很好的报酬。但是更多的钱不会带来更好的表现。工程师们常常寻求挑战、创造的自由和个人成长。他们想被工作本身所激励，而不是受外界因素的驱使。
被大量引用的丹尼尔·卡尼曼（Daniel Kahneman）的研究表明，总体的幸福感和满足感（与绩效和动机高度相关）在薪酬水平合理后会陷入停滞。有些人主要靠薪酬激励，但用高薪酬来保持一个有动力的团队，长期来看似乎是一个失败的策略。（请注意，在研究中发现的75,000美元左右的数字可能与软件工程师的薪酬不尽相同，他们可能会要求支付具有竞争力的市场薪资，那可比这个具体数字要高得多。）
如果你支付的薪资低于市价,那么即使他们喜欢他们的工作,你也很难保持工程师的积极性。所以薪资也是动机因素的一种拙劣的替代品。
与其试图用更高的薪水或更好的奖金来激励你的工程师，你应该确保你的工程师得到的报酬已经足够了，钱不再是决定因素。把它从桌上的选项中拿下来。
这并不意味着你必须支付最高的工资。这意味着给工程师们足够的报酬，让他们觉得自己很有价值，不想仅仅因为薪水而离开。
然后，把注意力放在与他们的幸福和动机有关的其他因素上。
管理过程，而不是人
软件工程师（如同设计师、作家和其他各种类型的战略家一样）主要关心如何解决问题。他们想分析一个情况，仔细考虑各种可能的解决方案，然后实施最好的那个。
总之，软件工程师们非常重视自主权。
但在实践中，这意味着管理人员应该接受培训,使其比员工更能管理流程。与其指导员工做什么和如何做，不如给他们挑战，给他们适当的时间和工具来解决这些挑战。
这种自由是几乎所有行业的专业人士都渴望的。毫不奇怪，过度的人员管理往往会降低绩效。
一项关于软件开发人员的研究显示了他们对一天中不同活动的感受。这可能并不意外:“编码”–或者，可能更准确地说，解决问题–排名第一，大多数开发者觉得这是富有成效的。
像会议、文档和电子邮件之类的东西，对很多开发人员来说都使他们分心，而他们正在集中精力解决手头的问题。
当然，这些活动通常是工作的一部分。有时候你确实需要开会来安排事情。
尽管如此，这也指出了管理层在塑造工作环境方面应发挥的作用。他们的目标不应该是监督个人的任务和工作习惯。相反，将重点放在创建系统和流程上，使开发人员能够以最专心的时间来工作。为成功而设置这些系统和流程。
给某人一个问题并且挑战他们去解决问题，比指导某人采取具体行动更有趣。它涉及到更高层次的思考，给他们一些寻找解决方案的机会，而不是简单地给出一个任务清单。
让他们给出自己的观点
大多数工程师不喜欢做填鸭式的工作。但他们也不喜欢在没有上下文的情况下接受挑战。
首先，它效率低下。解决问题的根本在于，尽可能多地使用上下文，这是能够提出最佳解决方案的先决条件。
但更重要的是，工程师们应该对自己所做的工作有一种主人翁意识。
不是每一个项目都是最令人兴奋的。不是所有的产品都是市场上最性感的新工具。但是，几乎每一个企业家都知道，如果这个问题让你第一眼就有强烈的感觉，那么解决它就可能会变得很重要，甚至会让人上瘾。
在实践中，这意味着要首先和员工讨论他们要做的工作，将它与公司更大的愿景联系起来。或者，它是如何帮助真正的用户解决实际问题的。
这难道不是重点吗？
如果你让你的工程师们参与讨论为什么他们要做手上的工作——这对公司意味着什么，为什么它很重要，以及最终决策是如何达成的——那么这就成了一个团队协作努力为解决问题而创造的东西。
至此，工作变得越来越不是一个工作，更多的是目的。
消除愚蠢的指标
许多经理和高管仍然——是的——仍然——坚持度量工程性的指标，比如工作时间、修复bug的数目或编写代码的行数（简直令人不寒而栗）。
也许一个专门创建时间跟踪应用程序的软件公司会质疑利用时间来度量绩效，这似乎很滑稽。但是，这是真的。时间跟踪最好用作一种机制，使开发人员能够衡量和改进自己，而不是作为公司评估绩效的一种方式。
如果你认为可以通过这些指标来激励工程师，那么你该醒醒了。
对于创造性的工作来说，这是一个非常糟糕的方法。 他们往往需要更多的“休息”时间来酝酿想法，测试，试错，并重新开始而不是在做传统意义上“实际的工作”。
是的，写一段具体的代码可能需要1个小时。但要到这一步，可能需要5小时甚至5天的时间。这些不是相互排斥的。
