가능한 모두가 참여하는 공간에서 커뮤니케이션 진행하기!
비대면 업무가 늘어나면서 자연스레 커뮤니케이션 방법이나 상황 역시 다양해지고 있다. 여전히 대면에 비해 비효율적인 경우가 많지만 나름의 방법을 하나, 둘 찾아가며 초반보다는 효율적인 커뮤니케이션이 진행되고 있다. '비대면'이라는 상황 자체가 주는 어려움은 기존의 방법을 조금씩 맞춰가며 해결할 수 있지만, 그중 가장 조심해야 할 유형은 바로 1:1 커뮤니케이션이 아닐까 싶다. 정확히는 우리가 하는 업무에 '직접적' 영향을 줄 수 있는 1:1 커뮤니케이션은 가장 피해야 할 커뮤니케이션 방법 중 하나라고 생각한다. 당장은 단 둘이 메시지를 주고받게 되지만, 어떻게 마무리되느냐에 따라 팀 전체에 영향을 줄 수도 있고, 별도 논의를 다시 진행해야 하는 상황이 발생할 수 있기 때문이다.
(디자이너) OO님,OO님이 말씀하신 웹사이트 얘기 들었어요?
(우리) 웹사이트 지금 기획 단계이고 지난주에 기본 정의 바탕으로 리뷰 했는데요? 그거 말씀하시는 거죠?
(디자이너) 네? 아뇨. 서비스 소개를 위한 별도 웹사이트를 말씀하신 거 같은데요?
(우리) 저는 처음 듣는 이야기인데.. 제가 다시 확인해볼게요!
(디자이너) 네, 우선 디자인팀에서는 레퍼런스 확인 어제부터 진행 중이니 참고해주세요.
(우리) 확인해보니, 지난주 리뷰 진행한 내용 중 회사 소개 페이지에 대한 내용이네요. 기능 정의에 포함된 내용입니다.
(디자이너) 아, 별도 웹사이트라고 이해했네요. 네, 알겠습니다.
(우리) 혹시, 오늘까지 진행하기로 한 레퍼런스는 정리되었을까요?
(디자이너) 아까 말씀드렸던 (별도 웹사이트 구축으로 이해한) 레퍼런스를 먼저 찾느냐고 지금 다시 작업 중입니다.
(우리 ㅠㅠ) 네, 그럼 내일까지 꼭 정리 부탁드립니다.
프로젝트에 참여 중인 멤버가 있는 슬랙 채널이 별도로 존재하는 상황에서 디자이너와 기획자가 1:1 커뮤니케이션을 진행, PM에게 해당 내용이 다시 1:1로 전달된 상황이다. 결과적으로 PM은 순식간에 일정을 조절해야 하는 상황을 마주하게 된다. 동일한 웹사이트를 두고 다르게 해석해 담당 디자이너는 별도 작업을 진행하게 되었기 때문이다. 모두가 모여있는 공간에서 이야기를 꺼냈다면, 다른 웹사이트가 아닌 동일한 웹사이트라는 점을 빠르게 인지하고 정해진 일정에 따라 업무를 진행할 수 있었다. 물론, 업무 단위의 논의 시 '명칭'을 애매하게 지정한 PM의 잘못도 있지만, 서로의 '이해'를 바탕으로 1:1 커뮤니케이션을 진행했을 때 우리가 충분히 만날 수 있는 상황이자, 전체의 업무에 영향을 줄 수 있는 상황이라고 생각한다.
(개발자) OO님, A 기능에 대한 정의가 수정되어야 할 것 같아서요.
(우리) 어제 논의한 내용에서 변경된 내용이 있는 건가요?
(개발자) 네, 공유해주신 문서를 보고 개발팀과 논의했는데 수정이 필요하다는 결론이 났어요.
(우리) 네, 어떤 부분인가요?
(개발자) (중략) 인식한 정보를 서버에 저장하고 있다가 디바이스에 내려줘야 할 것 같아요. 원래는 디바이스에 저장~ (중략)
(우리) 그럼, 지연 등에 대한 안내가 별도로 필요하겠네요? 그 부분 제가 기능 정의 문서에 업데이트하겠습니다.
(개발자) 네, 감사합니다.
(우리) 이런이런 이유로 수정된 문서 공유드립니다. 내용은 이렇습니다.
(개발팀) 네? 이거 왜 내용이 바뀐 거죠? 어제 논의와 다른데요?
(우리) ??? 네 ??? 오늘 오전에 개발팀 논의가 별도로 있었다고 들었는데요?
(개발팀) 아, 그거 개발 리뷰 전에 논의한 거라 어제 논의가 최신 내용이 맞습니다.
(개발자) 제가 문서에 기입된 날짜를 잘못 봐서 헷갈렸어요. 죄송합니다.
(우리 ㅠㅠ) 그럼, 이전 문서로 다시 확인해주세요. 지금 공유한 문서는 버전을 삭제하겠습니다.
(개발팀) 네, 알겠습니다.
앞선 사례와 같이, 결과적으로 문서 수정을 위해 별도 시간을 투자해야 했고 정해진 일정을 일부 미룰 수밖에 없었다. 이번에는 수정이 필요하다는 전제가 '개발팀 논의'에 있었기에 PM이 그냥 넘어갈 수 없었던 상황이다. '논의'의 시기가 최종 리뷰에 앞서 있었다는 점을 놓쳤고, 이로 인해 이미 논의가 끝난 문서에 대해 수정을 하게 된 상황이기도 하다. 이 내용 역시 최초 1:1 메시지가 아니라 공통 채널에 등록되었다면 불필요한 문서 수정 등을 진행할 필요가 없었다. 물론, 공통 채널에 되묻고, 확인하는 과정을 거치지 않은 것도 문제지만 1:1 커뮤니케이션으로 발생할 수 있는 팀 단위의 문제를 보여주는 중요한 사례가 될 수 있다.
왜 이런 문제가 발생했을까? 나 역시 이런 경험을 몇 번 해봤고, 프로젝트 진행에 있어 기본적으로 모두가 확인할 수 있게 메시지를 공통 채널에 남겨달라는 내용을 전하고 있지만 주변에서도 이런 사례를 종종 만나게 된다. 같은 업무를 하는 사람들로부터 말이다. 상황은 조금씩 다르지만, 결과는 늘 비슷했다. 각자의 정해진 일정에 영향을 주게 되는 출발점이라는 점이다. 특히, 오해 또는 진행 상황 등에 대한 파악이 덜 된 상태에서 1:1 메시지를 주고받게 되면 서로가 조심스럽기보다 더 '중요한' 메시지로 인식해 모두가 함께 논의해야 할 상황임에도 그 자리에서 결정, 업무가 진행되는 때가 많았다.
주니어 멘토링 프로그램에 참여하면서 가장 많이 듣게 된 질문 역시 커뮤니케이션, 그중에서도 동시다발적으로 이뤄지는 개개인 간 커뮤니케이션에 관한 내용이었다. 그래서 네 가지 이유를 통해 우리가 1:1 커뮤니케이션을 피해야 하는 이유를 조금 더 자세히 정리해보고자 한다.
'이해'란 '동기화'와 밀접하게 연결되어 있다. 같은 프로젝트를 진행하고, 프로젝트 관리를 위해 여러 툴을 쓰고 있는 상황이라 하더라도 참여하는 인원의 담당 업무와 현재 진행 중인 업무에 따라 서로가 이해하고 있는 상황은 다르게 인식될 수밖에 없기 때문이다. 게다가 프로젝트 중간에 합류한 팀원이라면 아무리 문서를 잘 정리해두어도 모든 내용을 한 번에 이해하고 따라오기란 그리 쉬운 일이 아니다. 이런 상황에서 1:1 커뮤니케이션을 진행하게 될 경우(특히 업무와 밀접한 내용이라면 더더욱) 대화 과정에서 앞, 뒤 맥락에 대해 별도의 시간을 할애해야 하거나 하나의 답을 위해 여러 문서를 다시 확인해야 하는 등의 과정이 필요하다.
물론 프로젝트에 빠르게 온보딩 하기 위해 필요한 과정이라 생각할 수 있지만, 참여자들이 모두 모여있는 공간에서 대화가 진행될 때보다 속도가 훨씬 느리거나 잘못된 정보가 전달될 수 있다. 열린 공간에서 대화를 하게 되면, 내가 잘못된 내용을 전달할 경우 누군가 빠르게 바로잡아 줄 수 있지만, 1:1 대화에서는 정보가 부족한 사람이 전달받은 내용을 그대로 흡수할 가능성이 높다. 그 내용을 바탕으로 다른 리뷰나 커뮤니케이션에 참여할 경우, 잘못된 정보가 순식간에 팀 전체로 퍼질 가능성 또한 높을 수밖에 없다. 실제로 나 역시 이전 버전의 기능 정의를 바탕으로 개발자와 1:1 대화를 진행, 다음 리뷰 시 클라이언트 개발자가 내 이야기를 그대로 받아들여 기능 구현을 다르게 진행한 경우가 있었다. 개발팀과 이미 논의를 끝낸 내용이라, 프로젝트 참여 채널에서 이야기가 오갔다면 금방 잘못된 점을 찾아낼 수 있었을 거라 생각한다.
프로젝트 진행 상황을 모두가 잘 알고 있는 상황이라면, 굳이 모두에게 알림이 가는 전체 채널에 메시지를 남길 필요가 있을까?라는 생각을 할 수도 있지만, 앞서 말한 것처럼 사람의 기억이 아주 체계적이고 완벽하지 않다는 것을 잘 알기에 가능한 모두가 참여할 수 있는 준비가 되어 있는 공간에서 대화하는 것이 더 좋은 방법이라고 생각한다. 일부만 참여하더라도, 모두가 볼 수 있으며 다 같이 확인한 내용을 최종적으로 문서에 업데이트 해 공유하는 과정이 팀 전체가 '놓칠' 가능성을 줄여주기 때문이다.
1:1 대화를 피해야 할 또 하나의 이유는 다른 팀원에게 다시 한번 내용을 정리, 공유하는 과정을 거쳐야 하기 때문이다. 개발자와, 디자이너와, 또 누군가와 1:1 메시지를 주고받은 뒤 어떻게든 마무리가 된 경우, 그대로 남겨두는 것은 위험하다. 둘 사이에서는 정리가 되었지만, 참여하지 않은 사람들은 공유받지 않는 이상 내용을 파악하기 어렵기 때문이다. 게다가 그 대화가 '일정 수준의 변화'를 포함하고 있다면 모두에게 빠르게 정리 후 공유해야 상황을 파악하고 적응할 수 있는 기회를 가질 수 있다.
공유되지 않은 상황에서, 대화한 상대가 지난번 논의 시 이렇게 결정하지 않았어요?라는 메시지를 던진다면 그 순간 모든 책임은 또 한 명의 대화 상태가 될 수밖에 없다. 아마, 그 사람은 PM일 확률이 높다. 열린 공간에서의 대화, 미팅 등에도 '기록'과 '정리'는 늘 뒤따르지만 1:1 대화는 결정되지 않은 내용을 정리해 공유해야 한다는 점에서 또 하나의 단계가 될 가능성이 있다. 더 큰 문제는 여러 명과 1:1 대화를 진행하는 상황이다. 빨리 중단하고, 같이 이야기할 수 있는 환경을 마련하지 않을 경우 대화 별 내용을 정리해야 함은 물론, 의견을 하나로 취합해 결정까지 해야 하는 상황이 생길 수 있다.
위의 내용과 밀접하게 연결되는 내용으로, 1:1 대화에서는 쉽게 '결정'을 할 수 없기에 시작된 논의를 다시 공통 채널로 옮겨가야 하는 상황이 발생할 수 있다. 어떤 상황에서, 어떤 주제로 이야기를 나눴는데 어떻게 생각하는지? 등과 같은 논의를 다시 한번 시작해야 하는 것을 의미하기도 한다. 둘이서 내용을 어느 정도 잘 매듭지었다 하더라도 다른 팀원의 생각은 또 다를 수 있기에 이 경우 아예 논의를 위한 '미팅' 등으로 이어질 가능성이 높다. 그럼, 결국 같은 주제를 가지고 두 번의 논의를 거쳐야 하는 상황이 생길 수 있다. 처음부터 열린 공간에서 이야기를 시작하거나, 이런 내용을 가지고 15-20분 정도 논의하고 싶다 등으로 시작했다면 두 번에 걸쳐 논의할 상황을 피할 수 있으며 서로 논의할 내용에 대해 미리 생각할 수 있는 시간을 가질 수 있다.
개인적으로 가장 우려하는 상황이다. PM이 모르는 상태에서 프로젝트와 관련된 업무가 생기고, 실제 인원과 시간이 투입될 수 있기 때문이다. 앞서 살펴본 사례 중, 웹사이트에 대한 이해가 다른 상태에서 디자인팀이 레퍼런스 확인을 진행하고 있는 것과 같다. 1:1 대화가 위험한 이유는 이처럼 내가 모르는 상황이, 나도 모르게 만들어질 수 있다는 점이다. 공유가 되지 않는다면, 일정 시간이 흐른 뒤 내용을 파악하게 되고, 그 업무가 당장의 우선순위에 포함되지 않는 내용이라면 모두의 일정에 영향을 주게 된다.
1:1 대화 자체를 피해야 한다는 이야기는 아니다. 하지만 위에서 살펴본 2가지 상황과 4가지 이유를 통해 우리는 1:1 커뮤니케이션에도 일정한 기준이 필요하며, 그 기준은 철저히 '팀'과 '프로젝트'의 관점에서 생성되어야 한다는 사실을 알 수 있다. 생각보다 더 많은 1:1 메시지가 오간다는 사실을 여러 번 경험하고 들었기에, 그리고 비슷한 결과를 가져온다는 것을 알기에 이 글을 통해 기준이 없다면, 적합한 기준을- 기준이 있다면 다시 한번 확인하는 계기가 되었으면 좋겠다.
2023년 07월, 제 첫 도서가 출간되었어요. 제목은 ’10년 차 IT 기획자의 노트’입니다. 브런치 '기획자가 일하는 방법'을 시작하게 된 이유는 사수 없이 일하는 어려움을 저보다 조금 늦게 출발한 분들이 덜 느꼈으면 하는 마음 때문이었는데요. 같은 맥락에서, 9개 노트(기록)를 바탕으로 기획과 PM의 주요 업무를 어떻게 하면 좋을지 정리한 내용입니다. 아래 링크를 통해 자세한 내용을 확인하실 수 있어요!