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

无穷无尽地“开会”

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

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

过于小的团队

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

结语

向其他团队借人

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

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

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

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

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

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

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

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

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

让工程师计划他们的工作

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

不会构建软件的领导

让交付软件变得痛苦

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

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

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

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

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

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

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

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

文章来源：《中国表面工程》 网址: http://www.zgbmgc.cn/zonghexinwen/2022/0728/826.html