最能摧毁程序员工作效率的 12 件事

小编推荐： 掘金是一个面向程序员的高质量技术社区，从 一线大厂经验分享到前端开发最佳实践，无论是入门还是进阶，来掘金你不会错过前端开发的任何一个技术干货。

很多文章都涉及技术主管和项目经理的角色。 我们经常遇到的一个共同主题是如何提高团队的工作效率。 但是在你集中精力来提高团队生产力之前，你可能首先要考虑是什么在摧毁程序员的生产力，以便建立一个可靠的基础。

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

因此，让我们深入探讨 12件摧毁程序员提高效率的事情。下面给出的顺序是按最重要到不重要的 排序 的（从我的视角）， 随意评论！

如果你想知道这些投入是否值得，只要考虑给程序员们加薪水就可以了。即使加薪 10% 也能很大程度上提供程序员的工作效率。

1）打断 和 会议

在我看来，最影响程序员工作效率的事情是随意打断他们的工作。开发人员无法轻松回到被打断之前的状态。他们需要进入原先的思维模式，然后慢慢追溯到他们离开时的思路。这可能需要超过 30 分钟。打断越多，挫折越多，工作质量越差，错误也就越多 – 而且还在持续。

“你越是在我尝试一些新想法的时候，你来打断我，我每次尝试的时间间隔越来越长。如果你让我的早晨老是被打扰，当一天什么事都没干的时候，请不要感到惊讶。“ Reddit上的开发人员

会议怎么中枪了？会议和打断的唯一区别是，会议是有计划的打断，这会让事情变得更糟。如果开发人员知道他们在工作时会被打断干扰，他们就无法在任务上取得大的进展。因此，如果他们在一两个小时内召开会议，他们将无法取得任何进展，因为大多数工程任务需要更多时间。

正如保罗·格雷厄姆（Paul Graham）所写的那样，“一次会议可以将整个下午分成两部分，碎片化时间太多导致无法做任何事情。”

如何避免这种情况？这里有成功的先例；你没有理由不借用。例如，在一天的开始或午餐前举行简短的状态会议，以避免不必要的打断。

2) 微观管理

在不同类型的管理人员中，微观管理人员在开发人员的效率方面可能做的是最糟糕的。 当然，微观管理人员往往会有更多的会议和意外打断。 但不仅如此。 他们表现出对程序员缺乏信任，这样一来，程序员会觉得他们在不断地摧毁自己的技能和完成工作的能力。 这时候，开发人员的工作劲就消失了。 影响的不仅仅是效率。 微观管理人员可能是程序员离职的最主要原因，或者至少是更换团队的原因。

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年前截然不同，但教训仍然是相同的。在考虑团队工作效率的同时，不能忽视人为因素。与您的团队一起改善工作流程，环境和工作习惯，让开发人员指导您如何提升工作效率和影响力。

翻译自：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190