工程师有一种观念，认为其他大多数职位都比较次要，如果让他们负责的话事情会变得更好。我以前也这么认为。当我还是工程师的时候，我经常直接和客户交流，能够一对一地和他们交谈，解决他们具体的问题，感觉我是在做出改变，尤其是在一个拥有众多客户的大型产品中，通常很难听到客户的声音。当然，一旦这些客户得到了我的关注，他们就会不断提出功能请求，而我最终花在他们具体问题上的时间太多了。也就是说，随着时间的推移，我的观点发生了变化。回顾过去，我帮助过的客户中，那些问题对我来说最有趣，我知道自己可以解决，但这些通常并不是会对整个客户群体产生最大影响的改变。…
源讨论在谷歌14年的经验教训原帖 687 条评论 · 导入时统计我之前每份工作都有类似的模式。工程师是不应该直接与客户接触的。 我认为有多个原因导致这种情况，但它们大多与维护内部权力结构有关。 产品经理不希望有零散的用户证据，显示他们对产品的设想是不完整的。 工程经理不希望用户反馈会削弱对产品质量的感知，并打乱已经计划好的“有影响力”的工作。 客户关系（或者支持团队、用户研究，不管哪个团队实际上应该直接倾听用户）不希望你比他们做得更好（用你对工程和产品的深入了解）。他们也不希望你破坏他们向高层展示的“主题”或“情绪”。 法务部不希望你公开承认产品可能存在任何缺陷。
完整原文把你的经验，加入这段讨论。
这话说得含蓄，但让我想起了我最近听到的一句关于战争的古老谚语：100个人中，一个应该是战士，九个应该是士兵，而90个根本不应该在那里。 我认为软件开发人员也是如此：只有在公司里，那90%的人并不真正知道自己不应该在那里，他们建立了一个与公司实际需求平行的系统和项目世界。
完整原文每一个客户投诉都意味着有N个不再说话的客户流失了 “最大的影响”是无法知道的，所以手中的一只鸟比灌木丛中可能有的更值钱
完整原文这看起来像是由产品经理写的。你在职业生涯早期缺乏更高层次的上下文和优先级处理能力，所以得出的结论是最好将自主权交给别人吗？ 有一种现代的观点认为，领导者应该提供上下文和技能，让高绩效团队在他们的工作流中拥有更多的自主权。
完整原文> 工程师认为其他大多数角色都是次要的 真的吗？我一直觉得自己在链条的最底层。"晋升"意味着离开工程领域，进入管理岗位。 > 如果他们被允许掌权，事情会变得更好。 这可能是一种过度简化吗？工程师了解产品是如何构建的，因为他们是构建产品的人。有时他们也会接触到其他人（例如产品人员）所做的决定，他们知道更好的方法。 作为工程师，如果产品人员倾听我说"从我的角度来看，这样做会更好"，然后设法向我证明他们理解了我的观点，但告诉我他们仍会采取不同的方向，因为有其他限制，我对此是没问题的。 在我的职业生涯中，我遇到过很多让我觉得傲慢的产品人员：他们只是忽视我的意见…
完整原文一个组织总是可能走向相反的方向，但这不是从不与客户沟通的借口。后者更有可能发生，所以不要与客户“勾结”的警告就站不住脚。 这是一个常见的模式。爱丽丝说0度太冷，我更喜欢20摄氏度，鲍勃插话：“100摄氏度太热了，会要了我们的命。”好吧，没人说过或暗示要调到100度。
完整原文同意这可能是个问题，但澄清一下，我当时是在寻找错误或遗漏的停机时间，而不是收集功能请求或进行产品开发。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。