没有人会要求开发人员在不使用计算机的情况下编写代码，但是许多公司认为，他必须以某种方式工作，而不能充分利用他的思维能力。 这几乎是不现实的。
因此，让我们仔细研究一下十二种阻止开发人员进入流状态并提供最大生产力的事物。 我将尝试从最关键的内容转向不太重要的内容。 建议您的选择和评论！
如果有人怀疑是否值得为此花费金钱和精力，那么只要记住程序员的薪水就足够了。 甚至将生产率提高10％也是很多钱！
1）会议和其他干扰
在我看来，分散开发人员的精力是杀死他的生产力的最可靠方法。 他不能简单地从他被打扰的地方接走。 首先，他需要再次参与该过程，然后遍历整个思路，直到合适的时机–仅此一项就需要花费半小时或更长时间。 而且，此类中断发生的次数越多，烦恼就会越累积，工作质量越低，出现错误的频率就越高，并且可以继续列出该列表。
“当我尝试开始一项任务时，越是分心，两次尝试之间的时间就越多。 如果我一整天都被抽走，那一天的结果实在是毫无用处，这不足为奇。”-Reddit的匿名开发人员
好吧，会议呢？ 它们与其他干扰因素的唯一区别在于它们是事先计划好的。 这只会使情况变得更糟。 如果程序员希望事先中断工作，那么程序员就很难解决问题。 因此，如果在一两个小时内他必须参加计划会议，则很可能他将无法对他的任何项目做任何有意义的事情-毕竟，大多数工程任务都需要更长的时间。
正如保罗·格雷厄姆（Paul Graham）所说：“一次会议可能会浪费半天：时间分为两个时期，在这个时期你不能做任何严肃的事情。”
如何避免这种状况？ 很久以来，一切都画在上面，所以没有任何借口。 您只需要在一天的开始时，或者在晚餐之前，就将刨床放好，这样就不需要在不必要的情况下分散人们的精力。
2）挑剔
在所有类型的经理中，出于任何原因进行干预的经理，对员工生产力的影响可能是最严重的。 当然，这也受到以下事实的影响：该特定类型特别倾向于组织一堆会议，并且出于不可预见的原因而需要开发人员的注意。 但这不是唯一的重点。 这样的举动表明缺乏信任，结果人们感到自己被认为无能为力，并质疑他们的专业技能。 即使程序员在无尽的打扰下仍然有一定的工作动机，但这种态度将完全使她沮丧。 结果不仅限于性能下降。 侵入性管理人员尤其经常迫使员工离开公司，或者至少离开团队。
3）不清楚
缺乏清晰性可以通过许多不同的示例来说明。 例如，一个本着“在这里不起作用，请修复它！”的精神的错误报告。 显然并不能为开发人员提供工作所需的所有信息。 顺便说一下，在这种特殊情况下，引入错误报告模板可能会有所帮助。
或另一种情况：产品某些部分的含糊要求。 有了这种介绍性的开发人员，他们便开始按自己的想象去做，然后经理为预期的用户行为提供了更详细的描述，他们都必须重新开始。
设置不明确的优先级属于同一类别。 尽管避免这种情况非常简单，但是程序员会花很多时间在脑海中思考应该从什么开始。 好吧，如果他们不得不向经理报告为什么要从事这项工作而不是这样做（尽管没有人规定订单），那么您可以肯定，这将使他们变得很棒。
4）海鸥经理
听说过吗？ 有些经理根本不参与工作流程...除了那些突然决定跳槽并犯错的时刻。 “这不好，这也没问题，但看起来一点也不对，”然后继续前进。 我必须承认，我喜欢这种比较，但是其背后的现象比我们想要的更为普遍。 这种行为对开发人员的影响非常严重：许多人随后不得不花上几个小时才能保持工作状态，然后有人整天都退出了工作。
5）桂冠盗窃
您是否曾经遇到过，一位经理或其他程序员将自己辛苦了几周归因于自己？ 开发人员将专业精神放在首位。 窃取别人的功绩就像剥夺一个人的能力以充实自己的能力。 我之所以提出这一点足够高，是因为我相信这样的事情会导致非常紧张的局势，这很长一段时间都可能使整个团队的表现“下降”。
6）家具：噪音，运动，工作区设计...
对于其他行业的人来说，这似乎很奇怪，但是对于程序员而言，环境在工作过程中起着决定性作用。 说白噪声（空调的嗡嗡声，街道上的汽车和卡车的嗡嗡声）有助于他们更好地集中注意力。 这就是为什么我们许多人使用耳机的原因！ 顺便说一下，我最近发现了RainyMood-很棒！
但是，如果办公室的设计要使人周围总是有一些运动，那么这将产生相反的效果。 此外，如果以使管理人员不断查看屏幕上所显示内容的方式来安装监视器，则这会造成不必要的压力和不必要的原因，从而分散了开发人员的业务精力。
7）偏移项目边界
在项目管理中，该术语用于项目数量不受控制地增长的情况。 通常在最初没有严格定义和记录它们或未在过程中对其进行监视时，通常会发生这种情况。
由于边界的移位，相对简单的查询会变成混乱的怪物，这些怪物会花费大量时间！ 在大多数情况下，这始于产品已经在开发中。
以一个简单的函数为例：
- 第一个版本（实施之前）：该功能定义为“显示位置图”
- 第二个版本（第一次迭代即将完成时）：描述更改为“显示3D位置图”
- 第三版（第二次迭代即将完成时）：描述更改为“显示用户可以在其上移动的3D位置图”
8）产品特征确定过程
乍一看似乎难以理解，但实际上，一切都很简单。 如果负责产品的人员优先考虑而不考虑（通过反馈或任何其他方式）关于受众对某些机会的兴趣的假设，而开发人员发现根本没有利用这些机会，那么他们会感到他们的工作没有意义，动力就会崩溃。 我们所有人都希望感觉到我们在世界上留下了一些痕迹，这对开发人员而言尤其重要！
9）忽略技术债务
技术职责是一项有意识的决定，允许在选择解决方案和编写代码时进行一定程度的扩展，以便更快地推出产品。 任何项目中不可避免地都会产生一定数量的技术债务，并且可以帮助缩短短距离的期限。 但是，从长远来看，它会增加系统的复杂性，从而减慢开发人员的速度。 远离编程的人们常常低估了这些过程对生产率的影响，因此需要不停地前进-在这种情况下，问题开始出现。 如果重构始终不在优先列表之列，则不仅会影响员工的工作效率，还会影响产品的质量。
10）各种工具和设备
开发人员每天都会使用许多工具来编写，推送和合并代码。 他们越努力地使流程自动化，那就越好。 不用说，古老的工具将直接影响性能。 它还决定了很多工作要做的事情-在一台笔记本电脑上还是在另一台屏幕上。 如果我们将铁价与程序员的薪水进行比较，那么即使将生产率提高5％，也肯定会付清所有费用！ 您只需要向团队提供他们更喜欢使用的设备和工具（对于设备，解决方案应该是个体的，对于工具-解决方案应该是集体的）。
11）使用说明文件
在教授编程的过程中，我们都了解到，您需要尽快并尽可能多地开始向代码中添加注释。 想法是，有太多评论总比没有评论好。 不幸的是，许多人误解了这一点，并决定每一行都需要解释。 这就是为什么我们从Jeff Atwood的
文章 “无注释的代码”中获得了这样的示例：
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年中，技术方面发生了很多变化，但是团队合作的基本原理保持不变：在讨论绩效时，有必要考虑人为因素。 改善您的工作流程，环境，团队习惯，并让他们有机会告诉您如何实现最大的生产力。