7장. 애자일팀의 탄생#3
#7-3 업무범위 산정
#7-3 업무범위 산정
앞선 과정을 거쳐 필자는 6개월간 샌프란시스코에 가게 되었다. 실리콘밸리에 가자마자, 일전에 통화했던 P사의 라이언과 에릭을 만날 수 있었다. 그들은 내가 일하던 사무실로 찾아왔고 우리가 하고 싶어 하는 프로젝트 개요에 대해 설명을 들었다.
* 초기 범위 검토
라이언은 오늘의 미팅을 ‘초기 범위 검토(Initial scoping)’이라고 묘사했다. 미팅의 목적은 실제로 이 일을 P사가 할 수 있는 일을 검토하는 것이라고 했다. 우리는 다음의 과정을 함께 하나씩 밟아나갔다.
1) (고객사) 제품의 비전에 대해 설명한다.
2) (고객사) 주요 사용자와 그 사용자에게 가장 중요한 시스템 사용 시나리오에 대해 설명한다
3) (고객사) 협업 기간 및 마일스톤에 대해 설명한다.
4) (P 사) 오피스 장이 해야 할 일에 대해 '상세 범위 검토(Detailed Scoping Meeting)'을 할 지에 대해 결정한다.
[초기 범위 검토]대화 도중 라이언에게 대략적으로 원하는 팀 인원 규모, 협업 방식에 대해 의견을 전달했는데, 인원 규모를 먼저 정하는 것에 대해 극도로 조심하는 반응을 느낄 수 있었다. 필자 입장에서는 협업 규모 및 형태를 확정해야 본사에서 인력을 데려올 수 있었다. 라이언으로부터 '의견은 잘 들었다. 하지만 실제보다 상세히 일에 대해 정의하는 미팅을 해야 한다' 정도의 이야기만 계속 들었다.
위와 같은 과정을 통해 오피스장인 라이언은 P사의 틀에 맞추어 매우 엄격하게 '성공' 할 수 있는 일을 설계하고 있었다. 이들은 고객에게 자신들이 일하는 방법을 제공하면서 자신들의 강점을 최대화할 수 있는 업무 형태를 만들어 성과 내기를 원하고 있었다. 그러다 보니, 필자가 본사와 힘든 대화를 하게 되는 입장이 만들어졌다. 외줄 타기를 하는 것 같았다.
미팅이 끝나고, 본사에 현재 상태를 리포팅했다. 회사 내에서 P사와의 협업에 참여할 훌륭한 인력들을 리크루팅 했다. 열정이 있는 1명의 기획자, 1명의 디자이너 그리고 3명의 개발자를 찾기 시작했다.
* 상세 범위 추정
일주일 뒤 P사와 두 번째 미팅을 했다. 이번 미팅은 P사 샌프란시스코 사무실에서 진행되었다. 샌프란시스코까지 가는 일은 쉽지 않았다. 난 당시 산호세에 호텔이 있었다. 산호세에서 샌프란시스코까지 차량을 이용하면 1시간 정도라고 들었지만, 출퇴근 시간에는 2시간이 넘게 걸렸다. 배이 에리어(Bay Area: 샌프란시스코에서 산호세, 오클랜드까지의 지역을 이르는 말)의 도로 101은 늘 막히는 도로였다. 샌프란시스코는 커다란 경제활동이 일어나는 곳인데, 생활을 위한 비용이 많이 들어 도시 안에 살기 힘든 사람들이 이 101로를 통해 출퇴근을 하고 있고, 이 도로가 거의 유일한 고속도로이다. 그러니 교통 체증은 서울에서 경험한 것보다 훨씬 심했다.
힘들게 P사 사무실에 들어섰다. 사무실에 들어서자마자 왼쪽을 보니, 커다란 부엌이 눈에 들어왔다. 수십 가지의 시리얼, 과자, 맥주, 와인 등이 빽빽하게 채워져 있었고, 아침식사가 무료 케이터링으로 제공되고 있었다. 다양한 머리스타일과 인종의 사람들이 티셔츠와 반바지를 입은 복장으로 즐겁게 이야기하며 식사하고 있었다. 리셉션을 담당하는 분이 혹시 식사를 안 했으면 하라고 이야기했고, 필자도 자연스레 그들과 섞여 아침식사를 했다.
[P사가 매일 제공하는 아침식사]식사를 하는 테이블 옆에는 밋업(Meetup)을 하는 공간이 마련되어 있었고, 반대편에는 탁구대 두 대가 설치되어 있었다. 그 옆에 우쿨렐레와 기타가 자리 잡고 있었다. 밋업 공간의 칠판에는 손님들을 위한 Wifi 정보와 패스워드가 적혀있었다.
"keepitsimple”
애자일을 하는 회사에 걸맞은 패스워드였다. 샐러드와 빵으로 간단하게 식사를 마칠 때 즈음 앤드류(샌프란시스코 P사 부 오피스장)가 내게 와 인사를 건넸다. 우리는 서로 인사하고 미팅 장소로 이동했다.
[P사의 손님들을 위한 와이파이 패스워드]첫 번째 미팅이 대략적인 업무 범위를 확인한 것이었다면, 두 번째 미팅은 속속들이 업무 및 기술에 대해 파악하는 것을 통해 상세하 업무 범위를 정의하는 것이 목적이었다.
미팅 장소에는 4명의 전문가 기다리고 있었다. P사의 미팅을 위한 퍼실리테이터, 개발자, 디자이너, 그리고 기획자가 있었다. 계약 전 미팅에 이렇게 많은 전문가가 역할별로 와 검토한다는 것이 의아했다. 하지만 이들은 업무 규모 산정이 잘 되려면 각 분야 전문가 대표가 규모 산정에 참석하는 것은 당연한 일이라고 했다.
정해진 시간 동안 최대한의 효과를 내기 위해 퍼실리테이터 한 명 또한 함께 참여했다. 퍼실리테이터는 본 미팅의 목적에 대해 설명했다.
"이 미팅은 함께 해야 할 일에 대해 보다 정확히 이해하고, P사가 적합한 전문가를 준비하고 계약을 할 수 있도록 하기 위해서입니다. 동의하시죠?"
다음과 같이 4시간의 미팅 아우트라인을 칠판에 적었다.
1) (고객사) 제품 비전에 대해 설명
2) (고객사) 주요 사용자와 사용자 시나리오 설명
3) (고객사) 기능 리스트 및 설명
4) (고객사) 프로젝트 마일스톤 설명
5) (고객사) (존재하면) 레거시 소스코드 설명
6) (고객사) (존재하면) 레거시 화면 디자인 설명
7) (함께) 프로젝트 리스크 식별
8) (P사) 다음 미팅에 대한 설명
나는 우리가 만들 제품 전체에 대한 설명을 하고 주요 사용자가 누구인지, 그 사용자가 주로 시스템을 사용할 시나리오가 무엇인지 한번 더 설명했다. 우리가 3개월 정도의 협업 기간 동안 만들어야 할 제품 기능에 대해 설명하고, 프로젝트에 중간보고/최종 보고 등 어떠한 마일스톤이 있는지 이야기했다.
4시간의 미팅 내내 진행된 질문들은 거의 모두 사용자에 대한 질문들이었다.
"이 제품을 만들면서 사용자는 어떻게 만날 수 있을까요? 사용자 중에 가장 중요한 역할자는 누구인가요? 이 기능에서 사용자가 가장 원하는 것이 무엇일까요? 혹시 이 기능을 사용하면서 사용자에게 받은 피드백이 있나요? 그들이 일하는 방식과 룰에 대해 설명해 줄 수 있나요? 이 사용자가 생각하는 일할 때의 행복이란 무엇인가요? "
이 관점은 당시 필자에게는 매우 어색한 질문들이었다. 과거, 업무범위를 정할 때 주로 개발할 기능들에 대해서만 이야기했었다. 반면, 오늘의 미팅의 관점은 온통 사용자에 대한 것뿐이었다.
여러 세션이 지나고, 기술 중심 세션이 진행되었다. 세션에서는 P사의 개발자와 소스코드 및 API 문서를 보며, 아키텍처, 이렇게 소스를 짠 이유 등에 대해 질문했다. 그녀는 기존 코드를 보면 책임이 너무 많은 일을 하고 있다고 이야기했다. 이런 경우 많은 리팩터링을 필연적으로 해야 하는데, 리팩터링을 하면서 코드를 짜는 것보다, 새로 코드를 짜고 API로 연결하면 어떠냐는 제안을 했다. 또한 테스트 코드가 어떻게 존재하는지 물었고, 현재는 테스트 코드가 없는데, 그래도 괜찮냐고 물으니, 본인이 생각하기에 테스트 코드는 반드시 있어야 한다고 생각하지만, 함께 일하면서 만들어나가는 것도 괜찮다고 이야기했다.
[코드 리뷰]프로젝트 리스크 식별 단계에서는 포스트잇을 이용하여 각자 본인이 생각하는 프로젝트 리스크를 식별했는데, 5분 정도 본인이 생각하는 리스크를 적어 회의 테이블 위에 놓고 퍼실리테이터가 비슷한 종류끼리 모으면 사탕으로 투표하고 토의하는 방식으로 진행했다.
[포스트잇과 사탕을 이용한 리스크 도출 기법]미팅 내내 이곳 사람들이 협력적이고 우리에게 좋은 인상을 주기 위해 노력한다는 것을 느낄 수 있었다. 프로젝트 성공을 위한 어려운 이야기들(협상, 제약, 계약)은 오피스 리더가 담당하고 실무자들은 어떻게든 프로젝트를 잘할 수 있게 하기 위한 방법을 고민하고 있었다. 이 커뮤니케이션 방식은 건강한 협업을 위해 좋은 구조라는 생각이 들었다.
필자는 미팅 결과에 대해 보고했다. 어떻게 진행했는지, 어떠한 반응을 보였는지 상세히 적었다. 그리고 이제 곧 계약이 이루어지겠구나 생각했다. 하지만 이것은 곧 나의 큰 오판이었다. 그들은 이 단계까지도 아무것도 약속하지 않았다는 것을 다음 미팅을 통해 알 수 있었다.
