프로젝트를 진행함에 있어서 가장 중요한 요소는 당연 커뮤니케이션입니다.
커뮤니케이션이 기본적으로 원활하지 못하다면 그 프로젝트의 성사는 불투명해질 수밖에 없으며,
기획하지 않은 정체불명의 완성물을 만들어 낼 수도 있습니다.
커뮤니케이션에 대한 방법론은 이곳저곳에 많이 다뤄지고 있습니다.
오늘은 게임회사에서 제가 활용하고 있는 커뮤니케이션을 위한 몇 가지 사례를 들어보고자 합니다.
아마도 웹에이전시와는 커뮤니케이션 프로세스에 있어서 다소 차이점이 있을 것입니다.
#1 커뮤니케이션 채널을 명확히 해야 합니다.
기획자와 디자이너, 개발자와의 커뮤니케이션은 프로젝트 개발 진행을 위해 필수적으로 수반되어야 합니다.
하지만 더욱더 중요한 것이 유관 부서 (마케팅, 전략기획, 게임개발) 와의 커뮤니케이션이라고 생각합니다.
유관부서가 많을수록 커뮤니케이션 채널은 뒤죽박죽 될 경우가 많습니다.
그럴 경우 담당자 교체 또는 유관부서 내부 공유의 문제 등으로 커뮤니케이션의 단절이 발생할 수 있습니다.
이때에는 각 경우에 따른 업무프로세스를 규정할 수 있는 명확한 담당체계가 필요합니다.
프로젝트가 진행되기 전 커뮤니케이션 채널을 규정하여 공유하고,
업무 프로세스에 대한 rule을 반드시 확립해야 합니다.
위의 구성표는 각 구성원들의 역할과 채널 흐름을 보여주고 있습니다.
예제를 위해서 간단하게 수정을 하다보니 예제의 프로세스는 다소 좀 꼬여있군요 ^^; skip!
담당자별 역할과 커뮤니케이션 채널에 대해서 공유하여
프로젝트의 주요 결정 항목에 대해서 커뮤니케이션 오류를 방지하도록 숙지합니다.
커뮤니케이션 채널 정의와 함께 중요한 것이 담당자별 담당 직무 및 업무 프로세스 rule입니다.
팀별 rule에 앞서는 프로젝트 rule을 확립하도록 하고 이를 공유하도록 합니다.
물론 성립단계의 필수 요소는 '모든 결정권자의 동의'입니다.
담당자별 담당 직무에 대해서 각 부서의 내용을 취합하여,
프로젝트 진행 간 '어떤 업무 진행에 대해서 내가 누구와 커뮤니케이션 해야 하는지'를 숙지합니다.
또한, 담당자의 변동사항이 있을 때에는 바로 문서를 업데이트하여 공유하도록 합니다.
이러한 것들은 매우 간단하지만.. 매우 힘있는 document가 될 수 있습니다.
#2 히스토리를 부지런히 남겨야 합니다.
프로젝트 회의 진행시 회의록을 통해 어떠한 결정된 이슈들이 있었는지,
또는 논의된 이슈들이 존재했는지를 확인합니다.
하지만 회의가 아닌 경우에도 우리는 수없이 많은 커뮤니케이션을 진행하게 됩니다.
그럴 때에는 항상 메모하는 습관을 중요시해야 합니다.
이것은 자기방어의 수단만은 아닙니다.
월활한 프로젝트 진행을 위한 수단입니다.
물론 때로는 커뮤니케이션 문제로 잘잘못을 따질 때에도 필요한 건 사실입니다.
실제로 프로젝트를 진행중에 이런 사건(?)이 있었습니다.
프로젝트 막바지에 뒤늦게 개발 사항을 체크한 운영팀에서
협조를 요청했던 항목이 빠졌다는 클레임을 걸어왔습니다.
해당 섹션 담당자는 그런 커뮤니케이션은 없었다고 얘기합니다.
하지만, 운영 담당자는 분명히 '관련' 회의를 진행할 때 그런 요청사항을 얘기했다고 합니다.
다행히도 담당 PL은 그 당시의 커뮤니케이션을 꼼꼼히 기록해 놓았고
누가 거짓말을 하는지 확인할 수 있었습니다.
업무진행사항 리스트를 통해 프로젝트 Kick-off부터 종료시까지 발생한 모든 사항들이
일별로 빠짐없이 기록되기 때문입니다.
이 케이스는 프로젝트 진행시 불필요한 논쟁에 소모되는 일을 방지해주는 하나의 예라고 볼 수 있습니다.
물론 이러한 경우만 있는 것은 아닙니다.
한창 프로젝트를 진행하다가 "근데.. 이거 그때 어떻게 하기로 했더라?"라는 질문들이
몇 번씩은 나오게 마련이죠.
업무진행사항 리스트는 초기 설정된 세세한 정책에 대한 부분들도 잊지 않고 되새겨 줍니다.
물론 이런 일들은 '프로젝트를 위하여 초기 설정된 전략과 정책들은
진행중 반드시 일정한 스펙에 한하여 변동이 되기 때문'에 발생하는 일들입니다.
#3 회의에서의 커뮤니케이션을 업그레이드시켜야 합니다.
물론 지금 일하는 곳이 효과적인 회의문화를 가지고 있다면 이것은 그리 문제가 되지 않겠지만..
대체적으로 효과적인 회의문화는 그리 흔하지 못합니다.
대게는 어떠한 주제에 대해서 유사하거나 또는 관련없는 대화들이 맴돌다가
아무런 결론도 짓지 못하고 다음 회의를 기약하는 경우가 많죠.
회의는 가능하면 길게 하지 않는 것을 개인적으로 선호합니다.
회의가 길어지면 길어질수록 결론 없이 시간만 허비하는 경우가 많죠.
심지어는 회의에 참석했으나, 무슨 회의인지도 모르거나, 회의에 포커싱 되어야 할 내용에 대한
이해도가 부족하여 회의진행이 어려울 경우도 종종 생깁니다.
회의에 참석하기 전 참여자들은 회의를 통해 무엇을 얻어내야 할지 명확하게 알고 있어야 합니다.
그러기 위해 회의 전 논의될 항목들을 미리 메일로 공유하여 참석 전에 회의 이슈에 대한
공감대가 이루어지고 추가로 필요한 자료들을 수집하는 것이 바람직합니다.
회의에서는 '이게 안되면 안된다'의 극단적인 접근은 위험합니다.
물론 실제로 그래야 할 이슈들도 존재할 수 있겠지만..
과연 그 이슈를 진행했을 때 그만큼 효과적일 수 있는지,
진행시 발생하는 리스크는 결과와 대비하여 감당할 만한 것인지에 대해서도 이성적으로 접근해야 합니다.
물론 브레인 스토밍의 경우는 다릅니다.
브레인 스토밍을 위해서는 더욱 많은 시간이 필요하며, 더 자유로운 공간이 좋습니다.
특히 주요 이슈들이 도출되기 전 단계의 아이디어 회의들은
회사 근처의 커피숍 같은 곳도 개인적으로 선호하는 회의 장소입니다.
회의를 통해 결정된 이슈들은 신속하게 담당자들과 결정권자들에게 공유가 되어야 합니다.
이때 작성된 회의록은 메일로 담당자들에게 공유하며, PM 또는 주요 담당자 (개발담당 또는 정책 담당자 등)
에게는 구두로 한 번 더 말하는 것이 좋습니다.
공유 메일에서도 회의록을 첨부하되, 회의에서 도출된 결론에 대해서는
첨부파일을 열지 않은 상태에서도 확인할 수 있다면 더 수월할 것입니다.
개인적으로 프로젝트 진행시 이루어지는 모든 회의들에 대해서는
그 중요성에 대해 여러 번 강조하고 싶습니다.
회의의 결과는 회의록뿐 아니라 2번째에 말씀드렸던 업무진행사항 리스트에도 꼼꼼하게 기록된다면
더욱 clear 한 프로젝트 진행을 위해서 효과적으로 활용될 수 있을 것입니다.
회의와 관련해서는 '일 잘하는 법, 마이크로소프트에서 배운다 (줄리 빅 지음/김동헌 옮김-한언 출판사)'
라는 책에서 매우 친절하게 설명을 해주고 있습니다.
"쓸데없는 회의는 과감히 없애라. 아니면 회의 시간을 철저히 이용하라" 라는 섹션을 시작으로
회의와 관련되어 이어지는 내용은 단순하면서도 많은 도움이 되는 내용들이었다고 기억됩니다.
개인적으로 이 책은 한번쯤은 읽어보시는 것도 좋을 거라고 권해드리고 싶습니다.
이상 3가지 정도의 '프로젝트 진행시 커뮤니케이션 방안'에 대해서 얘기를 해보았습니다.
물론 정답은 없습니다.
또 다른 어떤 분들은 훨씬 더 효과적인 방법을 활용하고 계실 수도 있으며,
어떤 조직에서는 이러한 방안들이 비효율적일 수도 있을 겁니다.
말씀드렸듯이 '정답은 없습니다' 하지만 '옵션'은 많습니다.
뭔가 답답하고 새로운 시도가 필요하다면 제가 활용하는 방법들도 한 번 고려해 보시길 권해드리며..
커뮤니케이션, 프로젝트 관리 및 조직관리등의 이슈에 대해서는
다음에 좀 다른 주제로 다시 말씀을 드릴까 합니다.
mins.
