Game PM으로 가는 길

  협회에서 일을 한 다음부터 팔자인지 관련 업무를 혼자 진행하는 경우가 많아졌습니다.
  현재도 일정 관리에 있어서는 혼자 업무를 진행하고 있습니다.

  협회에서는 아예 혼자였고, 웹젠이나 현재 있는 곳은 팀에 속해 있지만 담당업무를 혼자 해야 하는 경우입니다. 조금 다른 경우이긴 하지만, 업무 관련 고민을 처리하기에는 혼자라는 것에서 변함이 없습니다.

  무엇인가를 해결해야 하는 입장에 있는 저로써는 이런 구조에 지쳐가고 있습니다. 제 능력을 100% 신뢰하고 있지도 않지만, 그렇다고 제가 추진하려는 일이 100% 옳다는 보장 또한 없기 때문에 누군가 같은 고민을 하고 같이 해결책을 찾아갈 수 있는 조직이 있었으면 좋겠다는 생각을 자주 하고 있습니다.

  주변 지인들과 이야기를 나누기는 하지만, 역시 같은 업무를 하면서 같은 상황에서 고민을 나누는 것에는 부족합니다.

  이런 상황에서는 슬럼프라는 것이 더 자주 오는 듯 합니다. 주로 무엇을 해야지라는 고민에서 시작하기는 하는데, 딱히 답을 낼 수 있는 상황일 때는 무척 답답합니다. 혼자 고민해봐야 머릿속에서 잘못 된 길만 찾아가는 것 같고 말이죠.

  어떻게 해야 이 상황을 극복할 수 있을까요......? 

   현재 dotproject(ver 2.1.1)이라는 솔루션을 시험 중에 있습니다.

   이  솔루션은 웹을 기본으로 한 무료 프로젝트 관리 솔루션입니다. php로 개발되어 있어 웹 상에서 쉽게 설치하고 시험해 볼 수 있습니다.

   운영을 위해서는 php를 지원하는 웹서버와 mysql이 있어야 합니다. 이것 관련해서는 오토셋이라는 괜찮은 설치/관리 프로그램이 있습니다.

   회사를 옮긴 후에 프로젝트 관리 솔루션을 찾던 중 아는 분께서 이슈 트래커로 Redmine을 알려주셨는데, 제가 잠깐 사용해보니 제가 원하는 기능을 찾기 힘들더군요.

   그래서 이것저것 무료 솔루션을 뒤적거리던 중에 이 놈을 발견했는데 기본적으로 제가 원하는 기능을 지원해줄 수 있을 것 같습니다.

   대략적으로 제가 원했던 기능들은 다음과 같았습니다.

- 웹 상에서 간트 차트를 볼 수 있다.
- 각 task에 대한 issue 추적이 가능해야 한다.
- 작업자의 작업 결과를 팀장 혹은 별도의 참조인 알 수 있어야 한다. (이 작업에서 대부분 관련 기능을 못 찾았습니다.)

   dotproject에서는 직접적으로 작업 결과를 팀장에게 알려주는 기능은 없지만, 작업 로그를 작성 할 때에 각 내용을 작업자, 프로젝트 관련자, 작업 관련자 (프로젝트 관련자와 작업 관련자는 미리 정의할 수 있습니다.)들에게 선택해서 메일로 보내줄 수 있습니다. 뿐만 아니라 해당 내용을 알아야 하는 사람들을 선택해서도 메일을 보낼 수 있습니다. 이 기능을 통해서 프로젝트의 갱신 내용을 확인해야 하는 사람들에게 쉽게 알려 줄 수 있더군요.

   또한, 작업 관리에 있어서도 task를 만들 때 subtask들을 추가하여 해당 subtask들의 완료율에 따라 자동으로 완료율을 추적해주는 기능도 있습니다. (Ms project에서 작업 개요에 대한 기능)

   그리고, 자체 인트라넷이 없어 회의실 등 각 종 리소스의 예약 관리 등에 어려움이 있는 회사라면, 이벤트 기능을 통해서 각 종 약속들을 공유할 수 있습니다. 약속 제목을 쓸 때 리소스나 회의실의 이름을 추가해서 적는다면, 회사에 속한 모든 분들이 해당 정보를 공유할 수 있습니다.

   이전 회사에서는 인트라넷이 있어서 쉽게 회의실 예약 상황을 확인하고 회의를 진행할 수 있었는데, 지금 회사는 인트라넷이 없어서 회의실 문 앞에 종이로 회의 내용을 기록하고 있었습니다.

   해서, 회의실에 회의가 있는 지 없는 지 돌아다녀야 확인할 수 있었습니다만, dotproject를 도입하고 나면, 이런 용도로도 사용할 수 있을 것 같습니다. :)

   
   지금까지 시험해본 바로는 당장 상용 솔루션을 도입할 비용이 부담스럽거나 이러한 솔루션에 회사가 익숙해져 있지 않아서 비용 낭비가 예상 될 때에는 dotproject와 같은 무료 솔루션이 좋은 대안이 되리라 생각합니다.

   내일부터 회사 공유를 위한 매뉴얼 작업을 시작할 예정인데, 자료가 완성되면 다시 한번 관련 내용을 올리도록 하겠습니다.

  5월 6일부터 회사를 옮겼습니다.
  다행히 제가 원하는 업무의 역할을 뽑는 회사가 있어서 옮길 수 있었습니다.

  옮긴 회사에서도 개발이 한참 진행 중인 곳이기 때문에 본격적으로 애자일 방법론을 시행할 수 없을 것 같습니다.

  애자일은 저 역시 해본 적이 없기 때문에 몇 번의 시행착오가 있어야 한다고 생각하고 있어서, 당분간은 기존의 개발 방법에서 문제가 있는 경우만 급하게 처리하려고 합니다.

  하지만, 전체 일정 진행이나 진척 확인에 있어서는 일일 미팅을 시도해볼까 합니다. 지금은 시기적으로도 다양한 이슈들을 빠르게 확인 할 수 있어야 하기 때문에 필요하다고 생각하고 있습니다.

  다행히 Director 분들께서는 동의를 해주셔서 진행을 할 수 있을 것 같습니다.
 
  앞으로 진행하면서 공유할 수 있는 내용은 블로그를 통해 공유하도록 하겠습니다.

  아베*는 일본 기업보다도 앞서 있었다. 그는 일하는 사람들이 스스로 자신의 일을 관리해야만 한다고 반복해서 말했다. - 피터 드러커의 매니지먼트 - 97페이지

  의사결정의 책임은 그 의사 결정의 영향과 직접적인 관계를 맺고 있는 곳에 부여해야만 하는 것이다. 피터 드러커의 매니지먼트 - 104페이지

  애자일이나 린 소프트웨어 개발, 성공한 프로젝트 매니지먼트에서는 작업을 하는 사람이 무슨 일을 언제 할 지를 결정해야 한다고 합니다. 이것이 위에서 내려진 지시보다 더욱 효과적이기 때문입니다. 이런 것을 이미 19세기에 주장한 사람이 있었다는 것은 무척 놀라운 일이었습니다.

  * 아베: 1888년 차이스 사(독일의 렌즈 제작 회사)를 물려 받은 물리학자.

 

"원칙 3: 지식을 창출하라.
'폭포수 모델'이 우리를 곤혹스럽게 만드는 측면 중 하나는, 지식이 '요구사항'이라는 형태로 코딩과 분리되어 존재한다는 생각이다. 소프트웨어 개발은 지식을 창출해가는 프로세스다. 전체적인 아키텍처 개념은 코딩 전에 개략적으로 그려질 수 있지만 그 아키텍처의 검증은 코드가 작성될 때 이루어진다. 소프트웨어의 상세 설계는 설령 그것이 문서로 먼저 작성된다고 하더라도 실제로는 코딩 중에 이뤄진다. 초기 설계에서는 구현 중에 마주치는 복잡성을 충분히 예측할 수 없을 뿐만 아니라 실제 소프트웨어를 개발하면서 얻게 되는 피드백을 고려할 수도 없다." -린 소프트웨어 개발의 적용 중-

일반 소프트웨어가 지식을 창출해가는 프로세스라면 게임 개발은 재미를 창출해가는 프로세스라 할 수 있습니다.

이러한 관점은 기획과 프로그래머, 디자이너 들 간의 충돌을 조정해줄 수 있을 것이라 생각합니다.

이 글은 개인적으로 PM으로 돌아갔을 때 사용하기 위한 업무 메뉴얼로 남깁니다.
경험, 공부의 내용에 따라 지속적으로 업데이트 할 예정입니다.

2008년 3월 14일  내용 추가 - PRODUCTION 단계의 1내용 수정
2007년 10월 24일 내용 추가 - PRODUCTION 단계의 8, 9 추가
2007년 10월 22일 내용 추가 - PRODUCTION 단계의 6, 7 추가
2007년 10월 19일 내용 추가 - PRE-PRODUCTION 단계의 10. 팀 빌딩, PRODUCTION 단계 추가,
2007년 10월 18일 처음 작성


PRE - PRODUCTION: 프로토타입을 통과한 후 프로젝트 추진 승인이 떨어진 후 제일 처음 들어오는 단계라고 정의함.

1. 프로젝트 차트 작성 - 프로젝트의 목적, 프로젝트 총괄 책임자(PM)/게임 컨텐츠 책임자(디렉터) 정의, 개괄적인 예산, 기간 정의, 제약 사항 정의

2. 개발팀과 게임 개발 범위 논의
3. PM은 업무 프로세스 정의
4. 프로그램팀 개발 환경 구축(Ship it.성공적인 소프트웨어 개발 프로젝트를 위한 실용가이드 참고)
5. 기획팀 게임 디자인 문서 작성. 이 단계에서 대부분의 게임 기획서는 작성을 완료 해야 한다.
6. 아트팀 적용 기술 연구
7. 의사소통계획 작성 - 회의 계획(개발팀 일일 회의, 팀장 일대일 회의), 정보 전달 방법 등 정의
8. 리스크관리계획 작성 - 지속적인 관리 가능한 방법 추구
9. 프로젝트 개발 주기 정의 (사용할 개발 방법론 정의)
10. 팀 빌딩 - 팀 빌딩을 위한 팀 목표, 팀 핵심가치, 팀 규율, 팀원 선정 기준 등을 정함.

PRODUCTION: PRE-PRODUCTION 단계에서 만들어진 기획서를 가지고 본격적인 개발을 하는 단계라고 정의함.

1. PRE-PRODUCTION 단계에서 작성한 기획서를 기준으로 WBS 작성, 이 때 WBS 는 단계별 출시에 맞게 먼저 출시해야 하는 기능 우선순위로 구성
2. WBS 의 각 ACTIVITY 들의 품질 목표 결정
3. WBS Dictionary 작성
4. 사용할 프로젝트 개발 주기에 따라 일정 개발
5. 마일스톤 확정
6. 리스크 관리
7. 변경 추적
8. 매일 미팅 진행 (팀장 1:1 회의-실천가를 위한 실용주의 프로젝트 관리 7주, 애자일 프랙티스 참고)
9. 진행 상황 추적(작업 결과물 매일 확인. 관리)

애자일이나 "소프트웨어 프로젝트 생존전략"에서 제시하는 단계별 출시를 가능하게 하기 위해서는 먼저 계획을 세우는 단계에서 시작해야 할 것입니다.

이를 위해서는 먼저 작업의 기본이 되는 WBS의 분할 기준을 다음과 같이 바꾸는 것이 효과적일 수 있겠다는 생각이 들었습니다.

그 동안 WBS는 기능 위주의 분할을 생각했습니다. 하지만 이렇게 분할을 하게되면 결국 단계별 출시라는 부분에 있어서 오류가 생길 수 있을 것 같습니다.

WBS의 1차 분류는 몇 단계로 출시 할 것인가로 하고, 그 다음 각 단계에 들어가야 하는 내용은 무엇인가로 분류를 하면 하나의 묶음으로 단계별 출시를 위한 가능한 작업들을 놓치지 않을 수 있을 것 같습니다.

이에 따라 마일스톤 역시 단계별 출시에 맞게 나올 수 있을 것 같고요.

다음 프로젝트를 진행 할 때 적용해봐야겠습니다.

  오늘 출근을 하면서 책을 읽다가 다음 내용의 글을 읽었습니다. 비용과 일정은 중요하지 않다라는 문장으로 시작하는 글입니다.

  "나는 3M의 신제품 개발 프로그램을 여러 번 이끌었는데, 비용과 일정에 대해 거의 생각하지 않았다. 제품이 시장에 출시되기 전에 발생한 개발 비용은 제품에 전가되지 않는다.
   세상에 첫 선을 보이는 제품들은 발명에 기반을 둔 것일 테고, 모두가 알다시피 일정에 맞춰 발명을 할 수는 없는 노릇이다. 이러한 제품의 경우, 지연 비용은 상대적으로 적다. 왜냐하면, 시장을 점령해버릴 경쟁자가 없기 때문이다. 그에 반해 최대한 빨리 시장에 내놓아야 할 제품이 있고, 시장 시험용으로 가능한 일찍 내놓는 단순 버전형 제품이 있다. 일정은 개발팀이 고려할 수많은 트레이드오프 중에 하나일 뿐이다." - 린 소프트웨어 개발 238쪽 -

  물론 게임 역시 R&D의 성격이 크기 때문에 비용과 일정을 정확하게 산출할 수 없고 다는 것은 인정하는 내용입니다. 또한 제품의 성격에 따라 무엇이 중요하냐를 결정하는 것 또한 인정하는 내용입니다.

  하지만, 이런 내용이 비용과 일정이 중요하지 않다는 의미는 아니라고 생각합니다. 책의 저자는 위의 내용을 말하면서 다음과 같이 말합니다.

  "우리의 신제품 개발 프로그램에서 가장 중요한 것은 팀 회계 담당자가 초기에 작성해서 자주 수정하는 손익계산서였다. 손익계산서와 마케팅 계획서가 모든 것을 말해준다- 제품 단가를 어디에서 줄여야 하는지, 언제 제품을 소개해야 하는지, 초기에 얼마나 많은 기능이 필요한지, 트레이드 오프는 어떻게 할지 등. 사업계획서에 따라 일을 수행하는데, 누가 비용이나 일정 관리를 필요로 하겠는가?" - 린 소프트웨어 개발 239쪽 -

  손익계산서를 가지고 개발 내용을 조율한다는 것은 비용을 고려한다는 말과 무엇이 다른 지 모르겠습니다. 게임으로 예를 들면 마케팅에서 이 게임의 시장성을 최대 200억으로 보고 있으니 개발비가 100억이 넘어가면 혹은 출시 일정이 몇 개월 늦어질 때마다 손익이 줄어드니 개발 시 고려해서 만들라고 하는 것과 같다는 내용으로 이해합니다.

  하지만 보시다시피 이런 손익계산서에는 비용이라는 부분이 포함됩니다. 수입에서 비용을 뺀 부분이 손익이기 때문입니다.
  이것 자체가 비용을 고려한 개발이지 않을까요? 그리고, 소프트웨어 개발에 있어서 대부분의 비용은 인건비이고 이런 비용은 일정에 종속적이기 때문에 비용을 고려한다면 역시 일정도 고려하게 될 것입니다.
 
  가치 중심의 개발을 강조하기 위해 이야기 한 것으로 보이지만, 오해의 소지가 많은 글이라고 생각합니다. 아니면, 제가 무엇인가 오해 하고 있는 것일까요?

  요즘 '린 소프트웨어 개발'이란 책을 보고 있습니다. 도요타의 생산 방식에서 그 의미를 가져온 개발 방법입니다. 여기서 이야기 하는 가장 기본은 가치 중심의 사고인 것 같습니다. 저는 린 소프트웨어 개발의 핵심 주장을 프로젝트가 어떤 가치를 주려고 하는 것인가? 가치를 생산하지 않으면서 우리가 하고 있는 활동들을 낭비라고 생각하고 그런 활동들을 제거하기 위한 끊임없는 노력이라고 보고 있습니다.

  우리가 이런 활동을 원활히 하기 위해서는 '고객에게 제공하는 가치'를 명확히 정의해야 할 것입니다. 어떤 것을 장려하고 어떤 것을 제거해야 하는 가? 이것은 조직이 어떤 것에 더 가치를 주고 있는가?로 결정할 수 있다고 생각합니다.

  과거 제가 게임을 기획 했을 때에 가장 먼저 했던 일은 게임의 컨셉트를 잡는 것이었습니다. '이 게임에서 가장 중요한 것은 무엇이고, 무엇에 집중을 해서 게임을 개발하려고 하는가?' 이런 질문들에서 기획을 시작했었죠. 물론 팀과의 공유 부족, 경험의 부족 등으로 그런 부분들을 잘 하지는 못 했습니다만, 요즘 생각하면 그런 활동들이 '고객에게 어떤 가치를 제공하려하는 것인가?'하는 활동이었던 것 같습니다.

  이런 가치(요즘 전 사용자에게 어떤 경험을 제공할 것인지라는 질문으로 사용하는 등 경험이라는 단어들 더 좋아합니다. 게임은 가치보다는 경험이라는 말이 더 잘 어울린다고 생각하고 있습니다.) 중심의 내용을 보다보면 실용주의라는 말이 자주 떠오릅니다. 우리에게는 실학이라는 것도 있었죠. 왠지 이런 개념과 일맥상통하다는 느낌입니다.  그리고, 역시나 개개인이 중요하다고 생각하는 가치는 다르기 때문에 이런 가치의 통일은 반드시 필요하다는 생각도 하게 됩니다. 책에서도 그런 부분을 짚고 있습니다. (다른 내용을 언급하며 나오는 내용이라 조금 제가 이야기하는 의미와는 다른 부분도 있습니다.)

  "...다양한 팀 구성원들이 어떤 것이 중요한지에 대해 인식이 저마다 다르기 때문에 몇몇 사람이 만든 트레이드오프는 어쩌면 다른 사람이 만든 것과 상충할 수 있다. 결과적으로 모든 목표는 타협하게 된다.
     팀에게 경제 모델을 제시하고 구성원들이 비즈니스에서 무엇이 중요한지 파악할 수 있도록 권한을 부여하자. 모든 사람에게 참고할 수 있는 같은 틀을 주었기 때문에 그들은 동일한 가정을 바탕으로 작업을 진행할 수 있다. 결국, 이제 구성원들이 경제적 성공이 무엇을 의미하는지 알기 때문에 그 팀은 경제적 성공에 가까워질 확률이 더 높아진다."
                                                                             <린 소프트웨어 개발, 142쪽>

  저는 이 부분에서 역시 기업의 조직 문화, 기업에서 중요하게 생각하는 가치로 귀결됩니다. 조직이 저자가 주장하는대로 움직일 수 있기 위해서는 결국 조직이 어떤 것을 중요하게 생각하느냐를 조직원들에게 제공을 해주어야 합니다. 이런 과정들이 결국 조직원들에게 자유를 부여하고, 추적과 통제가 아닌 방향과 동기 부여 위주의 경영을 할 수 있도록 해준다고 믿고 있습니다.

  혹시 아시는 분들이 있을 지 모르겠지만, 리얼 서바이벌류 프로그램 중에 헬's 키친이라는 프로그램이 있습니다.

  마지막 한 명의 요리사가 남을 때까지 레드팀 블루팀으로 나누어 매주 한 팀에서 탈락자를 선정하는 서바이벌제도로 운영하면서 식당에서 주문을 처리하는 과정을 보여주죠. 연애 게임 류의 서바이벌 프로그램은 안 보지만 도널드 트럼프의 경영 관련 서바이벌 게임과 이 프로그램은 종종 보는 편입니다. 지난 주 토요일에도 채널을 변경하다가 방송을 하길래 보고 있었습니다.

  지난 토요일 방송에서 레드팀은 의사소통을 안했을 경우의  문제점을 잘 보여주었습니다. 주문 처리로 바쁜 주방 안에서 세 명의  팀원은 서로 말을 않고 작업을 진행 하였습니다. 그 결과 서로 무엇을 하고 있는지, 지금 자기가 무엇을 해야 하는지 모르게 됐고, 주방은 혼란스러워졌습니다. 끊임없이 들어오는 주문은 처리를 못 해 지연을 시키기 일쑤였습니다. 하지만 지적을 받은 후 서로의 업무를 알리는 대화를 시작하자 곧 안정을 찾았고, 팀은 주문들을 처리할 수 있었습니다.

  이 장면에서 문득 애자일의 도구로 언급하는 일일 미팅이 겹쳤습니다. 팀원이 자신, 다른 팀원이 무엇을 하고 있는 지 항상 의견을 나누는 일일 미팅은 현재의 상황을 항상 알려줌으로써 서로 간에 무엇을 해야 할 지 무엇을 하고 있는 지를 명확하게 하는 효과가 있는 듯 합니다.(아직 적용을 할 수 있는 상황이 아니라 추측일 뿐입니다.) 그렇지않으면 밀려드는 주문에 혼란스러워진 주방처럼 개발은 혼란에 빠치게 될 것입니다.

  "…개인으로 인정받고 싶으면 팀원으로 먼저 인정을 받아라…"
  "다른 팀원이 어려움에 빠져 있을 때 손을 놓고 있다면 고통 받는 것은 그 팀원이 아니라 그 음식을 주문하고 기다리고 있는 손님이다."

  -헬's 키친 중에서-