게임 제작 뿐만 아니라 개인 / 혹은 팀 단위 프로젝트가 일정 부족에 허덕이는 근본 이유는 단순하다. 자신도 모르는 사이에 프로젝트의 진행 방향이 계속 흔들리고 있는 것.
프로젝트를 진행하다 보면 계획은 계속 바뀐다. 이것 자체는 문제가 아니다. 프로젝트 시작 시점에 이후 발생할 모든 문제를 예상하는 것은 불가능하기 때문이다. 문제는 계획이나 목표를 변경하는 과정에서, 그것을 판단할 기준까지 함께 흔들리는 경우다.
프로젝트 시작 시점에는 앞으로 발견될 모든 문제와 변수를 알 수 없다. 실제 제품을 만들고 검증하는 과정에서 새로운 정보가 생기기 때문에, 초기의 목표와 세부 계획은 필연적으로 수정된다. 따라서 프로젝트 관리에서는 ‘변경을 없애는 것’보다 변경이 필요할 때 얼마나 빠르고 일관되게 의사 결정을 내릴 수 있는가? 가 중요해진다.
나는 꽤 오래전에 프로젝트 일정 관리와 관련한 큰 실수를 범한 이후부터 철칙이 하나 생겼다. 프로젝트 이슈에 대한 의사 결정은 최대한 빠르게 한다는 것이다. 그 이유는 아래와 같았다.
- 이전 경험을 돌이켜 봤을 때, 결정을 미루고 검토에 시간을 쓰곤 했는데, 체감 상 한 80%는 그냥 시간만 흐른 경우가 대부분이었다.
- 그렇게 되는 이유는, 어차피 고민한다고 더 나은 결과가 나오거나, 이슈에 영향을 미칠 다른 사건이 벌어지지 않기 때문이다. 스스로에게 확신을 주지 못하는 자신감의 문제로 결정을 못한 것이 대부분이므로 당연한 일이다.
- 때문에, 그냥 시간을 버리느니, 빠른 결정과 구현 > 재평가의 반복 개발(이터레이션) 사이클에 투자하는 것이 오히려 효과가 좋다.
소프트웨어 엔지니어링이 발전하고, 개발 방법론과 최신의 프로젝트 관리 기법 등이 소개되면서 위의 내용은 그렇게 새로운 내용도 아니게 되었다.
이 원칙을 세운 이후 납기를 지키는 비율은 이전보다 확실히 높아졌다. 하지만 그것만으로 프로젝트가 쾌적해지지는 않았다. 일정은 맞추더라도 여전히 야근과 크런치가 필요했고, 프로젝트 후반의 혼란도 완전히 사라지지 않았다. 빠른 의사결정은 분명 효과가 있었지만, 그것만으로는 충분하지 않았다.
그러던 중, 최근 회사에서 진행중인 프로젝트의 중간 마일스톤 관리는 꽤 인상적인 결과를 달성했다. 구체인 설명을 하자면,
- 다른 프로젝트와 마찬가지로 시간 대비 달성해야 하는 마일스톤의 결과물 수준이 상당히 높았다. (대부분 마일스톤 전의 일정 계획 미팅에서 다들 한숨을 쉴 정도)
- 프로젝트 커뮤니케이션 비용이 높은 상태(중 규모의 개발 팀, 프리 프로덕션 단계)였다. 프로젝트 커뮤니케이션 비용은 프로젝트 관리에 있어 높은 위험 요소이다.
- 그럼에도 불구하고 정식으로 크런치를 운용하지 않았다. (농담 반 진담 반으로 할 수도 있다는 이야기를 하긴 했지만)
- 크런치를 운용하지 않았다는 이야기인 즉, 프로젝트 일정을 계획한 기간에 (심지어 반나절 정도 당겨서) 완료했다.
- 프로젝트 관리의 삼각형에 의해 품질을 포기했는가? 오히려 계획한 제품 품질보다 더 높은 상태로 중간 마일스톤을 달성했다.
물론 나를 포함한 특정 인원들의 야근을 없앨 수 있었던 건 아니지만, 과거에 지나갔던 수없이 많은 날들 고생을 해가면서 진행했던 프로젝트에 비한다면 정말 쾌적한 환경에서 개발을 했다고 할 수 있다. 어떻게 그런 일이 가능했을까? 빠른 반복 개발, 짧은 확인 주기, 디자인 필러의 설정, 빠른 의사결정 같은 것들은 이전 프로젝트에서도 이미 시도했던 방식이었다.
이번에 달랐던 것은 방향성을 ‘설정했다’는 사실이 아니라, 설정한 방향성이 프로젝트 내내 크게 흔들리지 않았다는 점이었다.
당시에는 이것을 명시적인 원칙으로 인지하고 있지는 않았던 것 같다. 다만 실제 의사결정을 돌아보면, 방향성 자체를 반복해서 재검토하기보다 그 방향성을 기준으로 현재의 이슈를 어떻게 해결할지, 당장의 목표를 어떻게 조정할지에 커뮤니케이션이 집중되어 있었다.
흔들리지 않는 방향성은 프로젝트 관리에 부수적인 이점을 가져온다.
- 방향성이 기준이 되기 때문에 의사 결정의 속도가 더욱 빨라진다. 결정 근거가 명확하기 때문이다.
- 팀원이 늘어날 수록 발생하는 커뮤니케이션과 동기화 비용을 극단적으로 줄여준다.
- 해야 할 일이 명확해지고, 때문에 할 일을 구체화 할 수 있다. 구체화 된 업무는 계량화 및 정량화가 가능해지고, 때문에 세부 업무 계획이 객관적인 근거 하에 수립 된다.
대부분의 프로젝트가 나름의 방향성을 설정하고 시작한다. 하지만 돌이켜보면, 우리는 종종 그 방향성을 프로젝트가 도달해야 할 목표 자체로 취급했던 것 같다.
방향성은 본래 항해에서의 북극성처럼 현재의 위치와 진행 방향이 올바른지를 판단하기 위한 기준에 가깝다. 방향성은 달성되는 것이 아니라 계속 참조되는 것이다. 반면 목표는 현재 상황에 따라 설정하고, 달성하거나 포기하거나 변경할 수 있어야 한다. 이 둘을 구분하지 못하면 방향성을 지키기 위해 목표를 조정하는 것이 아니라, 한 번 정한 추상적인 목표 자체를 고수하게 된다.
어쩌면 문제는 방향성이 없었던 것이 아니라, 방향성과 목표를 구분하지 못했던 것인지도 모른다.
프로젝트의 목표는 상황과 학습에 따라 얼마든지 변경될 수 있다. 오히려 변경되어야 한다. 다만 목표를 변경할 때마다 프로젝트가 어디로 가야 하는지까지 다시 논의해야 한다면, 그 유연성은 곧 방향성의 상실로 이어진다. 변하지 않는 방향성이 있기 때문에 변하는 목표를 받아들일 수 있다.
여담으로, 어렴풋하게 가지고 있던 생각을 실제 프로젝트를 통해 확인하고, 그 생각을 좀 더 구체적인 형태로 정리할 수 있었다는 점에서 이번 마일스톤의 경험은 개인적으로도 각별하게 남았다.