PM 커뮤니케이션 스킬
명확한 소통을 이끌어 내기 위한 기술들
일을 할때 커뮤니케이션을 충분히 하지 않아 심각한 문제를 일으키는 경우가 많다. 커뮤니케이션을 하지 않은 이류를 물어보면 '정치적 위험 때문에', '공개적으로 이야기 하기엔 너무 사소해서' 등과 같은 여러 이유들이 있다. 하지만 과도하게 소통하는 것이 다소 귀찮은 일일지라도, 이는 심각한 문제로 발전할 가능성을 크게 줄일 수 있다. 업무에서의 충분하고 적절한 커뮤니케이션은 피할 수 있는 많은 문제들을 미리 방지하는 역할을 한다.
사소한 차이도 짚고 넘어가야 한다명백한 것을 질문하자
우수한 프로덕트 매니저는 명백한 것을 지나칠 정도로 명확하게 설명하려 노력한다. 개인에게 명확하다고 느껴지는 것이 다른 이에게는 그렇지 않을 수 있기 때문이다.
당연하거나 분명하다고 여겨지는 사항도 재차 언급하여 안전하게 진행하고, 의미의 차이를 미리 파악하여 큰 문제로 번지기 전에 이를 차단하는 것이 중요하다.
서로 생각의 차이가 없었다고 해서 실패한 커뮤니케이션이 아니다. 같은 이해 상태를 확인하는 과정 자체가 프로젝트를 더욱 안정적으로 진행할 수 있게 해준다.
최근 우리 회사에서도 이부분을 간과하여 생긴 커뮤니케이션 오류가 있다. 신입 개발자에게 "2022년부터 2024년까지의 데이터를 기반으로 예측 모델을 만들어 달라"고 작업을 요청했다. 난이도가 낮은 간단한 작업이였고, 데이터에 관한 질문 몇개를 받고 2주동안 팔로우를 하지 않았다.
2주뒤 개발자는 전체년도의 데이터를 통합하여 예측 모델을 제작했다. 그러나 원래 의도는 2022년과 2023년 데이터를 사용하여 2024년 데이터를 예측하는 모델을 만들라는 것이다.
나는 데이터 엔지니어라면 당연히 저렇게 데이터를 구성해서 예측 모델을 만들거라 생각했지만, 신입인 개발자에게는 당연하지 않았던 것이다.
돌려 말하지 말고 직접 말하기
상사가 "A 기능 이번주에 완료되나요?" 라고 물어볼 때가 있다. 부하 직원은 다른 설명 없이 저 워딩을 보면 많은 상상을 하게 될것이다. '이번주 까지 야근을 해서 하라는 건가?', '이번 스프린트엔 없던건데 추가 해야 되나?', '저번 미팅 때 이야기 하던걸 내가 놓쳤나?' 하지만 많은 경우 그냥 의문사항일 경우가 많다.
이 책의 저자는 영국 사람이다. 확대 해석하여 심리적으로 위축되며, 직장 상사의 눈치를 보는 것이 한국 에서만 일어나는 현상이 아닌 일반적인 현상인 것이 놀라웠다.
프로젝트 매니저는 상사나 임원진에게 질문의 의도를 알려달라고 말해야 하며, 질문을 하는 입장에서도 이런 오해가 있다는 사실을 염두한채 질문을 해야 건강한 커뮤니케이션이 가능하다.
무조건 사과하지 말기
많은 프로젝트 매니저들이 변명, 과도한 사과, 자기 비하의 경향을 보인다. 예를 들어, 프로젝트 매니저가 "이번 계획은 실패했습니다. 제가 일정 조율을 잘못했네요"라고 말할 때, 이는 팀 전체에게 성장할 기회를 제한 하는 결과를 가져 온다. 비록 프로젝트 매니저가 최종적인 책임을 지는 것은 맞지만, 이런 자세는 팀원들이 다음 프로젝트에서 성공하기 위해 필요한 개선점을 찾는 것을 방해 하기 때문이다.
또 다른 예로, 프로젝트 매니저가 "제 실수로 A를 잘못 생각했습니다. 제 책임을 지고 B로 진행하겠습니다"라고 말하는 경우를 들 수 있다. 이러한 말은 표면적으로는 책임을 지는 것처럼 보이지만, 사실상 "A의 문제는 무시하고 B로 넘어가 주세요"라는 의미와 다르지 않다. 결과적으로 팀원들은 A에서 B로 전환하는 이유에 대해 충분히 고민하지 않은 채, 단순히 프로젝트 매니저의 요청을 수행하게 되어, 이 역시 팀원들의 성장할수 있는 기회를 제한 하게 된다.
프로젝트 매니저로서 문제를 인정하고 책임을 지는 것도 중요하지만, 이와 동시에 팀 전체가 동일한 실수를 반복하지 않도록 학습하고 성장할 수 있는 환경을 조성하는 것도 필수적이다.
변명이나 과한 사과, 자기 비하에 앞서, 팀원들과 왜 이런 결과가 발생했는지를 공유하고 향후 어떻게 개선해 나갈지에 대해 충분히 소통하는 것이 중요하다.
결과에 초점 맞추기
실패의 원인을 '의도'에서 찾는 것은 피해야 한다. '의도'에 초점을 맞추는 것은 마치 감정적인 골드버그 장치처럼 우리를 부정적인 감정의 영역으로 끌어들일 수 있다. 대신, 대화에서 결과에 집중하는 것이 더욱 도움이 된다. 예를 들어, "이 상황이 원하는 결과에 도움이 되었나요?"라는 질문을 통해 문제를 구체적으로 다루는 것이 효과적 이다.
실제로 나도 많이 쓰고있는 방법 이다. 개발 중에 버그가 발생하는 경우, 개발자의 나태함이나 의도적인 행동 여부는 중요하지 않다. 중요한 것은 버그의 발생이라는 결과와 이를 해결하기 위한 방법이다. 나는 이와 같은 상황에서 이런식으로 질문한다 "버그 발생을 탓하는 것이 아니라, 이런 상황을 미래에 어떻게 예방할 수 있을지가 중요합니다. 우리 QA 시스템에 문제가 있는 것 같은데, 어떻게 생각하시나요?" 이런 접근을 통해 결과에 대한 대비책을 마련하면, 의도와 관계없이 다음 번에는 발전할 수 있다.
동의하지 않음과 헌신
"동의하지 않음과 헌신"은 인텔에서 개발한 팀워크 및 의사결정 규칙 이다. 이 규칙은 간단하면서도 효과적인데, 모든 팀원이 프로젝트에 대해 긍정적으로 헌신할 것을 먼저 약속하고, 그 약속을 이행하는 과정에서 발생하는 모든 질문, 우려사항, 반대의견을 철저히 해결해야 한다. 이를 위해서는 팀원들에게 이 규칙을 사전에 명확히 설명하여, 질문이나 우려 표현이 개인적 비판이 아니라는 점을 이해시켜야 한다.
또한, 이 규칙에서는 침묵을 동의하지 않는 것으로 해석 한다. 회의 중에 이해하지 못했거나 일부 동의하지 않는 사람들이 침묵할 수 있는데, 이때 "침묵은 동의하지 않음"이라는 원칙을 적용하면, 그들이 자신의 우려를 표현하기 시작 한다. 이러한 접근은 모든 의견이 충분히 논의되고 해결될 수 있는 환경을 조성하여, 프로젝트의 성공적인 진행을 돕는다.
회의가 너무많고 낭비적 인거 같아요
팀원들이 회의를 낭비적이라고 생각하고 좋아하지 않을 때, 이러한 인식을 바꾸는 접근이 필요 하다. 이때 팀원들에게 그들이 경험한 가장 생산적이었던 회의에 대해 물어보자. 이를 통해 팀원 들이 생각하는 '좋은 회의'의 조건을 파악할 수 있고, 파악된 의견을 바탕으로, 좋은 회의가 무엇인지에 대한 명확하고 달성 가능한 비전을 함께 만들 수 있다.
커뮤니케이션 시나리오 3가지
시나리오1
상황
임원진 : 2주안에 이기능이 무조건 필요해요! 구현 못하면 많은 고객을 잃게 될거에요.
개발자 : 2주라는 기간은 전혀 현실적이지 않습니다. 해당 기능을 구현하기 위해 최소 6개월이 필요해요.
피해야할 패턴
2주인지 6개월인지 누구말이 맞는지 따져볼까요?
2주안에 해야겠네요 어떻게 해서라도 안될까요?
2주는 말도 안되네요 돌아가세요!
할수있는 일
실제로 고객을 잃게 될지 점검해 보자
임원진이 생각하는 기능과 개발자가 생각하는 기능이 같은지 체크해 보자
우리 회사의 임원진은 모두 개발자 출신 이다. 그럼에도 불구하고, 시나리오 1과 같은 상황이 거의 항상 발생한다. 이전에는 "이게 왜 6개월이 걸려요?", "그냥 내가 해서 2주 안에 마치겠습니다. 다른 일을 처리하세요", "필요 없는 부분은 제거하고 어떻게든 2주 안에 완성해주세요", "이건 그냥 하지 맙시다"와 같은 부적절한 방식으로 문제를 해결해 왔다. 이런 행동이 피해야 하는 패턴에 모두 속한다는 것을 인지하고 반성하게 된다. 상황을 자세히 설명하고, 서로가 생각하는 기능에 대한 이해도를 높임으로써, 의견 차이를 좁혀 나가면 보다 나은 해결책을 찾을 수 있을 것이다.
시나리오2
상황
디자이너 : 요청하신 작업에 대해 4가지 시안을 만들었어요 어떤게 좋을까요?
피해야할 패턴
1번이요
다들 모여서 생각해 봅시다
아무거나 해주세요
할수있는 일
디자이너가 생각하는 최선이 있을수도있고, 목표가 명확하지 못해 골라달라고 하는 경우 일 수 있다
디자이너가 생각하는 최선이 있을때는 그 선택을 믿고 따라주자
목표가 명확하지 못하다면 커뮤니케이션을 통해 명확하게 해준다
결과에 의문이 들때는 디자이너가 목표를 명확히 알고있는지 점검한다
시나리오3
상황
개발자 : 왜 이런 불필요한 절차를 따르라고 하나요? 그냥 제 일만 잘하면 되는거 아닌가요?
피해야할 패턴
잠시만 사용해 봅시다. 사용하다 보면 생각이 달라질 수 있어요!
그래요 불필요한거 같네요 하지 맙시다.
나도 하기 싫은데 바보같은 상사가 시켜서 어쩔수 없어요.
할수있는 일
불필요하다 생각하는 이유를 진지하게 듣고 생각해보기
이 절차가 진정 팀을 위한 프로세스인지 같이 점검해보기
프로세스 개선점을 함께 찾기
시나리오 3은 우리 회사에서도 매일 같이 발생하고 있다. 회사가 아직 초기 단계이기 때문에 많은 프로세스들이 지속적으로 수정되고 변경되고 있기 때문이다. 잦은 프로세스 변경으로 많은 팀원들이 피로감을 느끼며, 일부는 새로운 프로세스를 따르려 하지 않는 경우도 있다. 처음에는 각각에게 이유를 설명하며 협조를 구했지만, 피해야할 패턴 1번인 '일단 사용하세요'라고 요청하는 경우가 많아졌다.
반대하는 팀원들의 의견을 진지하게 듣고 개선점을 찾으려 하지만, "그냥 귀찮아요"나 "이거 없이도 난 잘할 수 있어요"와 같은 반응 때문에 이러한 접근이 제대로 실행되지 않는 경우가 종종 있다. 이는 팀원들 사이에 필요한 프로세스의 가치와 중요성에 대한 인식 차이가 존재하기 때문이다. 이런 상황을 극복하기 위해서는 먼저 팀원들이 변화에 대해 긍정적으로 헌신하는 마인드를 갖는 것이 중요하고, 인식의 차이를 극복하는게 중요한 과제 이다.
세계적으로 유명한 프로젝트 리더 'Matt LeMay' 의 프로덕트 매니지먼트의 기술 책의 '4장 TMI 커뮤니케이션의 기술' 부분을 정리하고, 내 경험 부분은 남색으로 표시하였다.
