본문 바로가기
자기계발

오해를 막는 커뮤니케이션 노하우 6가지

실제 경험담을 바탕으로 프로젝트 진행 시 자주 발생하는 6가지 상황별로 오해와 불화를 방지하기 위해 필요한 커뮤니케이션을 정리했습니다. 이제 막 프로젝트 관리자가 된 분에게 도움이 됐으면 합니다.

목차

업무 회의 커뮤니케이션

1) 결정해야 할 것이 있을 때 다른 사람들의 의견을 경정해야 하나 최종 결정권은 기획자가 갖고 있다는 걸 명심

  • 그러므로 다른 사람들의 의견이 나의 의견과 다르다고 그 의견을 반박할 필요가 없음
  • 모든 사람들의 의견을 경청한 후 어떤 것을 받아들일 지를 자신의 주관에 따라 결정하면 됨
  • 어떤 것을 받아들일 지 판단하기 힘들 경우, (성급하게 결정하지 말고) 회의 후에 결정해서 그 결정을 그들에게 알려주면 됨

2) 다른 사람들의 의견을 경청하되 그 의견의 근거가 무엇인지 질문해야 함

  • 근거 없는 의견에 흔들려 잘못된 결정을 하지 않기 위함

3) 이 회의에서 내린 결정으로 인해 업무에 영향을 받게 되는 사람들이 있는 경우, 그 사람들을 회의에 참석하게 해야 함

  • 이 결정으로 인해 자신이 받게 될 영향을 알고 이에 대한 자신의 입장을 밝힐 수 있는 기회를 줘야 함
  • 이 결정이 자신의 의지에 반하는 경우 이에 미리 대비할 수 있게 해야 함
  • 자신의 의자와 상관없이 해야 할 일이 더 많아지는 것을 좋아하는 사람들은 없음

4) 프로젝트 매니저는 프로젝트 초기 팀원들과 프로젝트 목표, 우선순위 등을 공유해야 함

  • 이 프로젝트에서 중요하게 생각해야 할 것은 무엇이며 그 이유는 무언지?
  • 팀원들이 중요하게 생각하는 것은 무엇인지?
  • 사람마다 중요하게 생각하는 것이 달라 작은 결정 하나로도 팀원 간의 갈등일 발생할 수 있음
  • 팀원들이 서로에 대해 잘 알아야 갈등으로 인한 불필요한 에너지 소모를 막을 수 있음

5) 특정 사안에 대해 치열한 논쟁이 벌어지는 경우 아래와 같이 해야 함

  • 이 사안에 대한 의사결정권자가 누구인지 파악함
  • 이 사안에 대한 그의 의사가 어떤지 파악함
  • 그 의사와의 공통점을 중심으로 자신의 의사를 합당한 근거와 함께 밝힘
  • 의사결정권자의 결정을 수용함(대부분의 일은 자신의 뜻대로 되지 않음)

6) 회의는 무엇을 결정하기 위한 것이어야 함

  • 회의 전에 이 회의가 무엇을 결정하기 위한 것인지를 회의 참석자들에게 미리 공유해야 함
  • 회의에서 아무 것도 결정하지 못한 경우, 그 회의 참석자들의 인건비를 버린 것임

7) 회의의 횟수와 시간은 가능한 한 줄여야 함

  • 프로젝트 진행 시, 회의로 반나절 이상 소비하는 경우 많음
  • 회의가 잦거나 길면 실제 업무 시간이 줄어듦

상관 보고 커뮤니케이션

1) 문서, 메일, 구두 보고 시 상대방이 무엇을 궁금해하는지 미리 파악해야 함

  • 보고할 내용을 잘 정리해도 상대방의 관심사와 관련이 없으면 소용 없음
  • 보고 후 상대방이 추가로 질문한 것이 있는 경우 향후 유사한 보고를 할 때 보고 내용에 그 내용을 넣어야 함
사례(Bad)

보고하는 사람) “이 프로젝트 일정은 아래와 같습니다.”

보고받는 사람) “그런데 이 프로젝트에서 만들려는 게 뭐야?”

사례(Good)

보고하는 사람) “이 프로젝트에서 만들려고 하는 건 ㅇㅇㅇ이고 일정은 아래와 같습니다.”

보고받는 사람) “OK”

2) 프로젝트 진행 중 상관에게 주 1회나 월 1회의 현황 보고를 해야 함

  • 프로젝트 진행 중 발생할 수 있는 문제들을 사전 예측하고 대처하기 위함
  • 심각한 문제로 발전하기 전의 작은 문제들은 상관이 쉽게 해결할 수 있음
  • 프로젝트 완료 단계에서 상관이 주요 결정 사항들을 변경하는 것을 예방할 수 있음

3) 보고 시, 정확한 팩트만 언급하고 처음이나 마지막에 자신의 의견을 써야 함

  • 상관이 원하는 것은 정확한 팩트에 근거한 실무자의 의견임

4) 보고서를 회사 외부 사람에게 공유하는 경우, 공유하기 전에 회사 내부 관련 부서 결정권자에게 그 보고서를 외부 공유하는 것에 대한 승인을 받아야 함

  • 그 보고서로 인해 다른 부서 사람들이 피해를 받을 수 있음
사례

담당하고 있는 서비스가 1시간 이상 실행되지 않는 장애가 발생했다. 기술 담당자와 함께 원인 파악 후 보고서를 작성해서 내가 속해있는 부서장에게만 보고하고, 이를 관련 업체 사람에게 공유했다.

시스템 관리를 책임지고 있는 곳은 기술부다. 기술적 지식이 없는 기획자가 쓴 보고서는 보는 사람에 따라서 실제와는 다르게 해석할 수 있다.(불가항력적인 장애가 발생한 경우에도 기술 담당자의 실수, 업무 태도 등에 의해 발생한 장애로 보일 수 있음)

이 장애에 대한 책임은 보고서를 작성한 내가 아니라 기술부가 져야 하는 것이었다. 그러므로 이 경우 보고서를 관련 업체 사람에게 공유하기 전에 기술부의 결정권자에게 이 보고서를 외부 공유하는 것에 대한 승인을 받은 후 공유해야 했다.

사업 제안 커뮤니케이션

1) 자사의 강점을 객관적 수치와 함께 자신 있게 제시해야 함

  • 자사의 비전과 핵심 경쟁력을 소개
    “당사는 10년간 미국향 서비스를 제공하고 있는 업체로서 해외 이용자가 귀사의 동영상 콘텐츠를 끊김 없이 볼 수 있게 해 줄 수 있습니다.”
  • 구체적인 성과지표 제시
    “이러한 강점을 통해 소니TV, FOX, 넷플릭스 등을 고객사로 확보했습니다.”
  • 클라이언트에게 줄 수 있는 강력한 한방을 제시
    “당사에서 제공하는 동영상 콘텐츠 스트리밍 서비스는 국내 서비스와 해외 서비스의 속도에 차이가 없으므로 향후 귀사에서 한류 팬 대상 해외 서비스를 할 때 큰 도움이 될 것입니다.”

2) 클라이언트의 요구사항을 서면으로 정리하고 이를 재확인받아야 함

  • 클라이언트가 요구사항을 바꿔 재작업이 발생하는 것을 줄이기 위함
  • 클라이언트가 일정지연에 책임이 있음을 인지시키기 위함
  • 클라이언트는 요구사항을 자주 바꾸는 경향이 있음

3) 비현실적인 추가 제안을 하지 말아야 함

  • 제안한 수준이 산출물 평가의 기준이 됨
  • 클라이언트는 추가 제안의 현실성을 고려하지 않음
    “무엇이든 추가로 해주시면 저희야 좋죠.”
  • 리소스는 한정되어 있으므로 이를 핵심 기능 개발에 집중 투입해야 함

4) 클라이언트의 비현실적인 요구사항은 거절해야 함

  • 비현실적인 요구사항은 산출물의 퀄리티를 떨어뜨림
  • 비현실적인 요구사항은 프로젝트 실무자들 간의 신뢰와 의욕을 떨어뜨림

정보 공유 커뮤니케이션

1) 프로젝트 관련 정보와 정책은 모든 실무자들에게 정확하게 전달해야 함

  • 기획안, 보고서, 회의록 등을 이메일로 보낸 후 수신자들에게 구두로도 관련 내용들을 전달해야 함
  • 관련 부서 실무자와 비공식적 커뮤니케이션 기회를 자주 만들어 프로젝트 관련 정보들을 공유해야 함
  • 부서별로 자신의 부서에 프로젝트 관련 정보들을 공유할 사람을 1명씩 정해둬야 함(주로 각 부서 PM들이 그 역할을 수행함

2) 공유폴더 생성 후, 그 폴더에서 산출물을 통합 관리해야 함

  • 각 실무자가 항상 동일한 버전의 산출물을 참조하게 하기 위함
  • 문서 업데이트 후 관련 실무자들에게 변경된 내용을 확인하게 해야 함

3) 실무자들에게 결정된 정책을 준수해줄 줄 것을 요구해야 함

  • 결정된 정책을 준수하지 않을 경우, 산출물을 검토하기 어려워짐

4) 공식 의뢰 외에 실무자와 해야 할 각종 확인, 문의 등은 캐주얼한 상황에서 해야 함

  • 실무자 업무의 흐름을 끊지 않기 위함
  • 휴식시간, 점심시간 등을 활용하면 부담없이 장시간의 커뮤니케이션 가능

5) 기타

  • 수정 사항들은 모아서 정리한 후, 담당 실무자들에게 전달해야 함
    수정 요구가 잦으면 실무자는 스트레스 받음
  • 반드시 수정을 해야 할 것이 아닌 경우, 말하지 말아야 하며, 말을 할 때는 짧고 단호하게 해야 함
  • 협의할 사항이 생길 경우, 상대방에 연락하기 전에 나의 의견을 명확히 정리해야 함
    논리에 뒤지지 않기 위함

장애 보고 커뮤니케이션

1) 서비스 장애가 발생할 경우, 한 번에 많은 사람들을 모아 의논하기 보다, 가장 연관성이 있는 사람부터 차례차례 찾아가서 의논해야 함

  • 한 번에 많은 사람들과 의논하면 의논의 방향이 엇나가기 쉬움
  • 각자 자신의 기준에 따라 의논의 주제를 판단하기 때문임

2) 다른 사람에게 서비스 장애 처리 요청을 하는 경우, 그 장애를 최대한 단순화 해서 전달해야 함

사례(Bad)
“지난 금요일 새벽에 온에어가 안 된다는 연락을 받고 어드민에 들어가서 확인해봤더니 온에어 체크는 제대로 되어 있었음. 그런데 온에어가 계속 안 나와서 이것저것 해보다가 방송 시간을 2시에서 1시로 바꿨더니 온에어가 제대로 나왔다. 문제가 무엇인가?”
사례(Good)
“온에어 체크가 되어 있는데도 온에어가 안 나왔음. 이상하게 방송 시간을 변경하니 정상화 되었음. 문제는 무엇인가?”

기타 커뮤니케이션

1) 누군가가 나에게 업무 요청을 할 경우, 아래와 같이 해야 함

  • 정확한 요청 사항을 확인해야 함
  • 내가 할 수 있는 범위인지 파악해야 함
  • 할 수 없는 것은 할 수 없다고 얘기해야 함(내가 모든 것을 다 할 수는 없다.)
  • 말은 짧고 명확하게 해야 함(중언부언하면 상대방만 헷갈린다.)
  • 상대에 따라서 대화의 방식을 바꿔야 함

참고 도서: 프로젝트 관리 실무

프로젝트 관리 실무: 프로젝트 관리자의 실무 경쟁력! 프로젝트의 성공전략!
이 포스팅은 쿠팡 파트너스 활동으로 인한 수익이 발생할 수 있습니다. 구매자에게는 비용이 발생하지 않습니다.

이 글과 함께 보면 좋은 글

댓글