为什么测试转产品越来越难了?

4 评论 11926 浏览 23 收藏 19 分钟

一些做测试的同学,可能会转型项目经理、项目管理、团队管理,或者转型产品,各种不同的转型方向。本文作者结合自己转型产品的经验,分析为什么测试岗位转型产品越来越难?希望能给你带来一些启发。

分享我近两年的一个感受,并试着分析其背后的原因。职位只是外界对你工作内容的定义,我们从事怎样的工作,拥有怎样的生活,更关键的在于自己的思维模式和意愿程度。

这又是一篇拖更很久的文章,早在去年夏天,就有测试小伙伴问过我,是否可以转型做产品。一位甲方的测试负责人也和我聊过类似的问题,如何让测试人员具备更好的业务思维。虽然两位朋友的出发点不同,但其背后都反映了两个岗位之间千丝万缕的联系。

因为我本就是开发毕业,测试入行,之后通过测试+需求这“一头一尾”的把控,逐渐转型项目管理,又恰逢合适的机会最终走上产品这条路。

因此,测试岗位,于我个人始终存在不一样的感情。做过、招过、见过,也经历过这个岗位在互联网团队中的尴尬处境,自然也会萌生一些思考。

我认识很多测试同学,其后续有不同的发展方向,有的转型项目经理、项目管理、团队管理,当然大部分还是继续在测试这个岗位持续深耕,有的做到了测试主管、高级测试工程师等等。像我这样转型产品的也有不少,不过更多是在前些年完成的转型。

最近两年测试转产品的比例应该是呈下降趋势,所以今天借此来聊一聊为什么测试岗位(功能测试为主)转型产品越来越难,也试着回答一下前面两位伙伴的问题。

01 测试与产品的不解之缘

本身从软件开发流程来看,产品做设计,测试验证此设计的交付物,两者在一定程度上都可以归结为“业务导向”,关注点和工作内容存在诸多联系。之前的文章需求岗如何为实施团队赋能中,也提到了两者不分家的观点。

产品在制定最终的设计方案时,如果具备测试思维,会让自己的方案更细致、更健壮,尤其是异常情况的处理,提前想到了,需求评审时会更主动。

最近看了团队小伙伴的年终总结,好几位都提到了自己的需求文档规则不细致,对于异常情况考虑不足等问题。

所以产品和测试可以多多沟通,相互以不同的思维和对待系统的角度互补。

我相信一位合格的测试人员,对于系统的细节、处理逻辑是最清楚的。因为我们常见的系统规模,大多只配很少的功能测试人员,开发大概率仅对自己的模块了解,产品大概率仅对业务流程和各功能之间的耦合关系了解。所以最近两年我们经常在进行一些功能迭代时咨询测试的意见,初步探讨系统可行性和工作量,也是基于这个原因。

02 优秀的测试越来越少

2021和2022两年间,我大致面试了100位测试人员,base地遍布多个城市,从直观感受来看,靠谱的功能测试越来越少,使我不禁思考,为什么?

可能是整体基数的原因,可能是行业重视程度和发展前景的原因,也可能是其他我没有觉察的原因,致使越来越多的测试人员真的做成了曾经行业玩笑“点点点的工具人”,很少思考功能背后的缘由,很少思考业务背后的问题。

也可能没有遇到好的团队、好的领导。因为我相信在测试的过程中一定会有很多疑问,但是把疑问问出去之后,是否有人真的耐心解答?很多团队的负责人经常会说:你就按需求来、这不是你操心的…从而逐渐磨灭了各位伙伴心中的求知欲。

也有很多公司、团队管理者把测试定位成一个“流程化的环节”,只是为了完成这个测试任务而招人、用人。哪里有测试需求,就把人派过去,可能一个月测一个项目,测完即走,奔赴下一个战场。

这种情况对于测试从业者来说,很难形成高效的经验积累。如果是同类业务还好,可以通过不同的客户诉求、定制化场景培养业务思维;如果是不同的业务,短时间内很难理解,到头来项目做了不少,但最终沉淀下来的也许不多。

即业务的连续性不足,更多的重复劳动带来的只是经验的积累,很难形成突破式成长。

平心而论,测试本身在互联网行业中,入门的门槛相对较低。俗话说人人都是产品经理,与其相对的,其实人人也都可以是功能测试。所以很多其他行业想要入局互联网的,会优先选择功能测试这个岗位,因此对软件工程的理解本就有很多不足。

最后,也可能是因为看不到更高的职业发展路径,让很多同学缺少长期目标,逐渐的接受自己的现状,逐渐的不再向上生长。

总之,优秀的测试人员在肉眼可见的减少,而且产品圈现在也是供大于求,在供需不平衡的情况下,普通测试很难转,优秀测试不愿转(自己不愿或领导不愿)。

但愿我以上表述存在“以偏概全”和“主观臆断”的逻辑谬误,因为测试出身的我,更希望测试行业能够人才辈出。诚然,有很多优秀的测试伙伴,从功能到性能、自动化、安全等等领域均有不错的发展,但更多的是比例、是整体表象,但愿这些言论不会给自己招来阵阵骂声

03 测试更适合做需求分析

如果测试真的想转型产品,中间跨过了一个过程,这个过程是“需求分析师”。

我认为功能测试最容易转型的岗位就是需求分析师,除了显而易见的功能、逻辑、细节,还有外部的沟通会给你的转型带来助力。

尤其是外包类项目,项目组内的测试会有很多机会和甲方的测试人员、业务人员对接,沟通缺陷、讨论合理的场景。在此过程中,无论是对自己的表达能力、应变能力,还是业务理解能力都会有不错的提升。

我当初转型,就是因为通过频繁的和客户沟通,逐渐从接收问题,变成了解决问题,逐渐开始和项目经理一起讨论需求,向开发讲解修改方案。

所以如果功能测试真的想转岗,我最推荐的就是需求分析师。

04 需求分析和产品经理间的“窗户纸”

但是需求分析和产品经理之间存在不小的区别,我在去年的一篇文章中也提到过,其中涉及团队模式的区别、工作重心的区别,最重要的是思维习惯和目标的区别

虽然很多公司的产品经理实际上也是在做需求分析的工作,但是真正的产品经理和需求分析师之间,还是有一层“窗户纸”,很薄,但是不捅破依然是两个维度,捅破了才有可能互通。就像我的产品团队,最近在制定2023年的年度目标,我的目标就是真的做产品,而非做需求。

以我现阶段的理解(不一定对哈,欢迎讨论),需求分析和产品经理最大的区别在于思维方式和行动目标,这两者的区别导致了工作职责和日常内容的不同。

需求岗位更多是项目制管理中的关键一环,而产品岗位更多是研发管理中的关键一环,所处的环境不同,导致了这两者的区别。

即便两个岗位都在写文档、画原型、和其他岗位协同、和客户或者用户对接,但需求可能更关注于合同范围、产品更关注于业务边界;需求可能更关注于交付效率,产品可能更关注于标准化;需求可能更看重客户的意见,产品可能更看重用户的意见。

需求思维和产品思维之间的转化,也很难。

特别说明:以上内容存在以偏概全的问题,希望各位能够领悟精神,不纠结于具体用词。而且对于需求和产品并没有优劣之分,只是不同公司不同团队下的模式不同罢了)

所以测试更适合转型需求分析,如果真的对产品感兴趣,可以再从需求分析转型到产品。当然,很多公司的初级产品其本质更像是需求分析,如果能找到这样的公司,从初级产品经理做起也是不错的机会。

05 测试所处的工作环境变了

随着近些年行业的发展,团队中更加强调职责分明、各司其职。虽然测试拥有从业务角度和体验角度提缺陷的权利和义务,但久而久之很容易让团队中的其他岗位不耐烦,而此时如果遇到一些相对教条化的领导,大概率不会给测试人员太多的自由度。

而且对于一些第三方机构的外包测试而言,经常一个人对接多个项目,多个团队甚至多个公司。此时每个项目的出发点和利益点可能都不相同,而且项目组为了更快的上线,势必不希望测试人员过于“思维发散”、“较真”、“爱提建议”。

诸如此类的工作环境,也很大程度上致使测试人员更愿意(或者不得不)恪守自己的职责边界——一切以需求文档为主

需求文档上写了,我就需要测,没写就不测;写的不合理,反馈给需求人员或者业务人员来定夺。这也许是大多功能测试同学很难突破的一道坎。

我记得有一段时间,测试工程师的地位和重视程度比较高,可能大家都发现了测试的必要性。但是没过多久,这阵风又没了。可能大家逐渐发现,一个高质量的项目交付,一个好的产品上线,测试仅是其中一个环节,更多的是需要从管理体系、流程规范等方面入手。所以慢慢的,很多测试同学就开始考虑要不要转行。

06 扪心自问,你真的想吗?

城外的人想进去,城里的人想出来,盲猜各行各业有很多这样的人都有转行的想法。但是,我们需要认真考虑的是:这真的是你想要做的吗?

以测试转行产品来举例,我们需要先分析自己为什么想转?是因为觉得这个岗位不受重视?没有成长空间?整日受气?不被开发尊重?还是因为什么?

分析出来的原因,再进一步分析背后的底层逻辑,可能会发现最终的问题还是在自己。即便换了岗位、换了公司,现在所遇到的问题大概率还会遇到,因为我们的底层逻辑和思维习惯没有变

仅仅依靠外力,不足以推动自己的转变。所以一定要自内而外有强烈的意愿,才能让你在面对后续困难时持续斗争。否则浅尝辄止,最终会让自己更不再愿意主动求变。

如果你现在是测试团队的负责人,想让自己的下属具备一定的产品思维,以便更好的开展后续的工作。这时我的建议依然是,先确定他们真的想拥有产品思维吗?或者说如何让他们有这个意愿。再确认你们的工作环境,允许、或者适合测试人员具备产品思维吗?之后才是如何培养,如何转变的问题。否则我们提出一些要求和设想,在真正推进落地时会困难重重。

而本身培养产品思维、业务思维的方法有很多,我本身也需要在产品思维上不断加强。今天先不讨论怎么做的问题,最近我在读《底层逻辑》这本书,对于思维、产品、规律等方面又有了一些新的理解,待我认真读完之后,再聊怎样培养产品思维吧。

07 职位是定义,思维在自己

回到今天标题中的“转岗”两个字,其实我最终想表达的观点是:

职位只是外界对你工作内容的定义,我们从事怎样的工作,拥有怎样的生活,更关键的在于自己的思维模式和意愿程度。

即便转岗,没有转换思维和习惯,依然会面临诸多问题,甚至是更严重的问题;反之当我们养成了相对好一点的习惯,培养了更成熟全面的思维模式,即便不转岗,也能有自己的办法去应对当下的问题。

而且对于这些问题,我的另一个建议是【主动】,主动面对,主动接纳,主动沟通,才能主动解决。

  • 比如我们可以主动和上级沟通,表明自己的意愿和想法,看看领导怎么回答;
  • 比如我们可以主动和产品同事聊天,聊聊他在工作中的收获、困惑、甚至于做产品的心路历程,看看这些故事,是不是你想拥有的;
  • 你还可以回顾自己工作中的收获、困惑以及心路历程,通过复盘来寻找问题到底出在哪?

找到关键问题,才更容易解决现象。

以上就是今天的分享。因为我已经脱离测试岗位多年,更多以旁观者的角度分析,所以内容中若存在纰漏烦请多多理解、多多指教

写在最后

本文仅是针对一些实际情况进行分析,并不涉及测试、需求、产品三个岗位优劣的评判。任何一个优秀项目的诞生,任何一个好产品的问世,都离不开各个岗位的通力协作和各司其职。

今天虽然是在探讨测试和产品之间的现象,但也能客观反映出很多其他岗位、其他从业者的疑虑。其实无论是哪个岗位,只有自己深入探索,自驱成长,长远规划,持久坚持,才能真正掌握“核心竞争力”。

这份核心竞争力,能够让你应对大多数的外部因素,走出内心的焦虑和彷徨。至于如何做,因人而异,在此我分享《底层逻辑》中的两段话,希望能给你带来一点帮助。

学会选择,常常就是学会放弃:选择一个,放弃其他。选择有时比努力重要,但放弃有时比选择更重要。我们应勇敢选择,然后享受好处,承担坏处。

努力的时候,都希望大家瞬间认可,而出了问题后,却不去想几个月之前的懈怠。这是很多人都容易走进的思维误区。

——《底层逻辑》

本文没有写具体的方法,这和我之前的风格有些差异。但最近的体验就是:想通了,方法自然会出现;想不通,再多的建议也是徒劳,况且这些建议不一定真的有效。

所以,希望我们能通过不同的文字体会字里行间的观点~

专栏作家

不想延期,公众号:不想延期,人人都是产品经理专栏作家。半路转行的B端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 请问转行做测试有年龄要求吗?

    来自广东 回复
    1. 理论上没有,但肯定是年龄越大越难转。假如一位工作十年的人要转岗测试,起步从功能测试开始,薪资低,发展空间会更受限。而且现在更多的是测试岗位想转岗,很少见到其他岗位要转到测试的,除非是非互联网行业从业者

      来自河北 回复
  2. 赞同!我也是从测试入门了行业,后来一直做产品,对测试这个岗位和部门总有一些感情。最近刚好和发展受阻的测试同学聊转岗的事情,和作者的看法很接近,测试太容易被组织限制在一个框里了,加上测试的工作本来就是“发现更多的BUG”,使测试的创造性思维更难。
    PS:巧了巧了,昨天刚刚学完刘润老师的《底层逻辑》,觉得第三章的个体计划,挺符合您的观点

    来自浙江 回复
    1. 底层逻辑我刚看了一半,因为想法太多刻意停下来写了读后感,然后再继续读。既然有这么多相似的经历,你可以关注我的公众号然后加个好友一起学习、探讨哈

      来自河北 回复