부서 간 협업 잘하는 법 - 영화 프로젝트 헤일메리

좋은 영화 한 편은 두 시간짜리 오락으로 끝나지 않습니다. 집중해서 보면, 그 안에 우리가 매일 출근해 마주하는 직장 생활의 풍경이 고스란히 들어 있습니다. 올해 3월에 개봉한 영화, <프로젝트 헤일메리>가 그렇습니다. 우주를 배경으로 한 SF처럼 보이지만, 이 영화는 사실 '일하는 사람'에 관한 이야기이기도 합니다.
그래서 앞으로 닷새에 걸쳐, 이 영화 한 편으로 직장 생활을 다섯 조각으로 나누어 들여다보려 합니다. 첫째 날은 협업, 둘째 날은 큰일 앞에서 위축되는 평범함, 셋째 날은 일의 의미, 넷째 날은 신뢰, 그리고 마지막 날은 나만의 전문성입니다. 한 편의 영화가 직장인의 다섯 가지 고민에 어떤 답을 건네는지, 오늘 그 첫 번째 이야기부터 시작하겠습니다.

그런데, 오늘의 주제는 협업입니다.

분명 자기 일은 다 끝냈는데, 일이 옆 부서에서 멈춰 선 경험. 직장 생활을 해보신 분이라면 누구나 한 번쯤 겪으셨을 겁니다. 기획은 개발을 탓하고, 개발은 영업을 탓하죠. 같은 회사, 같은 목표를 향한다는데 어쩐지 서로 다른 언어로 말하는 것 같습니다. 부서 간 협업이 어려운 건 여러분의 역량이 부족해서가 아닙니다. 구조의 문제이고, 그래서 해법도 분명히 존재합니다.
올해 3월 개봉했지만, 저는 지난주에 보게 된 영화 <프로젝트 헤일메리> 속에서, 이 오래된 숙제에 대한 힌트를 얻게 되었습니다.

내 부서의 언어가 아니라 상대 부서의 언어로 요청하는 것이 가장 중요합니다.

 

언어도 공기도 다른 둘은 어떻게 한 팀이 되었나?

이 영화가 보여주는 협업의 본질은 '다름을 전제로 한 번역'입니다. 주인공 그레이스는 기억을 잃은 채 우주선에서 깨어난 평범한 중학교 과학교사입니다 (물론 박사 타이틀이 있죠). 그는 임무 도중 외계의 존재 '로키'를 만나는데, 두 존재는 언어도, 전공도, 심지어 숨 쉬는 공기마저 다릅니다. 상식적으로는 한 팀이 될 수 없는 조합이죠.
그런데도 둘은 각자 자신의 행성의 운명을 건 문제를 끝내 함께 풀어냅니다. 비결은 단순했습니다. 서로 '내가 아는 것'을 상대가 알아들을 형태로 끈질기게 번역한 것입니다. 그레이스는 과학을, 로키는 공학을 맡아 각자의 빈틈을 메웠습니다. 회사로 치면 기획자와 개발자가 서로의 언어를 배워 가며 일한 셈입니다.

부서 간 협업은 왜 75%가 실패할까?

냉정하게 말하면, 대부분의 부서 간 협업은 실패하도록 설계되어 있습니다. 스탠퍼드대 베남 타브리지 교수가 25개 기업의 95개 팀을 분석한 결과, 교차기능팀의 약 75%가 제 기능을 하지 못했습니다(하버드비즈니스리뷰, 2015).
여기서 '교차기능팀(cross-functional team)'이라는 용어를 짚고 가겠습니다. 말 그대로 서로 다른 기능, 즉 다른 부서·직무의 사람이 하나의 프로젝트를 위해 모인 팀을 뜻합니다. 다른 말로 '태스크포스팀 (Task Force Team; TFT)이죠. 신제품 출시에 기획/개발/마케팅/영업이 한 팀으로 묶이는 경우가 대표적입니다. 효율적으로 보이지만, 통계는 정반대를 가리킵니다. 타브리지 교수는 이 팀들이 예산, 일정, 명세, 고객 기대, 회사 목표 정렬이라는 다섯 기준 중 세 가지 이상에서 어긋난다고 보았습니다. 그가 지목한 핵심 원인은 두 가지입니다.

원인 1: 책임지는 사람이 없습니다.

협업이 깨지는 첫 번째 이유는 최종 책임자가 모호하다는 점입니다. '서로 핑퐁친다'라고 하죠. 모두의 일은 결국 누구의 일도 아니게 됩니다. 타브리지 교수는 권한과 책임이 명확한 한 명의 결정권자가 있을 때 비로소 협업이 살아난다고 강조했습니다. 실제로 그의 연구에서 강력한 의사결정 체계를 갖춘 팀의 성공률은 76%였던 반면, 그렇지 못한 팀은 19%에 그쳤습니다. 같은 인력, 같은 예산을 두고도 거의 네 배의 차이가 벌어진 셈입니다.

원인 2: 서로 다른 언어로 말합니다.

두 번째 이유는 부서마다 '말의 단위'가 다르다는 점입니다. 기획자는 고객 경험으로, 개발자는 기술 명세로, 재무는 숫자로 사고합니다. 같은 회의에 앉아 있어도 실은 서로 다른 주제를 이야기하고 있는 경우가 많습니다. 그레이스와 로키가 처음에 서로의 신호를 전혀 해독하지 못했던 장면과 똑같습니다.

해결의 핵심은 상대의 언어로 번역하는 것입니다.

협업의 승부는 더 많은 회의가 아니라 번역의 질에서 갈립니다. 한 제조 기업의 기획자 K의 이야기입니다. K는 신제품 협업에서 개발팀과 번번이 부딪혔습니다. "왜 이런 간단한 걸 못 해주나?"는 식의 요청만 반복했기 때문입니다. 그러다 방식을 바꿨습니다. 기능 명세서를 던지는 대신, 이 기능이 고객의 어떤 불편을 해결하는지를 개발자가 이해할 수 있는 언어로 정리해 전달한 것입니다. 한 달 뒤, 멈춰 있던 프로젝트가 다시 굴러가기 시작했습니다. 개발자는 '고객의 문제를 해결한 자기 효능감'을 얻게 된 겁니다. K는 이 부분을 주목하고 있던 겁니다.
그레이스가 로키에게 그랬듯, K도 자신의 전문성을 상대가 곧바로 쓸 수 있는 형태로 번역한 겁니다. 결국 부서 간 협업을 살리는 길은 멀리 있지 않습니다. 프로젝트마다 책임자를 한 명 분명히 세우고, 내 부서의 언어가 아니라 상대 부서의 언어로 요청하며, 회의를 늘리기보다 번역된 한 장의 문서로 말하는 것입니다. 
여러분은 지금 동료에게 '내 언어'로 말하고 있나요, 아니면 '상대의 언어'로 번역하고 있나요? 가장 협업이 어려웠던 그 순간이 어떤 상황이었는지 한번 떠올려 보시길 권합니다.

---

위시웍스 김작가 | 일과 삶의 지혜를 씁니다
내일은, 큰 프로젝트 앞에서 한없이 작아지는 마음에 관해 이야기합니다. 자신 없는 그 감정의 정체와, 그것을 자신감으로 바꾸는 법을 함께 살펴보겠습니다.

아래 글도 이어서 읽어보시기를 추천합니다.

딥 워크 실천법 4단계, 산만한 직장인 집중력 회복 가이드