1.1 软件工程价值观

概述与动机

软件工程价值观，是塑造人们如何共同构建软件的共同信念、规范和日常行为。它们不是墙上的海报，也不是员工手册里的文字。它们是当一次事故在凌晨三点把某人叫醒时、当一名初级工程师与一位首席工程师意见相左时、当截止日期与质量发生冲突时，真正发生的事情。价值观是每一个技术决策背后那个看不见的系统。

在一个小团队中，价值观通过耳濡目染传播：大家坐在一起，吸收这些规范，并自我修正。而在一个更大的团队中，耳濡目染的方式会失效。这时你必须把价值观明确表达出来，写下来，让领导者以身作则，并通过你的各种系统去强化它们。如果跳过这一步，文化就会分裂成几十种互不相容的微文化，悄悄地给每一次协作都增加税负。

对一个更大的团队来说，风险是结构性的。薄弱的价值观会表现为人员流失、决策缓慢、知识囤积，以及那些根本原因从未被彻底解决、反复出现的事故。强健的价值观则表现为快速、安全、可靠的变更：工程师会及早暴露问题，从失败中学习，并主动承担责任。这两种状态之间的差距，往往比任何技术选型的差距都要大。

企业和政府组织对此感受尤为深刻，因为它们的工作规模庞大，处于审视之下，且时间跨度漫长。今天构建的系统，可能会运行十年甚至更久，由那些从未见过原始作者的人来维护。在这样的环境中，文化正是跨越时间和人员更替、承载意图的东西。

受监管的企业还面临着另一重压力：用流程去替代信任的诱惑。当问责要求很高、错误又显而易见时，本能反应就是不断叠加管控、审批和追责。这种反应可以理解，但会适得其反。最可靠、最安全、最合规的组织，通常是那些学习文化最强健的组织，而不是惩罚性最强的组织。价值观与合规，是盟友，而不是对立面。

关键原则

心理安全感是基础；没有它，其他一切实践都会退化。
失败就是数据。无责的学习方式，能把事故转化为持久的改进。
主人翁意识（ownership）意味着对结果负责，而不仅仅是对产出负责：“谁构建，谁运维”。
写作即思考。一种把决策写下来的文化，能让判断力得以规模化。
可持续的节奏胜过英雄主义；职业倦怠是一种系统性的失败，而不是个人的失败。
多样性、公平与包容是工程上的优势，能提升决策质量。
价值观是自上而下示范、自下而上强化的；领导者的行动，比他们的言语更有分量。

建议

有意识地建立心理安全感

心理安全感，是一种共同的信念，相信你可以畅所欲言、提出问题、承认错误、挑战决策，而不用担心受到羞辱或惩罚。在大规模研究中，它是团队效能最强有力的单一预测因素。要有意识地去建立它。让领导者公开承认自己的错误（“这是我犯过的一个错误，以及我从中学到了什么”）。以好奇心而不是惩罚来对待坏消息。在会议中公开邀请不同意见。轮流让不同的人先发言，这样资深人士的意见就不会锚定整场讨论。并让说出”我不知道”和”我需要帮助”变成一件很正常的事。

践行无责学习

当出问题时，要审视那些让失败得以发生的条件，而不是触发失败的那个人。采用无责的事后总结（postmortem）：一份书面记录，说明发生了什么、时间线、促成因素，以及带有负责人和日期的具体行动项。从一个假设出发：每个人在当时所知的情况下，都做出了合理的行为。要问”是什么让这件事很容易出错？“，而不是问”谁搞砸了？“。并且要跟踪行动项直到完成为止。一种从不关闭后续行动的事后总结文化，只是一场表演。

建立清晰的主人翁模式

“谁构建，谁运维”（you build it, you run it）让编写某项服务的团队对运维这项服务负责，包括值班待命。这收紧了设计决策与运维痛点之间的反馈回路，从而提升了质量。把它与一份服务目录搭配使用，为每一个系统记录：谁拥有它、如何联系到他们、它的依赖关系，以及它的操作手册。保持主人翁归属明确且互不重叠。归属模糊，正是系统腐坏、事故拖延不决的原因。当一个团队确实无法独立运维某个系统时，给予它平台支持，而不是把问责分散稀释掉。

培育写作文化

写作能磨砺你的思考，并创造出能跨越时区和岁月留存下来的成果。让设计文档和决策记录成为重大变更的常规做法：一份简短的文档，说明问题所在、考虑过的方案、提议的方法，以及各种权衡取舍，在动手构建之前先传阅征求意见。这能在分歧还很廉价的时候，及早把它暴露出来，并留下一份持久的记录，说明你们当初为什么做出了那样的决定。保持模板轻量，让期望与决策的分量相称。并且要公开表彰优秀的写作。

保护可持续的节奏

英雄文化（）少数几个人一再靠不可持续的付出来拯救组织（）是一种虚弱的症状，而不是一种美德。它会耗尽人的精力、危险地集中知识，并掩盖了你本该去修复的根本问题。所以要度量和管理值班负荷。如果一个人不断被呼叫，就把它当作一个需要通过工程手段消除的缺陷来对待。让休假变得正常，保护专注时间，并以一个季度而不是一周为周期来评判产出。

把多样性、公平与包容当作一种工程优势

多元化的团队能做出更好的决策。它们能权衡更多视角，更少陷入群体思维和盲点，而这对无障碍访问、安全性以及服务广泛人群而言至关重要。把包容融入你日常的工程工作中：无障碍的文档、代码和界面中的包容性语言、能让声音较小的人也能参与贡献的会议方式，以及在耀眼的工作和幕后粘合性工作之间公平分配。

权衡：优点与缺点

方法	优点	缺点
无责事后总结	揭示真正的根本原因；建立信任；推动系统性修复	在外人看来可能像”没有问责”；需要纪律才能真正关闭行动项
“谁构建，谁运维”	紧密的质量反馈回路；归属清晰	值班负担；需要强有力的平台支持以避免职业倦怠
先写文档／RFC 文化	决策持久；能跨越人员更替而扩展；对异步协作友好	对琐碎变更来说较慢；如果过度应用，有陷入官僚主义的风险
可持续的节奏	留存率、可靠性、长期速度	在赶工期间感觉更慢；需要领导层坚守底线

核心张力在于短期速度与长期健康之间。英雄主义和追责能换来一阵表面上的掌控感，随后却是士气和可靠性的缓慢崩塌。无责学习、主人翁意识和可持续的节奏，在任何单独一周里都会显得更慢，但它们会在数个季度乃至数年间产生复利，带来远高于前者的速度。领导者必须愿意承受短期的不适，才能守护长期的能力。

与团队讨论的问题

你们如何防止”无责”在审计人员、高管和公众眼中被解读为”没有问责”？ 在一家受监管的企业或一个受监督的政府机构中，一份不点名任何”罪魁祸首”的事后总结，在工程团队之外的人看来可能像是一种掩盖。这里存在真实的相互竞争的考量：你需要只有无责才能产生的那种诚实，同时你也需要决策者相信失败真的会被解决。把具体证据带到讨论中，比如你们的事故复发率和事后总结行动项的完成率，因为一个能可靠地关闭后续行动的系统，即便没有替罪羊，其问责也是清晰可见的。把追责文化混为一谈的两个问题分开来看：是什么让这件事很容易出错，以及是否有人存在真正的疏忽或恶意。如果你们的答案是问责体现在修复条件和关闭行动项上，那就把这套机制公开出来，让外人也能看到他们所寻找的那种问责。
哪些团队正背负着他们实际上无法运维的值班系统，这个缺口由谁来买单？ “谁构建，谁运维”收紧了反馈回路，而它的前提是一个团队具备运维自己所构建之物的平台支持。在企业和政府的规模下，有些团队继承了遗留系统、供应商的黑盒，或者是没有哪个小团队能真正独自拥有的跨领域基础设施。这里的权衡，处在分散问责（不好）与让一个团队背负它无法应答的呼叫器而走向失败（同样不好）之间。带上呼叫数据来讨论：如果一个人或一个团队不断被呼叫，就把它当作一个需要通过工程手段消除的缺陷，而不是一枚荣誉勋章。这个答案应该告诉你们，该在哪里投资平台团队、分阶段上线，以及最新的操作手册，这样归属就能保持清晰，运维负担也能保持在人道的范围内。
你们实际推崇和奖励的行为，是否与你们公开宣布的价值观相符？ 一旦领导者奖励的恰恰是海报上谴责的行为，价值观就会腐化成犬儒主义，而在大规模场景下，这个落差会一直隐而不见，直到人员流失和悄然的知识囤积把它暴露出来。仔细审视你们上一轮晋升：奖励的是救火和英雄主义，还是防火以及维系一个大团队健康运转的那些幕后粘合工作？企业和政府机构会放大这种风险，因为僵化的职级体系和漫长的任期，会让一种错位的激励机制运行多年而无人纠正。带上真实的证据，比如谁被提拔了、谁在公开场合被表扬了，以及这些人实际上做了什么。如果英雄主义得到了奖励，你们其实是在训练自己的组织去制造那些日后被大家庆祝解决的危机，而解决办法是改变激励机制，而不是墙上的装饰。
你们如何才能真正知道某个团队的心理安全感是高还是低，而不是从组织架构图上想当然？ 安全感是其他一切实践赖以立足的基础，也是最容易让你自欺欺人的东西，因为安全感最缺乏的团队，恰恰是最不可能告诉你这一点的团队。在大规模场景下，一千人的平均值会掩盖真正重要的方差：一位经理可能在一个整体健康的组织内部，悄悄经营着一个基于恐惧的团队。相互竞争的考量在于坦诚与舒适之间，因为那些能揭示真实问题的调查问题，恰恰是人们最不愿意如实回答的问题，而收集这类信号本身，也可能让人感到不安全。带上具体的证据而不是感觉：来自一个经过验证的安全感测评工具的团队层面结果、人们以书面形式承认错误的比例、在演变成事故之前就被上报的险情报告，以及离职面谈中反复出现的主题。对企业或政府机构而言，要坚持数据只停留在团队层面，绝不用来惩罚一个得分较低的团队，因为一旦安全感评分变成了一根大棒，它衡量的就不再是安全感，而是对这项测量本身的恐惧。
你们真实的值班和英雄主义负荷是多少？你们奖励的是预防火情的人，还是扑灭火情的人？ 可持续的节奏，正是良好意图在交付压力下悄悄崩塌的地方，一个大型组织可能靠着少数几个精疲力竭的人所付出的隐形加班运转多年，而组织却对此毫无察觉。这里的张力是真实存在的：英雄主义确实能在当下拯救你，而依赖它却会集中知识、掩盖系统性缺陷，并耗尽你最投入的那些工程师。把运维数据带到讨论中：每人每周被呼叫的次数、下班后的部署、值班负荷在团队中的分布情况，以及其中有多少年复一年地落在同样那几个人身上。也要看看你们上一轮晋升奖励了谁。在拥有僵化职级阶梯和长任期的企业和政府机构中，一种为救火买单的文化可以延续十年而无人挑战，所以这个答案应该告诉你们，该在哪里用工程手段降低呼叫频率，以及如何让防火成为一件明显可以获得晋升的事。
过去两年中，哪些重大决策没有留下推理过程的书面记录？当作者离开后，这将付出什么代价？ 写作文化，正是跨越人员更替、承载意图的东西，而它的缺失，会一直隐而不见，直到有人需要改动一个已经没人理解的系统的那一刻。与之相对的拉力是速度：撰写设计文档或决策记录，在当下会感觉像是一种阻力，而如果过度应用，就会变质成拖慢琐碎变更的官僚主义。带上证据来校准它：有设计文档或决策记录的重大变更所占的比例、人们实际能找到并引用某个现有架构背后推理过程的频率，以及一名新工程师在一个没有文档记录的服务上达到高效产出需要多长时间。对于那些系统寿命超过所有建造者任期、并且可能面临审计或信息公开审查的企业和政府组织而言，书面记录既是机构记忆，也是尽职调查的证据，所以这个答案应该划出一条界线：决策的分量足以证明书写的必要，而不能再低了。

行业视角

初创企业。 价值观仍然通过耳濡目染传播，所以不要引入沉重的流程，但要明确点出一两条最重要的行为，通常是对错误保持无责的诚实，以及倾向于及早暴露坏消息。创始人通过公开承认自己的错误来定下基调，因为在一个极小的团队里，Slack 里一次尖锐的反应，就可能让所有人在此后数月都学会隐藏问题。你们稀缺的跑道，正是保护安全感、而不是跳过它的理由：一个隐藏缺陷的团队，代价远比一次五分钟的回顾会议要高昂得多。

小型企业。 没有专职的工程文化专家，预算也很紧张，因此要依靠轻量级的仪式，而不是需要购买或配备专人维护的工具。一个共享的事故频道、一份单页的决策日志，以及养成”是什么让这件事很容易出错？“的习惯，成本为零，却能带来大部分价值。在实践方面也要有意识地权衡”买还是造”：采用一份现成的事后总结模板和一份简单的值班排班表，而不是构建一套你们维护不了的定制系统。

企业。 在大规模场景下，工作在于实现一致性而非千篇一律：无责学习、清晰且互不重叠的归属，以及写作文化，成为全组织范围的规范，并配有相应的工具、期望和一份服务目录来支撑。治理和审计会把你们推向管控，所以要论证一种强健的学习文化才是最可靠、最合规的选择，并用事故复发率和行动项关闭率等指标来证明这一点。留意各团队之间的方差，因为平均值会掩盖那些悄悄流失人才和知识的、基于恐惧的角落。

政府机构。 采购规则、透明度义务和公共问责，塑造着价值观（尤其是关于追责的部分）的表达方式。一份不点名”罪魁祸首”的事后总结，在外部监督机构看来可能像是一种掩盖，所以要把这套机制公开出来，展示问责体现在修复条件和关闭行动项上，并让公民和审计人员看到这一点。由于系统的寿命超过历届政府的任期，人员更替以年为单位计量，所以要把书面的决策记录，既当作机构记忆，也当作在信息公开审查下尽职调查的证据来对待。

示例

初创企业。 一家六人规模的初创公司依靠信任和走廊里的闲聊运转，所以没有人把团队的价值观写下来。当一位创始工程师推送了一次糟糕的迁移、CTO 在 Slack 上对他厉声斥责时，整个团队都陷入了沉默，接下来的两个缺陷都被悄悄藏了起来，而不是被上报。这个团队靠着采纳一个轻量级的习惯恢复了过来：每次事故之后进行一次五分钟的无责对话，问”是什么让这件事很容易出错？“，不需要任何模板。这个小小的仪式，让这种耳濡目染式的文化保持健康，而不需要一个更大的组织所需要的那种流程开销。

企业。 一家大型金融服务公司，因为一次常规的配置变更在各服务之间层层扩散，遭遇了一次重大宕机。在一种追责文化中，推送这次变更的工程师会被训斥，事情也就到此为止。取而代之的是，一次无责的事后总结揭示出：部署工具让这次危险的变更看起来和一次安全的变更一模一样，当时没有分阶段上线机制，操作手册也已经过时。这家公司随后投资于渐进式上线和配置校验，如今类似的变更会以安全的方式失败。选择审视系统而不是审视个人，带来了一项持久的工程改进。

政府机构。 一家政府数字服务机构，在采用”谁构建，谁运维”的同时，配合了一套严格的、先写文档的 RFC（征求意见）流程。由于其系统必须在政治领导层更迭和以年计量的人员更替中存续下去，每一项重大决策都被记录在一份设计文档中，说明背景和权衡取舍。新加入的工程师和承包商，能够读到一个已有十年历史的架构背后的推理过程，而不需要靠逆向工程去猜测。正是这种书面的机构记忆，让这家机构即便在高人员流动率和严格问责要求下，也能保持公共服务的可靠运转。

业务论证：动机、投资回报率与总拥有成本

文化带来的回报是真实的，但也是间接的，这正是它长期投入不足的原因。在一个系统的整个生命周期中，最主要的成本并不在于构建它，而在于维护、事故响应、返工，以及流失并重新招募熟练人才的成本。一种强健的学习文化，能改善以上每一项。无责的事后总结能减少事故复发。清晰的归属能缩短平均恢复时间。写作文化能降低入职培训的成本，也能降低那些在对此前推理过程一无所知的情况下做出的决策所付出的代价。

仅以人员流失为例。一旦算上招聘、上手所需的时间，以及随之流失的机构知识，替换一名中级工程师的成本，通常在其年薪的一半到两倍之间。如果一种更健康的文化，能让一个千人规模的组织中令人遗憾的人员流失哪怕只降低几个百分点，节省下来的成本也会远远超过运行事后总结和撰写文档这些不算高昂的成本。采纳这套做法的成本，主要是领导层的关注，以及少量的流程开销。而不采纳它的成本，则会以持续、隐形的方式被支付：更慢的交付速度、反复出现的事故，以及悄悄流失的人才。

要向领导层证明这一点，就把文化与高管们已经在追踪的指标联系起来：交付前置时间、变更失败率、平均恢复时间、事故复发率，以及令人遗憾的人员流失。把心理安全感的定位，从一项”软性福利”重新构建为一种机制（）正是这种机制，让其他每一项工程投资都能获得回报，因为不安全的团队，恰恰会隐藏那些这些投资本应去修复的问题。

反模式与陷阱

追责与羞辱式的事故复盘：它们会把问题逼入地下，人们从此不再上报。
英雄崇拜：奖励救火而非防火，只会让火情持续发生。
领导者自己违反的”价值观”：宣称的价值观与实际行为相矛盾，滋生犬儒主义。
没有支持的主人翁意识：把值班责任分配给团队实际上无法运维的系统。
用流程替代信任：不断叠加审批，而不是构建真正的安全感。
文档表演：撰写没有人读、或从未真正影响任何决策的文档。
把包容当作一个打勾的选项：为了多样性而招聘，却又把这些声音排除在决策之外。

成熟度模型

第 1 级，初始阶段：价值观是偶然的、由个人性格驱动的。事故意味着追责，知识存在于少数几个人的头脑中，靠英雄主义把事情做成。没有人把团队所信奉的东西，或者在压力下应该如何表现，写下来过。
第 2 级，发展阶段：一些团队开始进行无责事后总结，偶尔撰写设计文档，也谈论主人翁意识，但这些实践并不一致，应用得也参差不齐，也还没有得到领导层的强化。你能否遇到一个健康的团队，主要靠运气。
第 3 级，标准化阶段：无责学习、清晰且互不重叠的归属，以及写作文化，已成为全组织范围内有文档记录的规范，配有模板、一份服务目录，以及明确的值班预期。领导者以身作则示范这些价值观，同样的行为在各处都被期待，而不仅仅是在恰好有一位好经理坐镇的地方。
第 4 级，管理阶段：文化依据基准被度量并用数据加以控制。你们追踪团队层面的心理安全感评分、事故复发率、事后总结行动项的关闭率、值班负荷的分布、平均恢复时间，以及令人遗憾的人员流失，并在一个团队出现偏离时依据这些数字采取行动。依据证据消除救火激励，并奖励防火行为，因为现在你们已经能够看见它了。
第 5 级，编排阶段：文化被持续改进，并与整个组织的规划、招聘和晋升方式相整合。安全感高，学习速度快，实践也会随着证据和情境的变化而调整。组织会有意识地重新平衡值班负荷、更新决策记录，并主动演化其规范，而不是等待一场危机来倒逼这个问题。

讨论想法

在我们的组织中，哪些地方的人不敢说”我不知道”或”我不同意”，为什么？
我们的事故复盘，是在改变系统，还是仅仅在归咎责任然后就此了事？
我们是否在奖励一些本该用工程手段消除掉的英雄主义行为？
过去两年中，哪些重要决策没有留下推理过程的书面记录？
幕后粘合工作和值班负荷，在团队中的分配有多均衡？
我们所宣称的价值观，是否与实际能让人在这里获得晋升的行为相符？

关键要点

价值观是每一个技术决策背后那个看不见的操作系统；在大规模场景下，价值观必须被明确表达出来。
心理安全感是基础；没有它，其他实践就会退化。
无责学习能把失败转化为持久的系统性改进。
清晰的归属（“谁构建，谁运维”）收紧了质量反馈回路。
写作文化能让判断力跨越时区和人员更替得以规模化。
可持续的节奏和包容，是长期的速度倍增器，而不是成本。

参考文献与延伸阅读

Amy C. Edmondson, “The Fearless Organization” and “Teaming”
Google re:Work / Project Aristotle research on team effectiveness
Sidney Dekker, “The Field Guide to Understanding ‘Human Error’”
John Allspaw, “Blameless PostMortems and a Just Culture” (Etsy Code as Craft)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate: The Science of Lean Software and DevOps”
Gene Kim et al., “The Phoenix Project” and “The DevOps Handbook”
Camille Fournier, “The Manager’s Path”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Tom DeMarco and Timothy Lister, “Peopleware: Productive Projects and Teams”