PM-Developer-Tester 삼박자의 시작
사실은 실리콘밸리 출장 당시, 시애틀을 들렀다가 샌프란시스코로 이동하는 일정이었다.
글을 쓰는 순서도 일정과 맞추려고 앞서 올라간 1-7회 까지의 글은 실리콘밸리에서 방문했던 회사 순서이다. 시애틀에서 방문한 Amazon과 MS, 이 두 회사는 내용 정리가 좀 늦어져서 실리콘밸리 내용을 먼저 올리게 됐다.
뭐, 말을 안했으면 이 순서는 나만 아는거겠지만 뭐 그렇다고...
난 LG전자에 다니고 있는데, 첫 입사는 휴대폰 사업부로 했다.
Verizon 담당이라 New Jersey로 장기 출장을 몇 번 갔었는데, 시애틀 MS 본사에는 그 당시에 New Jersey 법인에서 근무했던 옛 동료가 있다. 처음 출장지에서 봤을 때 일하는걸 보고 되게 똑똑하다고 생각했고 일하는 방식이 비슷해서 꽤나 죽이 잘 맞았던 그 동료는 내가 이번에 시애틀과 실리콘밸리로 출장을 간다는 소식을 전하자 매우 반겨줬다. 휴대폰 사업부에서 현 조직으로 이동하기 몇달 전 시애틀의 AT&T로 출장을 갔다가 마지막으로 본게 2012년도였다. 그 이후론 시애틀에 갈 일이 없어서 3년만에 만나는거였는데, 사람들을 데리고 간다는 말을 듣곤 적극적으로 미팅을 잡는 것을 도와주었다. 게다가 내가 요즘 스타텁에 관심도 많고 Lean UX를 공부한다는걸 알곤 Eric Ries의 Lean Startup 책을 선물해주었다. 이런 센스남같으니라고.
참고로 이번 방문의 모든 만남은 이렇게 내 인적 네트웍을 총 동원하여 지인 찬스를 백분 활용했다.
나의 지인, 그리고 나의 지인의 지인. 그럴려면 친화력은 필수다.
한국인이 참 많은 회사
시애틀 MS는 3년 전에 지인을 만나러 왔던 적이 있다. 규모가 커서 많이 놀랐었는데, 우리가 만나기로 한 미팅룸으로 갔더니 꽤 많은 분들이 오고 계셨다.
한국에서 함께 간 동료들은 모두 개발자이고, 영어권 native는 아니기 때문에 방문한 모든 회사에서 한국인을 주로 만났다. MS는 10여개의 회사 중에서도 가장 많은 직원분들이 참석해주셨는데, 한국인 커뮤니티가 있다는 이야기를 듣고 깜짝 놀랐다. MS는 그 정도로 한국인이 많은 회사구나!
* 참석해주신 분들은 Exchange server PM, Windows server PM, Azure, Cloud, Surface PM, Windows Phone, IoT, 마케팅.. 등 우리가 흔히 들어본, 관심있던 MS의 제품군에서 근무하고 계셨다.
개발 Trio 모델의 시작 (PM-Developer-Tester)
MS는 과거부터 다른 많은 SW 회사들의 벤치마킹 대상이었다.
SW 개발에 필요한 역할자를 PM(Product/Program Manager), Developer, Test 이 세 가지로 나누어 개발 Trio 모델을 굳건하게 만든 곳이기도 하다.
과거에 MS가 Trio 모델을 선택한 이유는 제품 개발 싸이클이 길었기 때문이다. Windows나 Office와 같은 제품들을 패키지 형태로 배포할 때는 1년 이상씩 개발 기간을 가져가기 때문에 trio 모델이 적합했다.
Software를 CD롬에 담아 패키지로 릴리즈한다는 것은, 그것을 사용자가 PC에 인스톨한 후에 문제가 발생했을 때 고쳐주기 힘들다는 뜻이다. 따라서 문제가 단 하나라도 생기면 안됐고, 그래서 test에 엄청 공을 들였다. 예를 들어, Window를 개발하는 사람들 중 한 명이 코드 한줄을 잘못 커밋하면 그게 복구될 때까지 다른 모든 사람들이 일을 멈춰야하는 어마어마한 상황이 발생했다. 비용 손실을 커진다는걸 뜻한다.
하지만 현재는 "Service"로 세상이 변했다. 더이상 SW 패키지를 CD롬이 아닌 클라우드로 서비스할 수 있게 된 것이다. 따라서 SW에 변경사항이 생기면 언제든 업데이트할 수 있기 때문에 더이상 싸이클이 길 필요가 없어졌다. 더이상 기존의 trio 모델이 딱 맞는 옷은 아닌게 되었다.
이에 따라 한 가지 재밌는 현상이 나타났는데, MS의 trio 모델을 따라 한국 유수 회사들이 만들었던 SDET(Software Development Engineer in Test) 역할은 MS 내에서는 현재 비중이 작아졌고, Dev와 Test의 경계가 모호해져 둘을 합쳐 Engineering 팀으로 부른다고 한다. 일부 팀은 아예 test 조직이 없는 곳도 있다. 이런 상황이기 때문에 Dev 중심으로 데이터 분석과 product code를 만드는 일을 같이 하는 개발자가 점점 더 중요해졌다.
즉, 예전에는 test가 완벽해야 릴리즈 했다면 이제는 빠르게 delivery하고 patch를 활용하는 편으로 변화했다. 엄격함보다는 속도를 중시하는 문화로 변화하고 있다.
PM의 역할?
Product/Program Manager을 지칭하는 PM은 한마디로 일이 되게 하는데 필요한 모든 일을 수행한다. "Make it happen"하는 역할로, 개발 빼고 모든 일을 다 한다고 보면 된다.
- 고객과 개발자 사이의 통로 역할
- PM specification을 정의 (개발자가 개발을 시작할 수 있는 수준으로)
- 일을 나누고 우선순위를 결정
- Dev leader, test leader와 커뮤니케이션. (이 때 Dev는 PM이 올바른 결정을 할 수 있도록 정보를 전달해야 함)
- 요구사항 단계에서 customer 대표. MVP들과 미리 소통해서 이슈를 잡아냄
- PM은 Planning Team과 협업하기도 하지만 필요한 요구사항을 직접 발굴하기도 함
또 하나, PM의 중요한 업무는 user의 data log를 분석해서 예측하는 것이다. 이는 새로운 feature를 만들 때 사용한다.
우리나라의 회사에서는 보통 개발자로 시작해 연차가 쌓이면 매니저가 되는 것이 마치 포상인 것처럼 되는 경우를 다분하게 볼 수 있지만, 미국에서 PM은 전문적인 역할이다.
즉, 경력이 쌓인 개발자가 PM을 하는 것이 아니라 해당 일에 적합하고 재능이 있는 사람이 PM 역할을 수행한다. 따라서 MS 내에서도 팀마다 다르지만 대학 졸업한 신입이 PM을 하는 경우도 있고, 신입 PM과 경력 10년 이상 dev leader가 함께 일하는 경우도 있다.
의사결정은 Data 기반으로
이는 기존 구조에서 Quality를 quantify하기 힘들다는 점이 드러났던 것이 단초가 되었는데, 우리가 얼마나 뒤쳐져있는지, 앞서있는지 논의하는 것이 필요했다.
예전엔 리더들이 직관이로 "이거 만들자!"고 했다면, 현재는 의사결정이 data 기반으로 분석하여 이루어진다. 어떤 feature를 먼저 개발해야 하는지, 어떤 서비스를 제공해야 하는지, 어떤 priority를 가져야 하는지 등에 대해서 직관으로 하나를 찍어서 만들기엔 세상이 너무 발전했고 고객은 똑똑해졌다.
Needs를 발견하고 건의하는 것은 누구나 가능하며 권장하며, 회사에서 인정 받는 분위기를 조성하고 있다.
또 일을 하기로 결정되면 팀이 그 일에 focusing할 수 있도록 TL들이 개발자들과 data를 뽑아서 부서장에게 올리고, 이 것을 마케팅과 story board로 작업해서 요구사항을 만들어낸다.
업무 환경
시나리오 상위는 마케팅과 개발팀이 함께 story boarding 작업을 한다. 이 때 PM이 PO(Product Owner) 역할을 하여 Agile Process로 진행하기도 한다.
개발해야 하는 요구사항 중 '어떤 것을 먼저 하냐?'에 대한 의사결정 때문에 Tech Leader와 Dev Leader는 기민하게 협업한다. operational한 업무나 고치면 좋지만 급하지 않은 일이 발생한 경우 slack 있는 동료가 가져가서 처리한다. 이 때 conflict이 생기지 않도록 Dev Manager가 관리한다.
조직 이동은 업무를 한지 3년정도 되면 그 후엔 이동을 권장하고 팀장의 허락이 필요 없다.
개발 커뮤니케이션은 주로 이메일로 진행하며 Visual Studio Online을 사용하기도 하지만 너무 무거워
Trello, Slack을 사용하는 팀도 있다. 보안에 대한 정책은 팀마다 다르다.
예전엔 브라우저도 IE(Internet Explorer)를 썼지만, 현재는 Industry가 함께 발전해야 한다는 인식으로 변해가고 있어서 크롬 같은 타사 제품도 사용을 허용하는 등 점점 개방적인 분위기로 변하고 있다.
서서 일하는 사람이 많은데 병원 진단서 있으면 서서 일할 수 있는 책상 및 장비들을 회사에서 지원해준다.