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

栏目: IT资讯 · 发布时间: 6年前

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

medium

今天的文章是来自 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  - 非常棒

本文由taoweng 创作,采用 知识共享署名4.0 国际许可协议进行许可

本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名

最后编辑时间为: Nov 23, 2018 at 06:26 pm


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Web开发敏捷之道

Web开发敏捷之道

Sam Ruby、Dave Thomas、David Heineme Hansson / 慕尼黑Isar工作组、骆古道 / 机械工业出版社 / 2012-3-15 / 59.00元

本书第1版曾荣获Jolt大奖“最佳技术图书”奖。在前3版的内容架构基础上,第4版增加了关于Rails中新特性和最佳实践的内容。本书从逐步创建一个真正的应用程序开始,然后介绍Rails的内置功能。全书分为3部分,第一部分介绍Rails的安装、应用程序验证、Rails框架的体系结构,以及Ruby语言的知识;第二部分用迭代方式创建应用程序,然后依据敏捷开发模式搭建测试案例,最终用Capistrano完成......一起来看看 《Web开发敏捷之道》 这本书的介绍吧!

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具