科技公司中的工程影响力 | AI生成和翻译
问题：在大公司中，工程师是否应该拥有更多影响力，产品经理是否应该深入理解工程技术以避免糟糕的技术决策？
回答：
是的，在强大的科技公司中，工程通常比传统公司拥有更多的决策权，但这并非因为“程序员凌驾于业务之上”。而是因为许多业务决策最终会变成系统设计决策，而糟糕的技术决策可能会带来多年的成本。
一个合理的结构通常是：
业务 / 用户
|
v
产品策略
|
v
工程设计 + 实现
|
v
系统能力
|
v
业务成果
错误在于将工程仅仅视为“写代码的人”。实际上，工程师通常理解：
- 可行性
- 架构权衡
- 运营成本
- 可扩展性
- 安全性
- 维护负担
- 开发者生产力
例如：
糟糕的决策：
团队A：开发iOS应用
团队B：开发Android应用
团队C：后来开发Web应用
三个代码库：
iOS Swift
Android Kotlin
Web React
相同的业务逻辑：
登录
支付
用户资料
通知
重复了3次。
一个技术能力强的团队可能会提出：
Flutter / React Native / Kotlin Multiplatform
|
v
共享业务逻辑
|
-----------------
| | |
iOS Android Web
这个决策并非“工程师想要花哨的技术”。它本质上是一个业务决策：
- 更快的迭代
- 更低的成本
- 更少的缺陷
- 更小的团队
然而，盲目使用跨平台技术也是一个错误。例如，一个高性能相机应用、游戏引擎或深度原生体验可能需要原生开发。
关键在于技术判断力。
一个优秀的产品经理不一定需要是资深工程师，但一个在技术公司中表现良好的产品经理应该理解：
- API
- 数据库
- 分布式系统基础
- 移动端/Web架构
- AI模型能力
- 工程权衡
最好的产品领导者往往有工程背景。
例子：
- Kevin Scott 拥有计算机科学和工程背景。
- Linus Torvalds 是工程驱动产品创造的极端例子。
- 许多成功的创始人都有技术背景，因为他们能直接将用户问题与实现可能性联系起来。
但还有另一种失败模式：
工程师认为：
“我构建了一个技术上完美的系统。”
用户认为：
“我不需要这个。”
业务死亡。
一个技术上优秀但缺乏市场价值的架构同样是浪费。
最强大的公司结合了：
卓越的产品直觉
+
卓越的工程判断力
+
快速执行
理想的关系：
产品经理：
“我们应该解决什么问题？为什么它重要？”
工程师：
“解决这个问题的最佳方式是什么？有哪些权衡？”
双方相互影响。
大公司往往在以下情况下变得低效：
业务方说：
“直接做这个。”
工程方说：
“我们不知道为什么，但好吧。”
或者：
工程方说：
“我们要构建完美的系统。”
业务方说：
“没人想要这个。”
高效能公司会避免这两种极端。
一个成熟的科技公司通常赋予工程师技术权威，赋予产品经理产品权威。任何一方都不应主导；决策由对各自维度理解最深的人做出。
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋