看当前什么样，你看到的是 bug 率 2%、迭代按时交付率 90%。这些数字告诉你团队现在在哪。有用，但不够。

看变了什么，你看到的是这个月方案评审时提反对意见的次数比上个月少了一半、最近三次线上事故的复盘比以前短了很多。这些变化告诉你团队正在往哪个方向走。

打个比方。看当前什么样，就像看一张团队的照片，大家站好、微笑、看起来挺好。看变了什么，就像把上个月的照片和这个月的照片摆在一起对比，你会发现有人站位从中间挪到了边上，有人笑容跟上次不一样了。照片对比才是发现问题的方式。单看一张照片什么都看不出来。

数字也一样。bug 率 2% 可能是团队质量一直很稳，也可能是没人敢报 bug 了。你不知道，除非你看趋势。反过来也一样，某个迭代没按时交付，可能不是退步，而是团队终于不再硬着头皮承诺不切实际的日期了。

作者给了一组例子，我挑几个加上解释。

决策时间在变长。一个方案讨论了两周还没定，以前三天就定了。代码评审（code review）变成了走形式，以前同事会在 review 里追问「这个边界条件你考虑了吗」，现在看到的全是「好的，没问题」。什么事都默认找同一个人，需求确认找他、技术选型找他、连部署出问题也找他，这不是他能力强，是其他人开始不担责了。同意很快，认账很少，会上大家都说好，会后没人动手。线上出个小问题，以前没人当回事，喝杯水回来看一眼就处理了，现在一个小问题能让好几个人焦虑一整天，不是环境变脆弱了，是团队对风险的承受力在变差。方案讨论的时候提不出替代方案了，不是方案完美到不需要替代方案，是不想提了，或者提了也没用所以不费那个力气了。新人问问题的次数在下降，犯的初级错误却在增加，不是因为新人变笨了，是不敢问，或者问了没人认真答。群里越来越安静，连需求评审会上都没人怼产品经理了，不是产品经理进步了，是大家懒得争了。

单拎任何一条都不等于出问题。一个同事这周在 review 里少写了几句评论，可能只是这周太忙。但如果连续三周都是「好的，没问题」，那你就该注意了。

看到一个变化之后，你的大脑会自动给它补原因。这不是你的性格问题，是人脑的工作方式，看到一个现象立刻补一个因果。远古时期靠这个能力判断草丛里的动静是不是老虎，活下来了。但管理团队靠这个能力会出事。

你注意到有个同事最近在设计方案讨论上不怎么说话了。这是你观察到的事实。到此为止你的大脑应该停下来。但它不会。它会在你没意识到的时候自动补上一句「他不积极了」「他对当前方向不满」「他在准备跳槽」。

如果你带着大脑自动补上的这个判断去跟他聊，你就不是在了解情况，你是在验证你的猜测。对方听完第一句话就知道你想说什么，后面你说什么都晚了。

换个聊法。「我注意到你最近几次方案讨论没说太多话，是有什么原因吗？」这不是话术，是顺序问题。先讲你观察到的事实，再问他的原因。这个顺序决定了你得到的是解释还是防御。

更关键的是，你的身份变了。你是组长。你说了一句「他不积极了」，下周再看他的时候就会带上有色眼镜。他发现你开始区别对待了，就更不说话了。你的判断从一开始就制造了你想解决的问题。

每个刚从技术转管理的人都经历过这种事，区别只是你意识到了没。

你是做技术出身的，git 你天天用。下面这套方法刚好能搬过来。

git 能做 diff，是因为你第一次 commit 的时候有了一个初始状态。管理上没有自动 commit，你得手动建。方法很简单，每月记三五句话的团队笔记，只给自己看。

💡 小贴士：怎么写团队笔记（5W1H）

Why / 为什么记： 没有基线就没法做 diff。git 知道你改了什么是因为它记住了上一次 commit 的样子。管理上没有自动 commit，只能手动建。

Who / 谁来记、给谁看： 你自己记，只给自己看。不是周报，不用发给任何人。一旦有了"要给人看"的心理负担，你就会开始加工。

What / 记什么：

• 这个月有什么决策卡了很久才定下来？
• 有什么工作不是计划内的，但消耗了大家大量时间？
• 有没有哪个模块或哪种问题反复出现？
• 有没有意料之外的事？
• 团队人员的状态有什么变化？

When / 什么时候记、记多少： 每月一次，月底最后一个周五下午花十分钟。三五句话就够，不用写多。刚开始记不出什么很正常，坚持三个月就有对比价值了。

Where / 记在哪： 文本文件、备忘录、钉钉文档、纸质笔记本，随便。挑一个你最顺手、打开成本最低的工具。

How / 怎么记： 不加工，看到什么写什么。别往上加「可能的原因是」，别加「团队积极性下降了」这种判断句。就写事实。

比如三月份的笔记长这样，

• 支付模块的迭代在评审阶段卡了两个星期，最后用了方案 B
• 这次需求评审大家都很快同意，没人提反对意见
• 小李连续两周加班处理线上工单
• 月底突然接到合规需求，打断了所有排期

翻出上个月的笔记，对比当前，什么跟之前不一样了？变化藏在日常工作里。翻一下最近几周的代码 review 记录，看看评论的平均长度有没有变短。翻一下线上事故的复盘文档，看看篇幅跟以前比有没有缩水。下次方案讨论的时候数一下，除了你之外还有没有第二个人提替代方案。新人入职一个月后去问他一句「有没有你想问但不好意思问的事」。一条一条对比，标出跟之前不一样的。

记差异的时候也有坑。别写「这个月代码质量在下降」，这不是事实，是你的推测。写你实际看到的：「这个月 review 记录里，超过五行的评论只有两条，上个月有十一条。」你大脑补上的「质量下降」可能是对的，也可能是错的，比如实际情况是需求太急，大家 review 的时间不够。只有事实才能回头验证，推测不行。

不要一看到几条差异就慌了，列出十项改进计划全面排查。人会累死，团队也被你折腾废。挑一个你觉得最值得关注的信号，去找当事人了解一下情况。

怎么聊？日常碰到的时候随口问一句就行。「我注意到最近几次线上出问题，大家的反应比以前紧张了不少，以前喝口水回来就处理了，现在能焦虑一下午。你觉得是为什么？」这句话里，「最近几次线上问题的反应比以前紧张」是事实，「你觉得是为什么」是把解释的空间给对方。

听完了之后，结合自己的判断，决定这事儿需要行动、还是继续观察、还是只需要你说一句「我知道了」。

假设你记了三个月团队笔记，今天翻回去看，发现一个变化。

二月，每次方案评审至少有两个人会提替代方案。三月，开始有人说「没意见，挺好的」。四月，三次评审没人提替代方案了。

这是你的 diff。

把事实和解读分开。事实很简单，替代方案的次数从有到零。解读呢？可能是方案质量确实高了？不太像，这几个方案的复杂度和之前没区别。可能是团队没想法了？也不是，私下聊天还是能听到有人提别的方向。我猜是有人之前提了替代方案被直接否了，之后没人想提了。

你选这条 diff 去了解。找你心里最先想到的那个同事，茶水间碰到的时候随口说一句，「我翻了翻这几个月的笔记，最近几次方案评审都没人提替代方案了，之前二月份还能有好几个，你怎么看？」

他可能说确实没争议，也可能说「上次我提了三个备选，老大说时间不够别想了，之后我就不在会议上费这个劲了」。不管哪种，你知道了。接下来要不要改什么、怎么改，是你的事，但至少你不是三个月后才从「迭代交付效率下降」这个数字发现问题。

这个习惯跟你的技术能力没关系，跟你的注意力有关系。你做技术的时候天天用 git status 和 git diff，status 告诉你工作区现在什么状态，diff 告诉你相对上次提交改了什么。管团队需要的也是同一个脑回路。看变化看起来是慢功夫，但它比看数字快得多。数字变了的时候问题已经大了，你能比数字更早知道。