데이터를 추출할 수 있으면 무궁무진한 분석을 할 수 있다. 위 이미지는 런던의 타워브리지 폐쇄로 인한 트래픽 변화를 데이터로 시각화한 것이다. 2016년 말 타워브리지는 3개월 동안 폐쇄되었는데, 이로 인해 매일 2만 대가 넘는 차가 통행 제한을 받았다. 그리고 이에 대한 데이터 분석으로 템즈 강을 기준으로 남쪽으로 이동할 때 폐쇄 전보다 시간이 약 65% 증가하고, 북쪽으로 이동할 때는 시간이 약 30% 증가했다는 데이터를 얻을 수 있었다.** 관련 글: Examining the Impact of the London Tower Bridge Closure (출처: medium.com) 이런 데이터 분석으로 드라이버와 라이더가 어떻게 움직여야 더 많은 고객을 태우고, 어떻게 시간을 절약해 목적지로 이동할 수 있는지 도울 수 있다. 내가 SQL을 배우게 된 계기는 매주 사업지표를 모니터하고 보고해야 하기 때문이었다. 사업지표가 급등하거나 하강했을 때 그 이유를 분석해야 하는데, 데이터를 다루는 팀에게 물어봐야 하니 업무의 속도가 붙지 않았다. 처음에는 어디서부터 시작해야 할지 몰라 SQL을 잘하는 동료가 쓴 쿼리(query)*를 수정해 데이터를 뽑아봤지만 오류가 많았다.* 프로그래밍 언어를 위한 명령어 프로젝트 매니저로 일하는 요즘은 SQL을 쓰는 일이 드물다. 그래도 잊지 않기 위해 매일 오후 다섯 시부터 한 시간 동안은 SQL을 사용하는 업무를 하려고 일정을 비워둔다. 데이터를 뽑아야 하는 일이 있으면 직접 하려고 한다. SQL을 학습하는 최고의 방법은 꾸준히 사용하는 것이기 때문이다.운영업무직에 지원할 때 SQL을 할 줄 알면 플러스 점수를 받는다. 게다가 배우기 어렵지 않다. SQL에 관심이 있다면 코세라의 Managing Big Data with MySQL 과정을 추천한다. 옵션으로 청강(Audit)을 선택하면 무료이고, 한국어 자막도 있다. 나는 스터디파이(studypie)라는 온라인 교육 스타트업을 통해서 SQL스터디 그룹을 운영하는데, 이런 스터디 그룹에 참여하는 것도 좋은 방법이다.개발팀과 일하기: 해결책이 아닌 문제를 말하라우버에서 처음 1년은 미국 동부를, 두 번째 해는 싱가포르 지사로 옮겨가 아시아 지역을 담당했다. 이렇게 한 지역을 책임지는 운영자로서 자나 깨나 이 지역에서 어떻게 하면 서비스가 더 나아질지 고민하는 건 당연했다. 당시 우버 드라이버(운전기사) 앱은 아시아 지역에서 사용하기에 흔한 말로 '무거웠다'. 실리콘밸리 본사의 개발자가 쓰는 아이폰에는 이 앱이 잘 돌아갈지 모르겠지만, 아시아에서는 아니었다. 인터넷 속도가 빠르지 않은 곳이나 드라이버의 휴대폰 사양이 좋지 않아도 앱을 원활하게 사용할 수 있도록 '가볍게' 만들 필요가 있었다. 매일 본사에 있는 개발팀에 이 문제를 알리기 위해 노력했다. 새벽 3시에도 본사에서 업무에 대해 이야기하자고 하면 현지 시각을 말하지 않고 미팅을 했다. 본사로 출장을 가면 아시아 지역의 특수함을 알리고자 설명회를 열었다. 우버 싱가포르 티셔츠를 준다고 사람들을 꼬셔 모아 이 지역 드라이버가 필요하다고 피력했다. 2년 동안 짝사랑을 제대로 했고, 나는 내가 잘하고 있다고 믿었다. 본사로 돌아와 개발팀과 협력하며 그때의 일을 돌이켜보니 나는 개발팀과 일하며 문제를 해결하는 방식을 잘 몰랐다. 보이지 않던 짝사랑의 결실은 싱가포르를 떠나 우버 본사의 우버 프레이트팀에서 일하기 시작했을 때 맺을 수 있었다. 개발팀 매니저를 찾아가 운영팀으로서 어떻게 하면 도움이 될 수 있냐고 물은 후였다. 개발팀 매니저는 이렇게 전했다.개발자는 고객이 어떤 점을 불편해하는지 알고 싶어 해.이전까지 내가 생각하는 해결책을 말했다면 지금부터는 문제점이 무엇인지 설명하게 된 거다. 나는 고객의 피드백을 개발팀에 전달하는 미팅을 매달 열기로 했다. 사용자가 보낸 피드백을 토씨 하나 빼지 않고 캡처해 테마별로 정리했다. 이렇게 해야 더 피부에 와 닿을 거라고 생각했다. 나중에 사용자의 피드백을 바탕으로 추가해야 할 기능에 대한 이야기를 개발팀과 나누었을 때, 개발팀으로서는 이미 미팅을 통해 인지하고 있던 문제였기 때문에 모두가 공감한 상태에서 문제를 해결할 수 있었다. 개발팀은 문제의 해결책보다문제점을 자세히 알길 원한다개발팀에게는 문제의 해결책을 설명하는 것보다 고객이 느끼는 불편에 대해 자세히 설명하는 것이 문제를 더 빨리 푸는 방법이라는 걸 배웠다. 다음의 영상을 보자. 일명 '개발자라면 봐서는 절대 안 될 영상'이다.
영상에서처럼 관리자는 대개 문제를 해결하는 과정을 모르고 개발자에게 해결을 요청한다. 그러나 운영업무 등을 하는 관리자는 개발은 모르더라도 고객이 원하는 것과 회사에 어떤 것이 중요한지는 안다. 매일 고객과 대화하고 사업지표와 핵심성과지표를 모니터하기 때문이다. 그래서 이제는 개발팀과 이야기할 때 해결책에 대해 이야기하지 않는다. 고객이 무엇을 원하는지, 이 문제가 해결되면 비즈니스에 어떤 임팩트가 있는지 우선순위를 매겨 이야기한다. 운영팀에서 A/B 테스트를 할 수 있으면 결과도 정리한다. 그리고 하나 더. 개발 스케줄을 이해하고 채근하지 않는다. 내가 생각하기에 참 간단해 보이는 기능(feature)이라도 변수에 따라(코드 베이스가 복잡하다든가) 몇 주, 몇 달이 걸릴 수 있기 때문이다. 또 개발팀은 문제를 파고드는 데 집중할 시간이 있어야 한다고 해서 일의 흐름이 끊기지 않게 미팅을 잡을 때도 책상을 떠난 때인 점심 전후로 한다.영업운영팀과 일하기: 다른 업무를 이해하는 방법우버 프레이트에 일하면서 올해 처음으로 영업운영팀과 일하게 되었다. 처음 영업운영팀과의 미팅에서 내 업무에 필요한 CRM에 새로운 기능을 넣어달라고 조심스럽게 요청했는데 반응이 좋지 않았다. 그는 이렇게 말했다.영업운영팀은 세일즈포스(Salesforce)*를 커스터마이즈(customize)하는 팀이 아니야. 너 지금 영업운영팀과 영업팀의 업무를 모르는 것 같은데, 영업에 대한 책을 읽어보는 건 어때?* 고객관리시스템 중의 하나. 세일즈포스에서 만든 동명의 소프트웨어한 대 맞은 것 같았다. 이전까지 B2C 서비스를 담당했기에 B2B 영업에 대해 아는 것이 많지 않다는 것에 찔리면서도, 그래도 함께 일하는 동료가 가르쳐주지 않고 책을 읽어보라고 하자 자존심이 상했다. 뭔가 이유가 있겠지 하고 책을 추천해달라고 했다. 그렇게 오기로 읽은 트리시 벨투치(Trish Bertuzzi)의 <영업개발안내서(The Sales Development Playbook)>란 책은 확실히 도움이 되었다. 이 책은 영업과 영업운영에 대해 설명한다. (우버 프레이트와 같은) B2B 소프트웨어 회사의 성공은 새로운 고객을 얼마나 효율적으로 유치하느냐에 직결하는데, 고객을 유치하는 영업팀의 일과 영업팀의 구성원을 어떤 방식으로 배치해야 할지 설명한다. 회사마다 조금씩 다르겠지만 영업팀의 성과는 몇 건의 계약을 따오느냐에 달려있다. 대개 성과급제이기 때문에 성과에 따라 월급과 보너스가 책정된다. 영업운영팀은 이런 영업팀과 다르다. 영업팀과 다른 팀에 속해 있으면서 영업팀에게 가이드라인을 주는 역할을 한다. 예를 들어 영업팀이 만나야 할 비즈니스 리스트를 정해주고, 팀원에게 매 분기 달성해야 하는 성과 목표를 정해주면서 달성 여부에 따라 월급과 보너스를 책정한다. 세일즈포스에 기능을 추가하고 빼는 '영업지원'의 일을 하지 않는다. 이런 걸 알지 못한 나의 태도로 중요한 이해관계자와의 첫 미팅이 불편해진 것은 당연했다. 알고 보니 책을 추천한 담당자 역시 영업운영 업무를 시작한 지 1년밖에 되지 않았다. 본인 역시 업무를 시작하는 데 독서가 가장 큰 도움이 되었기에, 순수한 마음으로 책을 추천한 것이었다. 책을 읽고 감상을 전하면서 이제 업무를 이해하고 있음을 보여준 다음부터 우리 팀과의 협업은 훨씬 좋아졌다. 그리고 나 역시 그 책을 팀원에게 종종 추천한다.