게임 개발에서 PM이란?
게임 개발에서 PM이란?
PM이란, Project Manager의 약자로 프로젝트를 관리하는 사람을 말한다.
최근 GameOver라는 게임을 기획하고 팀원을 모집하면서 해당 팀내에서 디렉터 겸 PM을 맡고 있다.(사실 기획도 하고 플밍도 하고 있다.)
프로젝트를 시작하기 전엔 PM에 대해서 나름 자신감이 있었다.
전에 참여한 팀이나 지금까지 참여한 팀에 대해서 프로젝트 협업 방식이나 진행 방식이 그렇게 마음에 들지 않았고, 여러번 직접 나서서 바꾸려고 노력했기 때문이다.
이런 삐뚤어진 생각을 가지고 답답한 것보다 “내가 직접 해보지 뭐!”라는 마인드로 호기롭게 시작했던 것 같다.
과거에 실리콘 밸리의 팀장들에서 읽은 팀장으로써 역할, 솔직함, 피드백, 관계, 성장.. 등 읽고 좋은 팀을 만나고 싶다는 생각도 했기 때문에 더욱 욕심이 나긴 했다.
하지만 게임회사의 PM이라면 조금 다른걸까? 실리콘 밸리의 팀장은 너무 대기업의 큰 팀의 이야기라 인디게임 팀에 적용하기 힘들 것일까? 애자일은 정말 이상적인 방법론인가?
최근에 너무 머릿속이 복잡해지고 있다고 생각했고, 이를 정리하기 좋은 시기라고 생각해서 글을 쓰게 되었다.
나의 생각만 가지고 떠들어 댈 수 없기 때문에 2019년도에 NDC에서 안광섭님이 발표하신 전지적 참견 시점 - 게임개발PM의 내용을 참고하여 내 생각과 비교하여 작성한다.
내용을 읽기전 내가 적용하고 있는 방식을 간단하게 소개한 글이다. 현재 GameOver 프로젝트 진행 방식
전지적 참견 시점 - 게임개발PM
개발 PM은 따로 정해진 문과나 이과의 제한이 없다.
게임 개발 PM은 게임 개발 되도록 하는 사람, 게임이 완성되게, 일이 진행되게 하는 것이 PM의 역할이다.
아무리 제품이 좋아도 출시/완성 되지 않으면 사람들은 제품을 볼 수 없다.
단순하게 PM의 업무를 키워드로만 나열해도 양이 엄청나다.
마일스톤, 커뮤니케이션, 업무 구조화, 회의, 신뢰 관계, 자료 조사, 인프라, 모니터링, 프로젝트 효율성, 지표, 문서화 등등.. (아마 이외에도 더 있을 것 같다.)
우리는 계획을 세워 본 적이 있다
- 누구나 그럴싸한 계획을 갖고 있다 쳐맞기 전까지는
- 마이크 타이슨
- “가장 완벽한 계획이 뭔지 알아? 무계획이야. 계획을 하면 모든 계획이 다 계획대로 되지 않는 게 인생이거든”
- 기생충 명대사
이처럼 계획에 관한 유명한 말이 되게 많다. 이것 말고도 생각나는 말들이 많은데..
여기서 공통점은 계획이 실패한다는 공통점과 그것을 이용한 공감성을 활용한다는 것이다.
사람들은 대부분 계획을 세우고 살지만 실제로 얼마나 지켜지는 것일까?
대부분은 아쉬운 결과를 항상 봤을 것이고 일상 생활이 아니라면 더욱 더 그럴 것이다.
Planning Fallacy(계획 오류)
- 호프스태터의 법칙
- 일이 마치는 데 예상한 것보다 더 오랜 시간이 걸리는 현상
그 일은 항상 당신이 예상한 것보다 더 오래 걸린다. 비록 호프스태터의 법칙을 고려했다고 해도 말이다.
- 계획 오류
- 앞으로 닥칠 일에 대한 낙관적인 전망 때문에 실제 계획했던 일보다 더 많은 비용과 노력이 들어가는 오류
쉽게 말해서 스스로를 과신하고 행복회로를 돌려 계획했지만 실패로 돌아가는 것이다.
이러한 계획 오류는 계획을 세울 때 부터 시작된다.
유명한 사례로 시드니의 오페라 하우스가 있다.
- 6년안에 7백만 달러로 완공
- 16년에 1억달러로 완공
이러한 계획 오류는 일생생활에서도 많이 발생하고 특히 소프트웨어 개발에서 많이 발생한다.
발표 내용과 같이 나는 어느정도 계획 오류를 인지하고 있다.
아직은 프로? 숙련공?이 아니기 때문에 불확실성에 대응하지 못하고 실패할 때가 종종 있다.
위 ToDo에서 해당 날짜에 채워지지 못한 Task들이 그렇다. (이외에도 코멘트로 작성한 문제점들도 있다.)
하지만 계속 수정해 나가며 나름대로 계획오류에 대응하려고 한다.
개인적인 생각을 좀 정리해보자면 사람은 기본적으로 자기 자신을 과대평가하는 경향이 있다.
실제로 나도 자주 그랬으며, 대부분의 사람은 스스로를 과신한다.
그래서 계획할 때 시간내 하지 못하는 능력 밖의 일을 계획하고 실패한다. 그리고 반복한다.
이런 경험을 실제로 직접 해보고 다른 사람들의 계획 오류를 보는 기회가 있으면 쉽게 메타인지가 되기도 한다.
나는 매주 토요일에 10:30분부터 12:30분까지 진행하는 모각코(모여서 각자 코딩)에 참여한다.
매주는 아니지만, 그래도 이번년도에는 많이 참가했다. 4번을 참여하면 무려 아메리카노 쿠폰을 준다..!
해당 링크에 들어가보면 진행방식을 알 수 있지만 이슈가 생성되면 코멘트로 할일을 적고 해당 시간에 구글미팅으로 참여하여 2시간동안 진행하고 이후에 각자 소감을 말하고 종료한다.
처음 참여했을 땐, “이거하고, 저것도 하고, 이것도 해야지”하며 해야할 일을 추상적으로 적거나 지키지 못할 양을 적었다.
결과는 예상할 수 있는 실패였다.
이유는 단순하게 내가 2시간동안 할 수 있다고 생각한 일정이 사실은 불가능에 가깝고, 머리로는 2시간을 쓴다고 했지만 실제 집중하는 시간은 1시간 30분정도였다.
실제 회사에서 8시간을 근무하지 않는 것처럼
지금은 목표를 명확하게 세분화하고, 할 수 있는 분량을 적지만 처음에는 그랬다.
여기서 재밌는 점이 있는데, 새로 들어오신 분들도 무조건 2~3번까지는 항상 2시간 목표 달성에 실패하는 것이다.
물론 모두가 그렇다는 것은 아닌데(아닌 사람은 뭘 해도 잘할 사람..) 대부분의 사람이 계획 오류를 겪는다는 것이다.
내가 계획오류를 극복하는데 많이 도움이 된 글은 박종천 개발자님의 GPAM이다. (내가 정리한 글도 있지만 원문을 보는 걸 추천)
이외에도 프로젝트에서 발생하는 개발자의 추정또한 계획 오류의 주범이다.
낙관적 편향
- 낙관적 편향
- 자신의 미래가 다른 사람들보다 더 밝을 것이라고 믿는 경향
- 소망적 사고로 인해
게임 프로젝트는 다양한 직군, 다양한 이해관계의 충돌의 연속이다.
이를 직접 계획을 세우고 관리한다면?
복잡도가 증가함에 따라 매우매우 힘들어진다.
프로젝트 매니저의 진짜 모습
사람들은 PM하면 높은 직급 무거운 느낌을 상상할 수 있지만, 실제로는 그렇지 않다.
연예인 매니저의 모습에 가깝다.
- 연예인 매니저(한정된 시간에 최대의 효율을 낼 수 있게)
- 연예인의 스케줄 관리
- 새로운 프로그램 잡기
- 연예인 섭외 요청 대응
- 프로젝트 매니저(프로젝트가 한정된 시간에 최대의 완성도를 낼 수 있게)
- 프로젝트의 스케줄 관리
- 새로운 일감 잡기
- 일감 추가 요청 대응
실제 게임 개발 프로세스
디자인/기획 -> 담장자 지정 및 개발 계획 수립 -> 개발 진행 -> 배포 및 후속조치
디자인/기획 단계
무엇을 만들 것 인가?
여기서 PM은 무슨 일을 할까?
- 문서 작성 확인
- 단순 글로 적혀있는 문서를 기획자와 이야기하여 기획 문서의 형태로 만든다.
- 이후 실무자가 바로 작업 가능한 레벨의 문서까지 만든다.
- 우선 순위 정하기
- 이슈를 S, A, B, C로 나누어 급한 우선순위를 정한다.
- S: 게임 진행 불가 이슈, 운영 불가 이슈
- A: 게임 플레이 지장 이슈, 추후 스노우 볼링 이슈
- B: 큰 문제는 없지만 수정되는 것이 좋은 이슈
- C: 수정 여부가 서비스에 큰 지장이 없는 이슈
- 구성원들간의 합의가 명확해야 한다.
- 이슈를 S, A, B, C로 나누어 급한 우선순위를 정한다.
- WBS(Work Breakdown Structure)
- 작업 분할 구조
- 작업을 세분화하여 작업의 흐름을 파악하고, 작업의 우선순위를 정한다.
문서 작성 확인은 팀 기획자분이 잘 해주시고 계시지만 PM으로써 좀 더 신경써야 하는 부분이라 생각된다.
우선 순위 정하기이건 실제로 이건 매우 좋은 방법이라고 생각해 프로젝트에 도입 예정
WBS는 실제로 프로젝트에 적용되어 있다.
아쉬운 점은 플밍파트에서만 적용을 해서 아트, 사운드, 기획단위에서도 좀 병합이 필요할 것 같다.
한 Feature를 모두 같이 작업하는 환경으로 재구성할 에정
담당자 지정 및 개발 계획 수립
누가 어떻게 만들 것인가?
- 일감 회의
- “문서가 없는 일은 진행하지 않는다”가 원칙
- 해당 문서로 일의 규모파악이 가능하도록
- 개발 파트장은 해당문서를 회의 전에 읽고 참여
- 이것을 “검토”라고 한다.
- 검토 과정에서 작업일을 산정
- 일감 회의에선 산정한 작업일을 실제 배치하고 확정
- 버퍼 확보
- 일감 회의에서 산정한 작업일에 약 50%를 더해 확보
- 버퍼는 휴가, 건강, 긴급 이슈등을 고려한 시간
- 실제로 50%를 산정해도 작업 시간이 남는 경우는 거의 없다.
- 문서화
- 문서화는 정말 중요하다.
- 전체 커뮤니케이션 시간을 두고 봐도 활용도가 높다.
현재 프로젝트는 일감 회의를 정기 회의 때 정한다. (모두가 있을 때)
매 회의 때 빌드를 뽑아서 직접 플레이할 수 있도록 하고, 각 작업자가 자신의 작업 사항을 공유하고 이후에 진행할 작업을 공유한다.
모든 작업자가 자신의 작업 사항을 공유했다면, 마일스톤을 생성하고 각자 작업을 적고 일정도 기록한다.
버퍼 확보는 사실.. 각 이슈에서 작업 날짜를 지정해서 가져가기 때문에 개인이 스스로 버퍼를 두는 것 같다.
인디게임 팀 특성 상 온라인 작업만 하다보니 버퍼자체의 개념을 도입하기 어렵다.
문서화는 회의를 포함한 모든 내용을 최대한 세세하게 기록하는 것을 원칙으로 하고 있다.
정기회의를 포함한 비정기(아트, 기획, 플밍)회의 모두 내용을 기록하고 모든 팀원이 공유받을 수 있는 환경을 만드는 것이 원칙이다.
프로젝트의 모든 이슈에는 다 기록이 되어있다.
개발 진행
- 체크하기
- 앞서 계획한 일정이 잘 진행되고 있는지 체크하는 것
- PM은 감시하는 존재가 아닌 다음 길을 알려주는 길라잡이(NPC같은)
- 즉, PM에게 말하면 문제가 해결된다는 것을 명확히 해야 한다.
- 이삭줍기
- 작업을 하다보면 흘려지는 일들이 있다. (생각보다 자주 일어난다.)
- 작업들이 Gray Zone에 빠지지 않도록 PM이 이삭을 줍는다.
강연자님이 강조하시긴 했지만, 가장 중요한 점은 압박감을 주지 않는다는 것이다.
자칫 잘못하면 쉽게 넘어질 수 있기 때문에 문제가 발생하면 PM에게 말하면 된다는 것을 명확히 해야 한다.
프로젝트가 대면작업으로 진행되는 것이 아니기 때문에 나는 1달에 한번 인터뷰를 통해 작업시 어려운 점을 물어보고 있다. (공통적으로 나오는 부분, 개인적인 부분은 최대한 해결해주고 있다.)
이삭줍기는 아직 개발 초기 단계라 발생한지 잘 모르겠지만, 이를 확인하고 통계를 내기 위해선 문서화가 정말 중요해 보인다.
배포 및 후속조치
- 패치 노트 작성
- 초안을 작성하고 이후에 유저에게 공지한다.
- WBS로 작성한 문서를 참고하여 작성한다.
- 점검 진행
- PM이 주도하여 점검을 진행한다.
- 후속 조치
- 이후에 반응을 확인하고, 수치화 등을 확인
- 이후에 다음 패치에 반영할 내용을 정리한다.
아직….! 멀었다 정안아!
PM의 업무
크게 4가지를 뽑아주셨다.
상기 시키기, 분배 하기, 전달 하기, 결정 돕기
상기 시키기(Reminding)
한 개발자는 한 기능만 작업하지 않는다.
여러 작업을 진행하기 때문에 PM은 작업자들에게 작업을 상기시켜야 한다.
또한, 작업자가 작업을 인지했는지 확인해야 한다.
현재 프로젝트는 작업자가 직접 디테일한 부분을 가져가기 때문에 걱정은 없지만 종종 회의 때 마일스톤에 대해서 다시한번 언급하여 강조하긴 한다.
분배 하기(Load balancing)
- 병목현상
- 폭이 좁아서 생기는 현상이나 사고로 인해 생긴다.
개발에서는 러닝코스트가 드는 작업들이 병목현상이 발생한다.
작업자는 해당 일을 파악하기 위해서 시간이 필요하고, 이를 통해 작업을 진행하기 때문이다.
PM은 이를 먼저 파악해야 한다. (Board에서 변화가 없거나 WBS에서 작업이 진행되지 않는다면?)
전달 하기(Messaging)
좋지 않은 소식을 전하는 것은 전달자에게도 유쾌한 일은 아닙니다.
PM은 부정적인 전달하는 경우가 많다.
하지만 누군가는 말해야 한다.
- 밀도 낮은 정보 전달
- ex) 기획이 바뀌었어요! (?? 뭐지..?)
- 대기하라는 건지, 다음 작업을 하라는 건지 알 수 없다.
- 많은 사람이 전달에 집중해서 급하게 전달하다 보니 밀도가 낮은 전달이 이뤄진다.
- 밀도 높은 정보 전달
- 바뀌게 된 이유, 어떻게 바뀌었는지, 업무 히스토리 등
- 언제나 유용한 문서화
- 핫픽스가 발생했다면 해당 상황을 기록하는지 적어둔다.
- 시간, 왜 그런 선택을 했는지, 무슨 일이 있었는지 등을 기록한다.
밀도 높은 정보를 전달받아야 하는 것은 당연하다.
결정 돕기(Decision making)
- 결정을 내리는 것은 PM이 아니다.
PM이 알고 있는 정보는 결정에 매우 유용한 정보이기에 이를 활용할 수 있도록 도와야 한다.
실제로 사람들을 이끌고 결정으로 이끄는 사람이 바로 PM이다.
PM의 역량
맥락적 이해 능력, 새로운 지식 습득, 신뢰 주기, 타협 하기
맥락적 이해 능력
업무적 맥락을 뜻한다.
이를 위해 문서화를 잘 해두는 것이 중요하다.
‘자신의 일상을 문서화하여 자신의 삶을 개선했다’와 같은 형태도 매우 좋은 방향임
가장 중요한 것은 원인을 파악하는 것이다.
새로운 지식의 습득
게임 개발 특성상 매우 다양한 사람들과 일하기 때문에 모든 직군에 대해 이해하는 것은 매우 어렵다.
PM은 마스터나 액스퍼트의 지식을 요구하지 않는다.
따라서 Generalist에 가까워지는 것이 중요하다.
개발자는 Specialist에 가깝다.
신뢰 주기
PM은 본의아니게 거짓말을 해야하는 경우가 생긴다. (일감에 대한..)
신뢰가 무너지지 않기 위해서 사전에 미리 말해두는 것이 중요하다.
타협 하기
좋아서 만들어지는 변수는 없습니다.
PM이 타협을 하면 프로젝트는 어떻게 진행하지?
PM이라도 모든 불확실성에 대해서 대응할 수 없다.
- 버스팩터
- 버스팩터란, 개발자한명이 버스에 의해 사고가 났을 때 해당 프로젝트가 진행이 불가능하다면 이는 버스팩터가 1인 상황이다.
여기서 중요한 능력이 소프트 스킬이다.
최근에 읽고 있는 책 제목이라 신기하다..
느낀점
개인적으로 PM이라는 직군에 대해 고민도 많았고 혼란스러웠는데 역시 생각을 깊게 하고 베테랑 PM분의 강연을 듣고 나의 생각을 정리하니 많이 도움이 되는 듯하다.
중간중간 개인적인 생각을 많이 적었는데, 또 1년이나 당장 몇 개월뒤에 달라질 생각이라도 이렇게 정리해놓고 이후에 본다면 얻어가는게 분명하다고 생각한다.
댓글남기기