我忍不住觉得整个经历是：“我们强迫一个工程师去接销售电话，我们……

这是我第一眼看到的问题。如果一名线路工程师能做得更好，为什么OP还有一份工作？ 提拔这个人当CTO，然后解雇那些无用的家伙，他们只是拿着工资无所作为。

你假设他们真的有产品经理。或者他们没有被大量需求压垮。

这可能是对的，但我在一个机械工程团队工作，是团队中唯一能编写代码或用代码自动化事物的人。我们处于一个大型公司中，有一个相当大的IT支持团队，他们内部开发了相当一部分软件，而我们团队认为其中大部分都很糟糕。因此，我重写了应用程序，或者用工具补充了“糟糕”但无法替代的软件，使我们的工作更容易。我认为我并不比我们内部的IT人员在软件开发方面更优秀，但作为实际终端用户，我的视角让我更清楚地了解如何满足我们自己的需求。我也有很高的动力让它有效，因为我自己会使用它。所以，标题最初引起了我的共鸣，没想到会看到这条评论。不过，我确信你的观点在许多情况下是正确的，因为我对正式的软件开发/项目管理并不熟悉。

好吧——好吧。我已经告诉你了：我处理那些该死的客户，这样工程师们就不需要处理了。我有人际交往能力；我擅长与人打交道。你不能理解吗？你们这些人到底怎么了？

大多数工程师在与产品经理开会时有两个主要问题： 1. 他们认为自己比其他人都更了解情况。有一个家伙这个问题困扰了五年，尝试了20种不同的解决方案？工程师们会花10分钟思考，然后提出一个解决方案（这不会奏效，但他们坚持认为会），并把这个问题视为“简单”，认为这个人很愚蠢。我自己也做过这样的事（我为此感到尴尬），而且我在从初级到高级/资深的各个公司都见过这种情况。软件工程团队缺乏谦逊可能是我这个行业最让我恼火的地方。结果，他们经常设计出糟糕的解决方案。 2. 一旦他们理解了问题和解决方案，他们通常很难从用户的角度思考解决方案，除非他们自己经历过这个问题。这不是…

即使在有产品经理的组织中，工程师们也常常有很坏的习惯，想要重写东西，或者按照他们自己想要的方式设计东西，而不是专注于客户的需求和问题

相反，这位产品经理确实给工程师上了宝贵的一课，他们可能需要每年重复一次——称之为用户培训吧，有点像安全培训。

是的，注意一下，完全没有提到原来软件为什么如此设计不良。甚至没有表现出一点好奇。你的结论更有道理，不过我并不一定把责任归咎于产品经理。敏捷/Scrum流程中，责任被分散，开发人员被迫快速完成设计不良的任务，导致了设计不良的软件。谁能想到呢？感觉这是现代臃肿软件组织中的系统性问题。