좋은 결과물을 만드는 팀워크
주간 팀 미팅
우리 팀은 매주 Weekly Design Critiques (이하 WDC) 라는 미팅을 한다. 이 미팅에서는 팀 동료들끼리 서로 진행사항을 짧게 공유하고, 각자가 당면한 문제를 자유롭게 들고 와서 다른 동료의 피드백을 받는다.
WDC에선 매니저인 나뿐만 아니라 모두가 서로에게 솔직하고 건설적인 피드백을 준다. 종종 나도 줄 수 없을 것 같은 피드백을 동료들이 줄 때가 있다. 그럴 때면 이 미팅을 만들기 정말 잘했다는 생각이 든다. 가끔은 사소해 보이는 아이콘까지도 끝까지 토론할 때가 있다. 그럴 때 모두가 공감하는 해결책을 찾으면 정말 만족감이 크다.
그리고 누구나 아직 고민 중인 미완성 작업을 공유하면서 자신도 모르게 약함(vulnerability)을 노출하는 연습을 하게 된다. 자신의 아이디어가 동료들의 피드백에 의해 발전하는 경험을 여러 번 겪으면 '중간 과정물도 괜찮아. 내 작업은 항상 완전할 필요가 없어. 동료들에겐 믿고 공유할 수 있어.'라고 긍정적으로 생각할 수 있는 힘이 생긴다.
그래서 미완성의 작업을 계속 공유하는 환경을 만드는게 좋다고 생각한다. 멋지고 완벽하게 보이려고 하다가 실수하는 것보다, 부족함을 드러내고 완벽해지는게 낫다. 오히려 완성된 것 같은 결과물에 대한 피드백이 훨씬 주기 어렵다. 피드백받은 사람이 다시 작업해야 될 것 같은 생각이 들기 때문이다.
이 미팅에서 모두 피드백을 받아야 한다는 강제성은 전혀 없다. 누구나 고민하는 문제를 들고 와서 피드백을 받을 수 있는 반면, 자신이 잘하고 있다고 생각하면 아무것도 공유하지 않아도 된다. 피드백을 받는 것도 개인의 자율성에 맡긴다.
하지만 대부분 어렵거나 미리 문제가 될 것 같은 부분을 가져온다. 이런 미팅이 있는데도 굳이 활용하지 않을 이유가 없기 때문이다. 사람들은 시간이 지나며 점점 자신이 약한 부분을 깨닫고, 그런 부분은 이 미팅을 활용하여 보완하고 개선한다. 만약 남의 도움 없이 단독적으로 진행하고 출시된 기능이 좋은 시장 평가를 받지 못한다면, 그다음부터는 문제를 다시 테이블에 꺼내 놓는다.
피드백을 받는 입장에서는 실질적인 도움이 되고, 피드백을 주는 입장과 지켜보는 입장에서도 동료의 문제를 간접 경험하며 성장할 수 있다. 하지만 무엇보다 좋은 점은 피드백을 주는 사람이 긍정적 감정을 느낀다는 것이다.
서로가 서로를 도우며 팀워크가 형성되고 특히 자신의 피드백이 동료에게 도움이 되었을 때는 뿌듯함을 느낀다. '나도 남에게 도움이 되는 사람이구나. 이 팀에 필요하구나.'라는 감정을 느끼게 된다.
이 미팅에서 매니저는 교통순경의 역할을 한다. 혼잡한 도로에서 차들이 충돌하지 않고 잘 갈 수 있도록 돕는다. 내 의견을 강하게 제시하기보다 개입을 최소화하고, 사람들이 서로 커뮤니케이션을 원활하게 하도록 돕는다.
예를 들어 논의가 너무 산으로 가면 다시 제자리로 데려오고, 너무 확산되면 수렴시키고, 너무 길어지면 끊고, 의견이 분분할 때 최종 결정을 누가 할지 최종 선택권을 부여한다.
매니저가 너무 많이 개입하면 미팅의 원래 취지와는 다르게 권력이 매니저에게 집중될 위험이 있다. 꼭 개입해야 할 순간이 아니라면, 팀 동료들이 자율적으로 참여하는 '시스템'을 만드는데 집중하는게 더 좋다고 생각한다.
공감대를 추진력으로
그동안 우리 제품은 큰 기능만 배포하느라 작지만 중요한 기능들을 챙길 여유가 없었다. 사용자가 당연히 기대하는 기본적인 기능이 작동하지 않았다.
우리가 해야 할 일은 꽤 명확했다. 사용자가 상식적으로 기대하는 기능들을 만드는 것이었다. 그런데 이 문제를 실제로 해결하기 위해서는 디자이너뿐만 아니라 모든 회사 구성원이 공감할 수 있어야 했다.
나는 여러 회의에서 조금씩 화두를 던지기 시작했다. 우리 제품이 이제는 기본적인 것을 챙겨야 한다고 설파했다. 사람들은 공감하기 시작했고, 이미 모두 우리 제품이 불편하다는 것을 인지하고 있었다. 다만 그런 문제를 공식적으로 드러내고 해결할 수 있는 방법이 없었다.
그렇다고 제품 개발 프로세스를 다 바꿀 수는 없었고 무엇인가 돌파구가 필요했다. 그러다가 해커톤에서 아이디어를 얻었다. 해커톤은 구성원이 하던 일을 잠시 멈추고 다 같이 모여 짧은 시간 동안 새로운 아이디어를 구현한다. 나는 우리가 다 같이 모여 문제를 해결하지만, 해커톤같이 거대하고 어려운 문제를 푸는 것이 아니라 작고 사소한 당면한 문제를 푸는 것이면 어떨까 하는 생각이 들었다.
그래서 모두가 참여할 수 있는 내부 행사를 기획했다. 사람들이 문제를 발견하고 해결책을 내면 모두가 성취감을 느낄 수 있을 것이라고 생각했다.
행사 제목은 'Fixit Day - OJT: 오 찌든 때'라고 지었다. 사람들에게 찌든 때를 청소하고 싶은 느낌을 주고 싶었다. 행사 참여를 장려하기 위해 내부 마케팅을 했다. 사람들의 흥미와 관심을 끌기 위해 홍보 포스터와 영상도 제작했다.
한 달 뒤에 열린 행사에는 감사하게도 대부분의 제품 팀 사람들이 참여했다. 미리 정해둔 팀끼리 나눠서 경쟁하듯 찌든 때(사소하지만 불편한 문제)를 찾고 내부 시스템에 등록했다. 마지막엔 팀별로 찾은 문제와 해결책을 공유했다. 결과는 대 성공이었다. 단 몇 시간 만에 수십 가지의 문제와 해결책이 등록되었다.
행사 후 바로 찌든 때 제거반 TF가 만들어졌고, 우리는 매우 짧은 기간에 수십 개의 기능을 만들어냈다. TF에 참여한 사람들은 근래 들어 가장 생산적인 기간이었다고 말하며 만족했다.
사람들은 의외로 무엇인가 필요하다고 느끼지만, 누군가 손발 벗고 나서기 전까지는 의견을 잘 내지 않는다. 그래서 누군가 사람들의 생각을 모으고 공감대를 형성하면 그 일이 훨씬 수월하게 진행된다. 매니저는 영향력이 더 있으므로 이런 일을 하기에 적합하다.
협업으로 변화 만들기
안타깝게도 우리 제품은 플랫폼별로 버튼 형태와 규칙, 폰트, 레이아웃, 팝업을 닫는 방식 등 모든 UI가 달랐다. 그나마 통일되어 있는 것처럼 보였던 컬러마저도 자세히 보면 플랫폼별로 미세하게 달랐고, 성공이나 경고를 나타내는 컬러도 제각각이었다.
시간이 지날수록 UX 부채가 너무 쌓여 해결하기조차 힘들 것 같았다. 더 늦기 전에 지금 해결해야만 했다. 그래서 담당 디자이너를 중심으로 모든 플랫폼의 제품을 통합하는 거대한 프로젝트를 시작했다.
디자인의 일관성이 조금씩 갖춰지는게 보이자, 사람들이 디자인의 가치에 대해 더 긍정적으로 생각하게 되었다. 엔지니어들이 "너무 이쁘다. 새로운 제품 같다."라고 할 때면 뿌듯했다. 실제로 구현하는 엔지니어 분들이 긍정적 감정을 느끼니 구성원 모두에게 새로운 활력이 되었다.
그뿐만 아니라 플랫폼별로 일관성을 맞추니 이제는 한 번만 디자인하고 개발하면 되었다. 디자인하는데도 시간이 줄고 개발하는데도 시간이 점점 줄고 있다.
담당 엔지니어가는 "재밌다. 더 공부해보고 싶다."라고 했다. 해보니 흥미가 생겼다고 했다. 가끔은 일단 시작하고 보면 하면서 좋아지는 경우가 있다.
엔지니어뿐만 아니라 제품 매니저와 함께 할 수 있는 일도 많았다. 예를 들어 우리는 담당 리서처를 중심으로 주요 고객이 어떻게 제품을 사용하는지 파악했고, 이를 토대로 제품 매니저와 함께 제품 전략을 세우고 있다.
이 경험을 하면서 다시 한번 협업을 통해서 얼마나 강력한 팀워크가 형성되는지 경험했다. 매니저는 타직군과의 협업을 추진할 수 있는 위치에 있다. 다른 팀과 교류하면서 더 좋은 시너지를 만들어낼 수 있는 영향력이 있다.
우리 디자인 팀에서 디자이너만 할 수 있는 일을 했다면 물론 다들 멋지다고 했겠지만, 다른 직군과 같이 협업하는데서 오는 즐거움을 느낄 수는 없었을 것이다. 그리고 직군과 직군의 벽이 허물어지며 끈끈한 팀워크를 발휘할 기회도 잃었을 것이다.
어떤 팀이든 그 팀만이 가진 특별한 능력이 있을 것이다. 그 능력을 가지고 다른 팀과 협업하여 시너지를 낸다면 이전에는 할 수 없었던 것을 할 수 있고 회사에 큰 변화를 만들어낼 수 있다고 생각한다.
