아무튼 괜찮다. 중요한 것은 꺾이지 않는 마음
※ 오늘의 로딩팁은 PC 버전에 최적화 되어있습니다. 웹에서 보기
⏱️신규 프로젝트의 개발 PM 업무
안녕 친구들! 벌써 연말이야! 정신없이 진행되던 공채 결과들도 속속들이 나오고 있지? 어떤 결과를 기다리고 있든 간에 중요한 건, ‘꺾이지 않는 마음’이지 않겠어?
오늘 준비해 본 레터는 신규 프로젝트 안에서 개발PM(이하 PM)이 하는 일을 소개해 보려고 해!

시작에 앞서 PM이라는 직무가 모든 회사에 보편적인 직무는 아니야. 신규 프로젝트를 시작할 때 기획자, 프로그래머, 아트만 가지고 프로덕션 과정을 시작하는 곳도 많지. 하지만 게임업계 대기업에서는 신규 프로젝트 킥오프 시 그 과정을 매니징 할 PM을 두는 것이 일반적이야. 또 개발PM을 뽑는 회사들도 점점 많아지고 있는 추세지!

-

1. PM이 신규 프로젝트에서 하는 일은 무엇인가요?

1. 진~짜 초기인 프로젝트에서는?

이제 막  프로젝트가 시작되었다면 PM은 ‘프로젝트 빌딩’을 시작해. 이때 PM은 협업 툴을 정비하고, 작업 프로세스를 정하지. 이 과정에서 작업자들과 ‘어떤 방식이 더 효율적인가’, ‘어떻게  작업 누수를 줄일까’ 등을 고려해.

게임 개발의 최종 목표가 라이브인 만큼, 개발 진척도를 파악할 마일스톤도 수립하지. '이 시점까지는 기본 전투를 완성한다', '이때까지 기본 성장 시스템을 구현한다' 등을 정하는 게 마일스톤이야. 마일스톤이 제대로 설정되어 있지 않거나 우선순위 등이 정리되어 있지 않다면 어떤 일이 일어날까? 기본 전투도 안되는데 차단 기능이나 채팅을 개발하고 있을 수도 있지. 명확한 목표 시점과 구현 스펙이 나오지 않으면 개발실이 일하는 데 우선순위를 파악하기 어려우니 마일스톤이라는 기준점을 세우는거야. 중요한 마감 기준이라고 생각하면 쉬워.

 즉, 개발 PM이 이제 막 시작된 프로젝트에서 하는 일은 개발실이 게임 완성을 위한 스텝을 착실히 밟을 수 있도록 제반 작업을 진행하는 셈이야.

마일스톤
프로젝트 마일스톤은 프로젝트 타임라인에서 특정 지점을 나타내. 특정 활동이 완료된 때나 새로운 단계 혹은 활동이 시작되는 때를 나타내는 일종의 체크포인트!

2. 초기 세팅 이후 본격적으로 개발을 시작한 프로젝트에서는?

개발 PM은 초기에 세팅한 협업 툴 사용이나, 프로세스 등이 잘 워킹하고 있는지 확인해. 그 안에서 개선점이 있거나, 변경 필요한 부분이 있다면 프로세스를 재정립해. 협업 툴 사용 역시 각 팀의 필요나 용도에 따라 각종 칸반, 빅픽처, 스트럭처, 대시보드 등의 협업 툴 기능을 활용해 일정을 확인할 수 있도록 세팅하지. 

PM의 주도로 관리되는 대표 협업 툴 JIRA

또 이 과정부터는 PM이 디렉터/팀장급과 함께 프로젝트 진척에 대한 임원 보고 등을 준비하는 등 상부와의 커뮤니케이션에 많은 힘을 써. '우리 프로젝트는 잘 개발되고 있습니다.', '우리는 이때까지 이렇게 작업해서 출시하려 합니다'라는 어필이 되지 않으면 언제든 프로젝트가 폭파될 수 있거든. '우리가 이만큼 의지가 있다.' '이만큼 개발했다.' 하는 것들을 잘 정리해서 상부 보고 때 프로젝트가 살아남을 수 있도록 돕는 것도 PM의 역할!

아무튼 괜찮다. 신규 프로젝트도, PM에게도, 우리 모두에게도, 중요한 것은 '꺾이지 않는 마음'  

3. 론칭이 코앞! 신규 개발이 막바지인 프로젝트라면?

이제부터는 정말 숨 가쁜 레이스가 시작돼. 론칭을 앞두고 온갖 개발실 인원과 협업 부서들이 PM을 호출하거든. 이때는 내부 개발실 일감 관리와 각종 유관 부서 협업 일정을 더 타이트하게 관리하게 돼. 예컨대 QA 팀이 론칭 QA를 최소 3주 진행하고자 한다면 그 3주 동안 완성 된 밸런스와 시스템이 탑재 된 빌드로 검증하는 것이 가장 좋지만 대부분의 경우에서 그런 상황은 만들어지기 정말 어렵거든. 그렇다고 개발실 입장에서는 안정적인 빌드를 제공하자고 게임의 재미를 타협할 수는 없는 법이니까 의견이 팽팽할 수 있어. 이럴 때 PM 팀이 QA 팀과 개발실 중간에서 커뮤니케이션을 하여 QA 일정을 조율해. 밸런스는 최종 일주일 전에 확인하고, 기본 시스템과 기능, 흐름 등은 그 3주  전까지 완성한다는 식이야.

당연하게도 론칭 직전 PM이 협업하는 부서가 QA 팀만 있는 것은 아니야. 예컨대 론칭 전 신규 프로젝트의 꽃, CBT나 OBT도 진행을 해야겠지? 유저들에게 선공개하기 위한 빌드 일정을 정하고, 테스트 때 공개할 스펙의 범위를 정하는 등 유관부서와 논의도 필요해. 모든 협업 부서와의 일을 PM이 조정하니 정말 끝없이 협의하고, 끝없이 일정을 테트리스하면서, 우리 프로젝트의 성공을 위해 놓친 부분이 없는지 점검해야 해.

또 PM은 라이브 됐을 때 프로세스나 버전 관리 등도 새롭게 정의해. 론칭 직전의 PM은 현재를 타이트하게 준비하면서 미래의 계획까지 함께 수립해야 하는 멀티태스커가 되어야만 하지!

-

2. 라이브PM과 신규 프로젝트PM

신규 프로젝트 PM은 기본적인 일정 단위가 '마일스톤'이고, 라이브 PM은 '업데이트' 라는 점에서 차이가 있지만 실제로 하는 업무는 크게 다르지 않아. 특히 프로젝트를 옮기거나 이직하지 않는 한 모든 신규 프로젝트의 PM은 게임을 성공적으로 런칭시켜서 안정적으로 라이브를 하는 것까지 목표로 삼아.

다만 성향상 어떤 게 더 본인에게 잘 맞는지는 다를 수 있어. 나 같은 경우는 라이브가 더 성향에 잘 맞았어. 아무래도 라이브일 때 업데이트를 하면 유저 반응 등이 가시적이고 즉각적이라 그런 것 같아. 또 라이브에서는 업데이트 일정을 바꾼다는 선택지가 정말 드물거든. 좀 더 단거리 달리기를 한다는 느낌이 들지.

오늘은 신규개발실의 PM 역할에 대해 알아봤어. 여러분이 신규 프로젝트에 가든, 라이브 프로젝트에 가든 PM은 언제나 여러분을 돕고 열심히 일할 수 있도록 돕고 싶어하는 사람이라는거 꼭 기억해줘~!

COMMENT

💬 먀미

프로젝트 망할 각이 보일 때에는 빠르게 탈주하는 것도 방법이지 않을까 싶어.

-

NOTICE


오늘의 로딩팁 레터를 유익하게 읽었다면 설문조사에 참여해 주세요💙
발행인 오늘의 로딩팁
이메일 주소 admin@loadingtip.com
stibee

이 메일은 스티비로 만들었습니다