浅谈测试管理—兵者诡道也

 测试管理,如领兵打仗。

  既然是征伐,一味蛮干,只懂得身先士卒,是不够的。

  谋定而后动,还是有一定道理的。今日姑且小议一句话。“兵者诡道也”。

  情景一:

  为了项目进度,需要晚上加班测试。

  如果你是个leader此时极有可能听到team中各种声音。

  “怎么会加班呢?啥时候能回家啊?”

  “今天能搞定嘛?不会通宵吧”

  “这要搞到啥时候?我还有事呢”

  ……

  分析:

  诚然这些声音多少包含消极的因素,然却无可厚非。

  正如我一贯主张,劳逸结合是最好的,但特殊情况是无可避免的。

  现象:

  我看到过一些领导,批评下属“你们的梦想呢……”

  也看到一些主管空喊口号“加油啊”

  自然也看到过一些leader,身先士卒,但是只顾埋头苦干。

  点评:

  第一种,大言不惭。

  有什么理由批评人,本来就是加班的事情。

  人都会疲惫都需要休息。

  批评只会让结果恶化。最多是口服心不服。

  第二种,华而不实。

  空喊口号久了,只能被冠上无能的称号。

  也会让人鄙视leader,喊口号谁不会呢?

  第三种,匹夫之勇。

  一味埋头苦干,人们碍于面子或许会跟着做。

  然而消极情绪不能消除。

  事倍功半。何况这又何尝不是一种精神上的压迫呢?

  对策:

  一言以蔽之“远而示之近”和望梅止渴的典故有异曲同工之妙。

  人因未知而恐惧,因恐而迷茫。此时重点是要激发斗志。

  “明确告诉大家,我们九点就能下班,就能搞定。

  希望就在眼前,马上大家就能回家各种happy”

  与此同时,和组内的同学一起做一点。

  哪怕只是一点,也胜过自己埋半天。

  即便你最后搞到了九点半,那多出来的半小时也是斗志昂扬的。

  更何况积极状态下2小时,能完成消极状态下3小时的工作

  注意:此方法,不可在短期内连续多次使用。最好还是规律作息。

  注意:前提是自己对实际的任务量有较为清晰的把控。

  情景二:

  在绩效考核,或职业等级评估晋升前期(一个月左右)

  一些同学觉得自己已经完成绩效计划中的任务,所以工作懈怠。

  一些同学觉得技术已经达到考核标准,不再虚心积累。  分析:

  惧满盈,则思江海下百川。

  可是很多工作时间不太长的同学还没有完全领悟这个道理。

  绩效的目标只是定在完成,考核的目标只是定在通过。

  其实这需要leader引导的,也是人才培养的一部分。

  现象:

  见过一些leader也随着大家一起松懈。

  见过一些领导在那空放厥词,大讲是非论。

  点评:

  第一种,我只想建议一句话:先天下之忧而忧,后天下之乐而乐。

  第二种,从来只是内因其变化

  不能激发主观能动性,只能徒增逆反心理。

  对策:

  一言以蔽之:“近而示之远”

  不用解释要有啥更高的追求。

  只找他一起回顾下半年前的绩效目标,

  绩效这东西就像海绵挤挤总会有空隙。

  只需要让他知其实还没有达到目标(尽管他已经无限接近)

  做一次模拟等级评定。

  他一来会感激你的关怀,二来你借此问一些偏冷门的问题。

  总有不会的,目的就是让他知道,他和自己心中的目标还有距离。

  人之所以自满是因为觉得自己距离目标已经无限接近。

  我们与其费力改变目标,不如制造距离感。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-11 13:09:25

浅谈测试管理—兵者诡道也的相关文章

浅谈测试管理—应对需求变更

今天想和大家说的,其实无非是和我们如影随形的需求边变更.似乎自我入行一来一直听到这个词语.先说何为需求?我按照广义和狭义简单的区分了下. 所谓广义需求,及时一切和项目有关的想法,建议反馈,都叫做需求.所以狭义,就是产品经理提出的需求文档.其实一定时期内,我们不得不承认,广义需求是相对稳定的,并且有一定的经验可谈.何意?广义需求可以是用户的一个反馈,可以是今年流行的一种设计风格,可以是近几年流行的聚焦区域.再具体点说,就是,用户可以希望音乐播放软件提供高品质,免费,且海量的搜索结果,这个要求可能是

浅谈测试管理—bug的含义知多少?

bug这个词,对我们来说从入行起,就形影不离.然而亲密如此,你真的了解他嘛?今日我不想穷究bug的全部属性,也不想谈多少理论.我们的足迹从一场实战开始. 试想,我们做了个移动端的app,一个是启动后,首页,有个明显的文字错误.一个是你点了十多步之后,发现一个逻辑错误(比如1+1算错了).如果是测试人员会觉得哪个bug最有价值?我相信,八成的人会认为后者,为何? 1)传统意义上说后者严重级别高: 2)发现步骤"复杂"显得有技术含量: 3)有成就感被人称为大牛. 曾几何时,我也极力追求后者

浅谈权限管理的对象模型和实现

对象 浅谈权限管理的对象模型和实现    beegee(原作) 关键字    权限管理 对象模型 ACL 电子政务 浅谈权限管理的对象模型和实现 beegee (2003-7-16) 目录: 1.权限管理问题的分析 1.1权限管理简要分析 1.2电子政务系统的权限管理 1.3商业化应用系统的权限管理 1.4他山之石 2.权限管理子系统设计 2.1权限管理子系统的总体目标 2.2权限管理子系统的对象模型 2.3注意与不足 3.权限管理子系统的实现 3.1面向对象的实现 3.2组件层与功能层对对象的

技术人员谈管理之浅谈团队管理

古语云":马,匹马徘徊,万马奔腾;人,单影单身难行,合群大成."团队是由一些拥有互补技能,为了共同目标而遵循共同方法和行为规则,相互承担责任的人组成的群体. 谈团队管理就不能不提人力资源管理,人力资源管理简单的理解就是管人,由于人才是企业最重要的财富,因此人力资源管理的重要性可想而知. 人力资源管理的过程包括如下4个方面: 1.      制定人力志愿计划 人力资源计划包括识别和记录项目角色.责任和汇报关系. 2.      组建项目团队 组建团队就是找人,为项目工作找到所需的人员以及

浅谈测试rhel7新功能时的感受

半夜起来看世界杯,没啥激情,但是又怕错误意大利和英格兰的比赛,就看了rhel7 相关新功能的介绍. 安装还算顺利,安装的界面比以前简洁的多,很清爽,分类很是明确. 有些奇怪的是,我安装的时候,怕有些基础的包没有装上去,所以选定了mini和Web的类型,结果还是有些基础的包没有安装,比如 ifconfig . 虚拟机的网卡,被识别为ens,有意思. yum groupinstall Base 这样的话,就可以把一些基础的包打上.可以正常的时候ifconfig lsof  . 这里需要说明的是,re

浅谈库存管理中的综合库存计划编制范围

综合库存计划的编制应该与主生产计划编制过程一致,综合库存计划的编制是生产计划编制的一部分. 最终的综合库存计划的形式类似于生产计划的形式.然而,综合库存计划包括每一种库存状态,也给出每一种库存状态允许的范围. 下面给出成品库存更详细的计划: 1.成品库存 成品库存计划可以按产品编制,也可以按生产计划中的产品族编制,该计划包括:展望期:时间段:检查周期.成品库存具有多种用途,如预计库存.运输库存.安全库存和批量库存. 2.在制品 要确定在制品平均库存金额,需要估计生产中的项目增值过程.项目成本按一

浅谈软件项目管理之测试

笔者从事软件行业相关工作将近十年,其中与测试相关时间有7年之久,现浅谈软件项目管理中测试的必要性,供大家参考. 一.测试的必要性 为什么需要测试,那是因为由于分工的精细化,软件开发必须经历客户.需求.设计.开发多个环节.为了保证最终的结果符合要求,上下游是需要确认的. 用户告诉我们:我需要什么?软件企业需要在理解正确.表达正确的情况下完成需求规则说明书,把客户的原始需求转变为IT需求,表达出能够提供什么 需求的下一环节是设计,设计主要是要要说清楚:我要让软件做什么.需要与前一环节确认理解正确了.

浅谈如何有效建立权限管理体系(原创)

体系|原创 作者:BALLOONMAN2002  2004年6月26日 本文拟结合POWERBUILDER语言,简述如何在传统C/S应用系统当中有效建立权限管理体系. 何谓权限管理体系?就是如何控制操作使用者对软件功能和系统数据的访问权限的各个方面.传统的C/S应用系统,多是"前台应用程序+后台数据库表"两部分,这样就决定了我们考虑权限管理体系就必然要考虑两方面的内容: 1.用户在前台的功能权限:即该用户能够使用哪些菜单或窗口功能,例如:张三只能使用数据录入功能,不能使用管理审批功能:

用户体验设计:浅谈可用性测试中沟通的技巧

文章描述:如何快速解除用户防备?--浅谈可用性测试中沟通的技巧.   一般来说,在产品的设计和开发过程中,不同阶段会使用到不同的用户研究方法.比如,在产品正式发布之前,通常会进行可用性测试.可用性测试,是指让一群有代表性的用户尝试对产品进行典型操作,同时观察员和开发人员在一旁观察.聆听.记录.该产品可能是一个网站.软件,或其他任何产品,它可能已经做好,也可能尚未成型. 对于一个典型的可用行测试,我们可以:1. 通过观察用户在使用产品过程中出现的一些问题,发现产品的可用性问题2. 从测试参与者的表