我是住在首尔的新西兰人。这篇写的是从内部看到的韩国开发现场，坐在招聘桌两边看到的东西，以及我想对考虑来韩国工作的人说的话。

我是怎么来的

#

入口是读研。在新西兰怀卡托大学读完本科，又在一家电信公司做了一年网络运维之后，我于 2017 年 3 月到 2019 年 2 月在庆熙大学读计算机科学硕士。实验室每学期都会去参加韩国国内的两个计算机学术会议 KSC 和 KCC。2018 年在平昌举办的 KSC，赞助商里有好几家韩国大型科技公司，还设了面向求职学生的招聘展位。如果你是在韩国读研的外国学生，这一点值得知道。

之后的经历是这样的：

工程是熟悉的那一半。在那家客服初创公司我才明白，交付软件的很大一部分其实是运维；创作者平台的后端跑在比我今天会选的多得多的技术栈上。韩国特有的差别都在边边角角。Naver 是你必须在意的搜索引擎：我给 Kiwi Alumni 上线新网站的时候，SEO 是按 Google 和 Naver 两边一起做的。韩国平台的爬虫名字你很难猜到（Naver 的爬虫叫 Yeti，KakaoTalk 的链接预览来自一个叫 kakaotalk-scrap 的东西）。还有，韩国的网上银行到现在还要你在电脑上装它们自己的安全软件。

不过这些都不是难的部分。

눈치是什么，为什么不是「optics」

#

눈치是一种感觉：不靠别人说了什么，而是从情境里察觉别人在想什么、要什么、期待什么。눈 是「眼睛」的意思。用 2019 年的《The Power of Nunchi》一书把눈치介绍给英语世界的 Euny Hong，把这个词译成「eye-measure」，也就是「用眼睛量」。它出现在不少日常说法里。说一个人「눈치가 빠르다」（눈치快），是说他很会看场合；说一个人「눈치가 없다」（没有눈치），是说他完全看不懂，这可不是夸人。而「눈치를 보다」（看눈치）是一直留意别人的反应，通常是上级的，好让自己站在不被讨厌的那一边，相当于中文的「看眼色」「看脸色」。

英语里大家这时候会拿出来的词是「optics」，我觉得用错了。optics 讲的是不管实际如何，从外面看起来怎样，比如「在裁员的同一周宣布发奖金，optics 很难看」。它关乎外表，管理它的是被看的那个人。눈치大多指向相反的方向：重点不是你在别人眼里怎么样，而是你把别人看得有多清楚。两者唯一的交点是「눈치를 보다」：观察所有人，好管理自己在他们眼里的样子。外媒写韩国职场时写到的，正是这个版本。

那些文章举的例子大同小异：不要比组长先下班，真要休年假（연차）时得看的눈치，聚餐（회식）时什么时候可以走，以及要反驳上级的话，是在会上说还是会后私下说。不管你怎么看这些例子，它们的形状是一样的：每一条都是所有人都遵守、却没人说出口的规矩。

而且这和语言是两回事。韩语在话里，눈치在话以外的一切里。

눈치在开发团队里出现在哪儿

#

开发团队靠的正是这种形状。第一次当经理几个月后，我写了一篇关于团队规范的文章，开头是这样的：我处理的摩擦大多不是技术问题，而是大家对一些事各有各的默认假设，比如代码评审该多快回、「完成」到底指什么、催第二次算不算没礼貌。那时我没用这个词，但那张清单每一行都是눈치要读的东西。每一条都是团队心照不宣的约定，新人只能靠观察学会。

同一篇里我还抱怨过，新人学规范是「当成口口相传的民间故事」，而不是在入职时被明确告知；也抱怨过跨国团队默认自己的标准就是所有人的标准。要描述눈치靠什么运转，我找到的最好的英语词就是 folklore，民间故事。如果团队里只有你一个外国人，偏离标准的就是你，而那些「故事」哪儿都没写下来。

代价最大的地方是站会。2023 年我写过自己负责的一个项目落后了，我却一直等着有人来问。三周后终于有人问了，那时已经是一场灾难。눈치好也解决不了这个问题。会看场合，你就知道哪些话没人想听；可它不会告诉你照样要说。我从中得到的习惯正好和等待相反：在别人问之前，先用文字说出来。「这件事比我预想的要久，现在估计要 8 到 10 天，不是 5 天。要砍范围，还是推迟截止日期？」

当你成了被读的那个人

#

2024 年 2 月，我开始在首尔一家软件公司带一个工程团队，눈치的方向就此反了过来。当开发的时候，是我在看场合；当了经理，我自己就是场合。我在会上说了什么、没说什么，回消息有多快，几点下班，全都成了别人可以读的东西。

我当项目负责人时写过的很多东西，当了经理之后更加适用。如果大家不敢放心地告诉你哪里出了问题，你就会是最后一个知道的人。信息捂得太久，大家是能感觉到的，你留下的沉默会被小道消息填满。会上五个人等着你回答时，「我不知道」感觉像是失败，而这恰恰是它值得说出口的原因。还有我反复想起的一句话：别人读不到你的意图，只读得到你的话。在一个靠눈치运转的团队里，他们照样会去读：读你的表情、读你跳过了什么、读你几点走。所以最好少给他们留猜的余地。

我靠的都是些不起眼的做法。和每个人做一对一，聊的是这个人而不是这个 Sprint，再问一个能解决大部分问题的朴素问题：「有没有什么需要我或者团队帮忙，好让你的工作更顺利？」

一份简短的团队规范，三到五条，写在所有人都看得到的地方，包括经理违反了规范会怎样。主动去问那些在八个人的会上永远不会开口的人，而不是等他们开口。再就是用一句坦白的「不行，原因是这样」，代替一句之后再也不会被提起的「再看看」，因为含糊的回答只是又多了一件需要察言观色的事。我入职一个月左右时，产品团队的团建是从一家咖啡馆开始的，先做了一个关于彼此价值观和团队规范的工作坊。一家公司能给눈치的回答，很少有比这更直接的：花一整个上午，把平时不说出口的东西说出来。

作为外国人被招进去

#

我没有一套针对韩国求职的打法。我有的是招聘经理那一边的经验，由此得出的建议，就是在签合同之前，先对公司用一用눈치。

我当经理招人的时候，最想招的开发者从来不在招聘网站上；而且我以前也写过，创始人更愿意招自己已经共事过的人。所以最好的入口，是任何能让别人在招你之前先看到你怎么干活的地方。小公司的实习经常会悄悄变成一份正式工作邀约。黑客松能让人看你一整个周末：2023 年，我和另外三个人组队，拿下了由 Lunit Global 主办的 Seoul Tech Impact Hackathon 冠军，做的是一个应用，用来找韩国那些没有地址的路边小吃摊。

然后是咖啡聊天。我写过，一个人在轻松的聊天里怎么表现，比一场排练过的面试更能说明和他共事是什么样子，而且这是双向的。对候选人来说，这是进去之前读懂一个团队的唯一机会。如果坐在候选人的位置，我会问：团队现在面临的最大挑战是什么？你为什么加入，又是什么让你留下来？在这里工作有什么可能会让我意外的事？最后一个问题，是在礼貌地请对方提前把눈치告诉你。如果对方在人员流动或公司方向的问题上含糊其辞，这本身就说明了很多。

如果你要招外籍开发者

#

如果你在韩国带团队，准备招一个从别的地方来的开发者，最有用的一件事就是那篇团队规范文章里的一句话：把隐性的东西变成显性的。别让他们把你的规矩当民间故事去学。第一周就告诉他们：评审一般多久回、「完成」指什么、催第二次算不算没礼貌、大家实际几点下班、休假除了填表还有没有别的讲究。最后两条是典型的눈치问题，团队里的人连想都不会想到要说。

之后就是一些让人少猜一点的无聊习惯。在别人问之前先说：周五给相关人员发一封三行的邮件（这周上线了什么、接下来做什么、有什么担心的），只要十分钟。会上别等安静的人开口，直接去问他们。给真正的答复，包括「不行」，并且附上理由。还有，用同样的问题、同样的评分标准面试每一个候选人。这一条我花了些时间才学会，但这是公平比较人的唯一办法，否则你会偏向最近聊过的那个人。这也意味着，不懂你团队潜规则的候选人，和懂的人被问到的问题一模一样。

这里的新西兰社群

#

2018 年我还是学生的时候，在 Kiwi Chamber 的一场领导力早餐会上负责拍照，事后写道，我非常喜欢为促进两国关系的活动做志愿者。2020 年 1 月起，我担任 Kiwi Alumni 的主席。这是一个面向在韩新西兰人，以及在新西兰读过书、如今在韩国生活工作的人的社群。这是志愿职位，大部分是和人打交道的工作：组织活动，和新西兰驻韩大使馆及各教育机构建立关系，还有一些不起眼的活儿，比如新 logo，比如一个会员真能找到东西的网站。2023 年我们和大使馆一起办了 Kiwi Alumni Night，还上了 KTV。

那晚之后我写下的一句话，最接近这篇文章的主旨：在韩国和新西兰都生活过的人，知道怎么在两者之间架桥，因为两种文化他们都经历过。如果你来韩国工作，不管你来自哪里，去找这样的人。他们会用大白话告诉你，那个场合到底在说什么。

在首尔做自由职业

#

辞掉经理的工作后，我在 2025 年 10 月开始做自由职业。实际做的是合同制的 DevOps 和 MLOps 工作，大多是本地部署：先搭了一个高可用 PostgreSQL 集群，然后在同一批硬件上搭 LLM 推理服务。做下来发现，质量把控比铺管道多：盯着 trace 和多轮对话，找模型输出从哪里开始跑偏。2026 年 2 月起，我还在另外做一款自己的集市加社区应用。

做自由职业并不能让你摆脱눈치，只是换了要读的对象。不管到哪个团队，我最先看的都是监控，因为它比 README 更能说明一个团队。这算是对系统用的눈치：读的不是团队说自己在做什么，而是它实际在做什么。

想对考虑来韩国的人说的话

#

1. 从一扇能让人在招你之前先看到你干活的门进来。我走的是读研这条路。黑客松、小公司的实习，或者你自己国家在这里的社群，作用都一样；而在社群里，你能找到两边都生活过的人。
2. 别把小公司排除在外，我职业生涯的大部分时间都在小公司。十个人的公司里，没人可以让你把无聊的活儿推给他，而你做的东西真的会上线。
3. 加入之前先读懂团队。用好咖啡聊天，问问在这里工作有什么会让你意外的事，对方在人员流动上含糊其辞，要当回事。
4. 别等别人来问。估算要延期、改动有风险、别人在等你做决定：先说，用文字说。
5. 把没写下来的规矩大声问出来：评审多久回、「完成」指什么、催第二次算不算没礼貌。如果没人写下来，主动提出你来写。
6. 学会你技术栈周边的那一圈。在这里，Naver 和 Kakao 的重要性，是你的 Google 习惯覆盖不到的。

工程是你来之前就能准备的那一半。눈치是你在工作中才学得会的另一半，而我知道的最快的学法，是请别人把没说出口的那部分说出来，并且自己先说。

最近常想起这件事，因为我自己也开始带项目了，那种想蒙混过去的冲动是真实存在的。开会时被问到一个问题，五个人等着你的答案，这时候说"我不知道"感觉像认输。其实不是。多数时候，这恰恰是最有底气的一步棋，前提是后面跟上下一步：去问谁，或者什么时候给答复。

装懂迟早穿帮

#

软件这行变化太快，没有谁能把所有东西都装进脑子里。而工程师对装懂的嗅觉出奇地灵。只要被团队抓到一次不懂装懂，之后你说的每一句话都会被暗暗打折扣。反过来，一个承认自己有盲区、然后老老实实去补上的管理者，说出来的答案大家反而信——因为大家分得清什么是真答案。

“我不知道"是起点，不是终点

#

关键在后面那半句。说完"我不知道"就没了下文，那叫甩手。好的管理者会接着问出更好的问题——“和我们现在用的方案比怎么样？““如果这个假设错了，会坏在哪里？"——然后把问题抛给对的人。每个团队里都有那种几乎住在数据库里的人，或者把前端所有恶心的边界情况都摸透的人。你不需要什么都懂，你需要知道谁懂，并且真的去问。

职场上怎么说"我不知道"才不显得没准备

#

我给自己定的规矩是：别让"我不知道"成为一句话的结尾。下面几种说法，都是真能说出口的：

• “这个我暂时不清楚，周四之前我查清楚给你答复。”
• “这块小李比我熟，我们直接拉他问一下。”
• “我没有十足的把握，倾向于是 X，但拍板之前我想先确认一下 Y。”
• “具体数字我手上没有，会后我发到群里。”
• “这个我还没仔细研究过，不想瞎猜，明天给你准话。”

说"我不知道"算不算不礼貌？只要带着下一步，就不算。真正让人不舒服的，是一句"不清楚"之后就没了下文，或者一个信心满满、事后发现是编出来的答案。面试也是一样：不知道就直说，然后讲讲你会怎么去弄清楚。这比硬猜一个答案更能让面试官看清你。

决策质量会变好

#

软件领域的决策往往影响深远，所以值得诚实地区分"哪些我有把握，哪些是在猜”。提前承认自己的盲区，就能在拍板之前而不是之后把缺的信息补齐，也让持反对意见的人敢开口——而那恰恰是你最需要听到的声音。定了就把理由讲清楚；错了就认。没有什么比一个不肯认错的管理者更能扼杀团队的坦诚。

这些道理一点都不复杂：多问，多听比你懂的人讲（永远有人比你懂），在猜的时候承认自己在猜。“我不知道，但我们一起查查"这句话给我攒下的信用，比任何一次蒙混过关的回答都多。

为什么我的默认仍然是公开

#

支持透明的那些老话都是真的，我一条条见过它们应验。人们理解了决定背后的理由，就会信任这个决定，哪怕并不喜欢它。大家掌握的信息和我一样多，就能不等我拍板自己做出好的判断。还有，一件影响到自己的事，居然是最后才知道的——没有人受得了这个。

原始信息直接倒出去，会坏在哪

#

主要是三种情况。

数量。连半成品的进展都一股脑转发，真正重要的事就被淹没了，大家很快学会充耳不闻。

背景。没有来龙去脉的原始信息只会制造混乱。“我们在重新评估路线图"这句话，带着解释是普通通报，不带解释就吓人得多。

时机。事情还没定就说出去，团队会花一个星期去猜测那些根本不在讨论范围内的结果。半生不熟的消息，耗掉的精力常常比最终决定本身还多。

等一等不等于藏着掖着

#

挑时机说话，听起来像在算计人。但只要动机是诚实的，效果恰恰相反：这是在保证消息送到时，带着足够让人理解它的背景。坏消息附上应对方案，落地就轻一些；好消息不埋在周五下午的通知堆里，才能真正被听见。

不过等待是有代价的，而且代价会滚雪球。信息捂得太久，大家能感觉出来。你留下的真空会被小道消息填满，而小道消息永远比现实更糟。还有，如果某个人总是最后一个知道，他会把这当成对自己分量的评价。这也怪不得他——通常确实就是。

我现在的判断方法

#

在分享（或者暂时压下）敏感消息之前，我会问自己几个问题。团队需要这个信息来干活，还是我只是想一吐为快？背景我现在能讲清楚吗，还是只能扔出去一堆碎片？这消息大概会怎么落地——那些显而易见的追问，我有答案吗？

之后不管怎么选，做法是一样的：信息和背景一起给；让大家事后方便提问；留意这次的反应，好让下一次的判断更准。每个人想要的信息量不一样，这只能靠观察和多问才能摸清。

默认公开，附上背景，按下发送之前花一分钟想想它会怎么落地。到目前为止，我遇到的情况基本都能用这三条应付。

这条线我是自己摸出来的。我不是科班出身的管理者，只是一个写着写着代码就开始带项目团队的开发者，所以下面这些，基本都是先犯过一点小错才学会的。

领导力中的同理心是什么意思

#

领导力中的同理心，是弄清楚团队里每个人的真实状态，并在做决定、给反馈、定团队工作方式的时候，把它当作一个有分量的变量。它不是什么都点头，也不是在会议上表现得和气：你完全可以充分理解一个人的处境，同时对他说不。当人们发现自己的处境真的被考虑进去了，就会放松下来，更早开口说话，工作也明显更顺。这一点上，那些老生常谈的建议是对的。

太少是病，太多也是病

#

所有人都在警告的失败，是那种把人当资源调度的冷面管理者。这种失败是真的：无视别人生活里正在发生的事，人就会沉默，士气会掉，问题要拖好几个月才浮出水面。

没有人警告你的，是反方向的失败。什么都迁就，边界就模糊了。截止日期变成参考意见。那些默默守着标准的人，开始为不被要求守标准的人兜底，怨气悄悄积累。我自己就干过这种事——当时觉得是体贴，多让了一步，可对团队里其他人来说，那一点都不体贴。

同理心的正反例子：做得好与做过头

#

放在一起对比，差别就清楚了。这些算不上规则，只是我努力想做到的样子：

做过头的那一栏有个共同点：当下感觉很体贴，实际上是把代价推给了以后，或者推给了别人。

大部分活儿是一对一沟通干的

#

我能勉强保持在平衡点附近，靠的不是什么理念，是日历上的一个循环日程。有了固定的一对一，小问题就会在还小的时候冒出来，而不是某天以一封辞职信的形式集中送达。

我的一对一每次问的差不多是同几件事：现在卡在哪，最近什么事做得不错，团队配合怎么样，接下来想往哪个方向成长，以及我有什么该改的。

最管用的问题特别朴素：“工作上有什么需要我或者团队帮忙的吗？“听着平淡，其实不然。它传递的信号是：我打算参与解决，而不是只听你说。而且得到的回答几乎总是能实际落实的具体事——帮忙对接某个人、拍板一个悬着的决定、抽一小时结对。

说"不"的时候更要坦诚

#

一对一聊多了，请求自然会攒起来，不可能都答应。怎么处理那些答应不了的，恰恰是信任建立或崩塌的地方。

我的做法是：认真对待请求，并且让对方知道我认真对待了；解释现在为什么办不到；有折中方案就给折中方案；说清楚什么时候再看这件事；然后真的回来再谈，哪怕结论没变。

这些做法不会让拒绝变得愉快。但一句有理由的、坦率的"不行”，远比一句再也没有下文的"再看看"更让人服气。

我能总结出的公式也就这么多：真心在意大家的状态，对工作的要求实话实说，然后保持足够频繁的沟通，好在自己偏向任何一边太远的时候，能及时发现。

我做过的项目里，最慢的从来不是代码，而是排队：一堆决策堵在某位经理的日程表前面，等一个三天后才到的点头。异步沟通和自主团队是标准解法，我也是信徒，但这场转变的本质，是一个披着工具外衣的信任问题。

为什么会变成事事签字

#

审批文化从哪来，值得公道地看一看。控制给人一种精确的错觉——每个决定都过经理的桌子，就好像什么都不会跑偏。一个错误决定不光砸项目，还砸经理本人的名声，所以恐惧出了大力。有时也确实是真心怀疑团队有没有足够的经验做判断。还有的时候纯粹是惯性：组织架构一直这么运转，于是继续这么运转。

注意，这四个原因里只有一个真的和团队有关，剩下的全是经理自己的事。

自主真正需要什么

#

没有对齐的自主，只是士气高昂的混乱。如果大家真的理解目标，各自独立做的决定大体会指向同一个方向——诀窍其实就这一条。培训也重要，因为一个装备齐全的人，比一个只有热情的人更容易被信任。边界要留着：确实有些决策应该留在管理层手里，把是哪些说出口，能避免最糟糕的意外。之后就让反馈循环转起来，把免不了的错误当学费，而不是当罪证。

如果信任已经受损——从审批文化里爬出来的团队，通常双向都受了损——那就没有捷径。开诚布公地把问题摆到桌面上，管理层先认下自己那份错，然后连续几个月无聊地保持言行一致。明确的分工和固定的沟通节奏，比任何轰轰烈烈的姿态都更能修复关系。

异步反而是容易的部分

#

工具的事三句话说完：Slack 或 Microsoft Teams 都够用。真正的功夫在文档——没人在同一间屋、同一个时区时，写下来的决定就是团队的记忆。定好响应规范，别让异步悄悄变成没人理；“一天之内”胜过“看情况”，这些规范应该和“谁收哪种更新”一起写进团队的沟通计划。另外要真的教大家写像样的异步更新：够做判断的上下文、需要的决定、截止时间。这个技能不是天生的。比如这样：

周四前需要拍板：支付重试
现在银行卡支付失败后，只会在 24 小时后重试一次；“我的订单怎么还没好？”已经成了最常见的客服咨询。
方案 A：24 小时内重试三次（大约半天工作量）。方案 B：维持现状，改为发邮件通知用户。
我建议选 A，细节和数据在附上的文档里。
如果周四下午 5 点前没人反对，我就按 A 开始做。

这样一条消息，早上 7 点看也好，晚上 11 点看也好，不管在哪个时区，都能不开会直接回复。

装一个 Slack 只要一下午。信任要花好几个月，而决定这一切成败的恰恰是信任。把目标讲清楚，让犯错的代价是一堂课而不是一份职业——做到这两点，异步那部分多半会自己长好。

我被拉去救火的那些项目，烂摊子多半不是烂代码造成的，而是该知道的信息没能及时传到该知道的人那里。在公司开始带项目之后，我一直在记笔记：如果哪天坐上CTO的位置，沟通该怎么管。这里整理出来。

先定好谁需要知道什么

#

不起眼但打底的东西是沟通计划：谁需要被告知、需要什么信息、多久一次、走哪个渠道。每个项目开始时就该定下来，而且要落到具体人头上——沟通一旦成了"大家的事"，就成了没人管的事。利益相关方也一样：理清谁真正关心这个项目，摸清每个人喜欢的汇报方式。发给CEO的更新，不能跟发到开发频道的一模一样。再定几条明文规则：多久之内该回复、什么算紧急、哪个渠道干什么用。所谓"沟通问题"，多半只是没说出口的期待对不上。

一份软件项目的沟通计划示例

#

这是我会先拿来用、再按项目调整的版本。每一行是一类受众，不是一场会议：

表格下面写规则，越直白越好：紧急指的是挡住了发版或者影响到客户，这时候直接打电话，别发消息；问题在聊天里问，决定记进任务跟踪系统；一个工作日内回复。决策日志我用的是决策文档，以GitHub Issues的形式保存，跟具体的工作放在一起。

这种计划能不能转起来，关键在两点：每一行的最后一列都写着一个具体的人；给管理层的更新是写下来的，不是口头说的，这样转发出去也不会丢信息。

工具和节奏

#

工具没有大家争论的那么重要。聊天用Slack，任务用Trello，需要见面聊就开Zoom——选个适合团队的，赶紧翻篇。更要紧的是节奏：敏捷团队就每日站会，周期长的项目就每周同步，然后真的坚持下去。还有，把东西写下来。决定、变更、待办事项，记进Notion或Jira，当成流程的一部分，而不是事后补的作业。半年之后，大家唯一的记忆就是那份文档。

软的部分才是硬骨头

#

上面说的都是机械层面。更难的在后头：问问团队现在的沟通方式到底管不管用，不管用就改。还有培养人——团队成员背景各异，有的人还没见过一个运转良好的项目长什么样。认真听别人说话，而不是等着轮到自己说；冲突要趁小趁早处理。而且这些问题解决一次不算完，上个季度好使的办法会悄悄失灵，只能定期回头检查。

分布式、异步开发团队怎么协作

#

如果你的团队是远程或以异步为主，这个演讲值得一看：

这些我自己也没全做到——没人能全做到。但回头看，进展顺利的项目大都占齐了这几条，而让人头疼的项目至少缺了三条。

这是简短版。下面是详细版，因为反馈谈崩的方式在我这儿几乎每次都一样，次数多到我都不太好意思承认：我刚指出一个问题，对方肩膀一紧，从那一刻起，我们俩谁都没在真正听对方说话。

人为什么会起防御心

#

防御不是固执，至少一开始很少是。人感到受威胁时就会这样，而反馈带来的威胁感，比我们通常以为的要大。表面上你在聊一个 PR，或者一个没赶上的截止日期。对方听到的却是：我到底能不能胜任这份工作？我在这个团队里还有没有位置？你是不是憋了好几个月，一直这么想？

人一旦有了这种感觉，注意力就全拿去保护自己了，顾不上你要说的重点。你越使劲争，越坐实了那份威胁。所以下面那些管用的做法，大部分都是先把气氛里的风险感降下来，然后才谈正事。

还有一点值得记住：有些人进这种谈话的时候，身上本来就带着伤。以前的上司只在批评时才开口，或者待过的地方犯一次错就会被边缘化。这些过去你没法在一次谈话里抹平，但它能解释为什么一句挺温和的话，有时会换来大得多的反应。

谈之前

#

大多数反馈谈话，在开始之前结果就已经定了。下面几件事，是我现在会做、以前不会做的。

我只挑一件事。如果我攒了五个问题一起说，对方听到的是一场审判，不是反馈。另外四个可以等等，而且到头来往往只是第一个问题的症状。

我尽快谈。六周前的事现在才拿出来说，对方心里想的是“那你怎么现在才告诉我？”。问得合理，而且我没什么好答的。事情过去一两天正合适：够新鲜，又不至于两个人都还在气头上。

我私下谈，而且能不用聊天工具就不用。文字会丢掉语气，一个本来就戒备的人读的时候，会用最坏的版本把缺掉的语气补上。如果因为团队远程或者有时差只能写，我就写短一点，再问对方要不要打个电话。

还有，我会先看看自己的状态。我要是心里有气，不管措辞多讲究，对方第一句话就能感觉出来。我给过的一些反馈，要是等自己不烦了再说，效果会好得多。

具体怎么说

#

我反复用回去的结构，通常叫“情境、行为、影响”（SBI）：什么时候发生的，对方做了什么，造成了什么结果。关键在于每一部分都是看得见的。里面没有一句在说这个人是什么样的人，只说发生了什么。

举个实际的例子。假设一位开发者周五下午没等代码审查就合并了一个改动，结果周末结账功能挂了。

让人立刻竖起防线的说法：“你总是急着上线。你得更仔细一点。”

还有机会谈下去的说法：“周五那个支付的改动没经过审查就合进去了，周六结账挂了好几个小时。我想弄清楚是怎么回事，因为我不觉得是你粗心。”

第二种只讲了一件事，直白地说出了代价，最后还默认对方是出于好意。杀伤力最大的就是“总是”和“从来不”这类词。它们把一次事故变成了对人品的判决，而对方会马上想到一个反例来证明你错了。

我也会尽量把观察说成是我自己的。“我注意到”“我有点担心”，老老实实表明这是我的看法，是从我这边说出来的，也给我留了看漏什么的余地。而我常常确实看漏了。

然后我就闭嘴，问一句：“从你那边看是什么情况？”通常会有我不知道的背景，比如死线是别人定的，或者负责审查的人正好请了病假。就算没有，这一问也在告诉对方：这是一场对话，不是一份判决。

反馈附上一条出路，也会好接受得多。不是一串问题清单，而是“下次我们能不能……”。要是这条出路是对方自己提出来的，就更好了。

对方还是反驳了怎么办

#

你可以每一步都做对，照样遇到抵触。抵触通常有几种认得出来的样子，每种都要稍微换个应对方式。

最常见的是否认：“事情不是这样的。”别争。回到两个人都看得见的东西上，比如那次提交、那条消息、那个日期，然后问问自己漏了什么。如果事实真有争议，说一句“我们都再看看，明天接着聊”完全没问题。

然后是转移话题：“需求一直在变啊”，或者“某某也这么干”。这里面常常有几分道理，所以别一口否定，先认下来：“这话没错，需求的问题我们也得解决。”再轻轻拉回来：“这个先放一边，我想聊聊审查这一步。”

反击，比如“你自己不也经常不走审查就合代码”，是最难忍住不回嘴的一种。先深呼吸。如果对方说得对，就承认，这是让气氛降温最快的办法，而且你正好示范了你希望对方拿出的那种开放态度。然后再回到原来的话题。

把自己关起来，不管是沉默，还是一句“行，你说了算”，看起来像同意，其实不是。我会轻轻点出来，比如“看起来这话你听着不太舒服，这没关系”，然后提出改天再接着聊。逼一个已经缩回去的人表态，你只会得到一个假的回应。

过度道歉（“我太差劲了，真的对不起”）也是一种防御，只不过矛头朝向了自己。对方抢先把批评说出口，以此保护自己。告诉对方这只是一件具体的事，不是对他整体表现的评价，然后把话题转到接下来怎么做。

不管遇到哪一种，我都尽量守住一条：别跟着对方的情绪走。对方一防御，我的本能也是马上防御回去，而这一招保证能把谈话搞砸。只要我稳得住，气氛通常会自己降下来。把感受直接说出来也有用，比如“我知道这话听着挺憋屈的”，总比假装屋里没有火药味强。

知道什么时候该停

#

有时候这些都不管用，墙就是不倒。这时候再使劲毫无意义。把话题先放一放，过一两天等情绪落定再谈就行。反馈说的事到明天也还成立，而且人睡过一晚之后，往往冷静得多，也更愿意反思。我经历过的几次最好的后续谈话，都是对方先开口：“你上次说的，我想了想。”

这一条，我学得最慢。

谈完之后

#

接下来一周发生的事，和谈话本身一样重要。如果对方改了，就说你注意到了，要明明白白地说，而且要尽快说。这样对方才知道，从你这儿来的反馈不全是坏消息，下一次谈话也会容易些。

合适的时候，也可以问问对方，这次反馈听着怎么样。一句“我这么说公平吗？”能让对话更对等，也把你希望对方拿出的开放态度先做给对方看。我转去做管理之后，开始习惯性地这么问，有那么几次，正是这一问让我发现：我脑子里想得清清楚楚，说出口却没讲明白。

简单来说

#

先把威胁感降下来，再谈问题。一次只挑一件事，私下谈、尽快谈，讲行为和影响，不评价人，提出解决办法之前先听听对方的说法。对方反驳时，别跟着加码。承认情绪，回到事实，也愿意先停下、改天再谈。之后记得跟进，因为信任恰恰是在那场谈话之后的谈话里建立起来的。