SDET / QA 직군에 대한 협업담 & 소견 #2
경력직 이직한 PM으로서 느낀 올드비 QA의 소중함과 중요성
- 2015년 여름 이후로는 사실상 개발자도, 풀타임 QA도 아니게 되었다.
쿠팡에 입사해서는, 왜인지 모르겠지만 모두가 PO의 생각과 발언을 매우 리스펙트하는 분위기여서
(이는 내가 잘해서가 아닌 전적으로 전임 PO님들이 훌륭하셨던 덕이라고 생각한다.)
입사 후 약 1~2 달 뒤에는, 팀 내 최고참 15년차 개발자 분들도 적극적으로 내 리드에 보조를 맞춰주셨고
여타 경력직 / 신입 개발자 분들의 업무적 자세를 보면서,
초기 스타트업의 젊은 열정은 없을지언정 (예외적으로 나보다 약간 더 일찍 입사하신 신입분에게서는 이런 열정을 느끼긴 했다, 이젠 5년 지났으니 여엇한 A급 시니어 개발자가 되셨을꺼라고 기대한다.)
모두가 '애자일'을 받아들일 준비는 어느 정도 되어있었던 것 같다. 퍼포먼스에는 차이가 있었을지언정....
어느정도 개발팀 내부 검수/코드 리뷰/퍼포먼스 검증까지 다 끝난 산출물이 PO에게 전달되서,
> 이게 2012년 당시에 네이버의 애자일 운동이 성공했다면 나왔을 next의 모습이었을까! 싶었다.
배포를 앞두고 내 역할은 최종 사용성 점검 후 배포를 최종 결정하는 거수기 역할 정도의 사용성 QA였다.
오히려 내가 tech 관점에서 꼼꼼하게 안챙겨도 되는 만큼, 그 시간에
더 사용자를 만나보고, 데이터를 더 분석하고, 더 중요하고 필요한 기능이 뭔지를 고민해서
당장 다가올 스프린트 준비와 눈앞의 이슈만 해결하는게 아닌, '로드맵'과 '비젼'을 그려야했음.
이러한 분업 덕분에 워라벨은 좋아졌고 - 특정 product에 몰입해서 원 팀으로 일하고 있다는 느낌도 받았었다. (처음엔 오 이거 이렇게 편하게 날먹이 되나! 싶었는데.... 이는 경기도 오산)
* 이후 새 프로젝트 2개를 더 맡으며.... 눈물 좀 닦겠습니다. 업무량이 2.5배로 폭증에
미국/중국에 있는 - 한국어가 전혀 안통하는 분들과 같이 (영어로..) 프로젝트를 연계했어야했다...
사실 이걸 하려면, 위와 같이 어느정도 개발 리소스가 안정적으로 확보 된 상황에서 - PO의 역할은 딱 이거다!라고 정의가 되면 가장 좋겠지만.... 현실적으로는 이것 저것 다 해야하고 업무시간엔 이런 작업을 못한다. 그러니 그냥 저녁이나 아침 일찍 야근/조근을 합니다.
* 어찌어찌해서 빠르게 쿠팡을 떠나게 되었는데 (누구나 나름의 사연은 있는데, 대략 이 시기 쿠팡내 한국인 남자 po의 퇴사율은 절정을 찍었다. '한국인' po 2명이 신규 입사하는데 반년이 걸렸는데, 그 사이에 6~7명 이상이 경력 1~2년만에 손절 후 퇴사했던 수준 / 그 당시의 동료들은 이젠 한두명 정도 남아계신 상태), 냉정하게 PO에게는 별로 안좋았지만, 같이 업무했던 개발팀과 동료급 po분들과는 여전히 좋은 사이!라고 생각한다.
이후에 다시 옮기게 된 곳은 2010'' naver 개발 문화를 여전히 고수하고 있는 11번가쪽 개발단 ('전무급인' 단장님 총괄의 개발+기획+디자인을 모두 품은 조직이라고 보면 됨)의 새 TFT 팀에 소속되어서
사내 개발 문화를 부분 애자일 / 혹은 아마존식...으로 뜯어고치는데 실무 레벨의 경력 PM으로서 거들게 되었고, 이에 대한 부분은 별도로 발표 자료를 공유용으로 브런치에 올린 바 있음
여기서 다뤄야 할 부분은, 내가 맡은 agile팀에 반인분 정도 걸친 담당 시니어 qa가 있었고, 그 아래 서너명의 테스터가 있었다. 11번가의 qa는 기획서를 기반으로 도메인 전문가로서 테스트 시나리오/체크 포인트를 찾아내던 역할이었고, 테스터는 실제로 테스팅을 하고 개발에 티켓을 날리는 분으로서
수명이 별로 오래가지 않는 상품 도메인 서비스 기획자(혹은 pm)에 비해, 오랜 근속 연차와 쌓여있는 도메인 지식을 기반으로, 엥간한 기획자보다 히스토리/스펙 문서화에 대한 기록이 남았던걸 발견할 수 있었고,
qa 한명 당 큰 도메인 하나씩을 맞고 있는데 (반면에 기획자는 도메인당 거의 3~4명이 박혀있는 수준)
스크럼 팀 기준으로는 대략 두 팀에 qa 한명이 걸쳐있어서 qa가 양쪽 스크럼에 다 참석하기 위해 두 팀의 스크럼을 나란히 붙여서 순차 진행하는걸로 시간이 조정되었다...
매우 슬프게도 나보다 1년쯤 더 일찍 들어오셔서, 입사 만 1년된 분이 11번가 상품 product 기획의 최고참이었기에..... 그리고 지금도 아마 재입사지만, 만 2~3년 되신분이 11번가 상품 product의 최고참이실꺼다...
과거 문서가 일부 파일로 공유해서 전달된거 외에는 - 아주 먼 과거부터의 히스토리를 알 방법이 없어서
개발팀의 wiki도 보고, 예외처리 문서도 보고, qa쪽에서 관리하는 스펙 / 도메인 정리 문서를 기반으로 다른 도메인 영역에 대한 히스토리/기능별 예외 처리나/각종 테스트 노하우를 빠르게 습득할 수 있긴 했다.
그리고 이 부분에 대한 커버까지 어느정도는 qa/테스팅 레벨에서 거의 다 해결되기 때문에, po입장에선 테스팅이 참 편하다. 가끔은 각종 회의로 너무나 바빠서 - 배포 다 된 뒤에 한번 기능 써보는걸로 끝날때도 있다.
> 즉, pm/po의 입장에서 qa는 매우 소중한 동료이고, 없어서는 안될 존재이다. (직군 변경에 따른 스탠스도 급변)
> 커머스의 상품 도메인은 약간은 불지옥 느낌인데, 커머스의 모든 업무는 '상품' 도메인을 안 거칠 수가 없어서
회사에서 돌아가는 모든걸 알아야하고, 수많은 팀의 프로젝트에 서브로 뒷바라지 하면 내 일 할 시간이 없는데
막상 이랬다가는 넌 스스로는 뭐했니 하면서 연례 평가가 박하다....... 사실 나도 실제로 그런 느낌이라서 연말
내 프로젝트 진행 할때는 그냥 눈 딱감고 석달간 다른쪽 지원을 거의 멈췄다가, 입사 10년차+의 타부서 어르신 분들에게 불려가서 분노의 린치를 먹었지만... 그래도 뭐 어쩌겠는가 =_= 이거 안하면 회사가 망한다는데
> 코어 직군이 중요하면 제발 그만큼 충원을 하고, 잘하고 있는 사람 괴롭힘 안당하게 우대 해줍시다.
하여간 - qa 업무로 다시 돌아와서,
여기서도 테크니컬 qa/테스터가 기능에 대한 부분은 다 짚어주니까,
상대적으로 pm은 고객 지표와, 기능 구현 및 사용성에 집중할 수 있었다.
또한 제품의 1차 사용자이자 오랜 사용자로서, 개선의 히스토리를 파악하고 있는 상태에서
새 기능의 불편한 부분이나 이슈에 대한 의견 개진도 해준다는 점에서 pm의 보조자 역할도 있겠다.
> 결론적으로 테크니컬 qa는, 한 회사에 오래오래 잘 자녀줄 올드비가 한명 있다면 참 좋을 직군이다. 계속 바뀔꺼면 사실 큰 의미는 없을지도 모르겠다.
