진짜 '협업'을 하고 있나요?

본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 데이브 펠드먼(Dave Feldman)은 구글이 인수한 모바일 메신저 앱 ‘에뮤(Emu)’와 ‘미터(Miter)’에서 각각 공동 창업자 겸 CPO, 창업자로 활동했습니다. 야후, 구글, 페이스북 등에서 제품 관리자로 일했으며, 현재는 프로덕트 리더십 컨설턴트로 활동하고 있습니다. 이 글은 어떤 툴이나 규범을 지키기 위해 하는 모든 일이 협업인 것은 아님을 밝히며 올바른 ‘협업’에 관해 필자가 생각하는 기준을 제시하고 있습니다. 

협업을 너무 많이 하는 걸까요?

저는 협업을 좋아합니다. 단순하지만 사실입니다. 저는 끊임없이 협업할 때 스스로 가장 활기차고 창의적이며 성공적인 사람이 됩니다. 그리고 최고의 제품을 만들 수도 있습니다.

이건 어디까지나 제가 그렇다는 이야기입니다. 하지만 다양한 회사의 팀과 함께 일하면서, 그들도  협업을 더 많이 할 수 있을 거라고 생각하게 되었습니다. 그러던 중 스텔라 가버(Stella Garber)의 LinkedIn 게시물을 보게 되었습니다.

물론 가버의 말이 맞습니다. 협업 도구와 규범이 우리에게 너무 많은 것을 요구해서 실제 업무를 처리할 시간이 없을 수도 있습니다. 동료 검토, 상태 업데이트, 스탠드업(standups)*, 팀 작업 세션, 부서 간 조정 회의, 리더십 체크인, 킥오프... 우리는 무엇을 실제로 성취하고 있을까요? 만약 우리가 그 지긋지긋한 협업을 그만두고 무언가를 해낸다면 어떨까요?

*스크럼처럼 짧게 모여 팀 공지나 업무를 공유하는 미팅

그럼에도 불구하고, 저는 원래의 전제를 고수합니다. 필요할 때 협업하지 않는 팀이 너무 많습니다. 어떻게 둘 다 사실일 수 있을까요? 어떻게 하면 더 많은 협업과 더 적은 협업이 동시에 필요할 수 있을까요?

답은 간단합니다. 우리가 협업이라고 부르는 것, 즉 회의, 슬랙 또는 MS 팀즈, 이메일에서 하는 대부분의 작업은 실제로는 협업이 전혀 아닙니다. 때로는 협업으로 위장된, 조직의 기능 장애와 비효율성이기도 합니다.

결국, "우리 CMO는 마케팅 팀과 협업하는 데 시간을 할애합니다."라고 말하는 것이 "우리 CMO는 자기 방식대로 일을 처리하기 위해 다른 모든 사람의 업무를 꼼꼼히 살피는 데 몇 시간을 소비합니다."라고 말하는 것보다 훨씬 더 나으니까요.

협업: 함께 창조하기

‘옥스퍼드 랭귀지’*에서는 협업을 "누군가와 협력하여 무언가를 생산하거나 만드는 행위"로 정의합니다. 저는 이 정의가 마음에 들지만 이를 '함께 만들기'로 줄여, 협업을 두 가지 범주로 나누어 보겠습니다.

*옥스퍼드 영어 사전을 편찬하는 곳

• 생성적 협업(Generative Collaboration)은 함께 글을 쓰고, 페어 프로그래밍하고, 화이트보드에 스케치하고, 실시간으로 외부 활동 일정을 짜는 등 초기 창작 행위에 모두 참여할 때 발생합니다.
• 반응적 협업(Reactive Collaboration)은 초기 창작 이후에 이루어지며, 창작자는 창작물을 개선하거나 검증하기 위해 창작물에 대한 피드백을 요청합니다.

두 범주 모두 가치가 있으며, 서로 다른 결과를 낳기 때문에 두 가지를 구분하는 것이 중요합니다. 생성적 협업은 대칭적입니다. 적어도 이론적으로는, 모든 사람의 관점과 아이디어가 동등한 입장에서 함께 시작합니다. 반응적 협업은 비대칭적입니다. 제작자의 초기 작업에 따라 대화가 제한되고 가이드됩니다. 새로운 아이디어를 위한 여지가 있을 수 있지만, 필연적으로 아이디어를 다듬고 평가하는 데 초점이 맞춰질 수밖에 없습니다.

때때로 협업이 방해가 되는 것처럼 느껴질 때는 ‘생성적 협업’ 대신 ‘반응적 협업’을 사용하고 있기 때문입니다. 저는 제품 개발 팀에서 이런 경우를 자주 봅니다.

예를 들어 PM이 제품 요구 사항 문서(PRD)를 작성한 다음 디자이너와 엔지니어에게 제시하는 경우(반응형 협업)를 들 수 있습니다. 이를 본 디자이너와 엔지니어가 크고 근본적인 질문을 던지고 우려를 내비칩니다. PM은 좌절합니다. 일정을 이미 작성했고, 그들이 제기한 중요한 질문으로 다시 돌아가 검토할 시간이 없기 때문입니다. 디자이너와 엔지니어 역시 PM이 업무 수행 방식을 지시하면서 그들의 관점을 진지하게 고려하지 않아 답답합니다.

해결책은 ‘생성적 협업’부터 시작하는 것입니다. 요구 사항을 작성하기 전에 함께 모여 프로젝트에 대해 논의하세요. 그러면 PRD가 대화를 위한 사전 단계가 아니라 대화를 반영하는 것이 되며, 이를 통해 많은 장점을 얻을 수 있습니다.

• 제품, 디자인, 엔지니어의 요구사항을 통합할 수 있으며 전체 팀의 전문 지식을 활용할 수 있습니다.
• 첫 번째 대화에서 의견 불일치, 토론 및 반복이 이루어지므로 모든 사람의 시간을 절약할 수 있습니다.
• PRD가 설명을 위한 것이 아니라 기록하고 코드화하기 위한 것이 되므로, PRD를 제품 개요(Product Brief)에 가깝게 짧게 작성할 수 있습니다.
• 디자이너와 엔지니어는 이미 높은 수준의 요구 사항을 알고 있으므로 PM이 문서를 작성하는 동안에도 작업을 시작할 수 있습니다.

프로세스의 다른 단계에서도 동일한 솔루션을 사용하여 유사한 시나리오를 적용할 수 있습니다. 목업을 만들기 전에 생성적 협업을 통해 디자인할 시간을 절약합니다. 엔지니어링 문서나 코드를 작성하기 전에 범위(scope)와 아키텍처에 대해 논의하여 엔지니어링 사이클이 낭비되는 것을 줄입니다.

동기식(Synchronous) VS 비동기식(Asynchronous) 협업

여러 팀이 종종 비동기식 협업이 동기식 협업보다 더 효율적이라고 생각하는 함정에 빠지고는 합니다. 우리는 회의장을 둘러보고 모든 사람의 급여를 합산하고는 "이 회의에 얼마나 많은 비용이 드는지 알아요?"라고 말합니다. 하지만 슬랙에서 토론하고, 문서를 작성하고, 댓글을 달고, 이로 인해 의견 충돌이 발생해 (슬랙에서 일어난 일이기 때문에) 문제가 확대되고, 결국에는 이러한 의견 충돌과 관련 대인 관계 문제를 해결하기 위해 더 큰 규모의 회의를 예약하는 데 많은 시간을 소비하게 되는 경우 잃는 것은 거의 고려하지 않습니다.

간단히 말하면 이렇습니다.

• 비동기 협업은 단순하고 전술적인 질문에 적합합니다.
• 동기식 협업은 복잡한 문제, 감정이 많이 개입되는 주제, 사람들의 의견이 엇갈릴 때 유용합니다.
• 항상 그런 것은 아니지만 일반적으로 생성적 협업은 동기식이어야 합니다.
• 비동기식 토론이 장황해지거나 열띤 토론이 벌어지면 동기식으로 전환하세요.

가장 중요한 것은 비동기식 협업이 시간을 꼭 절약해주는 건 아니라는 점입니다. 30분짜리 미팅이, 이메일이나 슬랙에서 몇 시간 동안 힘들게 토론하는 시간을 절약할 수 있습니다.

비동기식 협업이 확실히 시간을 절약한다고 할 수는 없습니다.

협업이 아닌 것

협업이 아닌 것을 협업으로 가장하는 것이 허용되면, 문화나 프로세스가 변화할 필요가 있다는 사실을 가릴 수 있으며, 이는 다시 지나치게 협업하는 것으로 느껴질 수 있습니다.

다음은 몇 가지 일반적인 함정입니다.

• 피드백으로 위장한 승인(Approval disguised as feedback). '피드백' 미팅의 목적이 누군가에게 어떤 일을 허락하도록 설득하는 것이라면 이는 협업이 아닙니다.
• 피드백으로 위장한 경영진의 변덕(Executive whims disguised as feedback). 관련 리서치를 보지도 않은 임원에게서  "고객이 이걸 사용할 것 같지 않아요"라는 말을 들어본 적이 있는 PM이라면 무슨 말인지 알 것입니다. (디자이너라면 "더 적은 클릭으로 이걸 할 수 없을까?"라는 고민에 익숙할 것입니다.)
• 전파(Dissemination). 전파의 목표는 사람들에게 변경할 기회를 주지 않고 무언가를 알리는 것입니다. 모든 사람이 모든 일에 협업할 필요는 없습니다. 하지만 이것은 협업이 아닙니다.
• 동의 또는 조율(Buy-in or alignment). "우리 계획은 이렇습니다. 문제가 없나요?"(조율/동의)와 "우리가 생각하는 계획은 이렇습니다. 여기서 부족한 점은 무엇인가요?"(반응적 협업)에는 차이가 있습니다.
• 놓아줄 필요성(A need to let go). 조직이 성장함에 따라 리더는 세부 사항을 내려놓고 팀을 신뢰해야 합니다. 경영진이 "헬리콥터처럼" 프로젝트에 개입하여 프로젝트를 밀어붙이는 것은, 팀 규모가 작을 때 적당했던 협업의 흔적인 경우가 많습니다. 작년에는 괜찮았지만 지금은 그 프로젝트의 생산성을 높이는 데 필요한 수준으로 참여할 만한 시간이나 컨텍스트가 없습니다.
• 순수한 대화(Pure conversation). 팀은 관계를 기반으로 운영되며, 이러한 관계에는 업무가 필요합니다. 팀 점심시간과 친목 시간이 순수한 대화를 정면으로 다루고 있기는 하지만, 주간 팀 회의, 1:1 미팅, 다양한 임시적인 체크인도 마찬가지입니다. 물론 순수한 대화가 너무 많을 수도 있고, 그중 일부는 가치 있는 일이기는 하지만, 협업을 더 쉽게 만드는 경향이 있더라도 순수한 대화는 협업과는 별개입니다.

목표는 무엇인가요?

그렇다면 당신의 팀은 협업을 너무 많이 하고 있나요? 아니면 잘못된 방식으로 협업하고 있나요? 아니면 협업이 아닌 활동을 협업으로 취급하고 그 과정에서 파괴적인 행동을 변명하고 있지는 않나요?

결국, 회의에서도 일반적인 협업에서도 마찬가지입니다. 목표에서부터 시작하세요. 무엇을 달성하려고 하나요? 그 목표를 향해 가장 잘 나아가도록 하는 활동은 무엇일까요? 이러한 질문은 프로젝트를 시작하는 PM, 솔루션을 브레인스토밍하는 디자이너, 다음 분기 큰 출시를 계획하는 제품 마케터, 분기별 계획 주기를 만드는 리더, 또는 저처럼 그저 함께 무언가를 만들고 싶은 사람 모두에게 도움이 될 것입니다.

<원문>

Do We Collaborate Too Much?

위 번역글의 원 저작권은 Dave Feldman에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.