最好的工程师，就是这样被你“逼”走的

作者 | Podge O’Brien 编译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

基于我多年来所经历的离职面谈，下面我将总结出几点最可能会“逼”走优秀工程师的原因及解决办法。虽然表面上来看，这都是些不太严重的问题，但随着时间的推移，它们会逐渐将人们压得喘不过气，直至绝望离开。

不会构建软件的领导

要问什么最让工程师感到悲伤？那必然是高高在上的领导（工程经理、主管、副总裁）不了解他们每天在面临什么问题，也不了解从头构建一些功能和软件的难点。

解决方法：让公司的工程经理、主管或副总裁起码每个季度用大概一周的时间，学会构建和交付功能。他们要学的不能是像更改一行文本这样简单的功能，而要是积压中的客户功能，整个流程应控制在三天左右，并且这些领导应该以团队合作的方式工作。

招聘太多且不同层级的领导

一旦你的管理层人太多，势必将决策推向更高层，也就必须开会决定，可讨论越多，团队层面的对接指导就会越少。举个例子，当一个上级经理想要完成某件事时，他可能会跟下一个经理沟通不畅，而低效的沟通将导致团队不知道他们应该做什么。

解决方法：扁平化你的组织，尽可能减少管理层人数。

无穷无尽地“开会”

一旦有人不知道需要做什么，不确定软件是如何制作的，并且团队之间存在许多支持关系，就召开会议，制作甘特图让员工遵守时间表。随后，就要召开更多的会来审查是否根据甘特图推进。期间如果又有什么悬而未决的问题，就又要开会“碰一碰”解决。

解决方法：在设计你的组织时，尽量减少团队之间的协作，同时确保团队内部要有高度协作。

让定义软件的过程变得痛苦

如果工程师必须承担起找出需要构建的工作，并独自构建功能以完成工作，这必将导致逆反心理。软件开发应该是一个团队共同努力的工作，如果团队中没有产品人员和其他重要职能来帮助协调工作，团队内部成员就会产生不满情绪。

解决方法：找到一种分担工程师负担的方法，例如在创建工单时，至少需要 3 个人花 10 分钟讨论工单，确保所有相关细节都囊括其中，包括描述变化是什么、将如何测试等。在我看来，这 3 个人最好是工程师、测试人员和产品人员，即产品人员应该领导并提供需要构建的环境，开发人员询问其中的具体功能，而测试人员则提问该如何测试。如果对需要做什么没有达成共识，工程师就不会开始构建软件，但查找信息不应仅由工程师负责。

让交付软件变得痛苦

写完工单并不代表就万事大吉，现实中仍有许多“意外”。如果开发环境不兼容，工程师就不能在本地开发，或者很难在开发环境中测试更改。如果测试不稳定，或者软件经常无缘无故停止工作，这对工程师来说无疑是一种挑战。

解决方法：根据你的制作之路有多艰难，有以下几种方法可以解决。

1、啥也不做，放任摆烂。不过我不建议这个方法，因为这可能会对你的工作构成生存威胁。

2、开始花时间解决这些问题，大概从 20% 的时候开始，分析问题所在并制定计划解决问题。

3、对工单进行优化，尤其是在维护现有代码的情况下。

让工程师计划他们的工作

让他们提前一个月完成工作计划，一个月后如果他们没有按时完成，就责怪他们不善于预测未来的事情。

解决方法：别让他们计划了。我分析了我参与过的每一个使用这个方法的团队，其中 99% 都是没用的。所以从我的经验来看，这行不通。如果你需要日期，我会推荐一种更现代的方法，例如预测。

过于小的团队

有些公司中，存在一些仅由三名应用工程师组成的团队，采用专门负责制作功能的模式，其他运营和 QA 工作都是在团队之外完成的，平时来看似乎没什么问题。可直到有一天其中有人请假了，另一个也请病假了，仅剩的那个工程师就要独自背负高效的重担和巨大的压力。长此以往，这个人就会崩溃离开。

解决方法：确保团队至少要有六个人。

向其他团队借人

如果你是一名工程师，当公司需要完成一些工作时，你被调到其他团队，这可能会令人感到低落和沮丧，因为这说明你没有多少时间来发展成为一名专业工程师。

解决方法：要让团队长久存在，有一个使命，那就是不要到处调动人员。

结语

以上就是一些在我看来很常见的工程团队存在的弊病，同时我也给出了相应的解决方法。虽然有一些方法看起来很简单，但真正实施起来很难——因为你生活在一个系统中，而改变系统，特别是基于人类的系统，是非常复杂的。

所以最后，有句话我想送给你：如果你不能“改变”你的公司，那就“改变”你的公司。

原文地址：https://blog.hulacorn.com/2021/09/08/how-to-drive-away-your-best-engineers/

《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造！