|
| 1 | +#+TITLE: 读:一篇 1:1 会议实操手册 |
| 2 | +#+AUTHOR: lujun9972,Claude Code |
| 3 | +#+TAGS: 管理, 1:1, 团队 |
| 4 | +#+DATE: [2026-05-28 Wed] |
| 5 | +#+LANGUAGE: zh-CN |
| 6 | +#+OPTIONS: H:6 num:nil toc:t \n:nil ::t |:t ^:nil -:nil f:t *:t <:nil |
| 7 | +#+DESCRIPTION: 1:1 会议不是用来汇报进度的。这篇实操手册将 1:1 拆解为输入(准备)、处理(执行)、输出(跟进)、监控(反模式)四个环节,每个环节给出具体可操作的做法。 |
| 8 | + |
| 9 | +Ben Balter 在《[[https://ben.balter.com/2026/04/27/one-on-one-playbook/][How to one-on-one]]》里说,把 1:1 会议当成一个系统来对待,度量它,迭代它。我觉得这个类比非常好,我们可以把1:1会议分成输入、处理、输出、监控四个环节。输入是你会前准备了什么,处理是会上的对话质量,输出是会后的 action items,监控就是那些反复出现的反模式,它们是你 1:1 系统的告警信号。 |
| 10 | + |
| 11 | +* 1:1 应该聊什么 |
| 12 | + |
| 13 | +如果你在 1:1 会议里听到的是"修了三个 bug、review 了两个 PR、迁移文档写了一半",这个会基本白开了。这些事情应该写在文档里,不是拿来占用你们唯一能同步对话的三十分钟。 |
| 14 | + |
| 15 | +1:1 的时间只该花在必须当面聊的事情上。Ben Balter 归纳了五类。 |
| 16 | + |
| 17 | +1. 职业发展和成长。一年后你想在什么位置?想发展什么技能?这类问题需要来回试探,捕捉对方没直接说出口的东西,没法写成 issue comment。 |
| 18 | + |
| 19 | +2. 辅导和问题拆解。遇到了人际困境不知道怎么开口、面临一个没有标准答案的决策、卡在某个技术方案上反复纠结,了解你处境的人陪你聊,比自己闷头想要快得多。 |
| 20 | + |
| 21 | +3. 反馈和校准。反馈这件事,书面和当面完全两回事。书面反馈容易被读成指责,当面说可以看反应、立刻澄清,是一种对话而不是判决。 |
| 22 | + |
| 23 | +4. 交际。远程工作之后,人和人之间容易只剩下工作交接。1:1 是少数可以自然而然进行人情交际的场景。 |
| 24 | + |
| 25 | +5. 倾述。如果难言之隐,1:1 很好的倾述场景。 |
| 26 | + |
| 27 | +反过来,状态更新、信息传达、审批请求,这些东西不该出现在 1:1 里。你上周做了什么,上级应该在会前就知道,不是会上才听说。审批的事发消息或邮件就行。开会的时间用来讨论做这些事意味着什么、接下来怎么办,不是复读已经发生的事。 |
| 28 | + |
| 29 | +* 输入:会前准备 |
| 30 | + |
| 31 | +好的 1:1 会议在正式沟通之前就开始了。 |
| 32 | + |
| 33 | +在会议前维护一份共享议程,在线文档、共享笔记,什么都行,双方随时往上加东西。中途想到有什么该聊的话题立刻记上去,否则很可能会忘掉。 |
| 34 | + |
| 35 | +每个议题都要很清晰。不要只写"职业发展",要写"我在纠结是走技术专家路线还是管理路线,想聊聊两种方向的取舍"。然后对议题进行排序,你不必每周把所有东西聊一遍。如果某个话题连续几周被跳过,那它可能没你想的那么重要。 |
| 36 | + |
| 37 | +检验标准很简单,假设这会取消了,你会损失什么?如果答案是"没什么",要么是你准备不够,要么这个话题本身不适合实时讨论。 |
| 38 | + |
| 39 | +我的习惯是用 Org-mode 给每人维护一个文件,以日期倒序记录每次 1:1 的议程和结论。开会前看一眼上次的 action items,直接贴到本次议程里。 |
| 40 | + |
| 41 | +* 处理:会上怎么主持 |
| 42 | + |
| 43 | +先聊人,再聊事。开头花几分钟问一下近况。这是在建立关系,让后面的困难对话有信任基础。不是没营养的寒暄。 |
| 44 | + |
| 45 | +多问少答,尤其对上级来说。你的任务不是解决每一个问题,是帮对方自己想清楚。"你在考虑哪些方案?"通常比"你应该这么做"更有用。对不带人的一线同事来说也一样,不要等着被安排,挑战假设、表达不同意见。 |
| 46 | + |
| 47 | +跟着议程走,但不被它绑死。如果一个话题引出了更重要的对话,就顺着走下去,其他的可以下次再聊。 |
| 48 | + |
| 49 | +给没说出的话留空间。议程上最重要的东西往往根本没写上去,因为难开口或者觉得说了有风险。你自己先提一些不太好聊的话题,给别人开口的安全感。 |
| 50 | + |
| 51 | +结束时落到具体行动。这次聊出了什么?谁做什么?什么时候做?记在一个不会被忘掉的地方。 |
| 52 | + |
| 53 | +* 监控:四种反模式 |
| 54 | + |
| 55 | +如果把 1:1 当一个系统,下面四种情况就是告警信号,出现任何一种都说明有问题。 |
| 56 | + |
| 57 | +1. 言之无物。双方都没准备,没有议程,三十分钟在闲扯中过去。如果你们真的没东西可聊,要么一切运转得太好,要么有什么东西一直被回避,你得搞清楚是哪个。 |
| 58 | + |
| 59 | +2. 连续推迟。"这周太忙了,下次吧",连续三次。信号很明确,这段关系在你的优先级里排不上号。对团队来说尤其致命,因为本来就缺少走廊里碰面那种非正式连接。 |
| 60 | + |
| 61 | +3. 独角戏。上级一个人从头讲到尾,分享信息、给建议、自言自语。1:1 是对话,不是发布会。 |
| 62 | + |
| 63 | +4. 变成汇报。整场会变成了下属向上级汇报工作。你应该换一种方式了解这些信息,而不是占用你们唯一的同步时间。 |
| 64 | + |
| 65 | +* 输出:会后跟进 |
| 66 | + |
| 67 | +没有 action items 的 1:1 像没有测试的代码,当时感觉良好,但没人知道它到底有没有效果。 |
| 68 | + |
| 69 | +每次 1:1 结束后,把结论和待办记在共享文档里。下次开会前过一遍,上次定的行动完成了吗?没完成的话,障碍在哪? |
| 70 | + |
| 71 | +* 结语 |
| 72 | + |
| 73 | +你怎么开 1:1,就是你管理风格的缩影。共享议程、记录结论、提前准备,每一个让 1:1 变好的做法,也是让分布式团队运转的做法。 |
| 74 | + |
| 75 | +把 1:1 当成一个系统来对待,定好输入、关注处理质量、记录输出、监控告警信号,然后持续迭代。 |
0 commit comments