다양한 유관 부서와의 협업에서 어떤 방식으로 소통하며 프로젝트를 이끌어 나가나요?

유관 부서와 협업할 때 가장 중요하게 생각하는 것은 각 팀이 같은 단어를 다른 의미로 쓰고 있을 수 있다는 것을 초반에 확인하는 것입니다. 인턴 때 마케팅팀과 개발팀이 "사용자"를 각각 "앱을 설치한 사람"과 "유료 전환한 사람"으로 다르게 정의하고 있어서 데이터 수치가 달라 혼선이 있었던 경험이 있습니다. 그 이후 협업을 시작할 때 공통 용어 정의를 먼저 문서화하는 것을 습관으로 만들었습니다. 두 번째는 상대방의 우선순위가 나의 우선순위와 다를 수 있다는 것을 전제하는 것입니다. 요청을 할 때 "왜 이것이 필요한지"를 설명하면 상대 팀에서 자신들의 일정과 맞추는 방법을 더 적극적으로 찾아줬습니다. 협업의 마찰 대부분은 나쁜 의도가 아니라 맥락 부재에서 오는 것이라는 것을 경험했고, 맥락 공유에 시간을 쓰는 것이 결국 속도를 높인다는 것을 배웠습니다.

마케팅팀과 개발팀이 같은 지표를 다른 도구로 측정하고 있어서 수치가 매번 달라지는 문제가 있었습니다. 양쪽이 자기 데이터가 맞다고 주장하는 상황이었는데, 어느 쪽이 틀렸는지를 따지기보다 측정 기준 자체를 먼저 정리하기로 했습니다. 양 팀 담당자를 한 자리에 모아 각자 사용하는 도구와 이벤트 정의를 화면으로 공유하는 세션을 가졌습니다. 그 자리에서 두 도구가 이탈률을 계산하는 시간 기준이 달랐다는 것을 처음으로 확인했습니다. 별도로 논의했을 때는 드러나지 않던 차이가 화면을 함께 보는 순간 바로 보였습니다. 이후 공통 기준 문서를 작성해 양 팀이 공유하고, 수치가 달라질 때는 먼저 그 문서를 참조하는 방식으로 바꿨습니다. 협업에서 오해를 줄이는 가장 빠른 방법은 추상적인 설명보다 실제 화면을 함께 보는 것이라는 걸 그때 배웠습니다.

부서 간 협업에서 요청이 자꾸 지연되는 패턴이 반복됐습니다. 이유를 살펴봤더니 상대 팀은 우리 요청의 우선순위를 알 방법이 없었고, 우리는 상대 팀의 내부 일정을 고려하지 않고 마감을 잡고 있었습니다. 이것을 해소하기 위해 격주 싱크 미팅을 제안했습니다. 각자의 현재 진행 사항을 10분씩 공유하는 형식이었는데, 처음에는 불필요하다는 반응도 있었습니다. 하지만 두 번째 미팅부터 서로의 병목 지점을 미리 파악해서 일정을 조정하는 일이 자연스럽게 생겼습니다. 일방적인 요청 방식에서 서로의 일정을 인지하는 방식으로 바뀌자 지연 빈도가 눈에 띄게 줄었습니다. 형식적인 회의보다 짧더라도 정기적인 맥락 공유가 더 큰 효과를 냈습니다. 협업 마찰의 대부분이 나쁜 의지가 아니라 정보 비대칭에서 온다는 것을 그 경험에서 확인했습니다.