협업 요청 드립니다.
5 ways to foster better collaboration
다른 부서들과 협업하기가 너무 어려워.
어제저녁 친구와 밥을 먹다가 나온 이야기이다. 이 친구는 미국에서 일을 하다가 한국에 좋은 기회가 있어서 나갔다가 얼마 전 다시 미국으로 돌아왔다.
링글의 위세욱 님은 소프트엔지니어의 분류를, 목수와 대장장이에 빗대서 이야기했다. 목수는 제품을 만드는 엔지니어이고, 대장장이는 목수가 사용하는 도구들을 만드는 사람으로 목수의 생산성을 업그레이드하는 도구를 만들어내는 사람이라고 했다. 목수는 대장장이가 없으면, 비효율적으로 제품을 만들 수밖에 없으며 대장장이가 없으면 목수가 만드는 도구들은 쓰임이 없이 버려지게 된다.
“목수”의 능력치(생산성)를 업그레이드하는 도구를 만들어내는 사람이다. 때로는 목수가 더 쉽고, 빠르고, 정확하게 일할 수 있도록 돕기도 하고(DevEx), 목수의 신경을 분산시키는 업무에서 해방시키기도 하며(DevOps/SRE), 목수의 작업을 단순화하기도 한다(Platform/Infra Engineer).
디자인 쪽도 사뭇 비슷하다. 규모가 작을 때는 효율성이나 프로세스를 이야기하기엔 들어오는 요청 사항을 쳐내기에 빠듯하다. 하지만, 회사가 커지고 제품 군이 복잡해지면 어김없이 나오는 이야기가 디자인 시스템 구축이다. 한번 구축하는데 많은 리소스가 필요로 하지만, 한 번 구축이 되면 프로덕트 디자이너들이 정말 효율적으로 새로운 제품들을 만들 수 있다. 나는 줄곧 레고에 빗대서 설명을 하는데, 디자인 시스템 구축은 다양한 레고 블럭들을 만드는 일이다. 길쭉한 블럭, 얇은 블럭, 창문도 있고, 아치 모형의 둥그런 블럭들도 만든다. 그러면, 프로덕트 디자이너들은 이 레고 블럭들을 자신이 맡은 제품의 (고객의) 니즈에 맞춰서 조립을 하여 완성품을 시장에 내보낸다. 간혹, 조립하다가 조금 더 효율적일 것 같은 블럭이 있으면 디자인 시스템 팀에 요청을 하기도 한다.
레고 블럭들 말고도, 어느 정도 미리 만들어 놓은 빌딩 블럭이란 개념도 있는데, 모든 제품에 필요한 구성품을 가조립 상태로 만들어 놓은 것이라고 볼 수 있다. 예를 들면, 각 제품마다 사용자 온보딩하는데 필요한 온보딩 블럭이라든가, 사용자에게 코멘트를 작성하고 보여주는 코멘트 블럭, 사용자 그룹을 정의할 수 있는 사용자 그룹 블럭, 데이터를 차트에 보여주는 차트 블럭 등이 있다. 우리 회사에서는 플랫폼 팀이 제품들의 패턴을 파악해 빌딩 블럭을 정의하고 유지 보수하는 역할을 맡는다.
프로덕트 디자이너로서 이들과의 협업은 생산성을 높이기도 하면서, 사용자에게 일관된 경험을 제공해 줄 수 있기에 매우 중요하다.
3년 전,
워낙 탄탄한 기업에서 일을 하고 있는 친구라, 한국으로 들어간다고 했을 때 의아했다. 그 친구가 한국에서 일하는 걸 결심한 이유들을 더듬어 생각해 보면, 지금보다 큰 조직을 맡아 운영할 수 있고, 한국에서 일하는 걸 한번 경험해 보고 싶다고 했다. 물론, 금전적으로도 충분한 업사이드의 가능성도 전혀 없었던 건 아닌 것 같았다. 그렇게, 3년 만에 본 친구에게 '한국에서 일한 것은 어땠냐고 물었더니', 너무 힘들었다고 답했다. 무엇이 가장 힘들었느냐고 물으니, 다른 부서와 협업하는 게 너무 어려웠다고 했다. 일단, 협업을 하려고 미팅을 잡고, 미팅의 시작 부분에서 개략적인 설명 - 자기 부서가 무엇을 하려 하고, 왜 함께 해야지를 이야기하면 바로 다음과 같이 답변을 듣는다고 했다.
우리가 왜 해야 해요? 우리 바빠요.
협업은 사람과 사람 사이, 부서와 부서 사이, 더 나아가면 회사와 회사에서 벌어지는 것이기 때문에, 하나의 필승법은 존재하지 않는다. 그때그때, 상황에 맞춰서 적용해야 한다. 지금껏 잘된 협업도 있고, 억지로 이루어진 협업도 있으며, 협업을 하던 중 어그러진 경우도 많았다. 그러면서 느꼈던 점들을 이야기해 볼까 한다.
1. Win-Win 하는 전략 가져가기
서로 얻을 수 있는 혜택이 있으면, 협업을 하기 다소 쉽다. 우리의 KPI (핵심성과지표, Key Performance Indicator)만을 챙기기보다, 상대의 KPI를 이해하고, 어떻게 하면 이 프로젝트를 협업하면서 상대방의 목표도 이룰 수 있을지를 고민하고 이를 매력적으로 스토리 텔링하는 것이 중요하다.
올해, 우리 회사 디자인 시스템 팀의 화두는 새로운 버전으로 디자인 시스템을 업데이트하는 것이다. 한 번에 모든 컴포넌트들이 업데이트되면 금상 첨화겠지만, 안전을 위해서 입력창 같이 복잡도가 낮은 컴포넌트부터 데이트 그리드와 같은 복잡한 컴포넌트까지 점진적으로 배포하고 있다. 그러던 중, 그리드 업데이트에서 수많은 피드백을 받았는데, 그중에 하나가 내가 맡은 제품의 사용자 피드백이 많았다. 내 제품은 column의 개수가 20개에 다다르고, row의 경우에는 회사 사이즈가 커질수록 많아진다. 또한 편집 모드와 읽기 모드가 따로 들어있고 각 column당 다른 column에 영향을 받는 비지니스 로직도 들어가 있다.
우리 팀은 사용자들이 보다 직관적이고 편리하게 주어진 과업을 빠르게 실행하기 원하고, 시스템 팀은 이를 새로운 그리드 시스템 안에서 문제없이 수행하기 원했기 때문에, 다시 말해 서로 팀의 이해관계가 맞았기 때문에 짧은 시간 안에, 디자인 시스템 팀과 내가 태스크 포스팀을 꾸려, 사용자 인터뷰부터 시작하여 제품 팀이 맡을 것과 시스템 팀이 맡을 것을 구분하고 각각의 수정 디자인을 제안할 수 있었다.
2. 미리 이야기하기
보통 소프트웨어 회사의 경우 1년 치 장기 계획 안에, 분기마다 실제로 할 일들을 계획한다. 예를 들어, 12월부터 새로운 분기가 시작된다면 보통 11월 초부터 어떤 일을 할지 팀별로 계획해서 12월이 시작되기 전에 위에 보고를 하게 된다. 만일, 우리 팀이 필요로 하는 기술이나 리소스가 상대 팀으로부터 필요하다면 이 시기를 놓치지 말고 미리 그 팀에게 이야기해 놓아야 협업할 수 있는 가능성이 올라간다. 물론, 1번의 win-win 전략을 준비해서 이야기하는 건 기본이다.
3. 미리 관계 쌓기
사람 사이의 일이다. 팔이 안으로 굽는다는 말도 있듯이 이미 이야기를 해본 팀이 요청했을 때와 생판 모르는 팀이 요청을 했을 때, 과연 내가 어느 팀의 일을 도와줄 것인가 생각해 보면 쉽다. 언젠가 그 팀의 리소스가 필요하다고 생각이 든다면, 미리미리 관계를 쌓아 보자. 간혹 상대도, 내겐 쉬운 일을 가지고 머리를 싸매고 힘들어 할 수도 있고, 생각지 못한 인사이트를 주고받을 수 있다. 내 경우에도 지속적으로 플랫폼 팀의 디자이너와 커피 챗을 통해 그 팀이 곧 여태껏 쌓아 둔 Back logs(해결되지 않은 버그들이나 새로운 아이디어)나 paper cut (나는 UI에 표현된 문구들, 간격이나 색상같이 사용자가 제품을 사용하는 데 있어 불편함은 없지만, 디자인 퀄리티를 올리기 위한 작은 태스크들을 일컫는다)를 해결하려 한다는 걸 알게 되었고, 내가 예전부터 생각해 둔 paper cut 아이템을 공유하여 적시에 해결한 경험이 있다.
4. 정확한 요구 상황 정리하기
팀마다 일하는 방식이 다르며, 이해하고 있는 맥락 역시 다르다. 상대방에게 협업을 요청을 할 때에는 약간은 과할 정도의 맥락을 설명해 줄 필요가 있다. 3번을 통해서 미리 우리가 무엇을 하고 있는지 이미 알고 있다면 모르겠지만, 그렇지 않다면, 우리 팀이 무엇을 하려고 하는지 회사 차원이나 부서 차원에서의 큰 그림 안에서 설명하는 게 중요하다. 1번처럼, 이 일을 하는 것이 왜 우리한테만 이익이 아닌지를 이야기한다. 그러면서, 상대팀에게 어떤 것이 필요한데, 필요하다면 우리의 리소스를 쓸 수 있다고 이야기를 한다. 대부분의 경우, 본인들의 code base를 건드리는 것에 예민하다. 비지니스 로직들을 다 이해하지 못하고 개발을 했을 경우, 예기치 못한 오류들이 생길 수 있기 때문이다. 이럴 때는, 우리가 개발하고 리뷰를 상대 팀에서 하는 것으로 협업의 정도를 조정하여 제안할 수 있다.
5. Clean escalation 하기
마지막으로 정말 내 선에서 협업이 안될 경우 쓸 수 있는 카드이다. 이 경우 제일 중요한 건 내 윗선과의 의견일치가 필요로 하는데, 미리미리 보고를 하여 왜 이 프로젝트가 우리 부서, 회사에 중요한지를 어필하고, 협업 상황에 대해 지속적으로 업데이트한다. 우리가 중요하다고 생각했더라도 윗사람이 큰 틀에서 봤을 때 크게 중요치 않게 생각할 수도 있고, 상대팀의 이미 더 중요한 일들을 계획하고 수행하고 있을 수 있기 때문이다. 서로 중요하다고 생각할 경우, 이 방식이 사실 제일 효과적이기도 하다. 상대방에게도 협업을 해야 하는 명분을 제공해 주기도 하기 때문이다.
협업은 한 번만 이뤄지는 것이 아니라 일을 하면서 계속 필요하다. 한번 협업했다고 해서 끝이 아니라 우리가 도움을 받았다면, 도움을 주는 게 인지상정이다. 그래야 우리 공동의 목표, 고객을 만족시키는 제품을 만들고, 그 제품이 많이 팔려 회사가 성장하여 회사의 이익을 서로 나눌 수 있을 것이다.
어릴 적, 즐겨보던 드래곤 볼이 생각났다.
자기 보다 힘센 적이 나타났을 때, 그동안 사이가 안 좋았더라도 공동의 적을 물리치려고 같은 팀이 되어 싸웠다. 베지터를 본 피콜로와 손오공이 그랬으며, 셀을 만난 베지터와 손오공, 피콜로, 마인부우를 만난 베지터과 손오공이 서로 협업한 것처럼 말이다. (사실 관계 확인을 chatGPT에 확인함 ✅)
