工程师还是开发人员？
决定你的项目是扩展规模——还是在生产环境中悄无声息地崩溃的思维差距
TL;DR:
大多数团队都说他们想要“工程师”，但许多团队实际上奖励的是“开发人员”。不是作为头衔——而是作为思维方式。开发者模式优化的是吞吐量 (throughput)。工程师模式优化的是长期的产品完整性。你需要两者，但你必须诚实地面对你的系统实际上在激励什么。
这是一个让领导者彻夜难眠的问题（通常是在本季度的第三次“为什么这个又坏了？”的事故之后）：
你正在建立一个开发人员 (developers) 团队……还是一个工程师 (engineers) 团队？
在这一点被斥为语义上的吹毛求疵之前：这种差异已经决定了高风险项目、甚至整个行业的命运，以及人们赖以生存的产品的长期健康状况。
剧透一下：这与学位几乎毫无关系。
首先，让我们打破学历的神话
地球上一些最优秀的技术专家是自学成才的。有些人拥有博士学位。大多数人介于两者之间。
在某些受监管的、安全至关重要的领域（医疗设备、航空、基础设施），学位很重要。但对于大多数产品团队来说，分界线不是学术性的。
而是这个：
开发人员优化产出 (outputs)。工程师优化成果 (outcomes)。
记住这一点。这就是这整篇文章的核心。
开发者模式：交付任务 (Ship the task)
开发者模式从根本上讲是任务导向的。
有一个工单 (ticket)。
它有验收标准。
它被完成了。
下一个工单。
这不是一种侮辱——这是一种至关重要的能力。开发者模式在以下情况下蓬勃发展：
- 需求相当明确，
- 优先级是保持势头 (momentum)，
- 执行需要稳定且可衡量。
它也非常适合仪表板和状态报告（因为产出很容易计算）。
失败模式： 开发者模式可以在永无止境的待办事项列表 (backlog) 中永远前行……而从未询问团队是否正在向正确的目的地移动。
你可以不断地交付，但仍然：
- 构建了错误的东西，或者
- 在一个无法支撑的根基上构建了正确的东西。
工程师模式：审视现实
工程师模式始于一种不同的本能：
“这有意义吗？”
工程师质疑需求。他们挑战假设。他们关心在这个变更之后系统会变成什么样——而不仅仅是这个工单是否能在周五之前关闭。
开发人员看到的是一张工单，而工程师看到的是：
- 一个系统，
- 具有依赖关系，
- 具有权衡，
- 具有长期后果。
工程师模式提出的问题在当下让人感到不便，但在以后却价值连城：
- 我们是在解决真正的问题——还是只是在解决最吵闹的症状？
- 为什么这会再次发生？
- 这个解决方案是变得更简单了……还是只是变得更庞大了？
- 我们正在制造什么样的技术债务，以后要为此付出什么代价？
现实最终会审计每个人。
为什么许多管理者更喜欢开发者模式（以及为什么这很危险）
这部分令人不适：
许多组织的结构是为了奖励开发者模式，因为它产生干净、可报告的指标：
- 关闭的工单数
- 发布的特性数
- 燃烧的故事点 (story points)
- “我们按计划进行”
那是管理者的“安慰食物”。它能安抚利益相关者。它适合放在演示文稿中。
工程师模式产生一种不同的句子——通常是真实的，通常是必要的，也通常是可怕的：
“我们发现了一些根本性的错误。我们应该停下来并正确地修复它。”
这句话不太适合放在每周状态更新中。
它威胁到时间表。它迫使人们公开权衡利弊。它让不确定性变得可见。
但这也是防止昂贵灾难的那句话。
三个现实世界的视角
这些不是“陷阱”。它们是模式——激励机制如何在大规模范围内塑造行为。
1) 当“完成”并不意味着“工作” (Healthcare.gov)
Healthcare.gov 的早期推出被广泛引用为一个案例，其中许多团队交付了组件和里程碑——然而整个系统在现实世界的需求下却举步维艰。
教训并不是“人们不会写代码”。
而是这个：
当团队因为在孤岛中完成任务而获得奖励时，系统在纸面上可能看起来是完整的……但在整体上却是失败的。
2) 停止生产线的权力 (丰田)
丰田制度化了一种许多软件组织只是假装拥有的工程原则：
如果出了问题，任何人都可以停止生产线。
这种文化不庆祝运动。它庆祝预防：
- 尽早发现缺陷，
- 修复根本原因，
- 避免重复同样的问题。
这就是转化为组织肌肉的工程思维。
3) 一次性构建基础 (爱沙尼亚)
爱沙尼亚的数字政府故事经常被引用，因为它不是从“数字化每一个表格”通过开始的。
它专注于架构：建立一个安全的、可互操作的基础，以便服务可以在其上可靠地构建多年。
这是一个工程师的问题：
“什么样的基础能让接下来的 1,000 个特性成为可能？”
标注：真正的区别 (产出 vs 成果)
这是最简单的诊断方法。
产出 (开发者优化)： 关闭的工单，发布的特性，燃烧的故事点，修复的错误。
成果 (工程师优化)： 消除重复发生的事故，降低复杂性，消除客户痛点，提高系统弹性。产出感觉像是进步。成果就是进步——但它们更难计算。
那么……你现在需要哪一个？
答案不是“工程师好，开发人员坏”。那是懒惰的思维。
你需要两者。真正的问题是：
你的组织奖励什么？
一个实用的经验法则：
- 早期阶段 / 范围明确 / 快速迭代 → 开发者模式可能会赢。
- 日益增加的复杂性 / 重复发生的事故 / 用户规模扩大 → 工程师模式变得生死攸关。
最好的团队不会永远只雇佣一种类型的人。他们培养可以切换帽子的人：
- 当速度至关重要时发布，
- 当完整性至关重要时慢下来，
- 并用通俗易懂的语言解释权衡。
标注：领导者如何获得更多的工程师思维（而不损失速度）
如果你想要工程师模式的行为，请奖励以结果为导向的行为。明确地奖励。
- 庆祝那个能防止接下来五次事故的修复——而不仅仅是关闭今天工单的补丁。
- 追踪重复出现的问题并减少它们（“为什么这会再次发生？”）。
- 即使简化工作变得可见（消除复杂性就是进步）。
- 像保护特性交付一样保护系统健康的时间。
- 创造安全感，让人可以说“这个需求没有意义”，而不会被贴上“难搞”的标签。
最后的想法
如果你的待办事项列表正在缩小，但你的产品正变得：
- 更难改变，
- 更难测试，
- 容易崩溃……
你没有生产力问题。
你有一个激励机制问题。
开发人员让机器保持运转。
工程师防止机器变成一个脆弱、过度复杂的装置，仅仅靠希望维系在一起。
所以——你的团队今天奖励什么：产出，还是成果？
TIC Insights | 为驾驭技术、创新和变革的高级领导者提供的视角。