酷应用

@程序员，你和大牛究竟差在了哪？| 畅言

百家作者：CSDN 2019-04-11 10:44:28

世界上没有完全相同的两片树叶，也没有完全一样的两个人，在技术领域，即使两个人学习同样的知识也会有不一样的理解，而这自然就带来了差异性。但是作为团队的领导者，在面对开发者之间所存在的技能差异时，并不能一味地忽略，而更应该有效地管理它，至于怎么管理，本文或许能给你一定的帮助。

作者 | Thinking Sideway

译者 | 苏本如

责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

我们都知道，有些开发人员比其他开发人员更擅长他们的工作。正如有些足球运动员比其他足球运动员踢得好，有些医生比其他医生医术更高明，所以为什么开发人员不应该是这样呢？事实上，一些研究结果支持这一说法。而且这种技能上的差异在各行各业中都是众所周知的。Googleg工程与研究高级副总裁艾伦·尤斯塔斯在一次采访中说，一位顶尖工程师的价值“是普通工程师的300倍或更多”。他还说，他宁愿失去一整个班的工程专业的毕业生，也不愿失去一位杰出的技术专家。据他吐露，许多谷歌服务，如Gmail和谷歌新闻，都是由某一个技术牛人创建的。

我们当然可以从上面提到的研究结果或者尤斯塔斯先生的陈述当中挑出很多毛病。一个显而易见的问题是，就软件开发而言，没有适当的方法来衡量生产力。在过去的几年里，许多不同的指标被提出来，但是所有这些指标都存在严重的缺陷。不管怎样，我都认为否认“不同开发人员的技能确实存在很大差异”这一点是很愚蠢的。不管你喜欢与否，技能差异都确实存在，而且我们必须管理它。这就是本文想要阐述的观点。

那么，该如何管理一群技能级别差异很大的开发人员呢？我认为，首先也是最重要的是接受这个事实。许多经理仍然认为全职员工（FTE）的技能差别无关紧要，这种简单化地看法给他们在团队和项目之间随意调配开发人员提供了理由，但事实上这是完全错误的。五个高效率的开发人员并不等同于五个平庸的开发人员，更不等同于五个坏的开发人员，即使他们都是全职员工。而且，能力的高低至少部分依赖于一定的背景：如果开发人员使用他所熟悉的技术、模式和代码库，那么他会更加有效率。同样，一个伟大的Java开发人员可能只是个效率一般的C开发人员。如果经理们不考虑团队成员的技能水平，频繁而简单地重组团队，那就会很容易损害整个团队的生产力。

接受技能差异这一事实后的下一步是对团队中技能级别的分布有一个正确的认知。我想出了一个简单的方法来对团队成员进行分类（见下图）：

如你所见，我在这里将团队成员分为四组，类似于波士顿矩阵（BCG矩阵）中产品的分类方式。X轴表示开发人员的输出（代码行数、Bug修复数量、解决的客户问题数量等等），而Y轴则表示该输出的质量。当然，这是一个非常简单的视图，但是这个问题的“模糊”性质让我们很难找到更精确的视图。

在左下角，我们有低输出且低质量的开发人员。我把他们称之为植物（Plants），因为他们在办公室的存在感可以忽略不计（类似于盆栽植物的存在）。植物型开发人员的产出太低，所以他们的低质量不会造成什么影响。他们也不会把你的代码库搞得一团糟。尽管如此，他们还是会在团队中引起很多不满。但是由于投资回报率太低，把太多的管理“精力”放在他们身上可能不是一个好主意。

在左上角，我们看到了冰川(Glaciers)。这些开发人员工作质量高，但产出低。就像冰川一样，它们一直在移动，但是移动得太慢，肉眼几乎看不到。一般来说，冰川型开发人员是可以接受的合作者，因为他们考虑问题很全面，不会造成太多的问题。有些冰川型开发人员甚至有可能随着时间的推移成长为优秀的开发人员，如果他们的速度慢是因为缺乏知识或经验的话。然而，确实存在一些拥有几十年经验的开发人员仍然速度很慢。对这类开发人员，我的建议是接受他们的存在。重要的是不要给冰川型开发人员分配任何时间紧急的任务，因为这会导致双方都非常沮丧。记住一点，冰川型开发人员对团队的表现不是一个威胁。

让我们进入高输出区。在右上方的是明星(Stars)。明星型开发人员是一个团队的脊梁，他们完成了大部分的开发工作，而且质量很高。根据帕累托法则（即二八法则），通常一个团队中的大多数开发工作都是由一小部分开发人员完成的。你团队中的明星型开发人员有很大的可能性都属于这一小部分人。所以，保持这些明星型开发人员的好心情和高产出是非常重要的。通常，这意味着要尽可能减少他们的管理负担，以便他们把重心放在关键和艰巨的任务上。对他们进行微观管理是一个可怕的想法，因为这不仅浪费了他们的时间，而且很可能会造成很多不满。最好不要干涉他们的工作，但要注意是否有任何针对他们的投诉。由于开发人员的薪资并非总是和他们的生产力挂钩，所以明星型开发人员的性价比通常非常高。这对公司来说很好，但也有点危险，因为这会让他们觉得他们对公司的价值被低估了。

最后一个是火山(Volcanoes)：火山型开发人员高产出，但低质量。这是非常危险的，必须对他们严加管理以防止对代码库造成永久性的破坏。如果对他们放任不管，随着时间的推移，代码质量将会被侵蚀，并进而伤害整个团队的开发效率。有两种类型的火山型开发人员：

第一类我把他们叫做“经验不足的高手(inexperienced hot-spots)”，通常他们缺乏的是质量意识和足够的经验。如果给予他们额外的指导和培训来重塑他们，这类火山型开发人员有一定的机会转变为明星型开发人员。
第二类我把他们叫作“代码破坏者(serial code-manglers)。代码破坏者是无可救药的，因为他们深信他们做的每件事都是正确的，而忽略了所有相反的证据。他们确信他们的代码是完美无缺的，所以不认为任何（自动）测试有意义。他们意识不到自己的问题，因而所有试图改进他们的尝试都不会有作用。对付他们只有两种方法：要么限制他们的输出，要么将它们踢出团队。后者更有效但往往无法做到，所以本文我将重点放在前者。你可以通过加强代码质量检查来防止你的代码库被火山式的爆炸所摧毁。推荐你采取的第一步是采取措施确保只有当他们的代码编译通过，而且所有的自动测试都通过了时候，才允许他们执行“合并到代码主干”的操作。然后，您可以通过诸如Sonar之类的工具添加进一步的检查，并使用诸如Checkstyle之类的工具做代码样式检查。强制性的代码审查也可以减少损害。所有这些额外的措施增加了代码破坏者的草率开发的难度，这会拖慢代码破坏者输出坏代码的速度，同时保证了好的开发人员尽可能少地受到影响。我强烈推荐采取以上措施。另外一个建议是：尽量将火山型开发人员用于质量不太重要的开发工作，例如原型开发。

好了，开发人员的四种类型我们已经谈过了。澄清一下，我不认为坏的开发人员是坏人，反之亦然。一个明星型开发人员可能是个混蛋，而一个火山型开发人员可能是个圣人。这四种类型不是构建团队时你需要考虑的唯一指标。但是，我们必须记住这一点：开发人员的技能是有巨大差异的，忽视它可能是致命的。也就是说，你必须清楚如何确定你的团队中的所有开发人员的技能水平。这里我得申明一下，我不是开发经理，所以对我的建议你大可有所保留。在我看来，如果你想领导一个开发团队，你需要懂得相关技术。理想的情形是，你能够在紧要关头替换团队中的任何成员。至少，你应该知道团队目前必须处理什么问题，以及谁在做什么。我建议你尽你所能，帮助开发人员做你能做的一切。比如，您可以尝试解决一些支持请求。即使你不能亲自写代码来修复bug，但是了解bug根源所在也可以帮助你了解代码库乃至整个产品。

如果你会写代码，你应该不时地查看代码库。最近的代码更改应该能让你很好地了解当前正在发生的事情以及代码质量如何。GitHub提供了对代码库的贡献明细，这可能有助于你确定谁贡献了多少。当然，这是个不完善的统计，不应将其作为KPI使用。此外，你的错误跟踪工具可能会给一些其它的指标。遗憾的是，没有完美的方法来获得你需要的所有信息。你需要多做些尝试，找出对你有用的。然而，这并不是一个新的挑战，因为大多数公司都已经有某种绩效评估措施。如果您已经为每个开发人员设置了“等级”，那么对这些等级和技能矩阵交叉参考可能会得出有趣的结果。

一旦你对团队成员的技能分布有了足够的了解，你就应该确定你的团队中是否有火山型开发人员。如果有的话，你必须制定计划并采取行动。经理的职责是处理有问题的团队成员，不这样做会招致其他团队成员的强烈不满。拉森和拉法斯托在1989年写了一本关于团队表现的书。这里我引用他们说的一段话：

与团队领导力的任何其他单一方面相比，对团队成员困扰更大的是团队领导不愿意直接有效地处理自私自利的或对团队无任何贡献的团队成员。

当你的团队中有人不履行职责，甚至做出伤害团队的事情时，你的团队成员都会知道。作为一名经理，你必须面对这个问题，即使它具有挑战性和让你不舒服。你的不作为会对你的团队和你自己造成伤害。一切顺利时，没有人需要一个经理。只有在危机时刻，才能体现出你对团队的价值。我希望这里的技能矩阵会对你有所帮助。

原文：https://thinkingsideways.net/people/2019/03/01/developer-skill-matrix.html

本文为CSDN翻译，转载请注明来源出处。

【End】

热文 推荐

戳他↓↓↓

☞京东“地震”

☞掌握 Android 系统架构，看这一篇就够了！| 技术头条

☞漫画：如何给女朋友解释什么是乐观锁与悲观锁 | 技术头条

☞频繁跳槽涨工资？会影响征信的！ | 畅言

☞39个国外SCI抢发6万篇中国英文论文？然而，真正的问题是……

☞偷电、挖矿、赚快钱，这些大学生到底怎么了？

☞终于有人把5G和边缘计算的关系说清楚了 | 技术头条

☞程序员为什么都爱穿冲锋衣？（最全总结）

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！n");
cout < < "点个在看吧！" < < endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"