일을 할 때 누구나 소통과 협력을 하며 일할 것입니다. 그것은 단순한 논리이기도 하며 사실이기도 합니다. 끊임없이 협력할 때 가장 활력이 넘치고 창의적이며, 성공적인 자아이며, 최고의 제품을 만든다고 생각합니다. 하지만 다양한 조직 내의 팀과 협력하면서 더 많은 협업을 할 수 있다는 점은 긍정적인 방향을 가지게 될 것입니다.
협업 도구와 표준은 너무 많은 것을 요구하기 때문에 실제 작업을 완료할 시간이 전혀 없습니다. 동료 검토, 상태 업데이트, 스탠드업, 팀 작업 세션, 부서 간 조정 회의, 리더십 체크인, 킥오프… 실제로 이러한 작업들로 인해서 무엇을 달성할 수 있을까요? 하지만 팀은 필요할 때 협업하지 않는 경우가 너무 많습니다. 협업하지 않는 팀이 겪을 수밖에 없는 부정적인 사실을 어떻게 받아들일 수 있을까요? 더 많은 협업과 더 적은 협업이 동시에 필요한 이유는 무엇일까요?
협업이라고 부르는 대부분의 작업(회의, Slack 또는 Teams, 이메일에서 수행하는 작업)은 실제로 협업이 아닙니다. 때로는 조직의 기능 장애와 비효율성을 협업으로 위장하고 변명하기도 합니다. 결국, "CMO(최고마케팅경영자-Chief Marketing Officer)는 자신의 방식대로 처리하기를 원하기 때문에 다른 사람들의 작업을 따지는 데 많은 시간을 소비합니다."보다 "CMO는 마케팅 팀과 협력하는 데 시간을 보냅니다."라고 말하는 것이 훨씬 더 좋게 말할 수 있을 것 같습니다.
협업 : 함께 창조하기
Oxford Languages는 협업을 "무언가를 생산하거나 창조하기 위해 누군가와 협력하는 행위"로 정의합니다. 그 정의를 좋아하지만 이를 바꿔서 “함께 창조하다”로 줄여서 두 가지 범주로 나누어 보겠습니다.
- 생산적 협업
공동 글쓰기, 양방향 프로그래밍, 화이트보드에 스케치하기, 실시간으로 오프사이트 일정 짜기 등 창작의 초기 행위에 모두가 참여할 때 발생합니다. - 반응적 협업
초기 제작 이후에 발생합니다. 제작자는 자신의 창작물을 개선하거나 검증하기 위해 자신의 창작물에 대한 피드백을 요청합니다.
위에서 언급한 두 가지 범주, 모두 가치가 있으며, 서로 다른 결과를 산출하므로 구별이 중요합니다. 생산적 협업은 대칭적입니다. 모든 사람의 관점과 아이디어가 동등한 입장에서(적어도 이론상으로는) 함께 시작합니다. 반응형 협업은 비대칭적입니다. 대화는 제작자의 초기 작업에 따라 제한되고 안내됩니다. 따라서 새로운 아이디어를 위한 여지가 있을 수 있지만, 초점은 필연적으로 다듬고 평가하는 데 맞춰질 것입니다.
때때로 협업이 우리를 수렁에 빠뜨리는 것처럼 느껴질 때, 이는 생산적 협업 대신 반응적 협업을 사용하고 있기 때문입니다. 예를 들어 PM은 요구 사항 문서(PRD)를 작성한 다음, 이를 디자이너와 개발자에게 제시합니다(반응적 협업). 그들은 크고 근본적인 질문과 우려를 표할 것이며, PM은 일정을 만들었고 돌아가서 중요한 질문을 다시 검토할 시간이 없습니다. 디자이너와 개발자들도 PM의 업무 수행 방식을 지지하고 그들의 관점을 진지하게 받아들이지 않을 수도 있을 것입니다.
해결책 : 생산적 협업으로 시작하는 것을 권장합니다. 요구사항을 작성하기 전에 함께 모여 프로젝트에 대해 논의해 보면 어떨까요. 그러면 PRD는 대화의 전조가 아닌 대화의 반영이 되어 다음과 같은 여러 가지 이점을 얻을 수 있을 것입니다.
- 요구 사항은 처음부터 제품, 디자인 및 개발자의 관점에서 통합하고 전체 팀의 전문 지식을 활용합니다.
- 초기 불일치, 토론 및 반복은 첫 번째 대화에서 발생하므로 모든 사람의 시간을 절약할 수 있습니다.
- PRD는 설명보다는 기록하고 코드화하는 역할을 하기 때문에 제품 개요에 더 가깝고 더 짧을 수 있습니다.
- 디자이너와 개발자는 이미 높은 수준의 요구 사항을 알고 있으며 PM이 문서를 작성하는 동안에도 작업을 시작할 수 있습니다.
동일한 솔루션을 사용하는 유사한 시나리오가 프로세스의 다른 단계에도 적용됩니다. 우리는 누군가 모형을 만들기 전에 생산적 협업을 통해 디자인과 개발 시간을 절약할 수 있습니다. 우리는 엔지니어링 문서나 코드를 작성하기 전에 범위와 아키텍처를 논의하여 낭비되는 엔지니어링 주기를 줄일 수 있을 것입니다.
동기식 및 비동기식 협업
팀은 비동기식 협업이 동기식 협업보다 더 효율적이라고 가정하는 함정에 빠지는 경우가 많습니다. 팀을 둘러보고 모든 팀원의 급여를 합산하며 “이 팀으로 인해 얼마나 많은 비용을 치르고 있는지 아십니까?”라고 말합니다. 그러나 팀원들은 Slack에서 토론하고, 문서에 작성하고 댓글을 달고, 의견에서의 불일치가 발생할 때, 이를 확대하고(Slack에서 발생하기 때문에) 궁극적으로 이러한 불일치를 해결하기 위해 더 큰 규모의 회의를 예약하는 데 얼마나 많은 시간을 소비할 것인지에 대한 절충점을 거의 고려하지 않습니다.
간단히 말해서 :
- 비동기식 협업은 간단하고 전술적인 질문에 적합합니다.
- 동기식 협업은 복잡한 문제, 정서적으로 집중적인 주제, 사람들의 의견이 일치하지 않는 경우에 적합합니다.
- 항상 그런 것은 아니지만 일반적으로 생성적 협업은 동기식이어야 합니다.
- 비동기식 토론이 장황하거나 뜨거워지면 동기식으로 전환하세요.
가장 중요한 점은 비동기식 협업으로는 시간을 안정적으로 절약할 수 없다는 점입니다. 회의에 30분만 투자하면 이메일이나 Slack을 통해 어려운 토론 시간을 절약할 수 있습니다. 비동기식 협업으로는 시간을 안정적으로 절약할 수 없습니다.
협업이 아님
협업이 아닌 일이 협업으로 가장하도록 허용되면 문화나 프로세스 변화의 필요성이 가려질 수 있으며, 다시 말해 너무 많은 협업처럼 느껴질 수 있습니다.
다음은 몇 가지 일반적인 함정입니다.
- 피드백으로 위장한 승인
"피드백" 회의의 목적이 누군가에게 어떤 일이 일어나도록 설득하는 것이라면 그것은 협력이 아닙니다. - 피드백으로 위장한 경영진의 변덕
PM으로서 실무를 본 적이 없는 임원으로부터 "우리 고객이 이것을 사용하지 않을 것 같아요"라는 말을 들어본 적이 있다면 무슨 말을 하는지 알고 있을 것입니다.(디자이너들은 "더 적은 클릭만으로 이 작업을 수행할 수 있을까?"라는 두려운 질문에 익숙해질 것입니다.) - 씨 뿌리기
여기서 목표는 사람들에게 그것을 변경할 기회를 주지 않고 어떤 것을 알리는 것입니다. 모든 사람이 모든 일에 협력할 필요는 없습니다만 협업은 아닙니다. - Buy-in(아이디어 또는 접근 방식에 대한 동의) 또는 정렬
"우리 계획은 이렇습니다. 문제가 있나요?"라는 질문에는 차이가 있습니다. (정렬/구매) 및 "여기에 우리가 하려고 생각하는 것이 있습니다. 우리가 놓치고 있는 것은 무엇입니까?" (반응적 협업). - 놓아줄 필요가 있습니다
조직이 성장함에 따라 리더는 세부 사항을 버리고 팀을 신뢰해야 합니다. 경영진이 "헬리콥터를 타고" 프로젝트를 망치는 것은 팀 규모가 작았을 때 합법적인 협업의 흔적인 경우가 많습니다. 작년에는 괜찮았지만 지금은 생산성을 높이는 데 필요한 수준으로 참여할 시간이나 맥락이 없습니다. - 순수한 대화
팀은 관계를 기반으로 운영되며 이러한 관계에는 작업이 필요합니다. 팀 점심 식사와 사교 시간은 이러한 문제를 정면으로 해결합니다. 하지만 주간 팀 회의, 1:1 및 다양한 임시 체크인도 마찬가지입니다. 이 작업을 너무 많이 수행하는 것은 가능하지만 일부는 가치가 있으며 협업과 구별됩니다. 협업을 더 쉽게 만드는 경향이 있지만 말입니다.
당신의 원하는 목표를 달성할 수 있습니까
당신이 속한 팀은 불필요하게 많이 협력하고 있지 않은가요? 아니면 잘못된 방식으로 협력하고 있지 않는가요? 아니면 비협력 활동을 협력으로 취급하고 잠재적으로 파괴적인 행동을 용인할 수 있지 않은가요?
회의의 진실은 일반적인 협업의 진실입니다. 어떤 종류의 활동이 요구하는 목표를 향해 가장 잘 나아갈 수 있을까요? 이러한 질문은 프로젝트를 시작하는 PM이든, 솔루션을 브레인스토밍하는 디자이너이든, 다음 분기의 대규모 출시를 계획하는 제품 마케팅 담당자이든, 분기별 계획 흐름을 수립하는 리더이든, 아니면 그저 새로운 것을 만들고 싶은 사람이든 관계없이 이 글이 도움이 될 것이라 생각합니다.
Do We Collaborate Too Much?
Are we collaborating too much? Or too little? Both—because most of what we call collaboration isn’t actually collaboration at all.
dfeldman.medium.com
번역된 내용으로 오역이나 의역이 있을 수 있습니다. 자세한 내용은 원문을 참고하시기 바랍니다.
'Topic > 기획자라면..' 카테고리의 다른 글
| UX 디자인에서 개인화는 얼마나 중요한가요? (0) | 2024.01.03 |
|---|---|
| 점점 더 높은 수준의 디자인을 달성한다는 것은 무엇을 의미할까요? (0) | 2023.12.13 |
| 조나선 아이브(전 애플 최고 디자인 책임자)의 개인 프로젝트 방식이 디자이너에게 좋은 이유 (0) | 2023.12.06 |
| 일관성이 아닌 통일성을 위한 디자인 (0) | 2023.11.22 |
| 공감 매핑 : 디자인 사고의 첫 번째 단계 (0) | 2023.11.17 |
| 모든 UX에 기대를 어떻게 뛰어넘고, '와우!'를 이끌어내기 위한 통찰력을 얻을 수 있는 6가지 방법 (0) | 2023.11.03 |