게임 개발이 진행되는 동안 가장 어려운 문제는 프로젝트의 잦은 리젝트(Reject)와 사양 변경으로 목표를 잡지 못하고 프로젝트가 표류하게 될 때이다. 이러한 과정이 반복되면 구성원은 지치고 상호 신뢰는 불신으로 바뀌어 시간이 지날수록 상황은 더욱 나빠지기만 한다.
지금까지 나는 이러한 상황을 대부분의 프로젝트에 만나왔으며 항상 이를 극복하기 위한 방법으로 스크럼(Scrum)을 활용해 왔다.
스크럼(Scrum)은 소프트웨어 개발을 위한 방법론 중 하나였지만 이제는 다양한 업무 영역에서 활용될 수 있는 워크플로(Workflow)중 하나로 자리 잡았다. 이미 체계와 방법적인 부분이 정해진 다른 워크플로와는 다르게 요구 사항과 변화된 환경에 맞게 탄력적으로 운영 가능한 애자일 방법론은 여전히 게임 소프트웨어 개발에 있어 매우 강력한 수단이다.
과거 약 20개월이 넘는 기간을 투입했지만 잦은 리젝트와 사양 변경으로 인하여 프로젝트는 아직 프로토 타입 수준을 벗어나지 못했으며, 구성원들의 상호 신뢰와 사기는 바닥을 치고 있는 상황에 업무에 투입되었다. 이런 상황에서 나는 스크럼을 이용하여 핵심이 되는 전투 시스템을 단 5명의 인원으로 약 2개월 만에 새로 만들었고 이를 기반으로 코어 시스템을 구축하고 콘텐츠를 확장해 프로토 타입 수준의 프로젝트를 약 9개월 만에 완성할 수 있었다. 그리고 이와 같은 경험은 다음 프로젝트를 진행할 때 조직의 신뢰와 구성원의 전폭적인 지원의 바탕이 될 수 있었다.
또 다른 경험으로는 일반적으로 약 7명의 인원이 약 3개월 정도의 시간이 소요되는 규모의 프로젝트 오더(업무)를 단 3명의 인원으로 4(20일) 주만에 완료해야 상황을 마주한 적이 있다. 구성원 모두 불가능한 일정이라 생각했고 상급자 또한 되면 좋고 안되면 포기한다는 생각으로 시작되었지만 결과적으로 23일(4주가 조금 넘는 기간)만에 던전 시스템, 콘셉트, 레벨레벨 디자인, 레벨링, 보상, 전투 밸런스, 보스 몬스터, QA까지 필요한 프로젝트 사양을 모두 만족하는 결과물을 만들어냈고 라이브 서비스에 성공적으로 업데이트된 경험도 있다.
물론 스크럼의 도입만으로 항상 좋은 결과를 기대할 수는 없다. 스크럼은 하나의 워크플로(Work Flow)중 하나일 뿐이며 그것을 이용하여 목표를 달성하기 위해서는 책임자의 많은 노력이 필요하다. 그리고 그것은 당신을 무척이나 힘들고 피곤하게 만드는 일이기도 하기에 대부분의 사람이 목표를 달성하기 이전에 실패하는 이유이기도 하다.
시장에 나와있는 다양한 방법론은 대부분 그 방식에 결점이 없다고 생각해도 무관하다. 이는 방법론의 탄생 배경이 프로젝트의 목표를 달성하기 위해 이미 최적화된 방법을 제시하고 있기 때문이다. 하지만 우리 팀에 도입되는 방법론은 항상 목표 달성에 도움을 주기보다는 전반적인 개발 진행에 방해가 되거나 때로는 불필요해 보이기까지도 한다. 왜 그러한 상황이 발생하는 것일까?
다양한 이유가 있겠지만 도입된 방법론에 대한 구성원의 이해도 부족 또는 리드 담당자의 숙련도 부족이거나 최악의 경우 도입된 방법론이 현재 프로젝트와 전혀 맞지 않는 형태를 가지고 있는 경우들이 있을 수 있다. 예를 들면 제품 생산을 위한 방법론을 소프트웨어 개발에 도입해 좋은 결과를 기대하기 어렵다. 만약 어떠한 방법론이 적합한지 판단하기 어렵다면 스크럼(Scrum)을 선택해라 스크럼은 특정 상황을 가정한 방법론이 아닌 매우 넓은 응용 방법을 가지고 있기 때문에 리드 담당자의 숙련도에 따라 매우 효과적인 방법론으로 자리 잡을 수 있다
다만 내가 여기서 이야기하고 싶은 것은 정규 코스를 따르는 스크럼 방식보다는 경험을 통해 유의미한 결과를 만든 개인적인 방법론을 소개하고자 한다. 물론 이 방법론의 근간은 스크럼이라는 점을 잊지 말아주었으면 한다.
당신이 만약 프로젝트의 목표를 달성하고 구성원의 신뢰를 얻기 위해 스크럼(내 개인적인)을 도입하고 싶다면 경험을 통해 얻은 몇 가지 주의 사항을 준수하는 것을 권장한다.
1. 친분을 유지하라.
프로젝트의 목표를 달성하고 안정적인 스크럼을 운영하기 위해서는 업무(Task)를 믿고 맡길 수 있는 사람이 구성원에 포함되어 있어야 한다. 인정하기 싫겠지만 그러한 사람을 만드는 가장 기본적인 요구 사항은 나와 상대의 친밀도이다. 대부분의 사람은 자신과의 친분이 높은 사람의 의견에 더 힘을 실어주거나 의견의 대립을 회피하는 경향이 있다. 그리고 그러한 구성원들은 당신이 스크럼을 성공적으로 이끌기 위해 불필요한 의견의 대립과 반대를 억제하고 도움을 제공하는 가장 효과적인 수단이다. 다만 친분은 성공적인 스크럼 수행을 위한 적극적인 참여를 유도하기 위해 필요한 부분이다. 자신과 구성원의 친목을 위해 변질되어서는 안 된다.
2. 작은 것부터 시작해라.
당신이 스크럼을 도입하려고 한다면 하루아침에 구성원 전체에 그것을 적용하기 위한 불필요한 노력하지 않는 것 좋다. 대부분의 사람들은 현실에 불만족을 표현하지만 그것이 꼭 급진적인 변화를 원하는 것은 아니다. 역설적이지만 변화에 가장 크게 반발하는 사람은 현실에 지독하게 불만족스러운 사람들이다. 이들은 변화를 원한다고 하지만 그것이 자신과 관련된 일이 되는 것을 원하지 않는다. 당신의 스크럼에 이들을 포함하고 싶다면 강줄기가 구부러지듯이 오랜 시간 천천히 그들의 가치관을 깎아 낼 준비가 되어있어야 한다.
매일 아침 아주 작은 것으로부터 시작해라. 예를 들어 아침 커피 한잔과 함께 자연스럽게 어제 한일과 오늘 하려는 일을 물어보고 그들이 업무를 진행하는 데 있어 발생하는 불편 사항과 문제점을 확인해라. 그리고 당신이 할 수 있는 문제부터 해결해 보도록 하자. 어느 순간 당신에 대한 신뢰가 느껴진다면 이제 스크럼을 시작할 준비가 되었다는 뜻이다.
3. 호의적인 사람들로부터 시작해라.
친분을 유지하고 작은 것으로부터 시작해서 사람들의 호의와 신뢰를 이끌어 냈다면 이제 프로젝트의 목표를 위해 움직일 수 있는 필수적인 사람들을 찾아야 한다. 변화에 부정적인 사람을 바꾸기 위해서 당신은 상상이상의 에너지를 소모해야 한다. 반면 당신과 친분이 있는 호의적인 사람으로부터 시작한다면 적은 수고로 성과를 얻을 수 있다. 그리고 결과를 통해 이 놀라운 변화를 주변에서 하나 둘 호의적으로 변해갈 것이다.
4. 당신만의 방식을 만들어라.
당신은 간단한 검색만으로 스크럼에 대한 다양한 정보를 얻을 수 있다. 하지만 그들이 말하는 방식을 그대로 따를 필요는 없다. 스크럼의 가장 큰 장점은 필수적인 두 가지 스프린트(Sprint)와 태스크(Task)만 포함되어 있다면 그 어떤 것이라도 당신이 원하는 대로 바꿀 수 있다는 점이다. 개인적으로 나는 프로젝트의 목표인 스프린트 그리고 태스크를 구성하고 이를 관리하는 스프린트 백로그(Sprint Back Log) 단 3개로 스크럼을 운영한다. 스크럼을 운용하는 것은 상당한 에너지를 소비한다. 그래서 자신에게 익숙하지 않은 방식을 이용하기보다는 자신만을 위한 방식으로 운영하는 것을 추천한다.
5. 변화를 두려워하지 말고 맞서라.
스크럼은 전체 규칙을 설명하는데 10분도 걸리지 않을 정도로 매우 단순하다. 이러한 부분이 스크럼의 매력이지만 반대로 사람들은 스크럼을 아주 가볍게 생각하기도 한다. 하지만 사실은 그렇지 않다. 스크럼은 간단해 보이지만 엄청난 변화를 요구하고 그것은 기존 프로세스에 익숙한 사람들에게 심각한 문제로 받아들여진다. 대부분의 사람들은 변화를 원하지만 역설적이게도 익숙한 것들에 대한 변화에 부정적이다. 그리고 이것을 해결하는 것이 스크럼의 가장 큰 숙제이며, 참석자들에게 스크럼을 통해 보다 합리적으로 문제를 해결하고 보다 나은 업무 환경을 제공할 수 있다는 점을 설득할 수 있어야 한다.
이제 당신이 스크럼을 도입하고 이를 기존 워크플로에 적용한다면 수많은 문제점을 발견하게 될 것이다. 하지만 당황하지 말아야 한다. 그것은 스크럼이 만든 문제가 아닌 이제까지 발견되지 않은 문제들이 스크럼을 통해 발견되었을 뿐이다. 만약 아무런 문제가 없다면 그것은 당신이 시작한 스크럼이 문제이거나 굳이 새로운 워크플로를 도입하지 않아도 되는 상황이다.
그러니 문제가 많이 발견되었다면 축하한다.
이제 당신은 그 문제를 해결할 수 있는 방법을 제시하는 유일한 사람이 되었다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다
여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.
질문이 있으시면 방명록에 글을 남겨주세요.
'게임 기획 > 기획자의 프로젝트 리드' 카테고리의 다른 글
| 03. 게임 기획 매니지먼트 스크럼을 이용한 개발 (0) | 2024.06.26 |
|---|---|
| 02. 게임 기획 매니지먼트 스크럼(Scrum)의 시작 (0) | 2024.05.20 |