一个有趣的论点指出，是什么破坏了大型企业的软件工程生产力：那就是把可读性置于一切之上。大公司牺牲效率追求“可读性”以赢得企业客户，但真正维系运转的是不可见的“灰色工作”，工程师需在两者间走钢丝。
越是大厂，流程越复杂，开会越多，Jira票越厚，但真正“干活”的人反而越来越难推进事情？而几个程序员搭台子的小团队，却能在短短几周内做出惊艳市场的产品？这种反差不是偶然，而是一种必然——它源于一种叫做“可读性”（legibility）的管理逻辑。
今天，我们就借由澳大利亚工程师Sean Goedecke在博客《Seeing Like a Software Company》中的洞见，来深入拆解：为什么大公司宁愿牺牲效率，也要坚持“看得见、管得住”？而那些看不见却无比重要的“灰色工作”，又是如何维系整个组织运转的？
什么是“可读性”？为什么公司拼命追求“看得见”？
“可读性”这个概念最早来自政治学家詹姆斯·C·斯科特（James C. Scott）的经典著作《国家的视角》（Seeing Like a State）。他在书中指出，现代国家（比如19世纪的德国）为了让森林“更容易管理”，就把原本杂乱却生态丰富的原始林砍掉，重新种上整齐划一、品种单一的树。这样，官员只需走进林子，就能轻松数清有多少棵树、能产多少木材——森林变得“可读”了。但讽刺的是，这种“高效”的人工林反而更脆弱：土壤退化、病虫害频发，长期产量甚至不如以前的“乱林子”。
科技公司也是一样。为了让高层“看得见”团队在做什么，公司建立了季度规划、OKR（目标与关键成果）、Jira工单系统、需求评审流程……所有工作必须可预测、可估算、有记录、不依赖特定个人。这就是“可读性工作”——它让管理者心里有底：知道每个团队在做什么、上个季度完成了什么、未来三个月能交付什么，甚至在紧急情况下能快速调动资源。
但问题在于：真正决定产品成败的很多工作，恰恰是“不可读”的。比如：老工程师凭着十年经验快速定位一个诡异的线上Bug；PM私下拉一个后端大佬改一行配置，省下两周走流程；两个团队私下拉群，绕过层层审批快速对齐接口……这些工作没有文档、无法汇报、甚至不能写进周报，却极其关键。
为什么大公司宁愿牺牲效率，也要追求“可读性”？
你可能会问：既然“不可读工作”效率更高，大公司为什么不全部改成小团队模式？答案很简单：因为大公司要做的是“大生意”——特别是面向大型企业客户（Enterprise）的SaaS业务。
一家世界500强企业要和你签一个千万美元级别的合同，但他们要求未来12个月必须交付哪些定制功能、每月提供几次系统健康报告、设立专属客户成功经理……这种合作周期长、风险高、承诺重。如果你是一家“不可读”的小公司，老板拍脑袋说“没问题”，但团队内部连下个月做什么都定不下来，客户怎么敢把核心业务押在你身上？
所以，大公司必须变得“可读”，哪怕这意味着：一个简单需求要走12个审批环节、一个Bug修复要排进下个Sprint、一个工程师想改点东西得先写5页RFC（技术提案）。不是他们蠢，而是“可读性”带来的商业价值（比如赢得大客户信任、获得长期合同、方便资本讲故事）远超效率损失。
大厂工程师的日常：在“流程地狱”和“灰色通道”之间走钢丝
如果你在大厂工作过，一定熟悉这种场景：你想让另一个团队改一行代码，走正式流程要提需求、排期、评审、等Sprint，可能两个月都动不了。但如果你和对方工程师私聊一句“兄弟，帮个忙”，对方可能五分钟就搞定，连工单都不用建。
这就是“不可读工作的现实力量”。这些私下沟通、人情交换、即兴协作，构成了大公司实际运转的“暗流”。没有这些，90%的日常协作根本无法推进。
但公司不能公开鼓励这种行为——否则流程就形同虚设了。于是，聪明的公司会设立“临时非法区”：比如成立“猛虎团队”（Tiger Team），由几个资深工程师组成，绕过所有流程，专攻紧急问题（如数据库即将崩溃、大客户严重故障）。这种团队没有经理、不写日报、目标模糊，但被默许“无法无天”。可一旦问题解决，团队立刻解散——因为长期“非法”会动摇整个“可读性”体系的根基。
三类人：操盘手、老实人、躺平族——你在哪一档？
这里可以结合另一篇经典文章《加维斯原理》（The Gervais Principle）来看。作者拉奥（Venkatesh Rao）把组织人分成三类：
- 操盘手（Sociopaths）：他们看透规则只是工具，擅长利用“不可读”空间为自己谋利——比如通过私人关系抢功劳、用模糊需求把脏活甩给新人。
- 老实人（Clueless）：他们是流程的信徒，相信只要按OKR一条条打钩、按职级要求一条条对标，就能升职加薪。他们对“灰色操作”感到困惑甚至愤怒，总想用“正规化”解决问题。
- 躺平族（Losers）：他们看透游戏本质，但选择不参与。他们用“不可读”空间保护自己的时间和精力，比如接点“副业项目”、只做自己感兴趣的技术探索。
有趣的是，操盘手和躺平族都活跃在“不可读”世界，只是目标不同；而老实人则困在“可读性”牢笼里，越努力越被流程吞噬。
为什么“提升流程”永远赶不上“绕过流程”？
很多管理者天真地认为：只要优化流程，就能兼顾效率与可控。但事实是，任何流程一旦建立，就会立刻被现实打脸。
比如项目估算——你以为拆得越细、评估越久，就越准？恰恰相反！工程师会根据“官方交期”反向调整实现方案：能砍就砍、能绕就绕、能糊就糊。估算不是预测，而是表演。
再比如跨团队协作——官方流程要求你提前三个月预判所有依赖。但真实开发中，80%的接口调整都是临时发现的。指望靠“提前规划”解决？纯属幻想。
所以，真正高效的组织，不是消灭“不可读”，而是学会管理它：允许适度的灰色操作，但设置安全边界；承认流程的局限，但不否定其价值。
给工程师的“危险建议”：什么时候该打破规则？
Sean Goedecke直言，关于“不可读工作”的建议都是“危险建议”——因为一旦你公开说“我靠私聊搞定需求”，就会被流程捍卫者群起而攻之。但现实中，顶尖工程师往往深谙此道：
- 在关键时刻，敢于绕过流程，直击问题核心；
- 警惕那些利用“灰色通道”压榨新人的“老油条”；
- 主动经营跨团队人脉，因为未来80%的协作靠人情而非工单；
- 在正式规划外，悄悄推进自己的“副业项目”（Side Bets），这些往往是晋升Staff+的关键。
记住：晋升到高级职级（如Staff Engineer），拼的从来不是你多遵守流程，而是你多擅长在“不可读”空间里创造价值。
总结：效率与控制的永恒博弈
大公司追求“可读性”不是愚蠢，而是商业现实的必然选择；但完全依赖“可读性”又会扼杀创新与响应力。真正的高手，既懂得在流程中生存，又能在灰色地带创造价值——这才是现代工程师的生存之道。