为什么测试转产品越来越难了_第1页
为什么测试转产品越来越难了_第2页
为什么测试转产品越来越难了_第3页
为什么测试转产品越来越难了_第4页
为什么测试转产品越来越难了_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

为什么测试转产品越来越难了?一些做测试的同学,可能会转型项目经理、项目管理、团队管理,或者转型产品,各种不同的转型方向。本文作者结合自己转型产品的经验,分析为什么测试岗位转型产品越来越难?希望能给你带来一些启发。分享我近两年的一个感受,并试着分析其背后的原因。职位只是外界对你工作内容的定义,我们从事怎样的工作,拥有怎样的生活,更关键的在于自己的思维模式和意愿程度。这又是一篇拖更很久的文章,早在去年夏天,就有测试小伙伴问过我,是否可以转型做产品。一位甲方的测试负责人也和我聊过类似的问题,如何让测试人员具备更好的业务思维。虽然两位朋友的出发点不同,但其背后都反映了两个岗位之间千丝万缕的联系。因为我本就是开发毕业,测试入行,之后通过测试+需求这“一头一尾”的把控,逐渐转型项目管理,又恰逢合适的机会最终走上产品这条路。因此,测试岗位,于我个人始终存在不一样的感情。做过、招过、见过,也经历过这个岗位在互联网团队中的尴尬处境,自然也会萌生一些思考。我认识很多测试同学,其后续有不同的发展方向,有的转型项目经理、项目管理、团队管理,当然大部分还是继续在测试这个岗位持续深耕,有的做到了测试主管、高级测试工程师等等。像我这样转型产品的也有不少,不过更多是在前些年完成的转型。最近两年测试转产品的比例应该是呈下降趋势,所以今天借此来聊一聊为什么测试岗位(功能测试为主)转型产品越来越难,也试着回答一下前面两位伙伴的问题。01测试与产品的不解之缘本身从软件开发流程来看,产品做设计,测试验证此设计的交付物,两者在一定程度上都可以归结为“业务导向”,关注点和工作内容存在诸多联系。之前的文章需求岗如何为实施团队赋能中,也提到了两者不分家的观点。产品在制定最终的设计方案时,如果具备测试思维,会让自己的方案更细致、更健壮,尤其是异常情况的处理,提前想到了,需求评审时会更主动。最近看了团队小伙伴的年终总结,好几位都提到了自己的需求文档规则不细致,对于异常情况考虑不足等问题。所以产品和测试可以多多沟通,相互以不同的思维和对待系统的角度互补。我相信一位合格的测试人员,对于系统的细节、处理逻辑是最清楚的。因为我们常见的系统规模,大多只配很少的功能测试人员,开发大概率仅对自己的模块了解,产品大概率仅对业务流程和各功能之间的耦合关系了解。所以最近两年我们经常在进行一些功能迭代时咨询测试的意见,初步探讨系统可行性和工作量,也是基于这个原因。02优秀的测试越来越少2021和2022两年间,我大致面试了100位测试人员,base地遍布多个城市,从直观感受来看,靠谱的功能测试越来越少,使我不禁思考,为什么?可能是整体基数的原因,可能是行业重视程度和发展前景的原因,也可能是其他我没有觉察的原因,致使越来越多的测试人员真的做成了曾经行业玩笑“点点点的工具人”,很少思考功能背后的缘由,很少思考业务背后的问题。也可能没有遇到好的团队、好的领导。因为我相信在测试的过程中一定会有很多疑问,但是把疑问问出去之后,是否有人真的耐心解答?很多团队的负责人经常会说:你就按需求来、这不是你操心的…从而逐渐磨灭了各位伙伴心中的求知欲。也有很多公司、团队管理者把测试定位成一个“流程化的环节”,只是为了完成这个测试任务而招人、用人。哪里有测试需求,就把人派过去,可能一个月测一个项目,测完即走,奔赴下一个战场。这种情况对于测试从业者来说,很难形成高效的经验积累。如果是同类业务还好,可以通过不同的客户诉求、定制化场景培养业务思维;如果是不同的业务,短时间内很难理解,到头来项目做了不少,但最终沉淀下来的也许不多。即业务的连续性不足,更多的重复劳动带来的只是经验的积累,很难形成突破式成长。平心而论,测试本身在互联网行业中,入门的门槛相对较低。俗话说人人都是产品经理,与其相对的,其实人人也都可以是功能测试。所以很多其他行业想要入局互联网的,会优先选择功能测试这个岗位,因此对软件工程的理解本就有很多不足。最后,也可能是因为看不到更高的职业发展路径,让很多同学缺少长期目标,逐渐的接受自己的现状,逐渐的不再向上生长。总之,优秀的测试人员在肉眼可见的减少,而且产品圈现在也是供大于求,在供需不平衡的情况下,普通测试很难转,优秀测试不愿转(自己不愿或领导不愿)。但愿我以上表述存在“以偏概全”和“主观臆断”的逻辑谬误,因为测试出身的我,更希望测试行业能够人才辈出。诚然,有很多优秀的测试伙伴,从功能到性能、自动化、安全等等领域均有不错的发展,但更多的是比例、是整体表象,但愿这些言论不会给自己招来阵阵骂声03测试更适合做需求分析如果测试真的想转型产品,中间跨过了一个过程,这个过程是“需求分析师”。我认为功能测试最容易转型的岗位就是需求分析师,除了显而易见的功能、逻辑、细节,还有外部的沟通会给你的转型带来助力。尤其是外包类项目,项目组内的测试会有很多机会和甲方的测试人员、业务人员对接,沟通缺陷、讨论合理的场景。在此过程中,无论是对自己的表达能力、应变能力,还是业务理解能力都会有不错的提升。我当初转型,就是因为通过频繁的和客户沟通,逐渐从接收问题,变成了解决问题,逐渐开始和项目经理一起讨论需求,向开发讲解修改方案。所以如果功能测试真的想转岗,我最推荐的就是需求分析师。04需求分析和产品经理间的“窗户纸”但是需求分析和产品经理之间存在不小的区别,我在去年的一篇文章中也提到过,其中涉及团队模式的区别、工作重心的区别,最重要的是思维习惯和目标的区别。虽然很多公司的产品经理实际上也是在做需求分析的工作,但是真正的产品经理和需求分析师之间,还是有一层“窗户纸”,很薄,但是不捅破依然是两个维度,捅破了才有可能互通。就像我的产品团队,最近在制定2023年的年度目标,我的目标就是真的做产品,而非做需求。以我现阶段的理解(不一定对哈,欢迎讨论),需求分析和产品经理最大的区别在于思维方式和行动目标,这两者的区别导致了工作职责和日常内容的不同。需求岗位更多是项目制管理中的关键一环,而产品岗位更多是研发管理中的关键一环,所处的环境不同,导致了这两者的区别。即便两个岗位都在写文档、画原型、和其他岗位协同、和客户或者用户对接,但需求可能更关注于合同范围、产品更关注于业务边界;需求可能更关注于交付效率,产品可能更关注于标准化;需求可能更看重客户的意见,产品可能更看重用户的意见。需求思维和产品思维之间的转化,也很难。(特别说明:以上内容存在以偏概全的问题,希望各位能够领悟精神,不纠结于具体用词。而且对于需求和产品并没有优劣之分,只是不同公司不同团队下的模式不同罢了)所以测试更适合转型需求分析,如果真的对产品感兴趣,可以再从需求分析转型到产品。当然,很多公司的初级产品其本质更像是需求分析,如果能找到这样的公司,从初级产品经理做起也是不错的机会。05测试所处的工作环境变了随着近些年行业的发展,团队中更加强调职责分明、各司其职。虽然测试拥有从业务角度和体验角度提缺陷的权利和义务,但久而久之很容易让团队中的其他岗位不耐烦,而此时如果遇到一些相对教条化的领导,大概率不会给测试人员太多的自由度。而且对于一些第三方机构的外包测试而言,经常一个人对接多个项目,多个团队甚至多个公司。此时每个项目的出发点和利益点可能都不相同,而且项目组为了更快的上线,势必不希望测试人员过于“思维发散”、“较真”、“爱提建议”。诸如此类的工作环境,也很大程度上致使测试人员更愿意(或者不得不)恪守自己的职责边界——一切以需求文档为主需求文档上写了,我就需要测,没写就不测;写的不合理,反馈给需求人员或者业务人员来定夺。这也许是大多功能测试同学很难突破的一道坎。我记得有一段时间,测试工程师的地位和重视程度比较高,可能大家都发现了测试的必要性。但是没过多久,这阵风又没了。可能大家逐渐发现,一个高质量的项目交付,一个好的产品上线,测试仅是其中一个环节,更多的是需要从管理体系、流程规范等方面入手。所以慢慢的,很多测试同学就开始考虑要不要转行。06扪心自问,你真的想吗?城外的人想进去,城里的人想出来,盲猜各行各业有很多这样的人都有转行的想法。但是,我们需要认真考虑的是:这真的是你想要做的吗?以测试转行产品来举例,我们需要先分析自己为什么想转?是因为觉得这个岗位不受重视?没有成长空间?整日受气?不被开发尊重?还是因为什么?分析出来的原因,再进一步分析背后的底层逻辑,可能会发现最终的问题还是在自己。即便换了岗位、换了公司,现在所遇到的问题大概率还会遇到,因为我们的底层逻辑和思维习惯没有变。仅仅依靠外力,不足以推动自己的转变。所以一定要自内而外有强烈的意愿,才能让你在面对后续困难时持续斗争。否则浅尝辄止,最终会让自己更不再愿意主动求变。如果你现在是测试团队的负责人,想让自己的下属具备一定的产品思维,以便更好的开展后续的工作。这时我的建议依然是,先确定他们真的想拥有产品思维吗?或者说如何让他们有这个意愿。再确认你们的工作环境,允许、或者适合测试人员具备产品思维吗?之后才是如何培养,如何转变的问题。否则我们提出一些要求和设想,在真正推进落地时会困难重重。而本身培养产品思维、业务思维的方法有很多,我本身也需要在产品思维上不断加强。今天先不讨论怎么做的问题,最近我在读《底层逻辑》这本书,对于思维、产品、规律等方面又有了一些新的理解,待我认真读完之后,再聊怎样培养产品思维吧。07职位是定义,思维在自己回到今天标题中的“转岗”两个字,其实我最终想表达的观点是:职位只是外界对你工作内容的定义,我们从事怎样的工作,拥有怎样的生活,更关键的在于自己的思维模式和意愿程度。即便转岗,没有转换思维和习惯,依然会面临诸多问题,甚至是更严重的问题;反之当我们养成了相对好一点的习惯,培养了更成熟全面的思维模式,即便不转岗,也能有自己的办法去应对当下的问题。而且对于这些问题,我的另一个建议是【主动】,主动面对,主动接纳,主动沟通,才能主动解决。比如我们可以主动和上级沟通,表明自己的意愿和想法,看看领导怎么回答;比如我们可以主动和产品同事聊天,聊聊他在工作中的收获、困惑、甚至于做产品的心路历程,看看这些故事,是不是你想拥有的;你还可以回顾自己工作中的收获、困惑以及心路历程,通过复盘来寻找问题到底出在哪?找到关键问题,才更容易解决现象。以上就是今天的分享。因为我已经脱离测试岗位多年,更多以旁观者的角度分析,所以内容中若存在纰漏烦请多多理解、多多指教写在最后本文仅是针对一些实际情况进行分析,并不涉及测试、需求、产品三个岗位优劣的评判。任何一个优秀项目的诞生,任何一个好产品的问世,都离不开各个岗位的通力协作和各司其职。今天虽然是在探讨测试和产品之间的现象,但也能客观反映出很多其他岗位、其他从业者的疑虑。其实无论是哪个岗位,只有自己深入探索,自驱成长,长远规划,持久坚持,才能真正掌握“核心竞争力”。这份核心竞争力,能够让你应对大多数的外部因素,走出内心的焦虑和彷徨。至于如何做,因人而异,在此我分享《底层逻辑》中的两段

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论