Re: [請益] QA轉RD請益

軟工

16111

看到這文章就想到自己以前也是這樣想
給你我的歷程跟想法做參考
我目前是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的價值,
很煩...
但這就是工作的一部分。

隨手寫寫,希望對你有幫助,吃飯去。

: 請益
: 小弟非本科學士畢業目前在一家小公司擔任QA已經一年多了,發現自己對QA好像不是那麼
: 的喜歡,反而喜歡RD的工作也私底下寫了一些小工具當sideproject例如利用aws api做的
: 自動部署來跑幫朋友寫的批量google登入(目前好像被google鎖了)之類,也有寫個簡單的
: restful api
: 技能:
: Python
: Golang(沒到熟練,寫的出東西而已)
: 碰過簡單的ML
: 簡單的資料庫語法(crud)
: js(沒到熟練)
: 用過:
: docker
: aws
: 串接過api
: git
: 想請問各位大大我需要再補充哪些技能或是做些什麼才能走向RD呢?

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.125.120 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1621745230.A.73C.html
wawi21樓Pros 05/23 13:28
本人2樓感謝糾正,漏打 05/23 13:31
kvjo3樓沒做過PM 沒帶過team 就能轉TPM ?? 05/23 13:32
本人4樓PM 為什麼一定要帶Team? 這角度來說 QA 也不能轉RD囉 05/23 13:40
本人5樓 05/23 13:40
tbpfs6樓原PO在哪家公司? 05/23 13:51
本人7樓回樓上大:跟各位一樣的軟體公司,修正因排版截斷sta 05/23 14:14
本人8樓keholders 的錯字,不改了怕又改爛 05/23 14:14
MOONY1359樓QA最後一棒啊 05/23 14:32
bnd032710樓推比較 05/23 14:59
MoonCode11樓TPM是做什麼的 05/23 16:45
tbpfs12樓我其實是好奇是哪家公司,因為你的term很外商 05/23 16:49
kvjo13樓所以你認識的PM 都沒有帶team? TPM 也沒有經歷過PG 與 PM 05/23 18:55
kvjo14樓just question. 經驗不同 05/23 18:55
kvjo15樓TPM台灣定位好像比較少 因為也是國外經驗過來的位子 樣子 05/23 18:56
kvjo16樓我收過的面試 大多TPM是 Team Lead 帶8-20人不等 05/23 18:56
kvjo17樓package 150-180 up 只是說我看到的 沒有說一定 單純經驗 05/23 18:57
kvjo18樓我也跟美國的PG交流過 國外 的確也有TPM 是junior的 05/23 18:57
kvjo19樓但我實際知道的 比較多是 senior的 05/23 18:57
kvjo20樓國內有一家做通訊的 一年前找TPM 開的就是160 up 要帶過團 05/23 18:58
kvjo21樓另外還有一家 應該是外資 當時找TPM 要的也是有經驗senior 05/23 18:59
kvjo22樓為must 05/23 18:59
本人23樓我這裡指的TPM是Technical PM 係指更貼近於產品在技 05/23 19:25
本人24樓術性與可行性上的需求評估,舉例像伺服器承載的Spec 05/23 19:25
本人25樓定義,或門檻比較高的產品技術流程與需求的規劃,到 05/23 19:25
本人26樓這裡其實負責的項目已經夠複雜了,責任內容與是否要 05/23 19:25
本人27樓帶團隊的需求應該是這個職務的垂直發展,不是跨入這 05/23 19:25
本人28樓行的必需條件。會說QA是跳板,其中一個原因是QA做到 05/23 19:25
本人29樓一定的經驗,基本上應該可以培養產品與技術視角的思 05/23 19:25
本人30樓維,進一步知道團隊需求與技術可行性,當然他是不是 05/23 19:25