像一家软件公司那样观察

詹姆斯·C·斯科特（James C. Scott）在《像国家一样观察》（Seeing Like A State）一书中提出的核心思想，可以归结为三点：

  1. 现代组织通过最大化“可读性”来施加控制：即改造系统，使其各个部分都能被测量、报告等。
  2. 然而，这些组织又极度依赖大量“不可读”的工作：这些工作无法被追踪或提前规划，但却是不可或缺的。
  3. 因此，提高可读性往往实际上降低了效率——但其他好处足够大，以至于组织通常仍愿意这么做。

所谓“可读”，我指的是那些可预测、可估算、有文档记录、不依赖偶然因素（比如特定人员是否在岗）的工作。季度规划、OKR 和 Jira 的存在，都是为了使工作变得“可读”。而“不可读”的工作则是其余一切：请求或给予人情帮助、运用无法或尚未写下来的默会知识、插入未计划的变更、依靠人际关系网络推进任务。正如我将要论证的，科技公司必须同时支持这两种类型的工作。

用“可读性”与“不可读性”来思考，能解释许多在大型软件公司中令人困惑的现象。它解释了为什么公司会做许多明显反生产力的事，为什么实际执行的规则常常与明文规则脱节，以及为什么在某些情境下，公司竟出人意料地容忍违规行为。

像国家一样观察

詹姆斯·C·斯科特所描述的是治理领域中的“高现代主义”运动，这一运动催生了19世纪德国那种整齐划一的森林1。为了大规模生产木材，德国政府要求森林具备“可读性”：一名检查员可以走进森林，清点健康树木的数量。这意味着你必须能在林中穿行——即下层灌木必须被清除——而树木最好整齐排列，且为单一树种。

可读性的倡导者常将自己的流程称为“效率措施”或“避免浪费”的方式。但总体而言，这些新的“高效”森林实际上远不如旧的、不可读的森林高效。它们每年产出的木材更少，且更容易爆发疾病，因为灌木层对土壤健康起到了意想不到的支撑作用，而树种多样性原来也是一项资产。新的同质化森林可能被一种寄生虫或病害彻底摧毁，而旧的、更复杂的森林则不会。

然而，可读性带来的优势是巨大的。一旦你确切知道有多少棵树，你就能提前规划、签订大宗贸易合同、防止腐败等。对我来说，这是斯科特最引人深思的一点：大型组织确实相信更高的可读性必然带来更高的效率2。但即使后来事实证明这是错误的，这些组织仍继续推动可读性，因为其他优势太强大了。

像一家软件公司那样观察

在软件公司中，情况如出一辙。对软件工程师而言，几乎是一个不言而喻的常识：一个工程师独自工作时，往往比在团队中更高效。这正是为什么有那么多关于工程师请假后终于能完成工作的轶事，或关于在夜晚和周末才能真正产出成果的说法。

同样，任何一线工程师都应清楚：由工程师主导的工作，远比由上层指派的工作推进得更快。工程师主导的工作无需被翻译成“上级能理解的形式”，无需在各个方向主动沟通，通常可以以最直接、最高效的方式完成。

这就是为什么小型软件公司往往比大型公司在交付软件方面表现更出色：如果小公司效率是大公司的二十倍，那么即使大公司投入的工程师数量是小公司的十倍，也无济于事3。

为什么大型公司不干脆取消所有流程来应对这一问题？他们是傻吗？ 不是。那些拖慢工程师的流程，正是让他们的工作对整个公司“可读”的流程。而这种可读性（以金钱衡量）比更高效地产出软件更有价值。

可读性对科技公司的价值

在实践中，可读性对一家科技公司意味着什么？它意味着：

请注意，“交付高质量软件”、“让用户满意”甚至“赚钱”都不在这一列表中。这些是科技公司希望达成的目标，但它们本身并非“可读性”。

我们那个小而高效的软件公司，只满足其中一条：能够迅速转向某个亟需解决的紧急问题。其余信息都锁在各个工程师的脑子里，他们可能记不清两个月前做了什么（更不可能愿意承诺两个月后的工作）。只要大家对目标有共识，且产品持续改进，这未必是问题。

典型的大型软件公司则几乎满足所有这些条件——我说“几乎”，是因为在某些公司或部门中，调动资源处理“紧急任务”的能力已经退化（后文详述）。除此之外，大公司通常非常擅长记录当前工作内容、记住过去交付了什么，并在中长期规划工作。

为什么这些能力对大型软件公司如此重要，而小公司却可以没有？这略微超出了我的专业领域，但我相当确定，主要原因在于大型企业客户交易。与大型企业客户合作利润极其丰厚。因此，任何足够大的 SaaS 公司，只要可能，最终都会从服务小客户转向服务大企业客户4。但这类交易（a）往往需要数月甚至更长时间才能敲定，（b）还要求做出长期的功能承诺。一个“不可读”的公司无法持续数月维持一项乏味的企业级交易，不断回答问题、交付功能。大型企业客户根本不会相信一家小公司能在未来一两年内持续交付他们所需的东西。

这类客户通常高度重视可读性，因此也要求他们的供应商具备可读性。事实上，高度可读的组织很难与可读性较低的组织沟通（反之亦然）。他们缺乏合适的资质认证，语言不通，等等。这给成长中的科技公司带来了真实压力：即使损害了交付软件的能力，也必须变得更“可读”。

可读性的假设

在追求可读性的过程中，大型科技公司对技术工作的本质做出了一些简化的假设。例如，他们假设：

当然，这些假设全是错误的。同一职级内，工程师的能力存在巨大差异。工程师有不同的技能和兴趣，只有在项目与自身匹配时，才能高效工作。因此，团队的生产力与人数之间的关联很弱。

项目估算大多是幻想。更准确地说，它们是“表演性”的：最初的估算决定了工程师将如何调整工作以按时交付，而不是估算决定实际工作量。因此，将项目拆解并逐项估算，往往反而导致整体估算更不准确，因为它阻碍了工程师围绕最终交付日期进行整体协调。

然而，这些假设对它们的目的而言“足够真实”——即为公司高管提供可读性。无论估算是否准确，它都能用于规划，并与其他大型组织沟通（而对方通常也清楚这类估算不应被完全当真）。

临时的、被默许的不可读区域

我前面提到，大型公司有时会失去处理紧急任务的能力。这是因为让工作“可读”的流程本身带来了严重延迟。设想一家典型的大型公司在开始编码前可能经历的步骤：

  1. 某人提出一个产品想法。
  2. 他将这个想法提交给产品部门，进入“规划”阶段。围绕这个想法召开会议。
  3. 产品部门正式决定推进后，想法移交工程部门：由一群工程架构师进行初步技术评审。他们确定其在整体工程优先级中的位置，并给出粗略的时间预估。
  4. 工程部门的副总裁和高级经理协商由哪个团队负责。这通常是一个半技术、半组织的决策（因为工作应归属哪个服务，部分是技术问题）。
  5. 最终任务落到团队头上。它进入团队的规划待办列表，由技术负责人拆解为更小的任务。
  6. 这些小任务进入团队的工单待办列表，在每周规划会上进行估算。
  7. 最终，其中一些任务进入下一个冲刺周期，由某位工程师接手执行。

我略去了许多关键环节：每个工单的更新如何逐级上报，法务和设计评审可能耗时数周，以及最终将变更推送给客户的步骤。所有这些都让工作变得高度“可读”，但完全无法兼容那些必须“立刻完成”的任务。当突然出现紧急技术问题时——比如用户表的 int ID 列即将溢出，或某个大客户遇到致命 bug——该怎么办？5

为解决这类问题，科技公司通常会保留创建临时区域的权利，允许“不可读”的工作在此进行。这些团队有时被称为“虚拟团队”或“突击队”（甚至有个生动的名字叫“老虎队”）。成员是组织信任的精挑细选的工程师。通常没有正式经理，而是由一位资深工程师负责领导。他们被赋予一个宽泛的目标——比如“阻止数据库每隔几天就崩溃”——并被允许采取任何必要手段达成目标。

这是在完全不可读（会导致公司无法与大客户合作）和完全可读（连危及公司存亡的紧急问题也必须走完繁琐的规划流程）之间的一种聪明折中。

即便被限定在临时团队内，被默许的“不可读”仍与组织其余部分尴尬共存。团队外的工程师不喜欢看到别人能自由工作而不受流程束缚：要么出于嫉妒，要么是流程的忠实信徒，认为这种工作方式风险不可接受。管理者也不愿给予如此高的信任。正因如此，这类被默许的尝试几乎总是临时的。大型组织中发生的大多数“不可读”工作，仍然是未被默许的。

永久的、未被默许的不可读区域

如果你是 A 团队的工程师，需要 B 团队为你做点工作，正式做法是：在他们的“规划”待办列表中创建一个工单，然后等待它走完整整十二步流程，最终进入某个冲刺周期，希望有人能接下它。这可能耗时数周乃至数月。而当你只需要一行代码的修改时，眼睁睁看着请求在层层流程中缓慢推进——每一步都比直接修改代码耗时更长——令人极度沮丧。

官方的解决方案是：A 团队应在规划时就预见到 B 团队需要做这项工作，从而让 B 团队的工单与 A 团队的同步进入待办列表。理论上，它们应大致同时完成6。任何一线软件工程师都知道这个想法多么荒谬。你永远无法在开始编码前数月就预见到所有必须做的变更。

实际上解决问题的方式是“不可读的后门渠道”。A 团队的工程师直接联系 B 团队的某位工程师：“嘿，能帮我改这一行代码吗？”B 团队的工程师立刻动手，可能创建一个工单，也可能不。然后就完成了！这很高效，但它是“不可读”的，因为公司无法预期或规划它——它依赖于不同团队工程师之间的人际关系，而这种关系极难量化。如果你是一位受欢迎的工程师，使用后门渠道的能力远超刚入职或名声不佳的人。但“受欢迎程度”是公司无法在正式规划中使用的指标。

后门渠道在公司各个层级普遍存在。除了工程师之间的跨团队后门，团队内部、管理者之间、产品经理之间也都存在。通常，当一个问题在公开场合被正式提出时，它早已在私下与回答者反复讨论和打磨过。这些都不属于公司正式流程的一部分，也无法被记录，但它们却是支撑系统的关键。许多正式流程若没有后门渠道提供的共识机制或安全阀，根本无法运转。

有时后门渠道也会出问题。今年早些时候，我写过一篇《保护你的时间免受大型科技公司中的掠夺者侵害》（Protecting your time from predators in large tech companies），讨论了有些人如何利用后门渠道，为自己谋利而牺牲那些天真帮忙的工程师。当你感觉会议中所有人都已私下讨论过议题，唯独你被排除在外时，那种感觉也永远不好。正因如此，有些人认为后门渠道本身就是坏事，所有沟通都应通过正式、可读的渠道进行。

反社会者、懵懂者与失败者

还有另一篇文章，其影响力堪比《像国家一样观察》。它不是一本书，而是一篇博客：Venkatesh Rao 的《格里夫原则》（The Gervais Principle）。Rao 将组织分为三类：顶层是“反社会者”，他们愤世嫉俗地利用组织规则谋取私利；中层是“懵懂者”，他们相信组织的正式规则，却意识不到头顶上还有更深层的游戏；底层是“失败者”，他们知道游戏存在，但不愿参与。“失败者”这个名字并非价值判断——我认为它意在亲切地指代《疯狂店员》（Clerks）中的主角这类人，他们太过真实，不愿卷入 corporate 游戏。

我不完全认同《格里夫原则》的所有观点，但认为值得一读（如果你对此感兴趣，也应读读优秀的《道德迷宫》（Moral Mazes））。但这里的分类可以很自然地用“可读性”来解读。反社会者和失败者都与组织的“不可读”世界打交道。反社会者利用这个世界向上爬，而失败者则用它为自己打造一个舒适、低努力的安逸角落。

“懵懂者”只与可读流程互动。他们想晋升时，会去查阅正式的职级体系，制定计划，确保自己体现下一级的所有价值观。他们关心的是按章办事。当被迫面对“不可读”世界时，他们的反应是摇头叹息，并开始起草更新正式流程的方案，试图用一个苍白的近似版本来容纳那个更高效的不可读流程。

我认为称这些人“懵懂”太过刻薄。可读流程仍然非常重要——毕竟，它构成了组织运作的大部分内容。改进正式流程仍是高杠杆的工作，即使这些流程永远无法完全描述组织的全部运作方式。那些致力于可读性的人，对任何科技公司都有真实价值。

然而，用 Rao 的分类来看待人——那些利用不可读性的人、厌恶它的人、随意使用它的人——能带来启发。软件公司中许多常见的冲突，根源正是这些群体之间的摩擦。

最后的思考

我写过很多关于在科技公司中识别并利用“不可读性”的文章：

总体而言，关于不可读流程的建议，我称之为**“危险建议”**。它之所以危险，是因为一旦你将其“可读化”——比如公开宣布你通过后门渠道完成了某项工作而非正式流程——组织就会惩罚你，即使你的管理层其实希望你这么做。你不能说得太大声。它必须保持“不可读”。

我收到很多负面反馈，有人说你永远不该绕过正式流程。在他们看来，如果流程需要改变，你应该改变流程，而不是绕开它。换句话说，科技公司中的一切都应是“可读”的，“不可读”流程应被根除并转化为可读流程。

我认为这种观点天真了。所有组织——科技公司、社交俱乐部、政府——都有可读和不可读的两面。超过一定规模后，可读的一面很重要。它让组织能做原本不可能的事：长期规划、与超大型组织协调等。但不可读的一面同样重要。它允许高效工作，为不适应当前情境的流程提供释放阀，并满足人类对八卦和软性共识的天然需求。

编辑：这篇文章在 Hacker News 上引发了一些评论。一些评论者同意我的观点，但不认同“大型企业交易是可读性的主要驱动力”这一说法——他们认为是大规模沟通（链接）、或抢占市场份额的能力（链接）、或内部控制（链接）。

lobste.rs 上也有一些不错的评论。评论者大多赞同，但有人认为追求可读性的流程是自然演化而来（链接），而非刻意选择，或认为可读性对组织整体（而非一小部分领导者）并未带来真正好处（链接）。

Julik Tarkhanov 也写了一篇很好的回应文章，认为大多数所谓的可读性“改进”并未真正提高可读性，而只是制造了可读性的假象（为了让管理层感觉良好）。我部分同意，但大型组织有能力将假象变为现实（例如，基于假象进行晋升或解雇）。

我认为“真正”的可读性往往始于假象：先有可读性的幻觉，再通过蛮力使之成真。比如自上而下推行 OKR。起初，人们只是随便编造。但随着决策和晋升开始基于 OKR，人们越来越认真对待，几年后，所有人都真的在努力对齐它（无论好坏）。

如果你喜欢这篇文章，可以考虑订阅邮件，获取我新文章的更新，或在 Hacker News 上分享。以下是与本文相关的一篇预览文章。

寻找低垂的果实

假设你的工作是在一片巨大的果园里采摘水果。果园覆盖了数座山丘和山谷，大到你需要几周时间才能绕完边缘。你该先做什么？

像一个优秀的工程师，你可能会将其简化为一个优化问题：为了收获最多的水果，你应该最大化每棵树的采摘率。仅仅走到一棵树前，你估计踮起脚尖能摘到大约三成的水果，但大多数果实位置更高。你先造一架高梯，以便摘到最高枝上的果实，将采摘率提升到百分之九十。但有些果实不仅高，还向外伸展，树枝太脆弱，无法靠梯子。于是你设计一个采摘臂，可以横向延伸摘取更多果实。这将采摘率提升到百分之九十五，但采摘臂并不完美——有些果实位置尴尬，或紧贴树枝难以摘下。你不断改进采摘臂设计，逐步提升效率。经过大量努力，你终于达到了百分之九十八。

继续阅读…

https://www.seangoedecke.com/seeing-like-a-software-company/