破坏开发人员生产力的十二件事

今天的文章是来自 medium 的一篇文章，点赞数有将近 1 万 9，所以翻译出来给大家分享一下，有些概念怕大家不了解，所以我放了一些 维基百科的解释。如果有翻译得不是很好的地方，请看原文：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190

正文：

很多文章都涉及技术主管和项目经理的角色。我们经常遇到的一个共同主题是如何提高团队的工作效率。但是在你集中精力来提高生产力之前，你可能首先要考虑是什么在摧毁它，以便建立一个可靠的基础。不幸的是，即使 Peopleware 近 30 年前发布，我们也看到许多团队在一些（消极的）显着方式中遭受巨大的生产力损失！

没有人希望程序员在没有计算机的情况下完成工作，但是有很多公司希望程序员能够在不知情的情况下完成工作。这同样不切实际。

因此，让我们深入探讨我们的 12 个阻止您的开发人员“进入区域”并提高工作效率的事项列表。我将尝试从大多数到最不具影响力的列表中优先考虑此列表。随意评论！

如果您想知道这一切是否值得投资，只需考虑开发商的工资。生产力提高10％甚至更多！

1. 中断和会议

在我看来，中断是开发人员的首要生产力杀手。开发人员在中断之前不能轻易回到他们正确的位置。他们需要进入发展的思维模式，然后慢慢追溯到他们离开的地方。这可能需要超过30分钟。中断越多，挫折越多，工作质量越差，错误就越多 - 而且还在继续。

“The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.。” --A developer on Reddit

大概意思就是说，每次被打断都要重新开始，如果你的一天里经常被打断，那么当你一天没有任何成果的时候，不要感到惊讶。

会议怎么样？会议和中断之间的唯一区别是会议是计划中断，这会使情况变得更糟。如果开发人员在处理任务时知道他们会中断，则他们无法完成任务。因此，如果他们在一两个小时内召开会议，他们将无法取得任何进展，因为大多数工程任务需要更多时间。

As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”

意思就是：正如保罗·格雷厄姆（Paul Graham）所写的那样，“单次会议可以将整个下午分成两部分，每部分都太小而无法做任何事情。”

如何避免这种情况？这部分记录良好; 你没有任何借口。例如，在一天的开始或午餐前举行简短的状态会议，以避免不必要的中断。

2. 微观管理

在不同类型的管理者中，微观管理者在开发人员的生产力方面可能是最糟糕的。当然，微观管理者往往会有更多的会议和意外中断。但不仅如此。他们表现出缺乏信任，通过这样做，你会觉得他们不断破坏你的技能和你完成任务的能力。开发人员在中断之间的任何动机都会在那时消失。影响超出了生产力。微观管理者可能是开发人员离职的第一个原因，或者至少是改变团队的原因。

如果不知道什么是微观管理(micro-management)的，看下面的解释：

在商业管理中，微观管理（英语：Micromanagement），亦作微观管理学、微管理学、微管理或显微管理学，一种管理风格，与宏观管理的理念相反。在这种手法里，管理者透过对被管理者（员工）的密切观察及操控，使被管理者达成管理者所指定的工作。相对于一般管理者只对较小型的工作给予一般的指示，微观管理者会监视及评核每一个步骤。这个名词一般在使用上带有负面的意思。-- 来自维基百科

3. 模糊

有许多方法可以说明模糊性。错误的报告，如“出问题了，快修复！”没有足够的信息供开发人员使用。顺便说一下，拥有错误报告模板可以帮助解决这个问题。

或者对某个功能的规范不明确，在这种情况下，一旦管理员更好地详细说明了预期的行为，开发人员就会开始实施对他们感觉合适的事情。

不明确的优先次序也属于此类别。开发人员想知道他们是否正在处理正确的任务的时间可以很容易地避免。如果有的话，他们会得到经理的评论，询问他们为什么要处理这个特定的任务（虽然优先事项没有定义）……好吧，你得到它 - 很多挫折……

4. 海鸥管理

你听说过吗？当管理者完全没有参与工作时，就会发生这种情况，但是……他们偶尔会突然畏缩不前。“这是错的，这个，这看起来很糟糕，”等等，然后又飞走了。我不得不承认我喜欢这个形象，但不幸的是，这种情况比我们想要的更频繁。这种行为让开发人员感到非常沮丧; 他们将在接下来的几个小时内无法返回该区域，有时甚至连几天都没有。

5. 信用贪婪

您是否有过经理或其他开发人员，他们在过去几周内完成了您所做的工作？开发人员首先重视能力。为别人赢得信誉是为了自己并将其从他或她手中移除。这在我的名单上相当高，因为我觉得它产生了如此多的紧张，它只会在很长一段时间内摧毁整个开发人员的生产力。

6. 环境 - 噪音，运动，工作区设计……

这对于非程序员来说可能看起来很奇怪，但开发人员工作的环境对他们的活动有重要影响。例如，有一些白噪声 - 响亮的交流电，听力汽车和卡车翻滚 - 帮助他们更好地集中注意力。这就是我们这么多人戴耳机的原因！我其实刚刚发现了RainyMood  - 非常棒?！

同样，如果工作区设计为尽可能多的运动，那将无法帮助他们集中注意力！或者让台式计算机屏幕以这样的方式定位，使得管理者高度可见……这会产生一些额外的压力，甚至更多的机会被打断。

7. 范围变动

项目管理中的范围变动（也称为焦点变动，需求变动，特征变动）是指项目范围内的不受控制的变化。当项目范围未正确定义，记录或控制时，可能会发生这种情况。

范围蔓延将相对简单的请求转变为可怕的复杂且耗时的怪物！大部分时间它都发生在开发过程中！例如，对于一个简单的功能：

版本1（在实现之前）：功能是“显示位置的地图” 版本2（当版本1几乎完成时）：功能更改为“显示位置的3D地图” 版本3 （当版本2几乎完成时）：功能再次更改为“显示用户可以飞过的位置的3D地图”

8. 产品定义过程

所以这个看起来可能很奇怪，但实际上很容易理解。如果产品团队定义其团队的优先级而没有验证（通过客户反馈或任何其他方式）相应功能的兴趣，并且开发人员发现大多数功能最终都没有被使用，他们会觉得他们所做的事情是无用的会失去动力。我们都希望感受到有影响力，这对开发人员来说可能更为重要！

9. 缺乏对技术债务的考虑

技术债务是故意决定实施非最佳解决方案或编写不是最好的代码来更快地发布软件。承担一些技术债务是不可避免的，并且可以在短期内提高软件开发的速度。但是，从长远来看，它会导致系统复杂性，从而降低开发人员的速度。非程序员经常低估生产力的损失，并且总是倾向于前进，这成为一个问题。 但如果重构永远不是优先事项的一部分，它不仅会影响生产力，还会影响产品质量。

10. 工具多样性和硬件

开发人员每天使用许多工具来编程，推送和合并他们的代码。自动化越多越好。不言而喻，如果您使用“古老”工具，这将影响您的生产力。同样，拥有一个大屏幕而不只是一台笔记本电脑会产生影响。考虑到硬件成本和开发人员的工资，只需 5％ 的生产率，就可以获得任何投资！只需提供开发人员团队喜欢的工具和硬件（单独用于硬件，但作为工具组）。

11. “如何”文档

在学习如何编码时，我们被告知要尽早和经常写注释。这个想法是，多写一点注释总比写得少好。不幸的是，许多程序员错误地将其解释为他们必须对每一行代码写注释，这就是我们经常看到这样的代码的原因（来自Jeff Atwood的帖子“Coding Without Comments”）：

 r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

原文里就是这样，没看懂啥意思

你知道这段代码的作用吗？我也不。问题是虽然有很多评论描述了代码正在做什么，但没有一个描述它为什么这样做。如果程序中存在错误并且您偶然发现了这段代码，那么您将不知道从哪里开始。

12. 不可能紧迫的截止日期

最后一个与管理者倾向于询问开发人员的估计，然后推动他们尽可能降低这些估计，然后神奇地认为它们是最后期限有关！管理人员甚至会认为，由于开发人员自己“决定”了估算，他们承诺在截止日期前完成，因此截止日期应该被视为足够有效，以便与高层管理人员共享。

毫不奇怪，开发人员认为这些截止日期是不合理的，任意紧张; 这会造成紧张和无法集中注意力。

所有这些东西对开发人员来说都是独特的

如果你看看所有 12 件事，它们实际上对于大多数其他基于项目的工作来说都很常见。只是每个人的影响对于开发人员来说更为重要，因为他们需要深入关注他们的任务进展。

如果您认识到公司内部提到的一些问题，那么与开发人员讨论这些问题可能会很有趣。与他们交谈; 找出这些是否是一个问题以及如何解决。无论他们说什么，最重要的是相信他们的反馈和见解。虽然今天的技术与 30 年前截然不同，但教训仍然是相同的。在考虑团队生产力时，您不能忽视人为因素。与您的团队一起考虑您的流程，环境和工作习惯，让他们指导您如何获得最高的生产力和影响力。

本来今天想法关于 React hook 的文章的，但是怕大晚上的没人学习，所以放到明天早上发，明早请早。