# 软件公司的可读性困境：从组织控制到测试局限性的深度观察

关联知识库：# 软件公司的可读性困境：从组织控制到测试局限性的深度观察

软件公司的可读性困境：从组织控制到测试局限性的深度观察

文章背景：Sean Goedecke的文章《Seeing like a software company》借鉴詹姆斯·C·斯科特的《国家的视角》，探讨软件公司在追求"可读性"（legibility）与"不可读性"（illegibility）之间的权衡。文章引发Hacker News社区122条评论的深度讨论，涉及组织管理、测试方法论、博弈论等多个维度。

文章概述

作者：Sean Goedecke
发布时间：2025年9月3日
原文链接：https://www.seangoedecke.com/seeing-like-a-software-company/
Hacker News讨论：https://news.ycombinator.com/item?id=45505539（388 points, 122 comments）
核心问题：软件公司如何在"可读性"（便于管理层控制）与"不可读性"（工程师自主创新）之间找到平衡
核心观点：过度追求可读性实际上会降低效率，但组织仍然愿意为此付出代价，因为可读性带来的其他好处（如大企业客户、长期规划）更有价值

理论基础：从德国森林到软件公司

詹姆斯·C·斯科特的三个核心观点

《Seeing Like A State》的核心思想可以概括为三点：

  1. 现代组织通过最大化"可读性"来施加控制：通过改变系统，使其所有部分都可以被测量、报告等
  2. 然而，这些组织依赖于大量"不可读"的工作：无法被跟踪或规划，但却是必不可少的
  3. 增加可读性实际上往往会降低效率——但其他好处足够大，组织通常愿意这样做

德国森林的启示

历史背景：

  • 19世纪德国国家为了大规模生产木材，要求森林具备"可读性"
  • 检查员可以访问森林，统计健康树木的数量
  • 这意味着必须能够穿过森林（控制灌木丛），树木应该理想地排列成单一类型的整齐行

效率的悖论：

  • 支持者将可读性过程描述为"效率措施"或"避免浪费"的方法
  • 但实际上，新的"高效"森林远不如旧的、不可读的森林高效
  • 它们每年生产的木材更少，需要更多努力来对抗疾病
  • 因为灌木丛对土壤健康有重要的承载作用，物种多样性被证明是一种资产
  • 新的同质化森林可能被单一寄生虫或疾病摧毁，而旧的、更多样化的森林则不会

关键洞察：

大型组织确实认为更多的可读性必然会提高效率。但即使当这一点被证明是错误的，这些组织仍然继续推动可读性，因为其他优势太强大了。

软件公司中的可读性

可读性 vs 不可读性的定义

可读性工作（Legible Work）：

  • 可预测的、有良好估算的
  • 有书面记录
  • 不依赖于任何偶然因素（如特定人员的可用性）
  • 例子：季度规划、OKRs、Jira

不可读性工作（Illegible Work）：

  • 请求和给予帮助
  • 使用无法或不能写下的隐性知识
  • 适应未安排的变更
  • 利用人际关系

⚡ 效率的真相

工程师的共识：

  • 单个工程师独自工作比作为团队的一部分更高效
  • 这就是为什么有这么多关于工程师请假才能完成工作的轶事
  • 或者关于在夜晚和周末完成高效工作的故事

工程师驱动 vs 上级指令：

  • 工程师驱动的工作比上级指令的工作进展快得多
  • 工程师驱动的工作不需要翻译成有意义的东西
  • 不需要在所有方向上积极沟通
  • 可以以最直接、最有效的方式完成

小公司的优势：

这就是为什么小型软件公司通常比大型软件公司更擅长交付软件：如果小公司的效率是20倍，那么大公司投入10倍的工程师数量并不重要。

❓ 为什么大公司不放弃流程？

答案：使工程师减速的流程正是使他们的工作对公司其他部分可读的流程。而这种可读性（以美元计算）比能够更高效地生产软件更有价值。

可读性对大公司的价值

可读性的实际含义

对科技公司来说，可读性意味着：

  1. 部门负责人知道，到工程师级别，部门目前正在处理的所有项目
  2. 该负责人也知道（或可以请求）部门在上个季度交付的所有项目的综合列表
  3. 该负责人有能力至少提前一个季度规划工作（理想情况下更长）
  4. 该负责人可以在紧急情况下，将部门的全部资源投入到立即的工作中

注意："交付高质量软件"、"让客户满意"甚至"赚钱"都不在这个列表中。这些都是科技公司想要做的事情，但它们不是可读性。

大企业客户：可读性的主要驱动力

为什么这些能力对大公司如此有价值？

主要答案是大企业交易。与大企业客户达成交易非常有利可图。任何足够大的SaaS都会从小客户转向企业客户，如果它可以的话。

企业交易的特点：

  • (a) 可能需要很多很多个月才能建立
  • (b) 需要做出长期功能承诺

不可读公司的困境：

  • 不可读的公司无法配置为坚持一个无聊的企业交易数月
  • 不断回答问题并交付功能
  • 大企业客户根本不会信任小型软件公司在未来一两年内交付他们需要的东西

客户要求：

这类客户通常非常重视可读性，因此也要求供应商同样具备可读性。事实上，高度可读的组织与不太可读的组织根本无法沟通（反之亦然）。它们没有正确的凭证，不说同一种语言，等等。

这给成长中的科技公司带来了真正的压力，要求它们变得更加可读，即使这会损害它们交付软件的能力。

可读性假设的谬误

大公司的简化假设

在追求可读性的过程中，大型科技公司对技术工作的性质做出了简化假设：

  1. 任何具有相同职位头衔的工程师表现大致相同
  2. 工程师可以重新洗牌和重组，而不会大幅损失生产力
  3. 团队将随着时间的推移保持相同的生产力水平，如果它有相同数量的工程师
  4. 项目可以提前估算，尽管有一些误差范围。花在估算项目上的时间越多，估算就会越准确

❌ 现实情况

所有这些假设都是错误的：

  • 同一职位头衔内，工程能力存在显著差异
  • 工程师有不同的技能和兴趣，在适合他们的项目上会更有生产力
  • 因此，团队的生产力与团队中的工程师数量关系微弱

项目估算的真相：

项目估算主要是幻想。更准确地说，它们是表演性的：初始估算决定了为在该估算内交付而完成的工程工作类型，而不是相反。

因此，将项目分解为部分并估算每个部分通常会产生不太准确的估算，因为这使得工程师更难与整体交付日期保持一致。

但假设仍然有用：

  • 这些假设对它们的目的来说足够真实：为负责公司的执行官提供可读性
  • 无论项目估算是否准确，它都可以用于规划和与其他大型组织沟通
  • （这些组织本身通常意识到这些估算不应该被完全认真对待）

临时授权的不可读性区域

⚡ 紧急问题的困境

可读性流程的延迟：

  • 使工作可读的流程也施加了严重的延迟
  • 考虑一个假设的大公司在开始编写代码之前可能采取的步骤：
    1. 有人有一个产品想法
    2. 他们把这个想法带到产品组织，进入"规划"阶段。召开会议讨论这个想法
    3. 产品组织正式决定他们想要这样做后，想法传递给工程组织：交给一些工程架构师委员会，他们负责初始技术审查
    4. 工程组织中的VP和高级经理然后协商哪个团队将拥有这项工作
    5. 最后工作落在团队上。它进入团队规划积压，团队技术负责人将其分解为更小的工作块
    6. 这些更小的工作块进入团队票务积压，并在团队的每周规划会议中进行估算
    7. 最后，其中一些工作块进入下一个sprint，被能够实际完成它的工程师接手

问题：

所有这些使工作非常可读，但这些都不兼容必须立即完成的工作。当你遇到突然的、紧急的技术问题时——也许你的用户表的int ID列即将溢出，或者某个非常大的客户遇到了一个阻止性的bug——你该怎么办？

Tiger Teams：临时解决方案

解决方案：

  • 科技公司经常保留创建临时区域的权利，在这些区域中允许不可读的工作
  • 有时这些被称为"虚拟团队"、"突击队"（strike teams）或"老虎队"（tiger teams）
  • 它们由组织信任的精心挑选的工程师组成
  • 通常根本没有分配经理，而是由一些非常高级的工程师负责运行项目
  • 这些团队被给予一个宽松的任务——比如"阻止数据库每隔几天崩溃一次"——并被允许基本上做任何需要做的事情来完成它

聪明的妥协：

  • 这是完全不可读性（如上所述，会使公司无法与其最富有的客户达成交易）和完全可读性（会迫使甚至紧急的公司杀手级问题通过整个繁琐的范围、规划和估算过程）之间的聪明妥协

组织内的紧张：

  • 即使被隔离到临时团队，授权的不可读性仍然与组织的其他部分尴尬地共存
  • 团队外的工程师不喜欢看到其他工程师被给予在没有流程负担的情况下工作的自由
  • 要么因为他们嫉妒，要么因为他们是流程的信徒，认为这样的工作是不可接受的危险
  • 管理者也不喜欢扩展那种信任水平
  • 这就是为什么像这样的授权努力几乎总是临时的
  • 大多数在大组织中发生的不可读工作仍然是未授权的

永久未授权的不可读性区域：Backchannels

正式流程的问题

跨团队工作的正式方式：

  • 如果你是团队A的工程师，需要团队B为你做某种工作
  • 正式方式是在他们的"规划"积压中创建一个问题
  • 等待它通过整个十二步过程，最终进入他们的sprint之一
  • 希望有人会接手并完成它
  • 这可能需要数周到数月

荒谬的官方解决方案：

  • 官方解决这个问题的方法是团队A应该在规划过程中预期团队B需要做这项工作
  • 这样团队B的部分可以在进入团队A的积压的同时进入他们的积压
  • 理论上，它们应该大约同时完成
  • 任何实践中的软件工程师都知道这个想法有多荒谬。你永远无法在开始编写代码之前几个月预期需要进行的每一项更改

️ 实际的解决方案：Backchannels

不可读的后门渠道：

  • 实际的解决方法是不可读的后门渠道（illegible backchannels）
  • 团队A的工程师联系团队B的工程师，问"嘿，你能为我做这个一行更改吗"
  • 团队B的工程师然后立即完成，也许创建一张票，也许不创建
  • 然后完成了！

为什么有效但不可读：

  • 这很有效，但它是不可读的，因为公司无法预期或规划它
  • 它依赖于不同团队工程师之间的人际关系，这很难量化
  • 如果你是一个受欢迎的工程师，你利用这些后门渠道的能力比如果你是全新的或声誉不好的人要大得多
  • 但你有多受欢迎并不是公司在规划项目时可以正式使用的东西

Backchannels的普遍存在

无处不在：

  • 后门渠道在公司各个层面都是持续存在的
  • 除了工程师-工程师跨团队后门渠道，还有团队内部的后门渠道
  • 在经理之间、产品经理之间等等
  • 通常当一个问题在公共空间中正式提出时，它已经与回答问题的人私下排练和研讨过了

关键作用：

  • 这些都不能作为公司正式流程的一部分被记录，但它们是承载性的
  • 许多正式流程根本无法在没有后门渠道提供的共识机制或安全阀的情况下运行

⚠️ Backchannels的阴暗面

可能出问题：

  • 有时后门渠道可能会出问题
  • 有些人使用后门渠道以牺牲他们请求工作的天真工程师为代价来为自己谋利
  • 当你感觉到会议中的每个人都已经私下讨论过这个话题，除了你之外，这从来不会感觉好

反对声音：

  • 出于这些原因，有些人认为后门渠道本身就是坏事
  • 所有沟通都应该通过正式的、可读的渠道进行

Gervais原则：Sociopaths, Clueless, and Losers

组织中的三类人

Venkatesh Rao的《The Gervais Principle》将组织分为三组：

  1. Sociopaths（反社会者）：在顶层，他们愤世嫉俗地利用组织规则为自己谋利
  2. Clueless（无知者）：在中层管理中，他们相信组织的正式规则，没有意识到在他们之上正在玩一个更深的游戏
  3. Losers（失败者）：在他们之下，他们意识到正在玩游戏，但不想玩。这个名字不是价值判断——我认为它是指像《Clerks》中的主角那样的人，他们太真实了，无法参与企业游戏

从可读性角度解读

与可读性的关系：

  • 反社会者和失败者都参与组织的不可读世界
  • 反社会者利用这个世界爬梯子
  • 失败者利用它为自己创造一个舒适的低努力利基

Clueless的特征：

  • "无知者"只参与可读流程
  • 他们是那些想要晋升时，去查找正式工作阶梯并制定计划的人
  • 说明他们如何在下一级体现每个价值观
  • 他们关心按书做一切
  • 当他们被迫遇到不可读的世界时，他们的反应是摇头，开始起草可读流程的更新
  • 这些更新可以容纳更高效的不可读流程的苍白近似

重要提醒：

我认为称这些人为"无知"太愤世嫉俗了。可读流程仍然非常重要——毕竟，它是组织所做的大部分工作。改进正式流程仍然是高杠杆工作，即使正式流程永远无法描述组织运作的全部方式。投资于可读性的人对任何科技公司都有真正的价值。

冲突的根源：

  • 然而，从Rao的类别思考人——利用不可读性的人、发现它令人反感的人、随意使用它的人——可能是有启发性的
  • 软件公司中许多频繁的冲突领域源于这些人群之间的摩擦

Hacker News讨论的核心洞察

CEO控制权的现实

核心观点（zug_zug）：

CEO对公司的控制权只有大约7%。其余的控制权都掌握在他们雇佣的所有人手中——他们只是大脑，而不是全部。

现实困境：

  • CEO喜欢认为自己才是最重要的
  • 迅速忽略所有他们没有时间或专业知识去理解的事情
  • 例如：把工程师看作是可以互换的，而一个可能是进入麻省理工学院的天才，能够在他所从事的任何领域取得进步——另一个可能只是一个参加过训练营的普通人

历史反思：

  • 人们谈论谷歌的成功时，往往更容易将功劳归于两位创始人或一位首席执行官
  • 而不是去追溯数十位才华横溢的员工，正是他们打造了最优秀的搜索、邮件、地图、广告等平台

质疑可读性的代价：

我唯一想质疑的是它默认的领导层"清晰易懂"就一定值得付出所有代价。试想一下，如果你的大脑必须时刻意识到你的每一次呼吸、每一次手指的移动等等……你什么都做不了。同样的道理，如果CEO必须了解并批准你使用并行或其他方式加速单元测试，那又会怎样呢？

测试的局限性

路灯效应（Streetlight Effect）

核心概念（praptak）：

测试（尤其是单元测试）普遍容易受到"路灯效应"的影响。越是琐碎或不重要的事物，就越容易测试。这导致人们倾向于测试容易的部分，而不是真正重要的部分。

组织层面的放大：

  • 如果组织为了追求"可读性"而采用容易理解的指标（例如代码覆盖率）
  • 而不是采用难以理解的指标（例如由经验丰富的工程师审查测试）
  • 情况会更加糟糕

路灯效应的定义（arcanemachiner）：

路灯效应，又称醉汉搜索原理，是一种观察偏差，指的是人们只在最容易看到的地方寻找东西。

⚖️ 定性 vs 定量测试

TDD的局限性（piker）：

自TDD运动以来，一直存在一种倾向，即如果代码无法测试，就不能称之为"编写完成"。我认为"可读性"一词非常贴切地描述了这种想法。

真实案例：

  • 为Tritium编写了数百个单元测试
  • 但直到开始使用它写博客后，才发现一些定性错误
  • 这些错误没有被单元测试发现（而且很难发现）
  • 它们难以理解

核心启示：

事实上，你需要定性和定量两种衡量方法。

独立游戏开发的启示：

我认为这就是为什么独立游戏开发能够抵御市场经济冲击，而其他软件行业却往往陷入赢家通吃的局面。游戏开发者之所以能够提升产品质量，是因为他们内部的测试和测试做得非常出色。此外，正如文章中提到的，他们的"企业级"市场规模较小，因此对产品清晰度的要求也更低。

测试的认知陷阱

常见误解（godelski）：

当人们大声说出这些话时（甚至在HN上），很多人会把它们解读为"考试毫无价值"。很难理解为"考试是不完整的"。我不明白为什么这个概念这么难理解。除非你是全知全能的，否则考试怎么可能完整呢？

衡量方法的本质：

  • 你无法直接衡量任何事物
  • 你始终只能通过间接方法进行衡量
  • 如果你不了解这些间接方法的局限性，那么你只会让自己对可预见的问题视而不见

测试的本质：

所以，测试只是提示，而非证明。它们只能证明某些特定领域的正确性，而无法全面验证。更糟糕的是，你无法测试未知的未知因素。正如你所说，这就是为什么"狗粮测试"（dog fooding）在开发过程中如此重要。你不仅仅是开发者，你还需要扮演用户和"敌人"的角色。你应该尝试从尽可能多的角度审视你的程序。这样做虽然无法实现完全覆盖，但比单纯的测试要有效得多，而且能帮助你找到需要编写的测试。

TDD的反思（godelski）：

如果你只是在做测试驱动开发（TDD），那你只是在应用古德哈特定律而已。

手动测试的重要性（cjfd）：

我认为确实如此。我非常推崇测试驱动开发（TDD），但手动测试仍然至关重要。很多时候，事情的发展并不像人们预想的那样顺利。这一点在用户友好性方面尤为突出，但其他方面也同样如此。

️ 冲突地图：管理多利益相关者的工具

核心概念（rukuu001）：

太好了。我以前共事过的一个团队将其定义为需求和恐惧，并且在处理涉及多个利益相关者的情况时会绘制"冲突地图"。

结构：

  • 冲突地图列出了每个群体的需求和担忧
  • 指出了它们之间的不相容之处
  • 这些信息被用来积极主动地解决这些冲突领域，或者至少围绕这些领域制定计划

实际应用：

  • 冲突地图是一堆围绕中心问题或事件的摇摆圆圈
  • 摇摆圆圈的交集表示需求/恐惧的不兼容性，暗示潜在的冲突

延伸资源：

  • 苏黎世联邦理工学院冲突分析工具文档包含"需求-恐惧映射"条目

博弈论视角：理性行为者的边界

核心批评（nrclark）：

博弈论自有其用武之地。但我所见的大多数博弈论解释都忽略了人性的因素。人们非理性行事的次数远远多于理性行事的次数。

博弈论中的定义（godelski）：

  • 理性行为者：并非指行为者聪明或理智，而是指他们拥有某种可以追踪或量化的逻辑
  • 非理性行为者：逻辑混乱的行为者，不是不合逻辑，而是更接近于难以理解的行为

关键区别：

  • 非理性行为者是指那些明知故犯、损害自身目标的行为者
  • 这是一个非常狭义的定义
  • 非理性行为者在逻辑上是不连贯的

实际应用：

  • 行为取决于行为者认为将会发生什么
  • 像和光邪教这样的自杀邪教，从这个意义上讲是合理的
  • 即使从外人看来，有人认为自杀会把自己传送到一艘伪装成彗星的宇宙飞船里，这似乎难以理解
  • 这里的"合理性"在于存在某种逻辑，而不是存在一种好的逻辑

现实观察（nrclark）：

  • 即使按照博弈论的定义，人也是非理性行为者
  • 我们经常做出一些令人费解的选择，在做决定的那一刻并没有什么真正的理由
  • 然后我们的大脑会在事后进行自我补充和合理化

深层原因：

  • 我们的大脑是由血肉之躯构成的，它通过化学反应进行自我交流
  • 大脑不是数字计算机，而是一种非常模拟的器官
  • 大脑会犯错，而且确实会犯错，比如"计算错误"或"传输出错"之类的错误

对经济理论的启示：

  • 人类并非理性行为者，也从来都不是
  • 正因如此，经济理论才常常在预测行为方面出现惊人的偏差

组织政治与地缘政治的相似性

核心观察（boberoni）：

我在企业工作的时间越长，对办公室政治了解得越多，我就越能看到与地缘政治和外交的相似之处。如果我眯起眼睛，我甚至可以看到与社会和浪漫关系的相似之处。也许这是我这个数学家喜欢构建抽象模型的原因。

政治的本质（harrall）：

因为归根结底，它们都是一样的。这是人类像人类一样行事。每个人（和组织）都有欲望和恐惧。当两方聚在一起时，平衡每个人的需求是有趣的。这就像一个复杂的工程问题，只是用人的需求代替，政治是架构。我认为人们很棒，真正享受这类问题。

地缘政治的启示（rossant）：

我最近才意识到这一点。我把地缘政治看作是由数百名外交官组成的复杂系统的复杂、新兴行为。我意识到这仅仅是几个国家领导人之间的人际关系，他们恰好对各自的国家、军队等拥有权力。这与幼儿园操场的戏剧和争吵没有太大不同，当然是在某种近似程度上。

不可读网络的重要性（joarxpablo）：

我认为这是错误的教训。现实主义国际关系方法，即国家从顶层控制，如你所描述的，更具可读性。相反，我同意它确实基于人际关系，但这些关系是在CEO、外交官、移民社区、军官之间，当然还有国家领导人之间。这个不可读的网络实际上是指导政策的。

核心启示与实践建议

对软件公司的启示

  1. 平衡可读性与自主性

    • 过度追求可读性可能限制工程师的创新能力
    • 需要在管理控制和工程师自主性之间找到平衡
    • 承认"不可读性"的价值：某些工作本身就是复杂且难以量化的

  2. 重新审视测试策略

    • 测试只是提示，而非证明
    • 需要定性和定量两种衡量方法
    • "狗粮测试"和手动测试仍然至关重要
    • 避免"路灯效应"：不要只测试容易测试的部分

  3. 理解组织控制的现实

    • CEO的控制权是有限的（约7%）
    • 大部分控制权在雇佣的员工手中
    • 不要高估管理层的理解能力
    • 不要低估工程师的专业判断

  4. 利用冲突地图工具

    • 在处理多利益相关者问题时，绘制冲突地图
    • 识别需求和恐惧
    • 提前规划解决方案

  5. 承认Backchannels的存在和价值

    • 后门渠道是组织运作的重要组成部分
    • 虽然不可读，但它们是承载性的
    • 许多正式流程无法在没有后门渠道的情况下运行

警示与风险

过度追求可读性的风险：

  • ⚠️ 可能导致效率下降
  • ⚠️ 限制创新和自主性
  • ⚠️ 忽视隐蔽但重要的非正式沟通渠道
  • ⚠️ 过度依赖容易理解的指标（如代码覆盖率）

测试的认知陷阱：

  • ⚠️ 路灯效应：只测试容易测试的部分
  • ⚠️ 过度依赖定量测试，忽视定性问题
  • ⚠️ 将测试视为证明而非提示
  • ⚠️ 忽视"未知的未知因素"

组织管理的误区：

  • ⚠️ 高估CEO的控制权
  • ⚠️ 低估工程师的专业判断
  • ⚠️ 将工程师视为可互换的资源
  • ⚠️ 忽视不可读工作的价值

实践建议

对工程师：

  1. 理解测试的局限性，不要过度依赖单元测试
  2. 重视"狗粮测试"和手动测试
  3. 从多个角度审视你的程序
  4. 理解组织管理的现实，但不要被过度控制
  5. 学会利用backchannels，但要谨慎使用

对管理者：

  1. 承认控制权的局限性
  2. 不要过度追求"可读性"
  3. 重视隐蔽的非正式沟通渠道
  4. 使用冲突地图管理多利益相关者问题
  5. 避免将工程师视为可互换的资源
  6. 为紧急问题保留临时不可读性区域

对组织：

  1. 在可读性和自主性之间找到平衡
  2. 使用定性和定量两种衡量方法
  3. 避免"路灯效应"：不要只关注容易理解的指标
  4. 重视实际使用体验，而不仅仅是代码覆盖率
  5. 承认backchannels的存在，但不要试图完全消除它们
  6. 为不同规模的组织采用不同的可读性策略

延伸思考

独立游戏开发的启示

观察（piker）：

我认为这就是为什么独立游戏开发能够抵御市场经济冲击，而其他软件行业却往往陷入赢家通吃的局面。

原因分析：

  • 游戏开发者之所以能够提升产品质量，是因为他们内部的测试和测试做得非常出色
  • 此外，正如文章中提到的，他们的"企业级"市场规模较小，因此对产品清晰度的要求也更低
  • 游戏开发有更紧密的反馈循环：如果内存泄漏，每秒发生一百次；如果代码慢，会出现视觉卡顿

启示：

  • 小规模团队可能更容易保持"不可读性"的优势
  • 对清晰度的要求可能因市场规模而异
  • 独立开发可能更注重定性测试和实际使用体验
  • "有趣吗？"这个问题不太能够被正式测试和表达，它是"不可读的"

️ 政府与企业的相似性

观察（bruce511）：

政府通常是"大企业"。在大多数情况下，是一个国家中最大的企业。

透明度的代价：

  • 在某些国家，它们还承担着对外部人员可读的负担
  • 在股东（选民）和记者等之间，有很多流程必须透明
  • 这种透明度是可读性驱动的极端
  • 如果企业杀死一个项目（想想Windows Phone），它就完成了，我们继续前进
  • 如果政府杀死一个项目，会有很多外部关注什么出了问题，谁被解雇（或进监狱），以及"我们的钱是如何被浪费的"

规模的影响：

  • 随着事物变得更大，它们对更多人重要
  • 涉及的人越多，每一个想法和行动都必须被详细记录
  • 这就是为什么（民主）政府在实际完成任何事情方面如此糟糕的部分原因

延伸阅读

文章标签：#组织管理 #软件工程 #测试方法论 #博弈论 #可读性 #冲突管理 #Gervais原则 #Backchannels

文章类型：深度分析 / 行业观察
学习价值：⭐⭐⭐⭐⭐
适用场景：软件公司组织管理、测试策略制定、团队协作优化、大企业转型

特别提示：这篇文章的核心价值在于揭示了软件公司在追求"可读性"时的认知陷阱。过度追求可读性实际上会降低效率，但组织仍然愿意为此付出代价，因为可读性带来的其他好处（如大企业客户、长期规划）更有价值。理解CEO控制权的现实（约7%）、测试的局限性（路灯效应）、以及不可读工作（backchannels）的重要性，有助于我们更好地理解组织管理的复杂性。记住：所有组织——科技公司、社交俱乐部、政府——都有可读和不可读的一面，两者都同样重要。

posted @ 2025-12-05 23:53  吾以观复  阅读(3)  评论(0)    收藏  举报