Appearance
场景8——处理团队冲突
场景描述
你作为前端负责人，发现团队里两个人有矛盾：
小王抱怨：
"小张老是不按规范写代码，我Review他的代码要花很多时间。
说了好几次都不改。"
小张抱怨：
"小王Review代码太挑剔了，有些小问题有必要纠结吗？
耽误我的开发进度。"这是团队冲突场景。
常见的错误处理：
- 和稀泥："你们都退一步..."（没解决问题）
- 站队："小王说得对，小张你要改"（激化矛盾）
- 回避："你们自己解决..."（问题恶化）
正确的做法是找到冲突的根源，解决根本问题。
CPERF应用
C - Capture 捕获
第一步：分别了解双方的看法
和小王单独聊：
"最近和小张合作有什么困难吗？具体说说？"
小王的说法：
- 小张变量命名不规范，要花时间理解
- 注释很少，不知道代码在干什么
- 说过几次，没有改变
和小张单独聊：
"听说Review流程有些问题？说说你的看法？"
小张的说法：
- 小王太挑剔，连空格都要管
- 有些规范他觉得没必要
- 因为Review来回改，进度受影响第二步：收集客观信息
看Review记录：
- 小王确实提了很多修改意见
- 有些是命名规范问题（合理）
- 有些是代码风格问题（有争议）
看代码规范：
- 团队有代码规范文档，但比较简单
- 有些点没有明确规定第三步：定义核心问题
表面问题：两个人对Review标准有分歧
根本问题：
1. 代码规范不够明确
2. 没有统一的Review标准
3. 双方对规范的重要性认识不同P - Process 处理
分析冲突类型：
这个冲突是"标准不统一"导致的，不是人品问题。
小王的诉求：代码质量要有保证
小张的诉求：效率要有保证，规范不要太死板
两个诉求都是合理的，问题是怎么平衡。设计解决方案：
方案：
1. 完善代码规范，明确哪些是必须遵守的，哪些是建议
2. 必须遵守的用工具检查（ESLint），减少人工Review负担
3. 开一次对齐会议，达成共识E - Express 表达
和双方分别沟通：
和小王说：
"我了解了情况。你关注代码质量是对的，
但有几个点可以调整一下。
第一，规范不明确的地方，确实容易有分歧。
我打算完善一下代码规范，把必须遵守的明确出来。
第二，能用工具检查的，就用工具检查。
比如命名规范、格式问题，配置好ESLint自动检查，
你Review时就不用花时间在这些上面了。
第三，对于规范之外的建议，可以标注为'建议'，
不强制要求改。
你看这样是否可以？"和小张说：
"我了解了情况。效率确实很重要，
但代码质量也不能忽视，我说说我的想法。
第一，规范不明确的部分，确实容易有争议。
我会完善代码规范，哪些必须遵守会明确出来。
第二，能用工具检查的，会配置工具自动检查。
这样你提交前就知道哪里不符合规范，不用等Review了。
第三，Review意见里会区分'必须改'和'建议'，
必须改的才影响合并。
你看这样是否可以？"组织对齐会议：
会议目的：对齐代码规范和Review标准
会议内容：
1. 我先说明为什么要有规范（代码质量、维护成本）
2. 讨论哪些规范是必须遵守的
3. 讨论Review流程怎么优化
4. 形成共识，形成文档R - Review 复盘
执行后观察：
一周后观察：
- Review时间减少了，因为工具检查了基础问题
- 小王和小张的沟通顺畅了
- 没有再听到抱怨
一个月后观察：
- 新来的同事也能按规范写代码
- 规范文档有人开始补充完善复盘处理方式：
做得好的：
1. 没有站队，而是找根本问题
2. 分别沟通，照顾双方感受
3. 提出了具体的解决方案
可以改进的：
1. 代码规范早就应该完善，不该等出问题才做
2. 下次类似冲突可以更早介入F - Form 固化
冲突处理框架：
markdown
## 处理团队冲突的框架
### 第一步：分别了解
- 和双方分别沟通
- 了解各自的诉求和困难
- 不要当面对质
### 第二步：找根本问题
- 表面问题是什么？
- 根本问题是什么？
- 是人的问题还是制度/流程的问题？
### 第三步：设计方案
- 怎么满足双方的核心诉求？
- 需要什么制度/流程支持？
### 第四步：分别沟通
- 分别和双方沟通方案
- 照顾各自的感受
- 获得认可
### 第五步：组织对齐
- 如果需要，开对齐会议
- 达成共识
- 形成文档
### 第六步：持续观察
- 观察后续效果
- 及时调整关键要点
要点1：分别了解，不当面对质
当面对质会让双方防守，说不出真话。
分别沟通：
1. 能听到真实想法
2. 能了解各自的诉求
3. 为后续沟通做准备要点2：找根本问题，不和稀泥
"你们都退一步"只是暂时压下去，问题还在。
要找根本问题：
- 是人的问题还是制度的问题？
- 如果是制度问题，怎么完善制度？
- 如果是人的问题，怎么帮助成长？要点3：不站队
站队会：
1. 让对方觉得不公平
2. 激化矛盾
3. 失去管理公信力
要做的是：
1. 理解双方的诉求
2. 找到双方都能接受的方案
3. 从团队利益出发要点4：照顾感受
沟通时照顾各自的感受：
对小王说"你关注代码质量是对的"
→ 肯定他的出发点
对小张说"效率确实很重要"
→ 认可他的诉求
让双方都感觉被理解，而不是被批评。要点5：形成制度
冲突解决后，要形成制度/流程，
防止类似问题再发生。
这次：代码规范+工具检查+Review标准
下次类似问题就有据可依。本场景的CPERF检查清单
markdown
□ Capture
- 分别了解双方的看法了吗？
- 收集了客观信息吗？
- 找到根本问题了吗？
□ Process
- 分析了冲突类型吗？
- 设计了解决方案吗？
- 方案能满足双方核心诉求吗？
□ Express
- 分别和双方沟通了吗？
- 照顾了各自感受吗？
- 组织了对齐会议吗？
□ Review
- 观察了后续效果吗？
- 复盘了处理方式吗？
□ Form
- 形成了制度/流程吗？
- 总结了冲突处理框架吗？不同类型冲突的处理
markdown
### 标准不统一的冲突（本例）
→ 明确标准，用制度解决
### 资源竞争的冲突
→ 协调资源分配，或向上争取资源
### 个人风格的冲突
→ 强调共同目标，建立协作规范
### 权责不清的冲突
→ 明确权责边界，形成书面文档
### 个人恩怨的冲突
→ 私下调解，必要时调整人员安排小结
处理团队冲突的核心方法：
- 分别了解，不当面对质
- 找根本问题，不和稀泥
- 不站队，从团队利益出发
- 照顾双方感受
- 形成制度，防止再发
记住：大多数冲突不是人品问题，而是制度或流程的问题。解决制度问题，冲突自然消失。
下一章，我们看做出职业选择的场景。