처음 프로젝트 매니저를 하면서 알게 된 6가지

2015년 초, 주한 독일문화원이 놀공발전소와 함께 만든 빅게임 ‘Being Faust - Enter Mephisto(이하 ‘파우스트 게임’)’에 대한 평가 프로젝트를 두 달간 진행했습니다.
<출처 : Being Faust 공식 홈페이지>

피엑스디에 입사한 후 제가 처음으로 프로젝트 매니저를 맡았던 프로젝트였는데요. 저를 포함해 팀원 2명과 코치 1명으로 구성된 소규모 프로젝트였지만 여러 가지 배운 점이 많아 몇 가지를 공유드리려 합니다. 사실상 제가 배웠다기보다는, 코치였던 송영일 책임연구원이 ‘가르쳐’준 게 많습니다

1. 클라이언트가 내 움직임을 예상할 수 있게 하기

나 : 프로젝트 일정을 짠다고 해서 이대로 지켜질 것 같지도 않은데, 왜 짜야 하는 거죠?
송영일 코치(이하 ‘송’) : 누군가에게 일을 시킨다고 생각해보세요. 그 사람이 어떤 식으로 일하려고 하는건지 궁금하지 않을까요?

프로젝트를 시작하면 가장 초반에 해야 하는 일 중 하나는 전반적인 프로젝트 일정을 계획하고, 이를 클라이언트와 공유하는 것입니다. 하지만 워낙 프로젝트 초기였기 때문에 아는 정보도 별로 없는 상태에서 계획을 세워야 했고, 이에 대해 저는 어차피 이대로 흘러갈 것이 아니기 때문에 무의미한 작업이 아니냐고 코치님께 투덜댔습니다.(지금 생각하면 정말 바보 같네요 --;) 이 때 코치님은 프로젝트의 일정을 세우는 것은 우리의 액션 플랜을 만드는 것이기도 하지만, 동시에 클라이언트가 우리의 움직임을 예상할 수 있도록 하기 위함이라고 했습니다. 클라이언트 역시 이 프로젝트를 함께 하는 파트너이기 때문에, 이 일정이 철두철미하게 지켜지는 것보다 중요한 건 서로 바라보는 프로젝트 흐름이 일치하는 것입니다.

2. 나와 프로젝트의 연결고리 찾기

송 : 이 프로젝트 경험은 당신과 무슨 상관이 있나요?
나 : O_O??? 그냥 해야 되니까 하는 거 아닌가요???

프로젝트가 원래 내가 흥미있어 하는 분야이고, 한번쯤 연구해보고 싶던 주제라면 더할나위 없을 것입니다. 하지만 많은 경우 그렇지 않죠. 그래서 내가 이 일을 하는 이유는 ‘주어졌기 때문에’인 경우가 많습니다. 하지만 코치님은 프로젝트 RFP나 클라이언트의 요구와는 별개로, 이 프로젝트를 통해 스스로가 진짜로 알고 싶고 궁금해하는 ‘자신의 질문’을 계속 생각하고 가다듬어야 한다고 주장했습니다.
이에 따라 원래 인생의 목표가 ‘흥미로운 사람들을 많이 만나기’인 저는 ‘어떻게 하면 서로가 흥미로운 자극을 주고 받는 경험을 만들 수 있을까?’라는 질문을, ‘공감하는 디자이너’가 되고 싶은 팀원은 ‘어떻게 하면 다른 사람에게 관심을 가지고 공감할 수 있을까?’라는 질문을 가지고 프로젝트에 임했습니다. 프로젝트 진행이 내가 하고 싶은 것과 별개가 아니라는 것을 깨닫고 연결고리를 찾을 때, 프로젝트 몰입이 좀 더 쉬워집니다.

3. 리서치 프레임 세우기

나 : 설문지 설계하는 게 어려워요 ㅠㅠ
송 : 리서치 프레임을 먼저 설정하고 그에 맞춰 질문을 뽑아야 합니다.

프로젝트의 성격이 ‘평가’였기 때문에, 평가 척도를 세우는 게 프로젝트에서 가장 중요한 작업 중 하나였습니다. 처음에는 게임의 흐름에 맞춰 필요한 질문에 대한 아이디어를 모아봤는데, 뭔가 중구난방 진행된다는 느낌이 강했습니다. 코치님은 리서치 프레임이 없기 때문에 그런 거라며, 인터뷰를 설계하든 질문지를 설계하든 기본 리서치 프레임을 세우는 작업이 우선되어야 한다는 걸 알려주었습니다. 리서치 프레임은 기존의 베이직 리서치와 RFP(Request for Proposal), 클라이언트와의 이해관계자 인터뷰를 토대로 만들었습니다. 또한 인터뷰와 설문을 둘 다 설계해야 했기 때문에, 좀 더 깊이 있게 물어봐야 하는 인터뷰를 먼저 설계하고 여기서 객관식 질문으로 물어볼 수 있는 요소를 뽑아 설문지로 만들었습니다.

4. 클라이언트 먼저 찾아가기

송 : 오늘쯤 독일문화원에 먼저 찾아가는 건 어때요?
나 : 네? 먼저 부르지도 않았고 회의를 잡지도 않았는데요?

프로젝트를 하다보면 일정도 빠듯하고 일하기도 바빠, 정례미팅이 있거나 클라이언트 쪽에서 먼저 부르지 않으면 굳이 찾아갈 필요가 없다고 생각했습니다. 하지만 코치님은 분명한 목적이 없더라도 클라이언트를 찾아가 차 한 잔하면서 친해지기도 하고, 비공식적인 자리에서 편하게 프로젝트 이야기를 나누는 게 신뢰 형성에 중요하다는 조언을 하셨습니다. 그럼에도 불구하고 정말 ‘차 한 잔’하기 위해 클라이언트를 만날 용기를 내지는 못했지만, 프로젝트를 진행하는 과정에서 리서치를 하고 나면 데이터를 정리하기 전에 raw data를 들고 먼저 찾아가서 전반적 내용을 공유했습니다. 사실은 1주일 뒤에 깔끔한 보고서와 함께 어차피 나눌 이야기였습니다. 인터뷰와 설문 조사를 갓 마친 뒤 나온ㅡ 정리되지 않은 중요 인사이트를 먼저 공유하는 것은 보고서를 만들 때까지의 시간도 클라이언트의 신뢰를 바탕으로 여유롭게 확보하고, 중간 보고서의 흐름에 대해 서로의 생각을 확인하게 해주었습니다.

5. 각자의 역할 찾기

나 : 할 일이 너무 많아요... 계약서 검토에, 인터뷰 진행에, 클라이언트 미팅에...
송 : 너무 혼자 다 하려는 거 아닌가요? 팀원한테 걸맞는 역할을 나누어서 만들어 줘야죠.

이 프로젝트에는 홍콩 해외 리서치와 국내 리서치가 모두 포함되어 있었습니다. 저는 이전 프로젝트에서 해외리서치 경험이 있었기 때문에 초반에는 저에게 업무가 편중되는 경향이 있었습니다. 업무가 많아지는 저도 힘들었지만, 자신의 역할이 분명하지 않았던 팀원 역시 불편했던 건 마찬가지였습니다. 해외리서치를 마친 후에는 저는 PM으로 프로젝트 방향에 대한 생각과 클라이언트와의 커뮤니케이션에 힘쓰고, 다른 한 명은 사용자 리서치 총괄 담당으로 한국에서의 사용자 인터뷰, 데이터 정리 및 문서 작업을 수행했습니다. 각자의 역할에 몰입하며 쓸데없는 회의와 외근을 줄인 것은 야근 시간을 줄이는데도 좋은 역할을 했습니다.

6. 필요한 방법론을 쓰기

송 : 인터뷰 데이터는 어떻게 정리할 건가요?
나 : 어피니티 다이어그램 작업을 해서 핵심적인 보이스를 도출하려고 합니다.
송 : 정말 필요해서 어피니티를 하는 거에요, 아니면 기계적으로 프로세스를 따라가는 거에요? 지금 필요한 방법론이 뭔지 생각해 보세요.

이 프로젝트는 ‘평가’ 프로젝트였기 때문에, 설문조사를 통해 정량 데이터를 뽑고 심층인터뷰를 통해 정성적 데이터를 뽑은 뒤 이를 각각 정리하면 된다고 예상했습니다. 정량 데이터는 엑셀을 돌려서 그래프로, 심층 인터뷰는 어피니티 다이어그램(Affinity diagram/‘친화도법’이라고 번역하기도 합니다 ) 방법론을 사용해 데이터를 정리하면 된다고 생각했죠. 하지만 핵심이 되는 유저 보이스는 굳이 어피니티를 하지 않아도 인터뷰 데이터를 정리하면서 걸러진 상태였습니다. ‘뭐라도 나오겠지’라는 생각으로 방법론을 쓰려고 했을 때, 송 코치님은 제동을 걸고 ‘이 방법론이 정말 필요한지 생각해보라’는 조언을 했습니다.
논의 끝에, ‘파우스트 게임’이라는 새롭고 혁신적인 경험의 본질을 파헤치려면 플레이어의 경험을 잘 이해해야 하고, 그러기 위해서 pxd에서 가장 많이 쓰는 ‘퍼소나(persona)’ 방법론을 사용하자는 결론에 도달했습니다. 프로젝트 시작 때만 하더라도 평가 프로젝트에서 퍼소나를 만들 줄은 예상하지 못했던 터라 처음에는 당혹스럽기도 했습니다. 하지만 플레이어의 행동패턴을 퍼소나로 모델링하면서 이 경험을 이해하는 의외의 단서를 찾을 수 있었고, 최종보고서에서도 중요한 인사이트로 활용되었습니다.

이 프로젝트는 경험 평가, 적은 기간과 팀원, 일반기업이 아닌 클라이언트 등 조금은 특수한 맥락에서 진행되었던 것입니다. 이 프로젝트를 통해 배운 경험이 다른 프로젝트를 진행하는 데 큰 도움이 될지는 모르겠지만, 처음으로 PM이 되어 막막함을 견뎌야 하는 분들께 조금이나마 도움이 되길 바라며 써보았습니다. 돌이켜보면 실수투성이었던 두 달이었지만, 적재적소에서 필요한 조언을 건냈던 코치와 자신의 역할을 묵묵히 담당하며 항상 힘이 되어준 팀원이 있었기에 무사히 마칠 수 있었습니다. ‘Being Faust 게임 평가’ 프로젝트 관계자분들께 감사의 마음을 보내며 글을 마칩니다.

감사합니다.

[참고##프로젝트 방법##]