团队强才是真的强

简介:

没有优秀的个人,只有优秀的团队。如果说今天上午大兴交通局举办的“安全知识竞赛”我们拿了第一名是由于我本人发挥的出色不如说是我们这个团队的整体水平的再现,我们八个队轮番角逐,开始成绩分数不分上下,没有拉开距离。八个队每队三个人,每个人回答一道个人必答题,每个队回答两道组答题,个人必答题总共三道题三十分,组答题两道题共四十分,总共七十分,这些分值可以说是送分没有悬念的,如果能够准备一下的话,这些分值是不会丢的。能拉开差距的只用那十六道抢答题,每道题目十分,其他几个队也是很强的,这可是六百多家企业预赛产生的八个队,没有实力也不会坐到主席台上争夺含金量很高的奖项。


我们不是单兵作战,我们打的是兵团战役,应该发挥团队的优势,在前两次我们进行“安全知识竞赛”演练时,发现其他几个队准备的比较充分,每个人在回答问题时都能够应付自如,这点让我很是担心,要想在决赛时能够以压倒式的优势胜出,就要在抢答题上做足功课,如果连抢答器都抢答不了,你准备的再充分也没有希望得到高分。在我们进行抢答器预演时发现好多队或多或少会出现违规现象,理应在主持人提示准备时,抢答器系统会出现3、2、1开始后,我们按抢答器,如果抢答成功不能回答题目或抢答违规都会倒扣十分,有了这些约束,发现其他队在按抢答器时,都会考虑主持人提到的问题内容,这种边思考边按抢答器的做法不利于成功抢答,一心不能二用吗。


针对其他队的答题情况和整体素质我们首先制定了一些预案,专门要一名队员研究抢答器成功抢答的一些规则,经过几轮摸索,发现抢答器系统提示“3、2、1开始”,我们再按抢答器的时候,就比别的队慢了半拍,如果抢答器系统提示“3、2、1开”,按抢答器的时候有时会出现提前抢答犯规倒扣分的险情,怎么能够做到既能抢答成功又不会违反抢答规则出现倒扣分的现象。事情就怕琢磨,只要爱琢磨总能找到一些捷径来创造佳绩,每次看抢答器显示屏界面出现“3、2、1”,不要等系统说开始之类的文字,直接按抢答器发现抢答成功几率达到100%,即使别人发现这类抢答技巧我们也不会出现抢答违规扣分现象,抢答不成功不要紧就怕抢答后违规,还没有赛出实力就倒扣分,确实让人心里哇凉哇凉的。

如果对手实力相当,我们就要考虑战术、心理素质的较量,面对台下安监局、交通局、修管所、消防部门好多单位的领导,还有黑压压的观众,咱们坐在台面上一边注意听主持人出的题目,一边还要面对那么多目光的注视,无形中给自己增加了一些压力,当我坐在台上静静的望着台下的观众,让自己慢慢的静下心来,发现自己并没有受到波动影响。我们分析了其他几个队的优势和劣势,做出了适合我们团队特点的作战部署,让王辉负责按抢答器,如果抢答违规或抢答成功次数低于六次,赛后请客抚慰下,一心一意的按抢答器不要考虑题目内容和答案,如果抢答成功我不能够正确回答问题导致扣分,我负主要责任,邢万里主要负责备用,如果我在回答问题不流畅或出现答案失误酌情给予提示,毕竟我是站起来回答问题会承受一些压力,他有时间来考虑问题答案的正确性。


《我是特种兵》里面有这样一句话,“一个人强是只羊,一个连强是头狼”,细细品味这句话确实再现了团队的力量,如果团队的配合能像一个人那样具有高效可行的执行力,我们的决赛就有可能取得阶段性的胜利。个人必答题、组答题结束后,有三个170分并列第一,可见比赛是相当激烈。十六道抢答题被王辉成功抢答了八道题目,为了避免其他队有其他想法,其他八道题我们放弃抢答,让其他七个队抢答,7号队在抢答的过程中连续违规四次,直接扣掉四十分,连台下的领导都认为抢答器出现了问题,为了证明抢答器有无问题时,我们做了新一轮测试,发现抢答器完全正常。其他几个队在抢答完后,突然忘掉了题目内容,回答不上来出现扣分现象,因为其他队在按抢答器的时候,谁会这道题目由谁来按抢答器,没有明确分工,影响了答题发挥,这就是战术失误。我们以250分的成绩轻松摘得桂冠,比第二名180分多出了70分,电视台还做了一次专访。

回头想想整个决赛过程,我们整体作战部署比较完整,充分发挥了团队作战的优势,详细的分析了其他几个队的作战情况,能够在抢答问题这个环节脱颖而出,离不开周密的部署和团队协作。


 

本文转自 jiangxuezhi2009 51CTO博客,原文链接:http://blog.51cto.com/jiangxuezhi/1088106 ,如需转载请自行联系原作者

相关文章
|
12月前
|
运维 NoSQL 关系型数据库
带团队后的日常思考(十)
带团队后的日常思考(十)
|
12月前
|
缓存 运维 测试技术
带团队后的日常思考(九)
带团队后的日常思考(九)
|
存储 数据采集 SQL
为什么你成为不了团队核心成员
为什么你成为不了团队核心成员
93 0
|
存储 缓存 移动开发
带团队后的日常思考(四)
  这次公司有个五周年的庆典活动,但正好碰到两个APP的版本发布,以及三个测试老员工离职,只进来了两个新成员,其中一个恰好要休陪产假,那么测试组资源异常紧张。   虽然我们提前了整整一周提测,但一直到周五还有很多点没测到。测试组甚至想到了阶段测试,因为多个活动的上线时间不同,所以可以先测最先上线的活动,后面的再往后推,延迟测试,这是他们组的一个对策。
带团队后的日常思考(四)
|
运维 监控 NoSQL
带团队后的日常思考(一)
  由于公司规模并不大,因此一有事情就会拉个会议,例如需要大会、技术评审、汇报周会、突发会议等。一周中大概有20%~30%的时间会花在大大小小的会议上。
带团队后的日常思考(一)
|
移动开发 自然语言处理 前端开发
带团队后的日常思考(五)
  他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。   前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
|
SQL 小程序 测试技术
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
|
缓存 监控 前端开发
带团队后的日常思考(二)
  经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。
带团队后的日常思考(二)
|
缓存 前端开发 JavaScript
带团队后的日常思考(六)
  当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。   这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
|
缓存 运维 前端开发
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。