7장. 애자일팀의 탄생#4

#7-4 계약, 계약, 계약

#7-4 계약, 계약, 계약  

이틀 뒤 난 다시 샌프란시스코로 향했다. P사는 큰 IT 이벤트가 자주 열리는 모스콘센터 바로 옆에 위치하고 있었다. 

모스콘센터에서 열리고 있는 WWDC 이벤트

나는 P사 근처 스타벅스에서 간단하게 요기를 하고 시간에 맞춰 P사에 들어갔다. 이 미팅 후 곧 완전한 애자일 방식으로 협업을 시작할 수 있겠다는 즐거움에 희망이 앞섰다. 

그 날 필자는 대니라는 새로운 인물을 만났다. 그는 샌프란시스코의 오피스장(Director)이었다. 일전에 만난 라이언은 팔로알토 오피스의 대표였고, 대니는 P사 본사인 샌프란시스코 오피스의 오피스장이었다. 대니는 나를 만나자 정말 반갑게 맞아 주었다. (대니는 지금은 일본에 있고, 필자와 정말 좋은 친구가 되었다.) 

그는 지난번 범위 산정 결과에 대해 말해주었다. 시작부터 그의 눈빛은 매우 달라져 있었다. 대니는 매우 이성적으로 대화를 시작했다. 

"두 번째 미팅의 결과를 공유드리고 싶습니다. 결론부터 말씀드리면, 저희가 판단할 때는, 주신 일의 양으로는 3개월이 아니라 6개월 정도의 기간이 소요되리라 생각합니다. 생각하신 3개월의 기간 만으로는 기간 동안 원하시는 기능을 만들어 드릴 수가 없습니다."

"조금 더 설명해주시겠어요? 잘 이해가 가지 않습니다."

"지난번 상세 범위 추정 미팅에서, 각 분야의 저희 전문가들이 참여했습니다. 그들은 주신 이야기를 토대로 업무량을 산정했습니다. 우선, 크리티컬 패스를 생각하고, 몇 명이 개발할지를 생각하면, 이 일은 병행해서 일하기 어려운 내용입니다. 그러니까 10명을 투입한다고 해서, 더 빨리 끝낼 수 없는 종류의 일이라는 겁니다. 저희 계산으로는 최대 2개의 흐름을 만들 수 있습니다. 즉 페어로 일하면 2개의 페어 이상 나올 수 없는 일이죠. 이렇게 계산하면 개발해서 완료하는 것까지 23주, 즉 6개월 정도가 걸립니다." 

나는 기가 막혔다. 사실 협업을 성사하는 것이 목적이라, 원래 생각했던 산정량보다 어느 정도 많아도, 동의할 생각이었다. 하지만 2배라니... 

"저희는 저희 내부 전문가들과 먼저 이 일을 산정했었고, 그 때의 판단은 3개월 정도가 걸리는 것이었습니다. 지난번 미팅 때 참여했던 담당자들은 미팅 중에 'Doable(할 수 있는)'이라는 표현을 자주 썼습니다. 제가 먼저 산정한 내용을 공유드렸었기 때문에, 저는 그 말을 듣고 그들도 제 말에 동의한다고 생각했습니다. 이는 쉽게 받아들이기 어렵습니다. 심지어 저희 회사의 몇 명의 전문가들은 1명이서 6개월 정도면 다 할 수 있는 일이라고도 이야기 했습니다. 6명이 개발하면 한 달이면 될 일을 6개월이라니요. 이건 제가 생각하던 것과 너무 다릅니다. 어떻게 그 숫자가 나온 건가요?"

대니는 차근차근 나에게 산정 기준에 대해 설명했다. 

"보시다시피, 저희 역할별 전문가 3명이 다음과 같이 기능별로 PW(Pair Week)를 산정했습니다. 여기에 따르면 6개월의 기간이 걸립니다" 

그는 말을 이었다. 

"저는 저희 전문가들의 말을 믿습니다. 저는 이 사무실의 대표이고, 그들이 이 일을 하는데 가장 현실에 근접한 결과를 주리라 확신합니다. 전문가들이 4시간 동안 당신의 일을 파악하고, 4시간 동안 해당 일에 대한 7장짜리 리포트를 써 왔습니다."

그는 더 힘주어 다음과 같이 말했다.

"제가 지금 드릴 수 있는 말은, 일을 줄여 오시거나, 기간을 늘려오시길 기대하겠습니다. 그래야만 이 일에 대해 다시 이야기할 수 있습니다." 

미팅은 끝이 났다. 난 정말 얼떨떨했다.  또한 그들은 당연하게 시간 자재계약(Time and Material contract)을 주장했다. 한 달마다 개발팀의 규모 만큼만 후불로 청구한다는 것이었다.  

이때부터 힘든 3개월의 협상이 시작되었다. 이 3개월간의 협상 동안 필자는 IT 계약에 대해 많은 것을 배울 수 있었다. 전문성을 기반으로 업무량을 산정하는 기준과 근거를 내는 방법 그리고 시간 자재계약 방식에 대해서다. 

무엇보다 대니가 내게 보였던 태도에서 정말 많은 것을 배웠다. 그는 개발자들이 산정한 기준에서 한 발자국도 물러서지 않았다. 철저한 역할별 분업이 이루어지고 있었다. 개발팀이 가장 일을 잘할 수 있는 환경을 만들어주기 위해서는 사전에 진행되는 영업, 계약 모든 조건들이 함께 움직여 주어야 한다. 더 나은 개발 방식을 활용하려면 그 방식이 가능하도록 새로운 환경, 역할, 주변 상황들을 만들어야 한다. 그리고 그 역할을 해야 할 사람은 조직의 리더이다. 

P사 개발방식(당시 프로젝트 사진)

"우리가 일한 방식을 그대로 전수받고 싶다면, 우리가 산정한 방식도 함께 공감해주어야 합니다."

대니는 이렇게 말하며, 지속적으로 필자를 압박했다. 3개월 후 우리는 협업을 시작했고, 협업이 진행되면서, 몇 차례 다른 업무에 대해서도 업무 산정을 함께 할 기회가 있었다. 그리고 어느 순간 알았다. 필자도 대화를 할 때 똑같이 방식으로 이해관계자들에게 말하기 시작했다는 것을...