10 人团队为什么比 3 个人慢？
这是「后编码时代」系列的第 1 篇。 这个系列讲一件事：团队协作的真正瓶颈不是写代码，是做决策和传决策。
一个所有技术人都经历过的时刻
你从 3 个人的创业团队，走到 10 个人的小公司。产品做出来了，用户在涨，融资也到位了。按理说应该更快了。
但你发现 sprint 的速度反而慢了。
一个功能，以前两个人在白板前聊 10 分钟，下午就开始写代码。现在要拉一个会，5 个人参加，讨论 40 分钟没有结论，约明天继续。明天有人请假，后天补了个会，终于定下来方向，但负责写代码的那个人还在问："所以到底用 A 方案还是 B 方案？"
协作成本不是线性的
3 个人协作，沟通链路是 3 条。10 个人，45 条。20 个人，190 条。
人越多，信息同步的成本是平方级增长。但这个数学事实只解释了一半。真正拖慢团队的，不是"信息同步"本身，而是同步之后那件事——做决策。
如果你观察一个功能从"需求提出"到"代码上线"的全过程，真正写代码的时间大概只占 30%。剩下 70% 花在沟通、讨论、确认、对齐上。而其中大部分，花在了"做决策"和"传递决策上下文"上。
你的决策，都去哪了？
这里有一个小测试：上个月你们团队做的最重要的三个技术决策是什么？每个决策考虑了哪些方案？为什么选了最终这个？
大概率你答不上来。不是因为记性不好，是因为这些信息根本就没有被系统性地记录过。决策在团队中的流失，几乎总是以下四种形态之一：
散落在聊天记录里。 技术选型讨论发生在 Slack 的某个 channel，200 条消息瀑布一样滚过，最终结论藏在第 187 条。三天后被新消息淹没。
只在开会的人脑子里。 一个小时的会议做了三个技术决策，关键的讨论过程全部只存在于参会者的记忆里。有人请假了？这个决策的完整上下文永远丢失了。
写在没人看的文档里。 写决策文档是额外劳动，开发者最讨厌的事。要么不写，要么只写"选了方案 A"一句话带过。项目进行中推翻了原来的决策？文档没有更新。
干脆没发生过。 开发者在实现过程中做了几十个微决策，这些决策没有被讨论、没有被记录，甚至没有被意识到。它们累积起来就构成了系统架构，当后来有人问"为什么这样设计"——答案是"当时就是这么写的"。
决策债务
每一次没有被记录的决策，都是一笔债务。它的利息是：
- 重复讨论。同一个问题被不同的人讨论了三遍，每次都以为自己是在做新的决策。
- 决策矛盾。新做的决策和旧的冲突，但没人知道，因为旧的没有被传递。
- 新人 ramp-up 慢。需要大量口口相传才能理解"为什么系统是这个样子"。
- 知识集中风险。关键上下文集中在几个人脑子里，他们离开后，团队的决策记忆断崖式丢失。
技术债务至少可以通过代码 review、重构计划来追踪。决策债务呢？它不在任何追踪系统里。但它持续地拖慢你的团队。
瓶颈是决策，不是代码
团队协作的瓶颈不是"写代码的速度"，而是"做决策的效率"和"传递决策上下文的效率"。
你会看到 10 个人的团队在"讨论用什么框架"上花了一周。同一个技术选型问题，换了个人就重新讨论一遍。项目中途推翻了三个月前的方案，因为新加入的人不知道当初为什么那么选的。
这些问题不是项目管理的问题，不是代码质量的问题。这是决策过程没有被结构化地管理的问题。
真正有效的方案应该是这样的：决策记录是工作流的副产品而不是额外任务，上下文是自动传递的而不是口口相传的，历史决策是可以被搜索和关联的。
但这需要先回答另一个问题：现有的工具为什么做不到？以及一个新变量——AI——到底能改变什么？
下一篇：现有工具为什么不 work，以及 AI 不应该是聊天机器人暂未完成
