name: feedback-mastery description: 使用结构化框架导航困难对话并提供建设性反馈。涵盖准备-交付-跟进模型和情境-行为-影响（SBI）反馈技术。适用于准备困难对话、给予反馈或管理冲突。 allowed-tools: Read, Glob, Grep
反馈对话
概述
本技能提供框架，用于导航职场困难对话和提供有效反馈。无论是解决绩效问题、处理冲突还是提供建设性反馈，这些结构化方法都能带来更好的结果。
核心洞察： 研究表明，员工在准备困难对话时使用清晰框架，比没有计划的员工达到积极结果的可能性高60%。
何时使用此技能
在以下情况使用此技能：
- 准备向同事或直接下属提供反馈
- 处理绩效问题或未达预期
- 导航团队成员之间的冲突
- 进行关于敏感话题的一对一对话
- 接收反馈并希望建设性回应
- 管理利益相关者期望
关键词： 反馈、困难对话、一对一沟通、绩效、冲突、期望、行为、面对
核心框架
准备-交付-跟进模型
一个三部分结构，用于困难对话：
| 阶段 | 重点 | 关键问题 |
|---|---|---|
| 准备 | 理解问题、定义目标、管理情绪 | 问题是什么？我想要什么结果？我冷静吗？ |
| 交付 | 中立开场、使用事实而非指责、鼓励对话 | 如何开始？我有哪些证据？如何让他们参与？ |
| 跟进 | 记录行动、设定检查点、提供支持 | 我们同意什么？何时检查？如何支持？ |
SBI反馈模型
情境-行为-影响（SBI） 结构使反馈具体、客观且可操作：
| 组件 | 描述 | 示例 |
|---|---|---|
| 情境 | 描述具体上下文 | “在昨天的代码审查中…” |
| 行为 | 陈述可观察的行动（而非解释） | “…在Sarah解释方法时，你三次打断她…” |
| 影响 | 解释对团队/项目/个人的影响 | “…这让她犹豫分享想法，并减慢了我们讨论。” |
为何有效： SBI消除假设，专注于可观察事实，减少防御性。
准备阶段
步骤1：理解问题
自问：
- 问题究竟是什么？ （具体，不模糊）
- 它如何影响团队、项目或公司？
- 我收集了所有相关事实吗？
- 这是模式还是一次性事件？
步骤2：定义目标
对话前，明确目标：
| 目标类型 | 示例 |
|---|---|
| 行为改变 | “我希望他们按时提交代码审查” |
| 相互理解 | “我想理解是什么阻碍了他们” |
| 期望设定 | “我想澄清‘完成’对功能的含义” |
| 问题解决 | “我想一起找到解决方案” |
提示： 使用如果-那么语句澄清风险：
“如果这种行为继续，那么项目时间线将受影响，导致交付延误。”
步骤3：管理情绪
高情绪强度降低认知处理30%。对话前：
- [ ] 我冷静且能控制吗？
- [ ] 我将事实与个人挫折分开吗？
- [ ] 我考虑了他们的视角吗？
- [ ] 我能无指责地呈现吗？
重构技巧：
| 指责性 | 建设性 |
|---|---|
| “你总是错过截止日期，拖慢所有人” | “我注意到一些近期延迟，想了解你面临的挑战” |
| “你从不正确测试代码” | “我最近看到几个bug漏过。我们来谈谈测试流程” |
交付阶段
三步交付公式
- 以中立和意图开场
- 使用事实而非指责呈现问题
- 鼓励对话和解决方案
有效的开场白
| 上下文 | 开场白 |
|---|---|
| 一般 | “我想谈谈对我们团队成功重要的事情，我想听听你的观点。” |
| 绩效 | “我注意到一些模式，想讨论一下。我的目标是支持你，而非批评。” |
| 冲突 | “我感觉可能有紧张，我想从你的角度理解发生了什么。” |
| 期望 | “我想确保我们对期望一致。我们能谈谈这个项目进展吗？” |
事实，而非指责
| 指责 | 事实 |
|---|---|
| “你对此项目不投入” | “我注意到在最近三次会议中，你的更新很简短。有什么影响你的工作量吗？” |
| “你不关心代码质量” | “这个PR在QA中抓到12个bug。我们谈谈发生了什么以及如何改进” |
| “你总是迟到” | “站会9:00开始，过去三天你9:15加入。发生了什么？” |
关键原则：
- 使用具体示例，而非概括（“总是”、“从不”）
- 坚持可观察行为，而非动机假设
- 关注影响，而非品格
鼓励对话
陈述观察后，转向协作：
| 情境 | 对话提示 |
|---|---|
| 理解障碍 | “这有什么挑战？” |
| 寻求他们的看法 | “你如何看待这情况？” |
| 寻找解决方案 | “什么能帮助你在此成功？” |
| 检查对齐 | “这与你对发生的事情理解一致吗？” |
跟进阶段
即使成功对话，也需要跟进以创建持久变化。
跟进清单
- [ ] 记录商定的行动项 - 具体会改变什么？
- [ ] 设定检查日期 - 何时重访？
- [ ] 提供持续支持 - 如何帮助他们成功？
- [ ] 庆祝进展 - 发生时认可改进
示例跟进消息
嗨 [姓名]，
感谢昨天的对话。我欣赏你的开放。
**我们同意：**
- [行动项1] - [时间线]
- [行动项2] - [时间线]
**检查：** 让我们在[日期]重新连接，看事情进展。
如果需要支持，我在这里。感谢你与我合作解决。
最佳，
[你的名字]
SBI示例用于软件团队
积极反馈
代码审查：
情境： “在周二为身份验证模块的代码审查中…” 行为： “…你提供详细评论关于潜在安全漏洞，并建议高效修复…” 影响： “…这加强了我们的安全态势，节省了团队后来调试的小时。”
协作：
情境： “在昨天的架构讨论中…” 行为： “…你问澄清问题并基于他人想法构建，而非推动自己方案…” 影响： “…这帮助我们更快达成共识，让所有人感到被倾听。”
建设性反馈
错过截止日期：
情境： “当我们上周四最终化API部署时…” 行为： “…你的测试结果在我们约定截止后两小时到达…” 影响： “…这延迟了发布，风险了我们的SLA，并导致QA团队加班。”
会议行为：
情境： “在我们昨天的冲刺计划中…” 行为： “…你大部分讨论中在手机，当我们要求估计时未贡献…” 影响： “…这留下团队没有你在后端故事的专业知识，让其他人感到时间未受重视。”
更多示例： 见 references/feedback-sbi-model.md
常见困难场景
场景：绩效问题
情境： 开发者持续交付带bug代码。
方法：
- 准备： 收集具体示例（PRs、bug数量、时间线）
- 交付： “我注意到[最近Y个PRs中有X个bug]。我想了解发生了什么以及如何支持你。”
- 探索： 询问工作量、需求清晰度、测试信心
- 协作： “什么能让你对代码质量更有信心？”
- 跟进： 检查商定变化后，认可改进
场景：团队成员冲突
情境： 两位工程师在技术方法上分歧，影响团队。
方法：
- 先单独见： 理解各自视角
- 找共同点： 他们都想要什么？（工作产品、好代码等）
- 一起促进： 专注于事实和权衡，而非个性
- 建立决策流程： 团队在分歧时如何决定？
- 跟进： 检查解决方案是否有效
场景：不现实期望
情境： 领导希望功能在需要时间的一半内完成。
方法：
- 准备： 类似过去工作数据、所需任务分解
- 交付： “我想确保我们对现实一致。这是我看到的…”
- 呈现权衡： “我们可以在[减少范围/添加人员/接受风险]下击中日期”
- 协作： “这里什么最重要 - 日期还是完整功能集？”
- 记录： 书面获取协议以避免未来不对齐
详细脚本： 见 references/difficult-conversation-scripts.md
良好接收反馈
当你在接收端时：
对话期间
- 完全倾听 - 不要在他们说话时准备防御
- 问澄清问题 - “能给我具体示例吗？”
- 复述以确认 - “所以你说的是…”
- 承认影响 - 即使意图不同：“我能看到那如何影响你”
- 不要防御 - 感谢他们提出
对话后
- 诚实反思 - 反馈中有真相吗？
- 识别行动 - 你会做什么不同？
- 跟进 - 告诉他们你在改变什么
- 请求持续反馈 - 展示你对成长的承诺
快速参考：困难对话清单
之前
- [ ] 我理解具体问题
- [ ] 我有具体示例
- [ ] 我定义了对话目标
- [ ] 我情绪调节
- [ ] 我考虑了他们的视角
期间
- [ ] 我以中立和意图开场
- [ ] 我陈述事实，非指责
- [ ] 我使用SBI进行具体反馈
- [ ] 我问他们的观点
- [ ] 我专注于解决方案，非仅问题
- [ ] 我记录商定行动
之后
- [ ] 我发送跟进总结
- [ ] 我安排检查点
- [ ] 我提供持续支持
- [ ] 我认可进展
配套资源
references/feedback-sbi-model.md- 完整SBI框架与更多示例references/difficult-conversation-scripts.md- 开场白和回应references/expectation-alignment.md- 管理利益相关者期望
推荐阅读
- 《关键对话》 by Kerry Patterson & Joseph Grenny
- 《困难对话》 by Stone, Patton, Heen
- 《绝对坦诚》 by Kim Scott
- Amy Edmondson的关于心理安全研究