测试主管接手新团队的几件事

第一件事：环境熟悉
俗话说，知己知彼，方能百战不殆。切忌刚上手就胡乱打一通，有时正确的策略运用在错误的时机仍会产生坏的结果。
人员：你不是一个人在战斗。 6 g  W/ Y# v7 R0 V  X3 s
了解你团队中的核心成员，了解他们的特点、需求（方法很多，你可以找团队的上一任老板）。建立好跟他们的信任，是你接下来工作是否得心应手的保障。很多人更愿意使用「自己人」，除非你有十足的把握，不建议你在新团队中这样做。也许你并无恶意，但可能会引起其他员工的反感。 3 y* }: { 当然，作为测试团队的合作方，开发团队、PM团队、PD团队你也需要第一时间去认识。今后工作中除了团队内部人员外，你还有很多时间跟他们打交道。 6 r+ ]  V" n  k; i6 G4 ]! C2 L
流程：了解团队工作的流程，从中你可以发现各角色职责是否清晰明确、各项工作执行是否准确到位、工作效率是否符合要求。它们今后会给你的策略提供参考。 8 E% b; C1 O4 }! `0 f
Ps.团队中一定会有“潜规则”，这是在团队在长期磨合过程中形成的一种最舒适的工作状态。除非你觉得它影响到工作效率，否则也不一定是坏事。

第二件事：业务梳理
作为一个新主管，你不一定能够做到对新团队的所有产品细节了如指掌，但必须做到的心中有张地图。 ( q; r( M6 c7 X: r5 t/ m! d
这张「图」能做什么？ & ]# [0 k7 T: ^3 j
1. 了解产品的范围，掌握与其他团队的工作边界；
2. 清楚哪些属于重点业务，结合自己的理解和判断，划出测试重点保障的产品列表; # \1 j% l6a
3.了解产品所对应的系统及交互，看到系统与业务的mapping关系。 : s/ g, I( @& 0 
约个时间，让产品测试owner跟你讲解，即可学习，又可拉近跟团队成员的关系，同时侧面了解owner对业务和系统的理解能力，一举多得。
. D" [7 y- j3 W. e( R
在这个阶段，把自己当成一个学习者，储备最基本的知识。
, L& g! F9 M! O
第三件事：研发管理
在这个阶段，你已经清楚团队项目是如何运作的，也知道当前有哪些项目，谁在负责。也一定会接收到团队成员反馈过来的问题。
对每一个问题点，请了解事情发生的前因后果，听听核心成员的意见「这个时候，之前建立的初步信息开始在发挥作用」，结合自己的判断，给出直接并且有效的处理方案。
如果员工反馈的问题很大「譬如质疑项目的合理性」或者一时无法解决，不要急于求成，收集各方信息找个合适的机会再做决定。
4 ~5 a  S3 n% L+ H7 Q; S
在这个过程中，自己需要主动分析测试工作中的不足，并寻找突破口，运用一定的措施加以改变。 3 o- z: P& x. F" s( S
案例：主管A对测试工作进行Review，发现测试人员对于测试用例的重视度不高，很多项目用例覆盖点不足甚至没有写用例。详细挖掘后，了解到组内并没有一个清晰的用例设计规范，也没有明确的用例执行要求。因此，测试人员的能力和责任心不同，用例产出质量也参差不齐。
1. 如何解决用例规范的问题。这比较简单，测试行业中已有很多成熟的用例设计指南，万变不离其中。A采用的是把业界较为标准的用例规范作为蓝本，邀请组内一到两位核心人员根据产品线的特征进行修改。
2.有规范，重要的是有效的执行。为此，A挑选了一个合适的项目，安排一位有能力基础，并且稳重的主导测试人员，在项目中执行这套用例规范。这个试点项目，有A的全程关注，加上B的能力基础，理所当然的有了较好的质量结果。项目发布后，在某次团队会议中分享经验，并正式宣布推行。明确的规范，加上最佳实践，只待时间了。 ; c1 V/ ]  l( t0 n# N7 {
3.为加强测试人员的执行力，主管A还安排了核心成员定期对项目的用例质量进行审查，并在若干月后推行最佳用例评选活动。自此，这个环节再也没有出现差错。 / |+ m; C9 j1 {4 F% t& ?; f- e/ F
. _9 r9 d" v- x+ j
第四件事：团队协作' x / B# B1 L# W  @
在第二件事情中，新主管已经清楚团队中的重点产品，但并不一定清楚当前业务团队、开发团队的工作重点。如果你跟他们使劲的不是同一个方向，甚至可能给产品的研发带来负面的效益。对此，你应该去了解这些情况，并推动业务、开发、测试建立起一个良好的协作通道，保障重点业务目标的传达和反馈机制。 ) i  t: O/ x( k

而测试属于研发下游部门，你很快会发现很多事情并不是只要测试做好就可以的。很多时候质量问题频繁爆发的原因是，代码在敲下的那刻就存在先天不足。
因此，通畅团队协作渠道，抓好测试内部工作的同时，重点考虑的还有跟自己上游的开发团队如何相互促进？ + R/ ?% f$ \1 y5 d

案例：主管A看到的问题也有很多：开发交付给测试的版本质量很低，bug的reopen率也高居不下。但最致命的问题是，大家对产品交付给客户的质量问题缺少紧张感。因此，如何把质量问题明确化并影响到每位工程师将成为问题的关键。A经过跟开发主管及业务团队的沟通，决定将客户反馈上来的故障统一记录跟踪，设定指标并分解到开发和测试团队，甚至影响到测试人员的工作绩效。执行一个季度下来，研发团队对客户的问题更加感同身受，测试因为所承担的故障指标对开发提出更高要求，开发也会更care发布前的测试质量，形成了一个良性的循环。用户对产品的评价持续增加，同时测试人员有了更多的成就感。

第五件事：优先级管理
这个不用多说，很多人都看到时间管理的书籍。决定你当前要重点完成哪个的工作更为关键，而这个事情没有秘笈，需要的是一点sense。
案例：我在接手团队时，看到团队梯队中缺少测分层次人员「见第六件事，人员管理」，并且会影响到后续的目标达成。因此将人员招聘列为重要紧急的任务。
 w7 s9 D" ^' Z+ E
第六件事：人员管理3  D7 r  c, v8 r- S  C9 K& v& V0 q
人员梯队建设：梳理现有团队中的人员层次，针对于不同层次人员制订一定的提升计划（可以从核心成员开始）。
挖潜：团队中是否有人员没有放在合适的岗位上，也可能有人员真实能力没有发挥出来。这时用你伯乐的眼光来寻找这类的人员，并做出合适的调整。 9 o6 u$ j1 w3 T, m
招聘：当你接手新团队中，当前的人员梯队可能会有缺口，并且也不一定能够通过内部挖潜来弥补。你可以根据团队的实际情况和未来需求，申请headcount招聘合适的人员。其次，在一个相对成熟的团队中，要想完成改变是比较困难的，加入几个新鲜血液还会有意想不到的效果。 . l+ T4 d9 b% H4 C/ G% m" o
$ }" A( G* F$ r. }+ T, ]
第七件事：目标管理
前几件事情如果说，还在逐渐融入新团队的话，那从这件事情开始，你将逐渐开始代入角色。 0 e, N5 p3 T" a' H1 I# T
一个团队如果期望能够持续发展，首要的是目标管理。前几天，看到一个帖子说，测试团队得不到领导的重视。这跟公司对于测试团队的定位，以及如何制订质量目标有很大的关系： ( t, i: J3 [- k0 y! }0 T
质量意味着成本，从公司层面上来看，如何平衡成本与收益，将是非常重要的策略。因此，很多测试团队都会将「线上缺陷」和「测试效率」视为最重要的团队目标。
因此，如果你是一个公司测试团队的manager，你要搞清楚的是： $ P9 `$ \+ i5 @
1.你所处的是一家什么样的公司？创业型，互联网型，金融型，还是传统软件型。不同类型的公司对于质量的可接受性也是不一样的，你别指望在一家创业型的公司中，要求你的领导重视质量，因为快速用户买单的创新产品是公司的首要目标「现实是很多创业型团队一般由产品经理、开发、设计人员构成，在初期压根就不会有测试」。 + f# J1 z9 Y/ c# j* B* X
2.用户对于质量的要求是怎样的？你可以接受baidu.com的搜索结果不够精确，但你能接受银行把你的钱算错了吗？
了解这两点，你心里自然会有底，你该如何让测试团队更有成效，更能够满足公司的利益。
…有点扯远了，回到正题：
目标管理在于如何定位团队当前的重点，将把有限的资源投入到核心任务中。 2 j  Z6 n. E! K
6 _3 N) h9 R8 Y% c" Q
第八件事：团队形成
到这个阶段，时间已经过去两、三个月。再回顾一下你之前所做的几个事情，看看是否还有纰漏。仔细审查团队定义的目标是否落实到具体的事情和责任人？
最后适时组织一个户外的团队活动，增强团队成员之间的默契和感情。感受团队管理给你带来的乐趣吧！