디자인, 기획, 개발이 하나 되는 협업
트라이애드(triad)가 공동의 목표로 함께 나아가는 법
UX 디자이너라는 타이틀로 첫 직장에서 일할 당시 나에게 열심히 일한다는 것은 주어진 일(=디자인)을 그저 묵묵히 해내는 것이었다. 기획자 역할을 했던 당시의 창업자가 소위 “판”이란 것을 짜 놓으면—로드맵, 문제 정의, 대략의 솔루션 형태까지—나는 인하우스 디자이너이지만 마치 아웃소싱인 듯, 필요한 UI를 만들고 개발자에게 넘겨주며 프로덕트 비전과 계획이 있는 그들을 "서포트"하는 정도의 롤만 수행하고 있었다.
이것도 틀린 협업의 형태라고 볼 수는 없지만, 몇 개의 회사를 거치고 경력을 쌓아가며 깨달은 것이 있다. 진정한 협업은 "서포터쉽"이 아닌 "파트너쉽”을 기반으로 한다는 것. 기획, 디자인, 개발자의 개별 역량 최고치의 합인 300%가 아닌 "팀 전체의 합"에 대한 100%를 끌어내는 협업을 추구해야 한다는 것이다. 세 개의 다른 관점과 전문성을 가지고 공동의 목표—비즈니스와 사용자를 이롭게 하는 것—를 향해 가는 것이 우리가 함께 일하는 이유이기 때문이다.
이 글에서는 나의 미국 회사 경험을 통해 가장 효과적이라고 느낀 협업의 형태, 트라이애드(triad) 모델에 대해 이야기해보고자 한다. 우선 여기에 잘 된 정의가 있어 빌려와 본다.
A "product triad" is the most atomic product leadership unit - comprising a product manager, a product designer, and a technical lead within a development team. They guide and balance the team to build the right thing at the right time.
나의 경험으로 보면 보통 기획자(프로덕트 매니저)와 디자인은 팀 별로 한 명이고, 개발은 테크리드를 제외하고 5-7명의 엔지니어가 함께한다. 트라이애드는 이렇게 대략 10명 남짓이 되는 전체 팀 안에서 작은 유닛을 구성하여 공동의 로드맵에 대한 오너쉽을 갖고 팀을 이끌어가는 리더쉽 단위이다. 또한, 대외적으로 다른 팀이나 상위 매니지먼트와의 터치포인트에서 팀을 대표하는 책임도 가진다.
트라이애드 협업의 모습을 구체적으로 알아보기에 앞서, 이상적 협업의 모습, 협업을 잘한다는 것의 의미를 짚고 넘어가 보자. 이렇게 크게 두 가지로 요약할 수 있을 것 같다.
1. 프로젝트가 일정대로 진행된다. 우선순위나 프로젝트의 방향성이 좌지우지되지 않게 하기 위해서 필요한 정보 (예를 들어, 특정 기능을 디자인하고 구현하는 데 걸리는 시간, 다른 팀과의 디펜던시)를 최대한 빨리 수집하고, 목소리 큰 사람의 의견이 아닌 이 정보들을 바탕으로 의사결정이 진행된다.
2. 각 직군의 전문성이 존중되지만 "우리"가 주체이다. 프로젝트의 제약사항들을 잠시 접어두고 가장 이상적인 솔루션을 트라이애드 멤버 모두가 자유롭게 공유하고 논의할 수 있다. 하지만 어떤 논의든 결국 "우리"의 관점에서 보았을 때 가장 합리적인 솔루션과 스콥으로 수렴한다.
위의 사항을 염두하고 이제 본론으로 들어가 보자. (아래의 내용은 디자이너의 관점에서 바라본 협업의 모습이라는 점을 강조한다.)
우리 팀은 무엇을, 언제, 왜 만들 것인가?
트라이애드는 함께 로드맵을 고민한다.
로드맵핑은 롱텀 계획을 수립하기 위해 모든 프로덕트 팀들에서 주기적으로 행하는 액티비티이다. (혹시 그렇지 않은 회사에서, 근시안적인 프로젝트만 진행하고 있다면 이직을 추천한다.) 물론 프로덕트 매니저가 가장 큰 책임을 가지고 리드를 하지만 트라이애드 모델 안에서는 디자이너와 테크리드의 인풋이 적극적으로 반영된다. 이것이 전통적인 "서포터쉽" 기반의 협업 형태와 가장 큰 차이점일 것이다. 피엠이 비즈니스의 전략과 마켓에 대한 이해, 그리고 고객의 소리 등을 취합하여 대략의 아웃라인을 짜면, 세 직군이 모여 솔루션의 방향성을 논의한다. 구체적 피쳐에 대한 디테일은 피하고 대략적인 비전을 그려보는 것이 트라이애드가 할 일이다. 이때 디자인은 디자인에 대한 "level of effort"를, 테크리드는 개발에 필요한 "level of effort"를 예측해본다. 특히 다른 팀과의 의존성에 대한 정보를 취합하는 것이 이 단계에서 트라이애드 구성원이 가진 책임이다. 이런 논의는 주어진 시간 안에 더욱 실현 가능한 로드맵을 수립하는 것에 큰 도움을 준다. 프로덕트를 개발하는 데에는 언제나 예상치 못한 변수가 있게 마련이지만, 이러한 가능성을 줄여주고 따라서 방향을 재정립하는 비용을 절감시켜주는 베네핏으로 이어지게 할 수 있다.
어떤 트라이애드가 로드맵을 짜며 나누는 대화의 예:
피엠: 프로덕트 마케팅 쪽에서 다음 분기 말에 마케팅 캠페인을 계획하고 있는 데 이 프로젝트가 그전에 완료될 수 있을까요? 이 피쳐가 메인은 아니지만 이게 빠지면 우리 메세지가 좀 약할 것 같아요.
디자이너: 우리가 전에 했던 유저 리서치가 이 프로젝트와 관련성이 높아서 바로 컨셉, 디자인 단계로 넘어갈 수 있어서 최종 디자인까지 한 3주 정도면 될 것 같네요. 하지만 조금 더 욕심을 내자면 이 기회에 관련 컴포넌트 리프레시를 할 수 있다면 좋겠어요. 이 부분은 제가 디자인팀과 논의를 해볼게요.
테크리드: 디자인이 완료되지 않아도 백엔드 측면으로 선행되어야 하는 일이 있어서 우리가 미리 킥오프 할 수 있을 것 같아요. 단, 피엠이 대략적인 requirement를 먼저 짜주면 큰 도움이 될 것 같네요.
우리 팀의 일은 전사 단위 큰 그림에 어떻게 부합하는가?
트라이애드는 팀 외부와 꾸준히 소통한다.
우리 회사의 경우 각 팀 별 트라이애드와 VP 레벨의 피엠, 엔지니어, 디자이너를 포함한 상위 리더쉽과 주간 회의를 통해서 꾸준한 소통의 자리를 가지는데 개인적으로 가장 "쓸데없지 않다"라고 여겨지는 미팅 중 하나이다. 우리가 진행 중인 프로젝트의 상태를 공유하고, 이를 성공적으로 마치는데 리스크가 있다면 도움을 요청하기도 하며, 상위 리더쉽은 여러 팀을 모두 관장하기에 트라이애드가 보지 못하는 부분을 짚어주고 방향성을 제시해주기도 한다.
어떤 주간 회의에서 트라이애드와 리더쉽팀이 나누는 대화의 예:
트라이애드: 진행 중인 프로젝트가 절반 이상 왔는데 예기치 못한 변수 때문에 마무리가 늦어질 것 같네요. 기존의 타임라인 대로 가려면 플랫폼 팀에서 우리가 필요로 하는 부분을 먼저 해결해 주어야 합니다. 우리 팀의 영역 밖 일이라 이것밖에 방법이 없어요.
리더쉽팀: 타임라인이 미뤄지는 건 이상적이지 않지만, 지금 플랫폼에서 서포트하고 있는 다른 팀의 프로젝트가 전체 로드맵에서 더 상위에 있으니 그럼 이 프로젝트를 조금 연기하기로 하죠. 대신 플랫폼 서포트를 기다리는 동안 해결할 수 있는 technical debt이나 미뤄둔 버그 등이 있는지 생각해보면 좋을 것 같아요.
트라이애드가 하는 또다른 방향의 소통은 타 팀과의 소통이다. 사실 팀 간의 교류는 트라이애드 모델이 아닌 어떤 형태의 협업하든 필요하고 자연스럽게 이뤄지는 것이다. 하지만, 트라이애드가 가지는 클리어한 리더쉽, 그리고 오너쉽에 대한 책임감이 팀 간 커뮤니케이션을 더 원활하게 해줄 수 있다. 팀 내의 컨택 포인트가 명확하기에 어떤 요청이나 질문이 들어왔을 때 누군가는 대응하겠지 하는 생각으로 커뮤니케이션이 더뎌지는 경우가 최소화 되고, 이 컨택 포인트는 모든 직군을 포함하기 때문에 다양한 관점을 포괄하는 논의가 빠르게 이뤄질 수 있다.
마지막으로 덧붙이는 트라이애드의 장점은 오롯이 디자이너의 관점에서의 얘기다. 회사의 성격에 따라 디자이너는 상위의 의사결정에 참여하지 못하고 주어진 requirement만 그려내는 경우가 많다. 하지만 이러한 협업 구조를 가진 조직에서 일을 할 때 커리어가 빠르게 성장할 수 있다고 믿는다. (특히 주니어 레벨의 디자이너일 경우) 팀 내에서 리더쉽의 역할을 한다는 것이 부담으로 다가올 수도 있지만 책임이 큰 만큼 배움도 많고, 시야를 팀 외부로 넓히는 데에도 도움이 될 수 있을 것이다.
