Skip to content

Commit 96237f1

Browse files
lujun9972claude
andcommitted
blog: 读:一篇 1:1 会议实操手册
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 parent 239563c commit 96237f1

1 file changed

Lines changed: 75 additions & 0 deletions

File tree

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
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

Comments
 (0)