论大企业 | 原创，AI翻译
目录
- 论大公司
- 人才密度胜过团队规模
- 流程取代了对员工的信任
- 风险规避抑制创新增长
- 初创企业比大企业部署更快
- 官僚主义掩盖个人责任
- 大公司的工程实践
- 规则确保一致性但限制创造力
- 自动化检查难以捕捉设计质量的细微差别
- 测试工具缺乏战略评估深度
- 单体系统难以快速扩展
- 冗余流程确保知识留存
- 论协作
- 团队结构反映模块化代码组织
- 任务所有权减少沟通开销
- 透明度取代实时对齐需求
- AI工具增强个人贡献
- 预期不匹配导致项目失败
论大公司
大公司就像大型程序。对于一家拥有10万员工和5万承包商的大公司来说，它们就像一个包含15万个方法的大型程序。
Dario Amodei 曾表示，人才密度远比人才数量重要。200名顶尖人才可以胜过1000名人才中混杂800名普通人的团队。
Dario Amodei 还提到，大公司之所以有如此多的流程和程序，是因为它们不信任员工或承包商，因此需要大量检查和管控。
大公司的一大特点是害怕犯错。一方面，它们能成长为市值3000亿或1万亿美元的巨头，必然曾犯过无数错误并从中成长。然而，当它们成功后，却变得厌恶风险，不愿再犯错。
这就像一个讨厌bug的大型程序，尤其像大银行那样极力消除任何漏洞，特别是安全漏洞。
初创企业行动迅速，但资源有限，品牌也未建立，缺乏大公司的信任基础。
在中国，优秀的年轻人毕业后仍渴望进入大公司并为此奋斗。而在硅谷，初创企业遍地开花，有些仅凭创意就能起步并表现优异。
有些公司经营20年仍举步维艰，甚至可能已退市；而有些成立仅数月估值就达50亿或100亿美元。据报道，Mira Murati的Thinking Machines Lab在种子轮估值已达120亿美元，Ilya Sutskever的Safe Superintelligence融资20亿美元，估值320亿美元。
因此，用成立时间衡量初创企业并不明智，更好的指标是团队构成、创始人背景及其所在领域。
在我的个人创业项目中，部署后端服务器只需1分钟，修复小bug并上线仅需5分钟，直接高效。而大公司需要1周时间：准备部署请求、获得经理批准、与IT团队协作部署，最后进行健康检查。
尽管实际耗时可能仅8小时，但从准备部署到完成健康检查的流程仍占满一周。修复小bug并部署则需要两周：领任务单、分析测试、代码评审、合并代码、提交测试团队验证，最后部署。
大公司喜欢将所有政策强加于所有团队或项目。因为对于20万人的企业，仅适用于1万人的政策或流程意义有限。某些内部流程需要投入人力或资金开发工具支持，若仅服务少数员工，投资回报率就会很低。
大公司的另一弊端是重大失误往往无人担责。
我的初创经历中，曾获得50万美元融资并招聘9人，但两个月后不得不裁员并亏损。后来我通过50个小软件项目与兼职工程师合作，才赚回资金偿还投资人。
这是一段痛苦而深刻的记忆，让我始终铭记教训。
而某大公司的典型案例中，相关人员并未受到实质惩罚。一些高管和大量新员工被裁，但不确定是否与之前的急速扩招有关。
大公司繁琐的流程是原因之一。入职6至12个月的工程师贡献有限：通常花2个月入门、3个月熟悉项目、3个月应付冗长流程或测试，最后2个月才能真正为用户创造价值。假设每天工作8小时，两个月的高效工作收效甚微。部门预算耗尽，用户增长不及预期，最终引发更多裁员。
这次经历似乎未带来任何经验教训。最初一批管理者决定快速大规模招聘，当时看来并无必要。但追究全体管理者责任不现实，短期任职者被裁也不公平，毕竟其他管理者和技术骨干已在该团队工作6至8年。
董事总经理未从中学到多少，因为这只是其管辖的三个部门之一，且薪酬未受影响。团队中非直接责任人也未能汲取教训，正如Steve Jobs谈到的咨询现象——无人真正领悟组建卓越团队、为用户创造价值的核心要义。
对初创企业而言，情况可能更好，因为后果更真实。部分失败创始人处境艰难，尤其是诚实守信者。
对正直的人来说，损失数百万乃至数亿美元投资，最终只换来粗糙产品或庞大却低收益的用户群，可能令人心碎。
Paul Graham 曾撰文《招聘已过时》。
但大公司有何优势？一是长期主义。它们倾向于长远规划。优秀大公司的项目设计精良，采用微服务架构避免十年后沦为臃肿单体程序，还设有治理团队制定基础框架并统一开发规范。
流程本身并非坏事，但常使事务复杂低效。我们不觉Java统一代码格式烦琐，正因有Spotless或Checkstyle插件辅助。这些插件设计精良且易用。
另一特点是倾向开发内部工具，但用户仅数百或万人，规模有限。
我认为应直接使用外部工具。若某个工具对一家银行极佳，很可能也适用于200家银行，甚至能打造独角兽企业。
Pony.ai创始人楼天城指出，企业独立运营效率更高，确实如此。
大公司倾向凭资历奖励员工，而市场则根据结果或执行力奖励初创团队，二者截然不同。
在大公司工作如同学校晋级：从小学到中学再到大学。初创企业则起伏更大，在不同创意或市场间灵活切换。
大公司规避风险的益处在于产品相对稳定，无明显漏洞或宕机。这很棒。
但对于AI等创新产品，用户往往能接受早期不稳定，如DeepSeek在2025年2月至3月爆红期间频繁宕机，但后期改善后用户并无抱怨。
因此需具体情况具体分析。有时创新产品需快速上市，即使存在小问题，用户也能理解。
若思考流程优化，我们可以更精细化：区分部署类型——哪些变更可快速上线，哪些不可；测试分类——哪些需回归测试变更代码，哪些无需；SonarQube检查同理。
大公司中许多检查、测试或审批实无必要。不妨让工程师放手工作，系统留存完整记录，只需抽查即可。
还应取消所有管理层审批。管理者掌握哪些工程师不懂的知识？这些知识能否编码实现自动审批？
由于大公司节奏缓慢，员工难有改变动力。一个运行十年的单体项目迁移微服务可能耗时两年。
软件中代码与逻辑紧密关联，设计良好的系统尤甚。因此开发、测试或协作量可能非常庞大。
这就是为何突然扩编团队常不奏效。若为松耦合的微服务架构，团队产出可能与人手成正比；若是紧耦合单体项目，团队规模翻倍可能仅提升30%产出。
由于节奏慢，有时难判断是员工能力不足，还是系统过于复杂拖累新人。我曾见过入职四月仅修改几行代码提交PR的案例，代码质量也差，因其理解有限。该员工英语薄弱，只能截图并用简单英语提问。
关于稳定性，大公司习惯让多人重复工作。例如任务A和B，不让两人各自负责，而是共同参与部分A和B，确保相互知悉。这增强团队稳定性，避免出现某人垄断大片代码数年无人协作，离职后无人接手的局面。
大公司另一优势是保持现金流和利润纪律。随规模扩大，它们常面临重大财务危机，因此将此视为重中之重。即便年利润达100亿或300亿美元，仍持续优化人力并进行裁员。
一位同事曾告诉我，大公司垄断某些需大量人力或时间开发的产品，这很合理。它们不依赖速度，而是规模、资源和品牌。
如何在大公司生存？一是多做少说——我的外包交付经理曾如此建议。
二是随大流。成为团队中的普通工程师很安全，就像街上的普通人——既不出众也不被忽视，恰到好处。
必须指出大公司差异性很大。有些员工超20万，有些约2万；有表现优异的，也有业绩低迷的。市值或表象未必说明问题，它们可能如Nvidia近年般飙升，也可能如瑞信突然崩塌。
大公司的工程实践
大公司擅长严格的政策管控，谨慎检查及彻底的软件发布评估。
但许多工程问题无法简单归结为规则。方法或Java类的简洁设计与优化难以通过规则检验。
SonarQube扫描和高测试覆盖率是好事，但多数软件设计或工程质量不能如此简单衡量。
API质量与功能易用性不易评估。方法参数、函数设计、分支策略、开发策略及命名规范都难量化。
阿里有Java开发手册，Google和Plantier有Java格式规范，这很好。但Java项目中并非所有内容都能自动化检查。
测试工具众多，但并非所有测试策略、设计理念或技术都有固定规则。
产品层面，A/B测试和数据驱动开发普遍，但并非所有产品技术、技巧或洞察力都可量化。
为何讨论这些？因为这说明我们的价值正在于此——弥补大公司不擅长的领域。
为何专论大公司而非泛指企业工程？实际上，大小公司皆由人组成，区别主要在员工数量。
大公司的工程多样性弱于初创企业。
论协作
协作充满挑战，需要为共同目标合力。从编码角度思考：
本质上，每个人都像由生活经历、工作背景、世界观、亲密关系、成长环境和数字互动构成的复杂程序。
难题在于如何让团队达成目标。群体该如何高效协作？微服务如何和谐共处？
个人项目中，一人包揽一切，无需协作。如今人们常用多种AI工具达成目标。
几人小团队可分工：一人设计，一人开发；或前后端分离。
大公司常忧虑员工离职导致项目知识断层。接任者或需数月甚至一年适应，拖慢或搁置项目。
但在AI时代，我们应调整思路。”人月神话”依然成立。
我强烈主张自然协作。随着项目推进，团队会自发形成协作习惯，这类似于代码自然模块化——开发出50个Java类后按包组织，100个Python文件后用模块管理。
任务分配应基于个人优势。AI时代，一人可精通多领域，因此需重新思考大任务的拆分方式。
我认为每位成员一次应负责较大任务，尽量减少频繁沟通或对齐。大任务需相对独立，个人可向资深成员求助。这样更多人能参与，但责任人仍然明确。
若两人逐行协作或共同处理每个细节，势必繁琐。计算目标有多种实现方式，只要结果优质达标，就应接受不同方法或工具——无论特定IDE、SQL客户端、Python脚本还是手动操作。
另一改进是最大限度透明化工作记录。近期工作中，我与团队共享脚本、日志和笔记，包括向Copilot的提问、遇到的问题及相关日志。这种透明化便于沟通，相当于录制操作屏幕的过程。
协作为何失败？团队预期不匹配是主因，可能致项目延误或质量不达标。