测试管理不是只盯流程，先管人

上个月，一个带了三年团队的测试主管找我聊天，原话特别扎心：

> “流程我都梳理清楚了，缺陷率还是上不去。每天催进度、盯用例、追 Bug，感觉自己像个流程警察。关键是，团队里最能打的那个要走，我居然连留的底气都没有。”

我问他平时花多少时间跟人聊。他愣了几秒：基本没聊，事都堆着呢。

这不是他一个人的问题。过去两年我陆续接触过几十个从技术骨干转管理的中小团队负责人，绝大多数第一次摔大跟头，都不是因为流程设计不好，而是团队情绪崩了、骨干走了、新人不长、老人躺平，全是人的问题。

所以这篇文章想讲清楚一件事：测试管理，不是不盯流程，而是在流程跑起来之前，得先盯人。

一、先把结论说清楚：人没“对齐”，流程只会放大混乱

很多新晋管理者有一个默认逻辑：

> 团队产出不稳定 → 流程不够细 → 把流程拆到每一步都能追溯 → 质量自然可控。

这个逻辑在成熟团队、稳定业务上成立。但在大多数现实场景里，它忽略了一个致命前提：人愿意被流程管吗？人有动力把事情做好吗？

我观察到一种很有意思的反差：

• 把人当执行单元的团队，流程越做越重，Review 越来越正式，但线上事故并没有减少，因为没人愿意举手说“这里感觉不太对”。
• 先把人调动起来的团队，哪怕初期用例写得糙一点、回归做得手忙脚乱一点，但团队成员会主动补位。他们知道为什么测，知道漏出去会打谁的脸。

所以我的结论非常直接：测试管理的第一公里不是「定流程」，而是「搞定人」。 流程是骨架，但它是在血肉（人）长好之后才撑得起来的。

二、你面对的真实场景：光杆司令式的“非典型管理”

谈理论没意义，我们先讲多数人面对的真实处境。

一、你不是在管理一座工厂

国内大部分中小研发团队的测试，是这样的：

• 团队 3-8 个人，测试主管自己还要写用例、测核心模块、跟进生产回归；
• 招聘权限不在自己手里，人可能是抽调过来的，技术栈五花八门；
• 业务线多，迭代节奏一周一次甚至更短，“排计划”这件事本身就很奢侈。

这不是教科书里假设的“专业测试组织”，这是戴着镣铐跳舞的小规模作战单元。

在这种团队里，纯靠流程推动根本推不动，流程一细，反而变成“官僚主义”。你今天发一个《缺陷生命周期管理规范 V2.0》，明天连你自己都不一定想再打开。

这时候管人不是“高情商”的锦上添花，是生存必要。 你得靠几个关键的人帮你稳住，否则你连流程升级的窗口期都撑不到。

二、你最怕的不是“缺流程”，而是下面这些

上个月我在一个团队做了个匿名小调查，问他们今年以来最难受的时刻是什么：

• “我跟开发说这里有风险，开发不理我，主管也没撑我。”
• “线上出了事故，复盘时所有人都盯着测试为什么没测到，但需求变更根本没通知我们。”
• “组里老员工藏东西，新来的问他，他说‘看文档’，但文档是两年前的。”

这背后是什么？是人的信任、人的尊严、人的协作意愿。

流程解决不了这些。你把“需求变更必须抄送测试负责人”写进规范，不如那个开发的组长在群里回你一句“下次提前说”来得管用。

三、常见的致命误区：把“管人”当成软技能的空话

一说“先管人”，很多人脑子里蹦出来的是：要会说话、要情商高、要做团建。

这是最深的误解。

在实际测试团队管理中，“管人”不是抽象的领导力，而是一套可以拆解、可以执行、可以复盘的方法，就像写测试用例一样，有输入、有条件、有预期结果。

下面讲三个最典型的误区。

误区一：“管人是高层的事，基层主管先把事做好”

这句话半对半错。

对的地方是：基层确实不可能脱离具体事务。错的地方是：你以为你可以先不管人，实际上你每天都在影响人，区别只是你是在消耗人，还是在建设人。

一个用例评审会上，你把一个刚入职半年的组员的用例打回去三次，什么也没解释。你觉得你在管事、保质量。但在对方眼里，是你否定了他的能力，而且没给正反馈。

管理者不管人，但你的每一个动作已经在“管人”了，不过是管成了负资产。

误区二：“质量是流程的产物，管人不如定制度”

这是一个很隐蔽的陷阱。很长一段时间里我自己也掉进去过。

当时我带一个小团队，要求全员写详细测试分析报告，每周提交。结果是：两个老员工按时交，但质量是复制粘贴；一个新人拖了三天，交上来一堆空壳。

你说是制度不明确？我都发模板了。但问题在于：他们心里不觉得这个报告有用。

老员工觉得这是考核形式，新人觉得是额外负担。你在推流程的时候，人已经在暗地里抵抗。抵抗不是罢工，抵抗是“我做了，但我不负责”。

真正让我转变的是一个老员工离职前跟我说的：“你太信流程了，信到我们觉得你只在乎报告，不在乎我们怎么想。”

这话我记到现在。

误区三：“先用流程框住人，再去谈温度”

还是套用上面那句话的逻辑：流程框不住没被“激活”的人。

有团队试点强流程化，测试计划、测试方案、测试报告每一环都必须走审批。三个月后数据一拉：回归测试覆盖率反而下降了 6 个百分点。

复盘发现，大家把精力花在“填表”上，不再主动补充用例，因为表格里没要求的事，没人愿意多干。

人被框住之后，第一反应不是“更守规矩了”，而是“守规矩就好”，内驱力一熄火，质量和创新一起停摆。

四、我的判断逻辑：管事是抓手，管人是引擎

到这里必须给一个明确的专业判断，否则就是空辩论。

我总结了一句，后来反复用来提醒自己：

> 管事是抓手，管人是引擎；流程保下限，人决定上限。

具体怎么理解：

• 管事（流程、用例、缺陷、度量） 是你每天可以落地、可以度量的载体。你必须依赖这些抓手去推进工作、暴露问题。
• 管人（信任、动机、能力成长、协作关系） 是驱动这些抓手的底层力量。没有这一层，抓手只会抓空。

举个例子。

一个团队要引入自动化回归，这显然是一件“管事”的事：选工具、写脚本、搭 CI/CD、设覆盖率指标。

但如果你没搞定人，你会遇到什么？

选工具时谁都行，到写脚本时发现只有两个人愿意学，其他人推一下动一下；覆盖率指标报了 80%，但脚本质量极差，全是半真半假。

相反，如果把“人”先搞定，找到那个最有技术热情的人，让他负责技术选型和培训，争取给他一部分专用时间，并明确告诉他这是加分项，工具还是那些工具，流程还是那个流程，但整个推进速度和脚本质量完全不一样。

流程没有灵魂是废纸，而灵魂就是团队里每一个人的“我愿意”。

五、一个真实的对照案例

去年我见过两个规模接近的团队（各 6 人左右），做的是类似复杂度的 SaaS 产品。两个团队都在推测试左移。

团队 A（流程驱动）

• 测试经理定了《测试左移执行规范》，要求测试从需求评审开始介入，输出《可测试性评估表》。
• 实行两个月后：评估表是交了，但基本是“已评审，可测”这种套路化内容。
• 开发反馈：测试提的问题七成都是“这里要加个校验”，没前置风险意识。
• 负责人跟我吐槽：人不行，推不动。

团队 B（人先行）

• 测试经理没出任何正式规范，而是做了一件事：连续三个迭代，每周五下午开一次质量问题复盘会，不追责，只找根因。
• 会上让每个人任选一个线上问题，用 5 whys 追问到自己觉得“够深了”为止。
• 两个月后，团队自然形成了一批“需求阶段关键检查点”，是大家自发总结的，贴在白板上，比模板好用十倍。

结果： 团队 B 的线上缺陷逃逸率在三个迭代内下降了接近 12%，而团队 A 几乎没变化。

这不是说流程不重要，而是说 “人先理解为什么要做” 的效率，远高于“你规定他必须怎么做”。

六、不同情况下，怎么把“先管人”落下去

下面给一套可操作的步骤，按场景分类，别一上来就想搞全套，先从你最痛的地方切进去。

场景一：团队里有“情绪僵尸”，人还在，心死了

特征： 活也干，但不主动、不沟通、不反对、不支持，卡点到了就等你推。

行动建议：

1. 停止用流程加压。此时加流程只会加速死心。

2. 做一次不带绩效目的的 1-on-1。别问进度，问他最近哪个需求做得最烦、哪次上线最慌。

3. 找到他“还在乎什么”，可能是想学自动化，可能是想少背锅，可能是觉得工作没意思。你不需要承诺立刻解决，但必须让他知道你听到了。

场景二：新老断层，老员工藏手艺，新人靠猜

特征： 知识没有沉淀，老人不愿意带人，新人反复踩同一个坑。

行动建议：

1. 不要把“带人”写成 KPI，那会变成更隐蔽的应付。先找一个老人和一个新人，搭一个临时结对测试组，做一个短周期（一两周）的小模块。

2. 你亲自参与首轮结对，不是为了审他们，而是当“翻译”，把老人的经验转化成新人能理解的检查点。

3. 结项时公开肯定老人的贡献，让他的经验变成团队的公共资产。荣誉到位了，传承才不用逼。

场景三：骨干要走，裸辞信号已经出现

特征： 高强度但低满足感，开始沉默、迟到、请假频繁。

行动建议：

1. 立刻排查过去三个月他“做到了但没有被看到”的事情，挑出一件最大的，公开复盘表扬，不要等到挽留时再说，那时候已经晚了。

2. 争取一个短期调整：换模块、给更多技术自主权、让他牵头一个小型技术改进。他要的不是轻松，是掌控感。

3. 跟他聊未来：不是画饼，是明确告诉他“如果你留下，我接下来半年可以帮你争取什么”。

不同情况下的取舍参考

七、一句话总结，和一件马上能做的事

我不说“流程不重要”这种漂亮话。我想说的是这个排序逻辑：

> 先攒人，后建流程，流程才有杀伤力。

> 人没站对位置，没被点燃，再精致的测试策略都只能跑在纸面上。

如果你今天只带走一件事，我希望是立刻约一场 1-on-1：

• 找团队里你最摸不透的那个人，或者你觉得状态最不对的那个人；
• 不问进度，问他最近在工作里最有挫败感的一件事；
• 听完别急着给方案，回一句话就好：“这个我之前没注意到，后面我们一起想想怎么调。”

就那么一句，可能比你的新流程更早改变测试质量。