08 - 团队与流程：人员协作的长期战斗力
代码是死的，组织是活的。组织决定代码能活多久。组织混乱 = 半年后写的代码没人敢动。
一句话
团队的战斗力 = 单兵能力 + 协作效率 + 知识传递 + 持续学习的循环——4 个齿轮同时转，组织才有动力。
团队规模的 5 个阶段与困境
SE@Google Ch2-7 反复讨论了规模化的挑战：
1 人: 没团队，只是写代码
2-3 人: 创业期，沟通 1-1 即可
5-9 人: 开始有"分工"，需要明确角色
10-20 人: 需要"流程"，但流程变成负担
30+ 人: 需要"团队组"，协调变跨团队每一阶段的"扩大"都会撞特定困境：
| 团队规模 | 主要困境 | 解决方式 |
|---|---|---|
| 1→5 | 决策靠人 → 5 人后决策混乱 | 明确 Owner |
| 5→15 | 一人扛所有 → 知识单点 | 知识传递机制 |
| 15→30 | 互相不通 → 跨团队协调 | RFC + 协调员 |
| 30→100 | 团队组各自为政 → 平台脱节 | 共享平台 + 公共治理 |
团队角色定义
5 个核心角色
| 角色 | 人数比 | 责任 |
|---|---|---|
| Tech Lead / 架构师 | 1:8 | 技术决策 + 系统设计 + 代码质量 |
| Product Manager | 1:8 | 业务价值 + 优先级 + 利益相关者 |
| Senior Engineer | 占 20-30% | 技术难点 + 带新人 + 架构演进 |
| Engineer | 占 50-60% | 实施功能 + 维护 + 单元测试 |
| QA / SRE / 设计 | 1:5 | 质量 / 稳定性 / 用户体验 |
"10 人 8 个角色"原则
10 人团队不应该是"10 个工程师"——而是：
- 1 架构师
- 1 产品经理
- 1 QA
- 1 SRE / 运维
- 6 工程师
反模式：全工程师无 PM——没人接业务需求，全埋头写代码。
每周节奏
可参考的"标准周"：
周一
10:00-10:15 全体 Standup
10:30-12:00 架构 / 设计讨论
14:00-15:00 跨团队协作会议
15:00-17:00 写代码
周二 / 周三 / 周四
10:00-10:15 Standup（可选）
10:15-12:00 专注时间（写代码 / 设计）
14:00-17:00 专注时间
周五
10:00-10:15 本周回顾
10:30-12:00 Sprint Review (Demo 给利益相关者)
14:00-17:00 代码清理 / 文档 / 学习时间原则：
- 专注时间神圣不可侵犯——会议不抢
- 重复会议合并——类似主题 1 周 1 次
- 周五下午是"清理时间"——文档 / 重构 / 学习
反模式：周一开会一整天
症状：周一下午 4 点没人提交过代码。
修复：周一上午 1 小时 Standup，之后全写代码。
知识传递的 6 大机制
机制 1：Code Review（最日常）
已在 06 章节详述——除了检查代码，更是知识传递。
机制 2：Pair Programming
何时用：
- 新人学习代码库
- 关键技术决策
- 复杂 Bug 调试
反模式：所有代码都 Pair = 速度减半 = 不可持续。
机制 3：Tech Talk
频率：每两周 1 次，每次 15-30 分钟。
内容：
- 一个技术决策分享
- 一个新工具介绍
- 一个事故复盘
- 一个外部技术报告消化
关键：轮流讲，避免只有 senior 讲。
机制 4：设计文档 / RFC
何时写：技术决策涉及多模块或多团队。
何时不写：1-2 天的改动。
格式（5 分钟可读）：
# RFC：XXX
## 背景 / 问题
[为什么需要决策]
## 提议方案
[具体的方案 + 备选]
## 影响范围
[哪些模块 / 哪些团队]
## 风险
[已知风险 + 应对]
## 决策人
[谁决策 / 谁执行]
## 时间线
[从提议到决策的时间]机制 5：知识文档
Notion / Confluence / 语雀：
knowledge/
├── onboarding/ # 新人入门
│ ├── 0-welcome.md
│ ├── 1-dev-env-setup.md
│ ├── 2-codebase-tour.md
│ └── 3-deploy-runbook.md
├── architecture/ # 架构文档
├── decisions/ # ADR / RFC
├── runbooks/ # 运维手册
└── postmortems/ # 事故复盘机制 6：Buddy（师徒制）
新员工配 buddy：
- 1-1 关系，非汇报关系
- 6 个月陪伴期
- 每周 1 次 30 分钟 1-1
- Buddy 是"安全网"，不是"老师"
反模式：只分配任务不分配人——新人没人带 = 3 个月后还在摸索。
远程协作（疫情后常态）
异步优先
SE@Google Ch5 关键洞察：
"Many of the best engineering decisions are made offline, written, and reviewed."
翻译：很多好决策是异步思考 + 写下来 + 评审后产生的。
异步优先的 4 个工具：
- 文档替代会议——能写的不要开 1 小时会
- 24 小时规则——所有问题 24 小时内有人响应
- 明确"会议时段"——避免 8 小时被会议塞满
- 时区协作——亚太 / 美洲团队用 Handoff（早交接晚接续）
远程高频会议的健康比
健康比:
1:1 30% (团队沟通 + 个人发展)
全体 Standup 20% (进度同步)
评审 / Demo 20% (交付确认)
设计讨论 20% (技术决策)
杂务 10% (协调 / 数据对齐)
不健康比:
多人协作会议 50%+ → 效率崩溃远程协作的反模式
- 永远在线——大家时区不同，永远有人在工作 = 永远有人在等
- 过度依赖同步沟通——半小时能写清楚的文档，非开 1 小时会
- 缺乏异步反馈循环——写完 PR 没人 review 24 小时
- 状态同步靠"我以为你知道"——所有状态必须写在文档里
1-1 沟通（一对一）
1-1 是管理者最重要的工具：
议程模板
【本次 1-1】 日期：____ 管理者：____ 团队成员：____
1. 上次 1-1 之后的进展
[上次讨论的事有什么新进展]
2. 现在阻塞 / 焦虑的是什么
3. 个人方向 / 兴趣
[最近想学什么 / 想做什么]
4. 团队 / 项目问题
[非个人，对组织的问题]
5. 我能帮什么
[管理者能做什么]
6. 下次 1-1 前想达成什么频率
- 直属下属：1 周 1 次 30 分钟（首次 6 个月）
- 成熟下属：2 周 1 次 30 分钟
- 跨级：季度 1 次 30 分钟
反模式
- 1-1 = 汇报工作——不对，那是 Standup 的事
- 1-1 不到场——管理者比下属重要吗？错，下属重要
- 1-1 没议程——每周都变成"还行吧"——浪费时间
招聘（团队战力的源头）
技术团队招聘 5 原则：
- 结构化面试——同一岗位用同一组问题，每轮打分
- 能力 ≠ 经验——招的是能成长的人，不是当前最强的人
- 价值观匹配——文化不匹配的人再强也快离
- 多做 Reference Check——候选人前雇主电话一定要打
- 试用期内"养"——人招进来不是结束，是培养的开始
面试 4 轮模板：
1. HR 初筛（30 分钟）—— 价值观 + 经验
2. 技术电话面（60 分钟）—— 基础知识
3. 技术现场（3 小时）：
- 算法题 1 道（45 分钟）
- 系统设计 1 道（45 分钟）
- 文化匹配讨论（45 分钟）
- 代码 Review（30 分钟）
4. 团队 / 管理者面（60 分钟）—— 性格 + 动机 + 成长性新人入职（Onboarding）
目标：入职 1 周内能提交第一个 PR。
清单：
第 1 天
第 1 周
第 1 个月
第 3 个月
第 6 个月
技术债管理
技术债是必然的——问题不是有没有，是如何管理。
技术债的 4 类
1. 紧急且重要 (马上修)
例: 关键路径性能问题
2. 重要不紧急 (排进 Sprint)
例: 模块边界混乱
3. 紧急不重要 (有时间再修)
例: 代码风格不一致
4. 不重要不紧急 (放在 backlog)
例: 过度抽象技术债的可见性
技术债清单（Notion / Confluence）：
## 技术债列表
| 类型 | 描述 | 影响 | 估算 | 优先级 |
|---|---|---|---|---|
| 性能 | 订单列表未分页 | 大数据量慢 | 2 天 | P1 |
| 安全 | JWT 过期无限 | 安全风险 | 1 天 | P0 |
| 文档 | X 模块无 README | 新人难上手 | 0.5 天 | P2 |
| 测试 | OrderService 测试覆盖率 30% | 重构风险 | 1 周 | P2 |规则：每 Sprint 预留 20% 给技术债——否则累积。
反模式
- 积累不还——技术债像信用卡，利息越来越高
- 大爆炸式重构——一次性改 6 个月 = 团队半死
- 没衡量指标——技术债 = 主观判断。需要指标（测试覆盖率 / 性能 / 故障率）
远程 vs 现场 vs 混合
各模式比较
| 模式 | 优点 | 缺点 | 适用 |
|---|---|---|---|
| 纯现场 | 沟通效率最高 | 人才地理限制 | 团队 < 10 人 |
| 纯远程 | 人才池最大 | 协作效率低 | 时区一致 + 异步习惯强 |
| 混合（推荐） | 平衡 | 公平感问题 | 主流团队 |
混合团队的"远程优先"原则
远程优先 = 重要会议 / 决策 都远程可加入 + 录像 + 文档
现场才有的好处 = 1-1 沟通 / 团队建设 / 难题研讨反模式：重要决策在午餐聊完——远程成员不知道。
团队文化
4 个核心价值观
- 诚信 (Integrity)——能力可以培养，诚信不能
- 反馈 (Feedback)——彼此直接反馈 → 成长
- 学习 (Learning)——拥抱未知 → 持续改进
- 结果 (Results)——不仅仅是工作，是结果
文化的可见动作
诚信：数据透明 / 公开 okr 进度 / 失败汇报 反馈：360 评估 / 每次 Retro / 1-1 直接 学习：每两周 Tech Talk / 鼓励学新东西 结果：每个 Sprint 看 Sprint Goal 完成 / Demo 真实展示
反模式
- 文化墙——只挂在墙上的标语 = 没用
- "我们很 open"但从来不听反对意见 = 假开放
- 失败当耻辱——团队变得不敢尝试
- 加班当荣誉——长期会崩
组织的 3 大反模式
1. "优秀团队特殊论"
症状：认为"我们团队非常特殊，所以标准流程不适用"。
修复：先套用标准流程 3 个月再说。
2. "英雄主义"
症状：靠某个牛人解决问题。牛人离职 = 团队瘫痪。
修复：英雄做的事 = 必须流程化——不能只有一个人知道。
3. "目标延期"
症状：每个 Sprint 都延期，但没人警觉。
修复：重复延期 = 必须重新审视 Roadmap——不是能力问题，是目标不合理。
团队扩展的 4 个阶段
SE@Google 实践：
1. 创建团队（Founding）—— 1 架构 + 1 产品 + 5-8 工程
2. 扩张阶段（Building）—— 加 5-15 人，引入 Tech Lead
3. 稳定阶段（Operating）—— 团队稳定，明确边界
4. 重塑阶段（Renewing）—— 引入新方向，反思关键：避免"自然成长"——每个阶段主动审视结构。
组织的可衡量指标
这些不是 KPI，是健康指标：
- 人员流失率 < 10%/年
- 新人 1 周内能提交 PR：100%
- Sprint 完成率：60-80%（不能 100%，那是估算太保守）
- 1-1 完成率：> 90%
- Tech Talk 频率：每两周 1 次
- Retro 频率：每 Sprint 1 次
- On-call 响应时间：< 5 分钟（严重告警）
- 代码覆盖率（核心）：> 70%进入下一章
团队是项目生命周期的"血液循环"——回到 01 总览 看全局图，本方法论开始循环上升。
作者：基于 SE@Google Ch2-7 (Culture) + INCOSE C07 (Organizational) + 敏捷 / 远程协作实践综合 最后更新：2026-06-28