소통의 기술

한수찬·2024년 7월 22일

개발자에게 개발실력보다 중요한게 바로 소통능력이라고 생각합니다.

이 소통이란 것이 단순히 저 혼자 적극적이고, 솔직하다고 해서 모든 상황이 해결되는것이 아니더라고요.
구성원 모두가 합리적이라 판단하면서도, 1+1=2가 아닌 3, 4,5가될 수 있는 잠재된 시너지를 이끌어내는 장치를 공유시켜야 비로서 가능합니다.

그래서 이 부분을 보다 기술적으로 접근해보고 좋은 피드백이 있었던 방법들을 기록하며 발전시켜 나가고자 합니다.

비판회의

청자에게 완전한 반론의 자유를 주어야 가장 옳은 아이디어가 탄생한다 자유론 中

이건 사실상 현대한국사회의 우리 모두가 이론으로 알고있습니다. 하지만 친구사이에서조차 상대방이 기분을 상하지 않게하려 쉽게 반대주장을 내지 못하는데,

하물며 상사, 선배의 의견에 어떻게 반론을 쉽게 할까요.

그래서 여러 조직에서 악마의 대변인을 두어 의견이 통합되는 과정에서 대수롭지 않은, 간과했던 부분을 세세하게 캐내어 결점을 찾아내는 시도를 하고 있습니다.

악마의 대변인 : 의도적으로 다수파를 향해 비판과 반론을 제기하는 역할

여기서 의도적의 의미는 무조건적이 아닌, 의식적으로 이같은 역할을 맡는다는 뜻입니다.
반론하는 사람이 그러한 역할을 맡았다는 사실을 인지한 상태라면 상사나, 선배라 하더라도 감정이 상하기 어렵고, 반론하는 사람도 더 쉽게 목소리를 낼수 있죠.

결론적으로 이상적인 반론의 자유를 현실적인 장치를 두어 실현시키는데에 있습니다.

하지만 기획회의에 직접적 참여를 하지 않는 개발팀에겐 악마의 대변인은 비효율적인 면이 있다고 생각합니다.

자기가 맡은 부분이 아니면 캐치할 수 없는 부분이 있거니와 아이디어 통합의 과정또한 비교적 짧게 진행되니까요.

그래서 비판회의라는 것을 진행합니다.

비판회의 : 한명씩 진행상황을 공유하고 의도적으로 결점을 찾아내어 절충안을 이끌어내는 회의

포인트는 반론을 또 반박할수 있다는 점에 있습니다. 해당 시간엔 반론하는 것 자체가 자연스러운 분위기를 조성하여 반론을 주고 받는 결과로 절충안이 나오는 것입니다.

이러한 반론은 단순히 코드적 결함을 뜻하는 것이 아닙니다.

왜 이 회의에서 한번도 반론을 하지 않았죠? 제 코드의 이거 애매하지 않나요?
진행상황 공유해주셨는데, 말로만 설명해주시니 잘 와닿지 않네요. 시각자료를 준비해주실 수 있나요?
A : 맡으신 테스크가 5일 남았는데 지금의 진행상황으로는 시간이 부족해 보이는데요?
B : 사실.. 이 기능 구현하려면 이 라이브러리 써야하는데 제가 이번에 처음 써봐서요.
A : 테스크 맡으실때 미리 말씀해주셨으면 좋았을텐데요. 이 라이브러리 써보신분?
C : 제가 써보긴 했는데 저도 이러이러해서 시간 내기가 촉박하네요
A : 저도 안써보긴 했지만 여유가 있으니 B와 조인하겠습니다. 대신 중간중간 자문을 구해도 되겠죠?
C : 넵 그럼요. 참고문서들도 이 회의 끝나고 보내드리겠습니다.

이렇듯 평소 하지 못했던 말들을 하며 절충하는 회의입니다.

비판회의 이유 :

소심한팀원의 경우 '좋은것같아요'라며 불만이 있는데도 안고 가다가 의욕까지 떨어지는 경우가 있습니다. 이를 방지합니다.
소심하거나 혹은 반대로 허세가 있는 팀원의 경우 '일단 알겠습니다'라며 자신없는 테스크를 맡고 시간이 지연되거나 해결하지 못하는 경우가 있습니다. 다른 팀원들은 해당 테스크가 완만히 완료될 것이라는 전제로 앞으로의 계획을 그리기 때문에 시간이 지날수록 실패 스노우볼이 커지는 위험이 있습니다. 이를 방지합니다.

포인트

충분히 사전 설명을 가져야 합니다. : 감정적 갈등 없이 잠재된 문제들을 찾아 효율을 높이는 것이 목표입니다. 회의 자체가 불필요하다고 느끼거나, 왜 억지로 까내리지? 라는 생각을 하면 의미가 없어집니다. 그러한 생각까지 공유할 수 있는게 비판회의니까요.
이건 억지로 까는게 정상입니다. 그렇게 느껴질경우 근거를 대며 당신이 억지로 깠다 혹은, 잘못이해한 상태로 결점을 집은것 같다라고 재반문을 해야합니다.
시간을 정합니다. : 비판 시간을 10분 혹은 15분 정도로 짧게 정합니다. 그래야 평소부터 가지고 있던 불만이나, 치명적 요소들에 대한 비판 위주로 회의가 구성되고, 감정적 갈등으로 연결되지 않습니다.

동기화 회의

비판회의가 가장 옳은 의견으로 통합시키기 위한 것이라면, 동기화회의는 정말 통합이 잘되었는지를 검토하는 것입니다.

힘들게 회의를 통해 의견을 도출해냈는데, 다른 식으로 이해했거나, 집중하지 못하여 아예 체크를 못하는 팀원들이 있을 수 있습니다.

회의록을 쓰는것도 하나의 방법이지만, 보다 확실한 방법이 이 동기화 회의라고 생각합니다.

룰

질문자와 답변자를 랜덤으로 정합니다.
질문자는 도출 의견에서 중요하게 생각되는 포인트를 직접 선정하여 질문합니다.
답변자는 자신이 이해한대로 답변하고, 틀린 부분이 있다면 다같이 설명해주어 보충합니다.
의견의 중요한 요소가 더이상 없을 때까지 반복합니다.

효과

개발팀 특성상 온라인 회의를 하게되는 경우도 많은데, 이 때 집중을 못하는 팀원이 많습니다. 이를 방지하고, 집중을 못하였더라도, 보충설명을 통해 확실히 팀 내 동기화를 이룹니다.

주도권 이동

세대에 따라 조직의 리더-팔로워쉽 다르게 나타난다고 합니다.

그 이유는 젋은 세대로 갈수록 능력주의적 생각을 가지고 있기 때문인데요.

그래서인지 고정된 리더가 아니라, 업무별로 특화된 사람이 해당업무를 이끌어 나가며 일을 분배하는 형식의 팀이 많아지고 있습니다.

오래전부터 같이 일을 해오며 모든 팀원들이 서로의 장단점과 성향을 파악하고 있다면 이러한 주도권 이동은 자연스럽게 이루어 질 것입니다. 팀의 효율또한 당연히 올라가고요.

하지만 팀원들의 깊숙한 성향 모두를 알지 못하는 팀이라면 이부분에서 난항을 겪습니다.

확실한 리드개발자가 팀에 있는 상황이더라도, 모든 팀원의 장단점을 확실히 파악해놓는 것이 중요합니다. 특정 상황에서 리드개발자가 어떤 팀원을 의지해야하는지 분명하고, 해당 팀원의 목소리에도 힘이 실려 리더로서 팀을 이끌 수 있기 때문입니다.

포인트

이 주도권은 임시적인 주도권입니다. 한 일행이 산을 탈때는 산을 잘아는 사람이 길잡이가 되어야하며, 바다를 항해할 때는 바다를 잘아는 사람이 길잡이의 역할을 해야할 것입니다.
이 전환이 얼마나 빠르게 이루어지는지가 핵심입니다. 일행이 산에서 바다로 옮겨갔는데 여전히 길잡이가 같다면 이끄는 사람도 이끌기 어렵고 바다를 잘알던 사람은 신뢰가 없기에 목소리를 못냅니다. 이러면 비효율이 생깁니다.
그러기 위해서 마치 면접을 보는 정도로 자기소개가 미리 이루어져 공유가 되어있어야합니다.

한수찬

이전 포스트

[Unity] 컨베이어 밸트 (최적화 ver)

다음 포스트