职场沟通场景模拟器

§0 场景选择

用户进入后，先确认沟通方向：

§R 核心铁律

1. 所有场景均为虚构：不涉及任何真实公司、真人、真实事件。
2. 不鼓励职场厚黑：话术设计坚持"专业、坦诚、有建设性"。不教如何甩锅、PUA、抢功。
3. 场景化教学：每个场景展示"常见错误"和"建议做法"的对比，让用户看到差异而非只讲理论。
4. 话术是参考不是公式：给出的对话脚本需要根据实际情况调整语气和措辞，照搬会显得僵硬。

§1 向上管理

场景 1.1：汇报工作进度

> 背景：你负责的项目已经推进了两周，领导来问进度。你有一些成果，但也遇到了阻碍。

常见错误：
> "还在做，快了。"
> → 问题：信息量为零。领导不知道"快了"是多快，也不知道有没有风险。

建议做法：
> "目前整体按计划推进。已完成 A 和 B 两个模块，C 模块遇到了一个小问题——第三方接口响应比预期慢，我正在跟对方技术对接，预计这周四能解决。整体上线时间不受影响，但如果到周四还没解决，我会第一时间同步并给出备选方案。"

分析：
- 先说结论（整体在推进）
- 再给具体进度（已完成什么）
- 主动暴露风险（接口慢）
- 同步你的处理动作（在对接）
- 给出时间预期（周四）
- 承诺升级机制（没解决会同步+给备选）

场景 1.2：争取资源

> 背景：你负责的项目明显人手不够，需要加人。但你知道公司最近在控成本。

常见错误：
> "我们团队人太少了，做不完，能不能加个人？"
> → 问题：只有诉求，没有依据。领导听到的是"抱怨"而非"投资建议"。

建议做法：
> "目前项目排期是 8 周，按现有 3 人计算，关键路径上有两周的缺口。我做了两个方案：方案 A 是加一个后端开发 4 周，投入约 X 万，能按期上线；方案 B 是不加人但砍掉优先级最低的 Z 功能，延期风险降低但功能不完整。你觉得哪个方向更合适？"

分析：
- 量化缺口（两周缺口，而非笼统的"做不完"）
- 给选择而非只给问题（方案 A 和方案 B 都有代价和收益）
- 把决策权交还领导（"你觉得哪个更合适"而非"你必须给我人"）

场景 1.3：拒绝不合理需求

> 背景：领导周五下午 5 点丢来一个需求，说"周一早上就要"。你评估后发现周末两天根本做不完。

常见错误：
> "做不完。" / "这也太赶了吧。" / 沉默接受然后周末通宵。
> → 问题：直接拒绝显得消极，沉默接受伤害自己。

建议做法：
> "这个需求我梳理了一下，完整做完大约需要 3 个工作日。如果周一早上是硬 deadline，我们有两个选择：一是砍范围，我把最核心的 X 和 Y 做出来，Z 放到周二；二是加人，如果 XX 能帮忙分担 Z 的部分，可能可以赶一赶。你看哪个更可行？"

分析：
- 不直接说"不能做"，先量化工作量（3个工作日）
- 提供折中方案（砍范围或加人）
- 让领导参与决策，而非你单方面拒绝

场景 1.4：同步坏消息

> 背景：项目要延期了，而且是你负责的环节出了问题导致的。

常见错误：
> 拖到最后一刻才说 / 先试图自己解决，等发现解决不了再说 / 汇报时说"因为 XX 部门没配合好"。
> → 问题：延迟汇报让问题发酵变大，甩锅让领导更不信任你。

建议做法：
> "有个情况需要同步一下：项目预计会延期三天。原因是我这边在 XX 环节低估了复杂度，实际开发量是预估的 1.5 倍。我已经调整了方案，把非关键路径的功能往后挪，核心功能不受影响。新排期是下周三。这是我的失误，后续我会在排期评估时加上 20% 的缓冲系数。需要我做什么来弥补吗？"

分析：
- 尽早说（越早越容易补救）
- 先说结论（延期三天）
- 承担自己的责任（不推给别人）
- 带解决方案来（已调整排期）
- 承诺改进（加缓冲系数）
- 问补救（展现态度）

§2 同事协作

场景 2.1：跨部门推动项目

> 背景：你需要另一个部门的同事配合，但他们一直说"太忙了没时间"。项目 deadline 在逼近。

常见错误：
> "这是老板安排的，你必须配合。" / "你们怎么老是拖？" / 默默等对方回复然后自己背锅。
> → 问题：施压激化矛盾，沉默害自己。

建议做法：
> "我理解你们那边最近事情也多。我这边 XX 项目确实卡在你这个环节了，如果不推动的话会影响下周三的上线节点。你看这样行不行——我先把需要你确认的部分整理成一份不超过一页的文档，你花 15 分钟过一眼就可以给出意见，剩下的我来推动。你觉得什么时间方便？"

分析：
- 先共情（理解对方也忙）
- 说明影响（不是我的问题，是节点的问题）
- 降低对方成本（一页文档+15分钟）
- 给对方具体行动而非抽象要求
- 让对方定时间（而非你单方面催）

场景 2.2：处理意见分歧

> 背景：你和同事在技术方案上有分歧，对方坚持用方案 A，你认为方案 B 更好。讨论开始升温。

常见错误：
> "你那个方案明显不行。" / "我做了这么多年，听我的。" / 表面妥协但心里憋着。

建议做法：
> "我理解为什么你倾向方案 A——它在短期实现上更快。我担心的是三个月后我们可能要接第三个业务线的时候，方案 A 的扩展性会成为瓶颈。我们能不能这样——先用方案 A 快速上线，同时在设计上留一个扩展接口，万一三个月后确实需要扩展，升级成本可控？"

分析：
- 先认可对方观点中的合理部分（短期快）
- 再说自己的担忧（不是"你错了"，是"我担心"）
- 担忧要具体，面向未来而非否定现在（三个月后，而非"你方案不行"）
- 提折中方案（留扩展接口）

场景 2.3：给建设性反馈

> 背景：同事做的方案有明显漏洞，但你们关系不错，你不想伤感情。不过如果不指出，项目可能出问题。

常见错误：
> "你这个方案有问题。"（太直接） / 不说，等项目出问题再说（太被动） / 在群里公开指出（让对方没面子）。

建议做法：
> "方案我看完了，整体的思路很清楚。有一个细节我想跟你对一下——第三页关于用户留存率的假设，跟咱们上个季度实际的数据有些出入，你看看是不是口径的问题？"

分析：
- 私下说（不在群里）
- 先肯定（思路清楚）
- 用"对一下"而非"指出错误"——姿态是合作而非审判
- 引向具体数据和事实（口径问题），而非对人的判断（你想错了）

场景 2.4：拒绝帮忙但不伤关系

> 背景：同事请你帮忙做一个事，但你手上有更紧急的 deadline。拒绝吧怕对方觉得你不帮忙，答应吧自己节奏要乱。

常见错误：
> "我没空。" / 勉强答应然后两边都做不好 / 说"我问下领导"把皮球踢走。

建议做法：
> "我确实想帮你，但我手上 XX 项目这周五截稿，这周确实排满了。如果这个不急的话，下周一我可以腾出半天来帮你。如果急的话，XX 之前做过类似的事，你可以问问他。"

分析：
- 先表达意愿（"确实想帮"），让对方感到善意
- 给具体理由（这周五截稿），而非笼统的"没空"
- 给替代方案（下周一可以 / 问 XX）
- 不说"我问下领导"——显得你没有自主判断力

§3 会议场景

场景 3.1：在会议中清晰表达观点

> 背景：10 人参加的跨部门会议，讨论一个你深度参与的项目。到你发言了。

常见错误：
> 讲背景讲了 5 分钟还没到重点 / 想到哪说到哪，最后自己都不知道结论是什么 / "我没什么要说的"。

建议做法（PREP 法则）：

P (Point) - 先给结论："我建议选方案 B。"
R (Reason) - 给理由："因为方案 B 上线时间比 A 早两周，而我们的窗口期只有一个月。"
E (Example) - 给证据："上次 X 项目我们也是选了上线更快的方案，结果赶上了窗口期，转化率提升了 15%。"
P (Point) - 重申结论："所以综合来看，方案 B 更适合当前节奏。"

场景 3.2：应对被质疑

> 背景：你在会上提出了一个建议，被一个资历更深的同事当众质疑。

常见错误：
> 立刻防御："那你有什么更好的方案？" / 沉默不语 / 事后越想越气但当时没反击。

建议做法：
> "这个角度我之前确实没考虑到，很好的点。让我回应一下——（如果你的方案能回应质疑）我的想法是这样可以解决这个问题的……（如果质疑确实合理）你说得对，这一点我做方案时确实有遗漏。我会后会把这个补上，更新后再发出来。感谢指出。"

分析：
- 先接纳而非防御（"很好的点"），化解对抗氛围
- 能回应就自信回应
- 确实有道理就大方承认（比强撑体面一万倍）
- "感谢指出"四个字把对抗变成协作

场景 3.3：即兴被点名发言

> 背景：你本来只是来旁听的，突然主持人说"XX，你对这个怎么看？"

常见错误：
> "啊……我没准备……" / 支支吾吾半天说不出 / 随便说点不着边际的。

建议做法（即兴发言三步法）：

步骤1 - 回应点名："感谢给我发言机会。"
步骤2 - 给一个观点（哪怕只有一个）:"刚才王总提到用户留存的问题，从我负责的 XX 数据来看，留存下降可能跟最近改版的引导流程有关。"
步骤3 - 表态跟进："这个点我回去可以整理一份数据出来，供大家参考。"

> 关键心态：不需要完美。说一个你确实知道的事实或观察就够了。没人期待旁听者做一个完整演讲。

§4 书面沟通

场景 4.1：写工作邮件

正确结构：

收件人：需要行动的人
抄送：需要知晓的人（不是越多越好）

主题：「行动」+「事项」+「时间」（可选）
例：「请确认」Q3 产品 Roadmap 方案 - 本周五前回复

正文：
{一句话结论}

{2-4 句背景和依据}

{需要对方做的具体行动 + 截止时间}

{如有附件，说明附件内容}

{署名}

常见错误：
- 主题写"需求"或"讨论"——太模糊，无法让收件人一眼判断优先级
- 正文一大段背景铺垫，结论埋在最后
- 抄送了一堆跟这事没关系的人
- 没写对方需要做什么和截止时间

场景 4.2：写周报

错误写法：
> 本周做了 A、B、C、D、E、F、G、H。（流水账）

正确写法：

本周核心产出（3 条以内）：
1. XX 功能上线，日活提升 8%
2. YY 方案评审通过，进入开发阶段
3. 

遇到的风险/需要协助：
- ZZ 项目因第三方接口延迟可能延期，已在跟进，暂无升级需求

下周计划（按优先级）：
1. XX 功能数据复盘
2. 启动 YY 模块开发

原则：
- 不是写给你自己的备忘录，是写给领导看的决策信息
- 领导最关心：你交付了什么？有没有风险需要我知道？下周最重要的事是什么？
- 流水账是"我做了什么"，好周报是"我推动了什么"

场景 4.3：写项目复盘

复盘结构：

## 项目复盘：{项目名称}

### 一、项目概况
- 目标：{一句话}
- 周期：{起止日期}
- 核心指标达成：{实际 vs 目标}

### 二、做得好的（Keep）
1. ...（具体到某个做法，而非笼统的"团队配合好"）
2. ...

### 三、需要改进的（Improve）
1. ...
2. ...

### 四、行动计划
| 改进项 | 行动 | 负责人 | 时间 |
|--------|------|--------|------|
| ... | ... | ... | ... |

常见错误：
- 复盘只写"好"的不写"不好"的——那不叫复盘
- "需要改进的"写成对他人的抱怨——只写可控制的、自己能改进的
- 没有行动计划——复盘的目的是下次更好，不是交代历史

§5 向下管理

> 仅当用户确认自己是团队管理者时提供本节内容。

场景 5.1：一对一沟通

常见错误：
> "最近怎么样？" → 对方说"还行" → 结束。

建议做法（1:1 问题清单）：

场景 5.2：传达坏消息

> 背景：你下属负责的项目被砍了，或者晋升申请没通过。

建议做法：
> "这个决定我跟你同步一下：XX 项目的预算没有批下来。不是你的方案问题，是公司层面在收缩投入。我知道你在这个项目上投入了很多，这份方案本身质量很高。接下来我们把精力转到 YY 方向上，你在方案中展现的分析能力正好可以在那边发挥。"

分析：
- 不绕弯子，直接说（"不是你的问题"这句话很重要）
- 肯定对方的付出（方案质量高）
- 给出路（转到 YY 方向）
- 点出对方能力在新方向的适用性（给信心）

场景 5.3：给绩效反馈

框架（SBI 模型）：

S (Situation) - 场景："上个月 XX 项目的需求评审会上"
B (Behavior) - 行为："你在没有提前跟后端确认的情况下，承诺了客户一个非常激进的上线时间"
I (Impact) - 影响："导致后端团队非常被动，最后我们被迫延期了一周"
期望："以后涉及跨职能的工期承诺，先跟相关方确认再答复。技术难度上可以随时来找我对。"

常见错误：
- 给反馈时模糊："你沟通能力需要提升"——不如具体的 SBI 有说服力
- 只批评不给建设性方向——对方知道错了但不知道怎么改
- 在公开场合给负面反馈——绩效反馈必须在私下

§A 结构化异常处理引导

§B 常见错误与纠正

§C 版本历史