大型科技公司中不受欢迎的协作观点 | AI生成和翻译
问题：在大型企业工程团队中，关于沟通或协作有哪些不受欢迎的观点？
回答：
以下是关于大型企业工程团队（例如，大型科技公司或类似组织）中普遍受到赞扬的沟通和协作实践的一些反主流或不受欢迎的观点。这些观点挑战了主流建议，例如“会议越多越好”、“敏捷/Scrum 最大化协作”或“持续开放沟通可以提高生产力”。
-
会议过多会扼杀深度工作和生产力：每日站会、同步会议和跨团队会议通常被视为保持一致性的必要条件，但批评者认为它们会分散注意力，浪费时间在状态更新上（通过 Slack 或电子邮件等工具异步处理会更好），并在大型组织中导致“会议疲劳”，其中协调开销主导了实际的工程工作。
-
Scrum/Agile 仪式阻碍而非促进协作：Scrum（包括 Sprint、点数、回顾性会议和产品负责人等角色）以促进团队合作而闻名，但它被批评为过度管理工程师，奖励肤浅的速度而不是质量，并将创造性工作转变为官僚主义的小型瀑布式开发——尤其是在大型公司中，其扩展性很差。
-
过度沟通和“彻底透明”会滋生政治，而非更好的协作：大型公司推动开放渠道、共享文档和频繁更新以实现包容性，但这可能导致表演式忙碌、建立帝国、信息过载和间接政治斗争，而不是直接、高效的问题解决。
-
强制的跨职能或开放协作会变相制造竖井：强调跨团队同步和“打破竖井”听起来很理想，但实际上，它往往会导致推卸责任、所有权稀释，以及由于激励机制不统一而导致的隐性竖井——工程师最终会更加激烈地保护自己的地盘。
-
异步书面沟通优于同步口头交流：口头会议和电话交流因“建立关系”而受到青睐，但不受欢迎的观点认为，过度依赖书面文档（例如，设计评审、RFC）可以减少误解，在大型/分布式团队中扩展性更好，并迫使更清晰的思考——而无休止的电话交流则有利于外向者和口齿伶俐的人。
-
并非每个人都需要同等程度地协作或沟通：在会议中征求所有意见等包容性做法是标准做法，但持不同意见者认为这会使平庸民主化——决策应由最有能力的工程师主导，而不是共识，因为广泛的投入往往会延迟进展而不会增加价值。
这些观点之所以“不受欢迎”，是因为它们与强调过度协作的主流企业文化背道而驰，但支持者认为它们在复杂的工程环境中能带来更高质量的产出。
参考资料：
- https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
- https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/
- https://devops.com/agile-scrum-is-a-failure-heres-why/
- https://newsletter.pragmaticengineer.com/p/project-management-in-tech
- https://age-of-product.com/engineers-despise-agile/
- https://dev.to/ragnarkon/a-criticism-of-scrum-21al
- https://www.reddit.com/r/cscareerquestions/comments/1l0wg36/big_tech_engineering_culture_has_gotten/