Re: [请益] QA转RD请益

楼主: fourplayers (Fusion)   2021-05-23 12:47:08
看到这文章就想到自己以前也是这样想
给你我的历程跟想法做参考
我目前是QA大概加减做了大约十年
历程: QA -> iOS RD -> QA (目前)
先分析职位的 POC
[RD]
Pros
* Domain Knowledge 深度深:如果你爱某些特定议题,做久了是有机会成为专家
* 专案导向:如果是敏捷开发,通常会有一个周期让你专心做特定的事情
* Visibility 高:若负责的专案是公司重视的,往往比较容易被看见
* OKR 较容易撰写:因为是专案导向,固然是做完事情为目标(除主管职外)
* 薪资成长空间:(普遍公司)可能会优于 QA (我知道某公司不一定)
* 有共同目标的战友:协同开发,学习速度很快
Cons
* 码农:你写的Code不是你的,你想做的,不一定在工作上能实现
* 陨石开发:若不幸跟到这种,神明会制造大量陨石,让你 Context Switch 不完
* Bug 风暴:专案开发期间一定会需要捡一些 Bug 修,还有时程上的压力
* Spec Changes:才刚写好的架构,可能一次的 spec change 又要改了
* 协同开发:如果碰到很雷的,不只会破坏程式架构,也可能在协同作业上造成很多困扰
* 同侪压力大:因为一山还有一山高,容易碰到互相竞争的战友
(这会影响薪资涨幅、能见度、有些公司还会有恶性竞争)
* 脏Code:不是你能控制的,有时候是商业或时程考量迫使写出一堆 workaround
[QA]
Pros
* Domain Knowledge 广:QA 要看的是E2E、Integration固然接触的技术广
* 比RD更了解产品架构:呈上所说,因为广度,所以往往QA较能发现产品弱点
* 自制工具改善效率:QA 做的事情杂,有些没效率,若有能力自制工具改善效率在QA世界里,是有很大的空间
* 懂程式的QA不多:这在QA的世界满吃香的,通常能见度会比其他QA来得高
* 转TPM转RD:QA我认为是一个跳板,如果你把它看成是一个优点的话
* 可以选择自己想要的架构做测试:如上所说,一个系统复杂,
QA使用的架构不可能只有一种,通常QA会需要找到很多工具或架构开发自动化。
这意味着你可以学到很多技术(但能请益的人有限)
Cons
* Domain Knowledge:广而不精,需要时间、贵人、毅力补齐某些技术
* OKR 难以量化贡献:要说找到Bug的数量?还是最佳化开发流程什么呢?要懂说故事
* 沟通技术:有些人觉得是优点,我认为这是缺点,QA需要大量的沟通技巧处理 stakehold
(做QA的人可能懂我在说什么)
* 重工率高:不只重工、反复做一样的事情也很常见
例:1. Bug 就像回力镖,开出去的Bug回来后还是要测,测不过又要重来
2. 新Feature的多寡决定 Regression 的多寡,每个循环越来越重
* 协作机会不大:通常QA都是少打多的状态,一个QA负责一甚至多的 Feature or Scenario
所以在写自动化架构时,若不是同一套,则很可能出现单打独斗的状况
这时候很需要靠自己自发性的杀出一条路,独立作业。
* 自我实现与成就感不高:除非自己知道在QA能发挥什么,
否则要得到别人的肯定,在QA是比较难的,通常是找到很有价值的Bug(刻板印象)
刚打的一堆被手机排版婊到...消失了(尽力还原了)
可能还有观点有缺漏,欢迎大家补上感谢!
总结一下
要先想想,转RD的目的是因为你对“特定技术有兴趣吗?”
如果不是,那技术这方面不一定要透过转职才能得到你要的
“把喜欢做的事情变成工作,不一定让你比较开心”
我自己喜欢在 QA 工作过程中,
学一些技术,觉得有趣
刚好私下找到自己爱的议题,
就用工作上或是自己学到的技能套用在
“自己的专案”
譬如说,自动抢票啊(教坏小朋友...)、
爬虫啊、APP 之类的
那反而可以找到莫大的乐趣,
有别于把程式当成工作的朋友们。
当然,这是我的方式,
我自认为我若转到 RD 应该是走了一阵子
我可能就阵亡了,
毕竟我对技术的广度比较有兴趣,
简单说我比较花心啦...
那QA就比较适合我这种人
反之,问问你自己,
你对某些 Domain 情有独钟,
那你可能真的很适合 RD
我大概是在 30 岁那年决定自己未来要走路,
所以我最终还是选择 QA
我觉得,对我来说没有感觉后悔,
反而觉得路满广的,也不会对程式疲乏
只是每天都要思考怎么量化QA的价值,
很烦...
但这就是工作的一部分。
随手写写,希望对你有帮助,吃饭去。
※ 引述《kornkorn78 (阿强)》之铭言:
: 请益
: 小弟非本科学士毕业目前在一家小公司担任QA已经一年多了,发现自己对QA好像不是那么
: 的喜欢,反而喜欢RD的工作也私底下写了一些小工具当sideproject例如利用aws api做的
: 自动部署来跑帮朋友写的批量google登入(目前好像被google锁了)之类,也有写个简单的
: restful api
: 技能:
: Python
: Golang(没到熟练,写的出东西而已)
: 碰过简单的ML
: 简单的数据库语法(crud)
: js(没到熟练)
: 用过:
: docker
: aws
: 串接过api
: git
: 想请问各位大大我需要再补充哪些技能或是做些什么才能走向RD呢?
作者: wawi2 (@@)   2021-05-23 13:28:00
Pros
楼主: fourplayers (Fusion)   2021-05-23 13:31:00
感谢纠正,漏打
作者: kvjo (同名专辑)   2021-05-23 13:32:00
没做过PM 没带过team 就能转TPM ??
楼主: fourplayers (Fusion)   2021-05-23 13:40:00
PM 为什么一定要带Team? 这角度来说 QA 也不能转RD囉?
作者: tbpfs (http://0rz.tw/Uk989)   2021-05-23 13:51:00
原PO在哪家公司?
楼主: fourplayers (Fusion)   2021-05-23 14:14:00
回楼上大:跟各位一样的软件公司,修正因排版截断stakeholders 的错字,不改了怕又改烂
作者: MOONY135 (谈无欲)   2021-05-23 14:32:00
QA最后一棒啊
作者: bnd0327 (阿噗噗)   2021-05-23 14:59:00
推比较
作者: MoonCode (MoonCode)   2021-05-23 16:45:00
TPM是做什么的
作者: tbpfs (http://0rz.tw/Uk989)   2021-05-23 16:49:00
我其实是好奇是哪家公司,因为你的term很外商
作者: kvjo (同名专辑)   2021-05-23 18:55:00
所以你认识的PM 都没有带team? TPM 也没有经历过PG 与 PMjust question. 经验不同TPM台湾定位好像比较少 因为也是国外经验过来的位子 样子我收过的面试 大多TPM是 Team Lead 带8-20人不等package 150-180 up 只是说我看到的 没有说一定 单纯经验我也跟美国的PG交流过 国外 的确也有TPM 是junior的但我实际知道的 比较多是 senior的国内有一家做通讯的 一年前找TPM 开的就是160 up 要带过团另外还有一家 应该是外资 当时找TPM 要的也是有经验senior为must
楼主: fourplayers (Fusion)   2021-05-23 19:25:00
我这里指的TPM是Technical PM 系指更贴近于产品在技术性与可行性上的需求评估,举例像服务器承载的Spec定义,或门槛比较高的产品技术流程与需求的规划,到这里其实负责的项目已经够复杂了,责任内容与是否要带团队的需求应该是这个职务的垂直发展,不是跨入这行的必需条件。会说QA是跳板,其中一个原因是QA做到一定的经验,基本上应该可以培养产品与技术视角的思维,进一步知道团队需求与技术可行性,当然他是不是资深的,我的认知是要看TPM负责的范围来判断。不过台湾有台湾的玩法回tp大:我是伪外商,待过的公司都是类似风格回kv大:我认识的公司PM有些有,有些的确没有,甚至一个产品有多个PM满常见的
作者: Samuellu (JellyFish水母鱼)   2021-05-23 22:53:00
推一个
作者: lairrol (小黑)   2021-05-23 23:21:00
TPM 大部分会想找的都会偏 Technical XD
作者: viper9709 (阿达)   2021-05-23 23:33:00
推分享
作者: nmns0110 (奶油塔)   2021-05-23 23:51:00
推分享
作者: e007926 (JeremyC)   2021-05-24 03:09:00
推分享,大大点出许多困扰我的部分,目前也在尝试寻找QA成就感中..
作者: Jamegil   2021-05-24 14:00:00
推分享
作者: undeader (宒宒)   2021-05-24 15:44:00
推分享!!
作者: joel913 (没事多喝水)   2021-05-26 23:59:00
推原po分享,对于QA经验分享很棒

Links booklink

Contact Us: admin [ a t ] ucptt.com