独立开发者团队扩张复盘：从一人全栈到三人协作的工程管理挑战
一、从"我"到"我们"的本质变化
一人的时候：代码风格一致（因为只有一个人写）、没有沟通成本（自己和自己讨论）、没有"别人的Bug"（所有Bug都是自己的）。三人团队后所有这些"便利"都消失了：
- 同样的功能三个人的实现方式完全不同
- PR Review变成耗时活动——"这里为什么要用for循环而不是map"
- "你的代码改了导致我的功能不work了"
- 任务分配变成了管理活动——什么谁做、做到什么程度算完成
这些不是团队"有问题"，而是从一人到多人的必然代价。
二、工程管理的四个关键工具
工具一：Lint + Prettier 消除风格争议
这是第一个引入的工具，也是ROI最高的。Prettier让"缩进用几个空格"、"分号加不加"这类无限讨论直接终止——工具说了算。
工具二：PR模板 + Review清单
# PR Template ## 变更类型 - [ ] Bug修复 - [ ] 新功能 - [ ] 重构 ## 变更说明 简述做了什么，为什么这样做。 ## 测试 - [ ] 本地测试通过 - [ ] 添加了单元测试 - [ ] 对现有功能无影响 ## 截图（如涉及UI变更） ## Checklist - [ ] 代码通过lint检查 - [ ] 关联Issue已更新 - [ ] 文档已更新（如有必要）工具三：GitHub Project做任务管理
不需要Jira/Linear这类重型工具（3人团队没必要）。GitHub Project的Kanban板足够：
- Todo → In Progress → Review → Done
- 每个任务关联具体Issue
- 每周一早上10分钟的Standup同步进度
工具四：决策记录（ADR）
# ADR-001: 选择Zustand替代Redux ## 状态 **Accepted** ## 背景 项目现有Redux代码维护成本高，新增功能需要修改5个文件。 ## 决策 新功能使用Zustand，旧Redux代码保持不动。 ## 后果 - 正面：新功能开发速度提升40% - 负面：项目中同时存在两种状态管理方案，新成员需要学习两者 - 负面：未来可能需要把旧Redux也迁移ADR的价值：当有人问"为什么我们选了X而不是Y"时，直接看ADR而不是再讨论一轮。
三、人的问题比技术更难
问题一：任务分配中的"知识孤岛"
某个功能只有一个人知道怎么改——这个人请假了，功能就阻塞了。解决方案：强制Code Review——每个人都至少看过其他两人的代码。鼓励Pair Programming每两周一次。
问题二：工作量评估的偏差
一人时评估"这个功能要3天"通常准确（因为自己知道自己的速度）。三人时每个人的速度不同——A的3天可能是B的5天。解决方案：用Story Points替代"人天"评估。先做2个Sprint，观察团队速度后再规划后续。
问题三：技术决策中的"民主 vs 高效"
三人投票做技术决策——2:1通过——但反对的那个人可能在实施时消极。解决方案：对于重要决策（技术选型、架构变更），同意者要承担主要实施工作。这样投票是"谁做决定谁负责"而非"多数压倒少数"。
四、协作效率的数据
| 指标 | 一人 | 三人 |
|---|---|---|
| 每周功能产出 | 5个 | 11个 |
| 线上Bug修复时间 | 2h | 1h |
| 决策时间 | 即时 | 30min(讨论) |
| 文档更新频率 | 每周1次 | 每次功能都有 |
三人的产出不是一人的3倍（理论值），而是2.2倍——多出来的0.8被沟通和管理消耗。但Bug修复时间从2小时降到1小时——因为有人可以pair debugging。
五、总结
从一人到三人的核心经验：
- Lint + Prettier是第一要务——消除代码风格的无价值讨论
- PR + Review流程让代码质量不退化——一个人的代码不会拖垮所有人的代码
- ADR记录技术决策——让"为什么这样做"有据可查，减少重复讨论
- Story Points替代人天评估——适应不同开发者的速度差异
- 接受"效率下降"——三人产出是2.2倍而非3倍，这是管理的必然代价
最大的心态转变：从"我想怎么写就怎么写"到"代码是团队的，不是我个人的"。这个转变需要时间——约3个月后团队才进入"默契期"。在这个过渡期中，工程工具（Lint、PR、CI）是信心保障——没有工具的约束，3个月可能全是争吵。有了工具，争吵被自动化检查替代，精力集中在"做什么"而非"怎么做"。
