회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
AWS 서버 비용 절감을 고민 중이신가요?
본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 데이브 펠드먼(Dave Feldman)은 구글이 인수한 모바일 메신저 앱 ‘에뮤(Emu)’와 ‘미터(Miter)’에서 각각 공동 창업자 겸 CPO, 창업자로 활동했습니다. 야후, 구글, 페이스북 등에서 제품 관리자로 일했으며, 현재는 프로덕트 리더십 컨설턴트로 활동하고 있습니다. 이 글은 어떤 툴이나 규범을 지키기 위해 하는 모든 일이 협업인 것은 아님을 밝히며 올바른 ‘협업’에 관해 필자가 생각하는 기준을 제시하고 있습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!
확인
본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 데이브 펠드먼(Dave Feldman)은 구글이 인수한 모바일 메신저 앱 ‘에뮤(Emu)’와 ‘미터(Miter)’에서 각각 공동 창업자 겸 CPO, 창업자로 활동했습니다. 야후, 구글, 페이스북 등에서 제품 관리자로 일했으며, 현재는 프로덕트 리더십 컨설턴트로 활동하고 있습니다. 이 글은 어떤 툴이나 규범을 지키기 위해 하는 모든 일이 협업인 것은 아님을 밝히며 올바른 ‘협업’에 관해 필자가 생각하는 기준을 제시하고 있습니다.
저는 협업을 좋아합니다. 단순하지만 사실입니다. 저는 끊임없이 협업할 때 스스로 가장 활기차고 창의적이며 성공적인 사람이 됩니다. 그리고 최고의 제품을 만들 수도 있습니다.
이건 어디까지나 제가 그렇다는 이야기입니다. 하지만 다양한 회사의 팀과 함께 일하면서, 그들도 협업을 더 많이 할 수 있을 거라고 생각하게 되었습니다. 그러던 중 스텔라 가버(Stella Garber)의 LinkedIn 게시물을 보게 되었습니다.
[스텔라 가버 링크드인 게시물 내용]
우리는 너무 많이 협력합니다.
도구는 협업의 장벽을 낮췄고, 이제 우리는 익숙해졌기 때문에 프로젝트의 모든 측면에서 협업을 기본으로 합니다.
그러나 비용은 천문학적으로 높습니다. 다른 사람들이 아무 이유 없이 들어오는 모든 회의, Slack 메시지, 작업 및 이메일을 생각해 보십시오. 이로 인해 프로젝트에 복잡성과 모호성이 도입되어 더 많은 사람들이 들어오면 누가 결정을 내릴 수 있습니까? 누가 궁극적인 발언권을 가지고 있습니까?
우리는 협업 과부하로 고통받고 있으며 캘린더, 마음 및 업무가 복잡해지고 있습니다. 이에 대해 할 수 있는 몇 가지 작업은 다음과 같습니다.
1) 관리자라면 직속 부하들이 모든 것에 대한 승인 없이 빠르게 움직이도록 격려하십시오. 허락보다 용서를 구하는 것이 낫습니다.
2) IC*인 경우 피드백을 여러 번 요청하기 전에 두 번 생각하십시오. 협업 주기를 단축하고 더 빠르게 움직입니다. *Individual Contributor(개인 기여자. 관리자 직책을 갖고 있지 않은, 전문 지식을 활용해 문제를 해결하는 실무자를 의미한다. 위 1)의 ‘관리자’에 대응해 사용한 것.)
3) 일정의 모든 회의에 대해 사전 읽기를 요청하고 질문에 비동기식으로 답변하여 회의를 취소할 수 있는지 확인합니다.
대부분의 경우와 마찬가지로 협업은 적당히 훌륭합니다. 너무 자주 너무 많으면 속도가 느려지고 필요한 집중 시간을 확보하는 능력이 저하됩니다. |
물론 가버의 말이 맞습니다. 협업 도구와 규범이 우리에게 너무 많은 것을 요구해서 실제 업무를 처리할 시간이 없을 수도 있습니다. 동료 검토, 상태 업데이트, 스탠드업(standups)*, 팀 작업 세션, 부서 간 조정 회의, 리더십 체크인, 킥오프... 우리는 무엇을 실제로 성취하고 있을까요? 만약 우리가 그 지긋지긋한 협업을 그만두고 무언가를 해낸다면 어떨까요?
*스크럼처럼 짧게 모여 팀 공지나 업무를 공유하는 미팅
그럼에도 불구하고, 저는 원래의 전제를 고수합니다. 필요할 때 협업하지 않는 팀이 너무 많습니다. 어떻게 둘 다 사실일 수 있을까요? 어떻게 하면 더 많은 협업과 더 적은 협업이 동시에 필요할 수 있을까요?
답은 간단합니다. 우리가 협업이라고 부르는 것, 즉 회의, 슬랙 또는 MS 팀즈, 이메일에서 하는 대부분의 작업은 실제로는 협업이 전혀 아닙니다. 때로는 협업으로 위장된, 조직의 기능 장애와 비효율성이기도 합니다.
결국, "우리 CMO는 마케팅 팀과 협업하는 데 시간을 할애합니다."라고 말하는 것이 "우리 CMO는 자기 방식대로 일을 처리하기 위해 다른 모든 사람의 업무를 꼼꼼히 살피는 데 몇 시간을 소비합니다."라고 말하는 것보다 훨씬 더 나으니까요.
‘옥스퍼드 랭귀지’*에서는 협업을 "누군가와 협력하여 무언가를 생산하거나 만드는 행위"로 정의합니다. 저는 이 정의가 마음에 들지만 이를 '함께 만들기'로 줄여, 협업을 두 가지 범주로 나누어 보겠습니다.
*옥스퍼드 영어 사전을 편찬하는 곳
두 범주 모두 가치가 있으며, 서로 다른 결과를 낳기 때문에 두 가지를 구분하는 것이 중요합니다. 생성적 협업은 대칭적입니다. 적어도 이론적으로는, 모든 사람의 관점과 아이디어가 동등한 입장에서 함께 시작합니다. 반응적 협업은 비대칭적입니다. 제작자의 초기 작업에 따라 대화가 제한되고 가이드됩니다. 새로운 아이디어를 위한 여지가 있을 수 있지만, 필연적으로 아이디어를 다듬고 평가하는 데 초점이 맞춰질 수밖에 없습니다.
때때로 협업이 방해가 되는 것처럼 느껴질 때는 ‘생성적 협업’ 대신 ‘반응적 협업’을 사용하고 있기 때문입니다. 저는 제품 개발 팀에서 이런 경우를 자주 봅니다.
예를 들어 PM이 제품 요구 사항 문서(PRD)를 작성한 다음 디자이너와 엔지니어에게 제시하는 경우(반응형 협업)를 들 수 있습니다. 이를 본 디자이너와 엔지니어가 크고 근본적인 질문을 던지고 우려를 내비칩니다. PM은 좌절합니다. 일정을 이미 작성했고, 그들이 제기한 중요한 질문으로 다시 돌아가 검토할 시간이 없기 때문입니다. 디자이너와 엔지니어 역시 PM이 업무 수행 방식을 지시하면서 그들의 관점을 진지하게 고려하지 않아 답답합니다.
해결책은 ‘생성적 협업’부터 시작하는 것입니다. 요구 사항을 작성하기 전에 함께 모여 프로젝트에 대해 논의하세요. 그러면 PRD가 대화를 위한 사전 단계가 아니라 대화를 반영하는 것이 되며, 이를 통해 많은 장점을 얻을 수 있습니다.
프로세스의 다른 단계에서도 동일한 솔루션을 사용하여 유사한 시나리오를 적용할 수 있습니다. 목업을 만들기 전에 생성적 협업을 통해 디자인할 시간을 절약합니다. 엔지니어링 문서나 코드를 작성하기 전에 범위(scope)와 아키텍처에 대해 논의하여 엔지니어링 사이클이 낭비되는 것을 줄입니다.
여러 팀이 종종 비동기식 협업이 동기식 협업보다 더 효율적이라고 생각하는 함정에 빠지고는 합니다. 우리는 회의장을 둘러보고 모든 사람의 급여를 합산하고는 "이 회의에 얼마나 많은 비용이 드는지 알아요?"라고 말합니다. 하지만 슬랙에서 토론하고, 문서를 작성하고, 댓글을 달고, 이로 인해 의견 충돌이 발생해 (슬랙에서 일어난 일이기 때문에) 문제가 확대되고, 결국에는 이러한 의견 충돌과 관련 대인 관계 문제를 해결하기 위해 더 큰 규모의 회의를 예약하는 데 많은 시간을 소비하게 되는 경우 잃는 것은 거의 고려하지 않습니다.
간단히 말하면 이렇습니다.
가장 중요한 것은 비동기식 협업이 시간을 꼭 절약해주는 건 아니라는 점입니다. 30분짜리 미팅이, 이메일이나 슬랙에서 몇 시간 동안 힘들게 토론하는 시간을 절약할 수 있습니다.
비동기식 협업이 확실히 시간을 절약한다고 할 수는 없습니다.
협업이 아닌 것을 협업으로 가장하는 것이 허용되면, 문화나 프로세스가 변화할 필요가 있다는 사실을 가릴 수 있으며, 이는 다시 지나치게 협업하는 것으로 느껴질 수 있습니다.
다음은 몇 가지 일반적인 함정입니다.
그렇다면 당신의 팀은 협업을 너무 많이 하고 있나요? 아니면 잘못된 방식으로 협업하고 있나요? 아니면 협업이 아닌 활동을 협업으로 취급하고 그 과정에서 파괴적인 행동을 변명하고 있지는 않나요?
결국, 회의에서도 일반적인 협업에서도 마찬가지입니다. 목표에서부터 시작하세요. 무엇을 달성하려고 하나요? 그 목표를 향해 가장 잘 나아가도록 하는 활동은 무엇일까요? 이러한 질문은 프로젝트를 시작하는 PM, 솔루션을 브레인스토밍하는 디자이너, 다음 분기 큰 출시를 계획하는 제품 마케터, 분기별 계획 주기를 만드는 리더, 또는 저처럼 그저 함께 무언가를 만들고 싶은 사람 모두에게 도움이 될 것입니다.
<원문>
위 번역글의 원 저작권은 Dave Feldman에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.