新测试主管的几件事「6.18完结篇」
本帖最后由 shtrong 于 2013-6-18 09:17 编辑{:4_91:} 在测试管理过程中，如果有具体案例，欢迎微信跟我交流探讨：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 不错的分享~ 不错，支持楼主 文章发布以后不能编辑的吗？想更新都没有办法哎。
新创建时能否加个预览功能，加个PV、UV数？
@楠族开心果
各位经常发贴的清楚吗？ 回复 4# shtrong
sorry，找到入口了。 不错，顶一个。 我碰到得比较多的问题是项目上线后出了经常出问题，测试需要对问题进行分析。
测试觉得出现问题很冤，进而在以后的测试工作中整出很多文档为以后出现问题拿来当作证据。
殊不知，整那么多文档的时候已经把测试累个半死，测试人员对此怨声载道。
两难境地：做这些工作吧，怨声载道。不做这些工作吧，测试可能面临背黑锅的情况。
是做这些工作好呢，还是不做好呢？又有没有折中的方案呢。 文章发布以后不能编辑的吗？想更新都没有办法哎。
新创建时能否加个预览功能，加个PV、UV数？
@楠族开心果 ...
shtrong 发表于 2013-6-4 20:39 http://bbs.51testing.com/images/common/back.gif
文章发布之后是可以编辑的。在帖子的下方有个编辑功能！ 不错，顶一下 回复 7# 千里
给你几个建议，可以参考一下：
「对外」跟开发主管把配合关系和相互之间的要求理顺。在组织层面上一个故障的遗漏上线一定是开发和测试团队共同承担的，所以也谈不上背黑锅了。-------如何跟团队（包括PD|PA等业务团队）配合，其实是挺难的。可以专门列一个讨论议题。
「对内」
1.为什么项目中会经常出问题，找到主要的几个原因（简单的测试遗漏？更深层次，以当前人员能力无法发现的问题？还是需求不明确？），可以参照#研发管理#章节中的内容进行针对性改善。
2.文档一定是为了更好的达到测试目标的。（比如「测试分析文档」是为了更好的分析项目/系统的测试点，以及非功能性测试问题；「业务总结文档」是为了知识的传递；「线上故障分析」是为了让大家能够理解故障原因，储备脑中的故障知识库等等）如果你确定有文档不是为了最终提高测试质量的目的，那完全没必要做/或者跟主管提建议可以取消。
还有一种所谓的「背黑锅」，可能跟业务人员及需求文档有关：
1.未提供明确的需求；
2.提供错误的需求；
3.需求不完整；
我目前给团队人员建议两种方案：
#1 在需求评审阶段要求业务人员将你认为不清晰，不完整的需求给全部列出来。
#2 如果上述因各种原因做不到的话，那由测试人员提出具体问题，给业务人员拍板。
测试人员在这两点都做到的话，如果频发需求问题，那就拉上开发主管一起去找业务方老大吧。
#希望对你有用，如果把问题/案例描述得更具体点，给你的建议也会更准确# 回复 10# shtrong
很有帮助，工作中确实出现了千里哥说的这个问题，“如果你确定有文档不是为了最终提高测试质量的目的，那完全没必要做/或者跟主管提建议可以取消”，其实这个最终目的不好判断，对于上级来说，即使没有提高产品质量的目的，但可以撇开测试的职责，未尝不是一件好事------
关键在于值不值得做的判定，最终还是上级说的算（如果你是上级就好办了）--- 回复 7# 千里
愚见：如果条件环境允许，可以考虑加强整个项目团队（包含开发，测试）的质量意识，让团队成员意识质量是每个人的责任，少一些对抗，多一些合作，一起头脑风暴解决遇到的问题，最终大家做事起来会更舒服一些。 回复千里
给你几个建议，可以参考一下：
「对外」跟开发主管把配合关系和相互之间的要求理顺。在组织 ...
shtrong 发表于 2013-6-16 07:28 http://bbs.51testing.com/images/common/back.gif
认真读了这个帖子，总结起来表现在两方面。一来和各方沟通好，达成共识。二来是重新认识文档的作用。指导方向还是，有些活儿还是得拒绝掉，至于如何拒绝，那是技术活了，哈哈。 文档的作用这部分讲得非常好，赞一个。 回复shtrong
很有帮助，工作中确实出现了千里哥说的这个问题，“如果你确定有文档不是为了最终提高测 ...
没翅膀的飞鱼 发表于 2013-6-19 08:16 http://bbs.51testing.com/images/common/back.gif
就是咱们认为没用，甚至劳民伤财，但始终没有办法说服领导。而且不太好的决策，领导不愿意去承认那是不太好的。总之，没有充分的理由，又不是明显的错误决策，是很难改变领导改变他说出口的决定的。这就是君子一言，驷马难追，就算知道错了，也是哑巴吃黄莲。 回复千里
愚见：如果条件环境允许，可以考虑加强整个项目团队（包含开发，测试）的质量意识，让 ...
omg 发表于 2013-6-19 21:03 http://bbs.51testing.com/images/common/back.gif
嗯，这是进阶方向。 很好的一片管理分享。精品！ 回复 12# omg
这个应该是测试发展的高成次，如果这种意识达成了，对于测试工作的开展会很有帮助，其中还需要流程和制度的规范--- :handshake 测试很多时候还是跟整个项目的流程管理做的好坏有很大的关系。。
对于那些流程很差特别是没有什么流程的项目来说，测试似乎就是天天打杂和背黑锅了。。
就像是体制问题，不是你一个leader就能解决的了的。。苦闷中。。。
页:
[1]
2
