新测试主管的几件事「6.18完结篇」

shtrong

在测试管理过程中，如果有具体案例，欢迎微信跟我交流探讨：WXshtrong

注：原标题是《测试主管接手新团队的几件事》，在编写的过程中，考虑到新担任主管和担任一个新团队的主管碰到的问题不尽相同。因此不再局限于原来的场景，希望可以给提升为主管或者刚接手新团队的主管更多帮助。


这个图是N年前自己在接手一个新的测试团队时整理的，一直也没有花时间来总结和回顾。借这个机会，整理出当时的所做的事情以及碰到的困惑，希望能产生价值和借鉴意义。
在文章描述的工作过程中，有一些是「主管」或「经理」应该具备的通用管理能力。为了让总结更有针对性，本文站在测试主管的角度上逐一介绍所做的每件事情的原因和价值。另，这八件事在大方向上有一定的先后顺序，但仍存在几件事情并行执行。

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

第二件事：业务梳理
作为一个新主管，你不一定能够做到对新团队的所有产品细节了如指掌，但必须做到的心中有张地图。
这张「图」能做什么？
1.        了解产品的范围，掌握与其他团队的工作边界；
2.        清楚哪些属于重点业务，结合自己的理解和判断，划出测试重点保障的产品列表。
3.        了解产品所对应的系统及交互，看到系统与业务的mapping关系。
约个时间，让产品测试owner跟你讲解，即可学习，又可拉近跟团队成员的关系，同时侧面了解owner对业务和系统的理解能力，一举多得。

在这个阶段，把自己当成一个学习者，储备最基本的知识。

第三件事：研发管理
在这个阶段，你已经清楚团队项目是如何运作的，也知道当前有哪些项目，谁在负责。也一定会接收到团队成员反馈过来的问题。
对每一个问题点，请了解事情发生的前因后果，听听核心成员的意见「这个时候，之前建立的初步信息开始在发挥作用」，结合自己的判断，给出直接并且有效的处理方案。
如果员工反馈的问题很大「譬如质疑项目的合理性」或者一时无法解决，不要急于求成，收集各方信息找个合适的机会再做决定。

在这个过程中，自己需要主动分析测试工作中的不足，并寻找突破口，运用一定的措施加以改变。
案例：主管A对测试工作进行Review，发现测试人员对于测试用例的重视度不高，很多项目用例覆盖点不足甚至没有写用例。详细挖掘后，了解到组内并没有一个清晰的用例设计规范，也没有明确的用例执行要求。因此，测试人员的能力和责任心不同，用例产出质量也参差不齐。
1.        如何解决用例规范的问题。这比较简单，测试行业中已有很多成熟的用例设计指南，万变不离其中。A采用的是把业界较为标准的用例规范作为蓝本，邀请组内一到两位核心人员根据产品线的特征进行修改。
2.        有规范，重要的是有效的执行。为此，A挑选了一个合适的项目，安排一位有能力基础，并且稳重的主导测试人员，在项目中执行这套用例规范。这个试点项目，有A的全程关注，加上B的能力基础，理所当然的有了较好的质量结果。项目发布后，在某次团队会议中分享经验，并正式宣布推行。明确的规范，加上最佳实践，只待时间了。
3.        为加强测试人员的执行力，主管A还安排了核心成员定期对项目的用例质量进行审查，并在若干月后推行最佳用例评选活动。自此，这个环节再也没有出现差错。

第四件事：团队协作
在第二件事情中，新主管已经清楚团队中的重点产品，但并不一定清楚当前业务团队、开发团队的工作重点。如果你跟他们使劲的不是同一个方向，甚至可能给产品的研发带来负面的效益。对此，你应该去了解这些情况，并推动业务、开发、测试建立起一个良好的协作通道，保障重点业务目标的传达和反馈机制。

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

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

第五件事：优先级管理
这个不用多说，很多人都看到时间管理的书籍。决定你当前要重点完成哪个的工作更为关键，而这个事情没有秘笈，需要的是一点sense。
案例：我在接手团队时，看到团队梯队中缺少测分层次人员「见第六件事，人员管理」，并且会影响到后续的目标达成。因此将人员招聘列为重要紧急的任务。


第六件事：人员管理
人员梯队建设：梳理现有团队中的人员层次，针对于不同层次人员制订一定的提升计划（可以从核心成员开始）。
挖潜：团队中是否有人员没有放在合适的岗位上，也可能有人员真实能力没有发挥出来。这时用你伯乐的眼光来寻找这类的人员，并做出合适的调整。
招聘：当你接手新团队中，当前的人员梯队可能会有缺口，并且也不一定能够通过内部挖潜来弥补。你可以根据团队的实际情况和未来需求，申请headcount招聘合适的人员。其次，在一个相对成熟的团队中，要想完成改变是比较困难的，加入几个新鲜血液还会有意想不到的效果。

第七件事：目标管理
前几件事情如果说，还在逐渐融入新团队的话，那从这件事情开始，你将逐渐开始代入角色。
一个团队如果期望能够持续发展，首要的是目标管理。前几天，看到一个帖子说，测试团队得不到领导的重视。这跟公司对于测试团队的定位，以及如何制订质量目标有很大的关系：
质量意味着成本，从公司层面上来看，如何平衡成本与收益，将是非常重要的策略。因此，很多测试团队都会将「线上缺陷」和「测试效率」视为最重要的团队目标。
因此，如果你是一个公司测试团队的manager，你要搞清楚的是：
1.        你所处的是一家什么样的公司？创业型，互联网型，金融型，还是传统软件型。不同类型的公司对于质量的可接受性也是不一样的，你别指望在一家创业型的公司中，要求你的领导重视质量，因为快速用户买单的创新产品是公司的首要目标「现实是很多创业型团队一般由产品经理、开发、设计人员构成，在初期压根就不会有测试」。
2.        用户对于质量的要求是怎样的？你可以接受baidu.com的搜索结果不够精确，但你能接受银行把你的钱算错了吗？
了解这两点，你心里自然会有底，你该如何让测试团队更有成效，更能够满足公司的利益。
…有点扯远了，回到正题：
目标管理在于如何定位团队当前的重点，将把有限的资源投入到核心任务中。

第八件事：团队形成
到这个阶段，时间已经过去两、三个月。再回顾一下你之前所做的几个事情，看看是否还有纰漏。仔细审查团队定义的目标是否落实到具体的事情和责任人？
最后适时组织一个户外的团队活动，增强团队成员之间的默契和感情。感受团队管理给你带来的乐趣吧！

end.
#欢迎微信跟我交流探讨：WXshtrong

heqingbluesky

LZ的微信号实效了。
文章的确不错，一句话：软件质量的保障和提升，不能光依靠测试团队。

citta

很好啊  虽然好久了  再顶顶

apple101

受益很多，收藏下来，慢慢体会

pwl0206

赞

思念梧桐

顶一个

sunln

lz微信咋找不到？

liusx

很不错！

lusheng0028

不错

hujishun

GOOD 受用

xidiancjw

很有参考价值，虽然比较老了

mable0405

值得收藏学习

xiaoshi_2011

学习了

寒柔月冰

很好的一篇文章。
公司对质量的重视以及开发、测试对质量的认识，是很重要的。
在做完8件事之后，应该增加绩效管理、流程管理。
形成良好的测试循环后，激励的绩效管理将会进一步巩固这种成功，诱使测试人员内部合作与竞争，形成不断提高的技能的良性循环。
良好的质量意识形成后，在公司层面形成流程管控， 用这种方式保持质量意识。

hbxtly

好文章，受教

lymmxz

恩 我能体会。很多是项目组内的问题聚集而成的，并不是单纯只提高某一个方面就能看到效果。

lymmxz

不错学习了。

没翅膀的飞鱼

回复 20# 挖掘

做自己力所能及的事吧，有些事积极并不是好事

guoguo2005

好。