• 0
  • 0
分享
  • 测试团队协作要成功,必须要避开这4个坑——软件测试圈
  • 曼倩诙谐 2024-01-12 13:54:24 字数 2181 阅读 699 收藏 0

  今天分享几个工作协作过程中的真实案例,每个案例中都有常见的协作问题,希望给大家带来思考。

  案例一:我功劳最大,但没有被认可

  某团队要将公司的基础组件在该业务落地实施,该团队主管安排两位QA同学跟进了该事情:小B和小D。小B是一个善于用技术解决问题、但服务意识差一些的同学,小D的技术功底弱一些,但服务意识强。

  小D日常收集大家的诉求,遇到不太懂的技术问题则请教小B,然后将问题和解答进行了整理,久而久之,最后形成一篇FAQ文档,FAQ文档经过推广、运营,知道的人越来越多,最后该FAQ文档得到了团队成员的普遍好评。因此,小D同学的影响力越来越大、正反馈越来越多。这时小B同学有点不高兴了,开始吐槽小D,诸如:小D什么也没干,他最开始的技术基础都是我给他普及的,你们看FAQ文档里的解决方案里的图片,很多都是我的账号登录的,这说明小D同学压根没有自己解决,只是把我的截图贴进去了。小D听到小B认为他什么也没干,也不甘心,针对小B的吐槽一一反驳,两人的矛盾愈演愈烈。

  案例分析:

  该案例中关于两人的分工,在主管安排工作时并没有明确,这是小B和小D两人矛盾产生的原因之一,但我认为这不是最主要的问题。工作场合中,类似不明确的事情是比较常见的,最开始不明确,但可以通过几次项目反馈,逐渐把两个人的职责、分工明确下来。

  又或者,这两个人谁主动承担的更多,谁就掌握了主动,或许可以主R整个事项。相比较来说,小D的主动性和服务意识值得点赞,事情整体的效果也是好的。但小D的问题是,在享受项目成果时比较自私,有很大的改进空间,比如在FAQ文档当中明确说明该文档是小B和小D的共同成果,如有问题请联系两个人。在该事项被他人正反馈的任何场合,也应该提及这是两人共同的功劳,不属于任何一方。这样,小B的技术付出得到了应有的尊重,以后也更愿意跟小D一起合作做更多的事情。

  再来看小B,小B的做法我觉得更可惜一些,因为该事项中小B的技术能力是稀缺能力,自己就有能力沉淀FAQ文档。虽然小D有自私的做法,但小B更应该思考,为什么自己不能把事情做得闭环、充分些呢。

  从两个人的协作来看,本来可以双赢的结果,现在变成了双输,他俩的矛盾,让其他同事看到了他们的不成熟,他们彼此也产生了不可调和的矛盾。

  案例二:我贡献了点子,但没有被认可

  某团队在进行自动化建设时,同学小H和小Q在讨论技术问题时,小H提出了一个好点子,小Q很认可。一段时间后,小Q同学基于这个点子把自动化实现进行了优化,产出了好的结果,还在较大范围内进行了分享。分享后,小H同学不是太开心。不开心的点主要在于,小H基于自己的点子做了改造升级,分享时却没有体现出自己贡献了这个点子。

  案例分析:

  出现这种情况时,我倾向于认为小Q不是有意的,因为如果不是直接参与了开发、编码,很难意识到是小H提出的好点子,且要在分享的场合明确提及。除非有人问这个点子是谁的主意,小Q也许才能意识到是小H。

  当然如果小Q能够意识到小H提出了一个好点子,并在分享场合提及,我认为这是很赞的做法。但我觉得在这件事上,小H需要改进的地方更多。如果小H比较介意自己贡献了点子,那可以在自己贡献点子的同时间体现出来,比如写在周报里、发到群里,又或者更早实现自己的点子,并进行分享。

  案例三:我参与了开发,但没有被认可

  小Q是某事项的主R(负责人),在跟进某事项的过程中,做出了一些阶段性的成果,成果推广到相应的群时,他人给予了正向反馈,小Q回应“这是我应该做的“,还发了”为人民服务“的动图。

  小Q的主管看到这一幕,立刻与小Q单聊,询问该功能都有哪些人参与了,因为主管知道该功能点是由多人协作完成的。小Q提及另外两个小伙伴也参与了该功能的开发,主管建议在受到他人正反馈时,要特别提及共同付出的其他小伙伴的参与。理由:作为主R,小Q没有提及协作伙伴的付出,那么小Q后续推动他人做一些事情时或许不太容易,因为他人觉得跟小Q合作只有付出没有认可。

  案例四:我是主R,但感觉被忽略了

  某专项,分配小S为主R(负责人),小S正常跟进中。组内同学小L比较主动,主动跟小S了解实现、学习技术,并询问是否可以承接某个模块的开发。小S觉得可行,把其中一个复杂度不高的、独立的功能模块分配给了小L。小L的功能模块很快开发完成,由于可以独立运行,小L将该功能推广给了使用方,使用方给予了高度评价。小S心里不太舒服,因为小S觉得是我教会你技术、是我分配你一个模块,现在正反馈来了,你却没有提及我的名字。

  案例分析:

  小S作为主R,理应承担主R的职责,应对整件事情做好整体规划,需要把设计、开发、发布、推广考虑在内,当引入他人参与时,应该更新项目规划,并将项目规划同步给参与的同学,这样步调才能一致。所以,小S主R的工作有明显缺位。

  而小L主动性强,模块开发完成后主动做了推广,协同方给了很好的反馈,主动行为应该被点赞。不足之处是没有提及小S的付出,这点可以加以改进。

  扩展思考

  “案例四“中小S和小L的情况跟”案例一“中小B和小D的情况很相似,你觉得应该如何化解小S和小L的矛盾,避免他们矛盾升级,演化为双输局面?


作者:GROW    

来源:http://www.51testing.com/html/79/n-7799279.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   本文将概述测试工程师的现状及发展方向,并着重介绍测试开发工程师的发展及所需具备的技能,以及本部门搭建的测试平台的概况和意义。  一、测试工程师的现状  很多测试小伙伴在工作中有时会比较迷茫,不知该怎样突破瓶颈,更好的发展。  那么测试人员究竟该如何打破瓶颈继续向上提升呢?如果你苦于不知所措,又满怀斗志向上的话,不妨一起聊聊。测试职业发展有典型的三种方向:  ·管理方向  · 技术型方向  · 转行  在此重点说下技术型方向的发展。曾几何时,提的bug被否认而倍感无力;曾几何时,遇到一个偶发复现的bug,到上线了都不知道该怎么复现;曾几何时,面对没有前端页面的测试任务,不知该从哪下手测试;曾...
            0 0 819
            分享
          •   特斯拉(Tesla)在美国和全球艰难地维持着销售增长,而在中国,特斯拉可能会有大动作,这对其实现在全球销售数百万辆电动汽车的目标至关重要。中国媒体的一份最新报道称,特斯拉有意扩建其上海超级工厂(Gigafactory),在这个年产能近 100 万辆电动汽车的工厂基础上再增加第三座扩建厂房。  上海 Gigafactory 是特斯拉产量最大的制造工厂,因为它得益于中国制造业对制造和工厂运营的适宜性,可以生产数十万辆汽车,在全球最热门的电动汽车市场上竞争。  今天的报道来自中国当地媒体,它分享了特斯拉上海工厂的所谓细节。特斯拉最初计划在 2021 年扩建工厂,但后来为扩建计划重新分配了团队。现...
            0 0 699
            分享
          • 购物车对于电商系统,还是比较重要的一个功能模块,看上去比较简单,但是关于这个功能的测试分析还是不是那么轻松的,因为它真的不仅仅需要功能测试,还需要其他技术的支持才能做好。功能上:购物车是否需要登陆才能进入;账号退出后,购物车添加的内容是否还在;购物车页面是否能够显示添加的商品的详细信息(商品名称、链接、数量、单价、总价);一条商品的单价、数量、总价的计算是否正确;多条商品是否能够以列表显示;多条商品同时显示,能否在相同的位置显示相同的数据;购物车能够返回商品首页继续浏览;能够移除购物车中的商品;购物车能够调整商品的数量;限购商品数量调整时能不能超过限购数量;没有限购要求的商品,添加数量能不能超...
            0 0 2000
            分享
          • 读者提问:什么时候需要写测试日报,为什么要写测试日报,怎么写测试日报 ?阿常回答:什么时候需要写测试日报,为什么要写测试日报:1、刚入职场的测试新人,测试主管根据测试新人的工作表现(含测试日报),对新人做试用期转正考核;2、临近项目关键节点,需要给出测试交付物时,和项目组汇报当下测试进展,是否有遇到阻碍、项目是否有延期风险;3、测试进度受到阻碍,项目存在延期风险,需要及时和项目组反馈当前测试情况。怎么写测试日报:1、整体测试进度有无风险:进度正常无风险、低风险、中风险、高风险。2、列出所存在的风险及对应策略,需要谁提供帮助。3、所测试模块,用例执行 XX %,发现了 XX 个 BUG...
            0 0 2513
            分享
          • index:比较两列表元素(不考虑顺序,不考虑重复);调get型数据库接口,循环造数据(示例);连接操作mysql数据库;多进程执行pytest UI脚本(示例)。1、比较两列表元素(不考虑顺序,不考虑重复)def compareList(list1, list2):     """比较列表元素,不考虑顺序,不考虑重复"""     if sorted(set(list1)) == sorted(set(l...
            0 0 1088
            分享
      • 51testing软件测试圈微信