프로젝트 관리가 필요할까?
팀 프로젝트든 개인 프로젝트든 게임 프로젝트 관리를 실천하는 것은 보기보다 어렵다. 사실 능력만 된다면 프로젝트를 제대로 관리하지 않고 진행하는 것도 가능하다. 하지만, 프로젝트를 관리하기 시작하면 프로젝트를 훨씬 긍정적인 방향으로 이끌어 갈 수 있다. 이는 보통 PM의 역할지만, PM이 아니더라도 팀원 개개인의 테스크(업무) 관리를 위해서 기획자가 신경써야 함. 그렇다면 어떤 방식으로 관리를 하느냐, "스케줄링", 일정관리 방식으로 프로젝트를 관리하게 된다.
Work Breakdown Structure(WBS)
일정 관리를 시작하기 위해 먼저 WBS를 알아 보자면 프로젝트 전체를 작은 작업 단위로 구성한 작업분배도, 업무를 잘게 쪼개게 된다. 먼저, 기획 부분을 분배하게 되고 그 이후에 프로그래밍과 그래픽으로 분배하게 된다. 그리고 크게 단계를 나누게 되는데...
1. 시스템 기획
1.1. 플레이어 기획
1.1.1. 공격 방식 기획
이런 식으로 보통 3개의 단계로 쪼개어 분배하게 된다. 그리고, WBS와 아주 적합한 스케줄링 차트가 있는데, 바로 간트 차트이다. 간트 차트는 시간의 흐름에 따라 작업 내역을 직관적으로 판단할 수 있는 스케줄링 차트로 기본적으로 업무명, 기간, 작업자, 연관 직업을 표기 하고 업무를 Task(해야 할 일)로 나누고 Depth(단계)를 3개 정도로 파고 든다. (1., 1.1., 1.1.1.) 이와 같이 Task를 Depth로 나눴다면, 날짜와 일정을 기재하고 몇%가 진행 됐는, 진척률이 차트에 나오게 된다.
그 외 스케쥴링 차트로는 작업관의 연관을 구조적으로 파악 할 수 있는 Pert Chat가 있고, 테스크명/ES 작업 종료하기까지 (Earliest Start time), EF(Earliest Finish time), LS(Latest Start time), LF(Latest Finish time), 작업자, 연관 작업을 표시한다.
이런 스케줄링 차트를 작성할 수 있는 소프트웨어들은 MS Project, Gantt Project, OpenPorji, RedMine, PupleMine, 구글 캘린더, Excel(XLGAntt), Trello(트렐로), 등이 있지만 개인적으로 Excel에 미리 만들어진 차트들을 팀에 맞게 수정해서 사용하는 것이 제일 좋고 편리한 것 같다.
Man-Month
Man-month 지표를 통해 업무 분배하는 방식의 프로젝트 관리 기법 있다. 이는 신입을 기준으로 1로 잡고 분배하는 형태로 파트장은 2..., 프로젝트를 진행 할 때 어느정도에 시간과 예산이 필요한가를 Man-month로 배치하는 방식이다.
주의점<현업 기준>
1. 근무 시간은 현에서 실제 업무 시간은 아니니 주의하자.
2. 최하단 유닛(항목의 최하단, 3번째 항목) 단위의 업무는 무조건 시간 단위로 환산 되어야 한다.
예) 총기 장전 시스템은 XX까지
3. 일 단위의 스케줄은 무조건 지켜라 (오늘 일은 오늘 안에), 개발 방범론을 참고하면 좋을 것 같다.
4. 업무 시간 산정을 방해하는 요소를 최소화 해야한다.
프로젝트 관리 항목
체크 포인트) 프로토타입 ,알파, 베타(클로즈 베타) 같이 개발 단계를 나눠야 한다.
중요 시점, 마일스톤) 각 체크포인트의 완성도를 체크하는 가이드라인으로 중요한 목표 또는 업무별로 완성해야하는 시점이다. 작자도 프로젝트를 진행 할 때 매주 1 마일스톤을 해보자는 방식으로 프로젝트를 진행 중이다. 시점은 하나만 존재하는 것이 아니며 프로젝트의 대한 전체적인 그림 또는 일정을 파악할 때 유용하다. 하나의 마일스톤이 종료되면 해당 마일스톤을 검증하는 것이 중요하다.
검증: 마일스톤은 최대한 정확한 검증이 가능하도록 작성. 검증은 테스트 케이스(TC)를 이용하여 진행하는 것이 좋다.
예) 회원 가입은 잘 되는가? -> Explorer, Chrome, FireFox에서 회원 가입 폼이 잘표시되는가? / 사용 가능한 아이디 찾기가 정확히 작동되는가? / 가입자의 휴대폰으로 인증번호가 5초 안에 전달 되는가?
변경 통제: 원래 계획에서 추가, 삭제, 수정 해야하는 사항의 관리. 타 프로젝트보다 게임 프로젝트는 외부, 내부 환경의 변화에 따라 프로젝트 변경이 불가피한 경우가 많다. 프로젝트 변경의 영향을 받는 당사자가 의사결정에 참여해야 하기 때문에 프로젝트 도중 프로젝트를 이탈하는 사람을 조심해야 한다. 프로젝트 변경은 정해진 기간에 공식적 절차에 의해 진행되어야 한다.
리스트 관리: 리스크란 프로젝트 목표에 긍/부정적인 영향을 미치는 사건으로 기회 + 위협, 리스크를 바라볼 때 기회와 위협을 모두 고려해야 한다. 기회를 놓치면 타 경쟁사가 가져가 위협이 될 수 있음 예상되는 리스크를 미리 체크하여 컨트롤 및 대안을 마련 해야 한다.
리스크의 예시)
- 인력: 수급, 충원, 퇴사, 사고, 소속 변경 등
- 요구 사항 변도: 사용자(유저, 경영진, 퍼블리셔, 투자자)의 다양한 추가적 요구, 사용자의 변덕
- 주변 환경의 변화: 엔진의 버전 업, 경쟁작 출시, 오픈마켓 정책 변경, 외주사의 개발 난항
- 비효율 업무 환경: 장비의 노후, 외부 간섭, 개발 외 업무 부하
- 기타: 상위 단계 마일스톤을 위한 하위 마일스톤 항목의 변화, 자금 상황, 비현실적 일정, 팀 내 불화
프로젝트 이력 관리
마일스톤 혹은 프로젝트 완료 후 기간, 사건 등 해당 프로젝트에 대한 이력을 기록하는 것이 좋다. 다음 프로젝트 혹은 타 팀을 위한 참고 자료로 사용하며 이력 관리에는 다음 항목을 포함해야한다.
- 프로젝트 개요(명/일정/참여 이원 등 기본 정보)
- 프로젝트 데이터
- 프로젝트 리뷰, 평가 및 반성
참고하기 좋은 마비노기의 프로젝트 이력이다.
https://dokumen.tips/education/-1-kgc-.html
(PDF) 이은석 마비노기 영웅전 포스트모템 1부 (kgc 버전) - DOKUMEN.TIPS
1. 마비노기 영웅전 개발 포스트모템 1부이은석 / NEXON 2010-9-14 2. 이은석2006 마비노기 영웅전 / 디렉터 Elvis Eunseok Yi 2002…
dokumen.tips
이렇듯, 막상하기는 어려운 프로젝트 관리에 대해서 알아봤다. 정말 이론을 따라서 할 수 있다면 좋겠지만, 여러가지 상황때문에 프로젝트 관리는 결코 쉬운 것이 아니다. 조금이나마 완벽한 기획자/PM이 되기 위해 프로젝트 관리를 습관으로 드려야겠다.
'게임 기획 이야기' 카테고리의 다른 글
| MDA Framework (0) | 2023.03.06 |
|---|---|
| 게임 기획서를 써 보자 (0) | 2023.01.11 |
| 게임을 이루는데 필요한 객체들 (0) | 2023.01.10 |
| 게임 기획자는 프로그래밍을 할 줄 알아야 할까? (0) | 2023.01.10 |