...
기적적으로 기획서가 첫 두어 주 안에 작성되어 협업 부서에 전달되어 본격적인 개발을 시작하게 됐다고 가정하겠습니다. 여전히 마일스톤 기간 전차를 오롯이 개발에 사용할 수가 없는데 이유는 마일스톤 끝에는 마감이 기다리고 있기 때문입니다. 마감 이전에 개발을 마쳐 기능을 조립하고 테스트하고 컨텐츠를 입력해 실제 동작하게 할 시간이 필요하기 때문입니다. 프로젝트 관리를 꽤 오래 하셨다고 말씀하시는 분들도 이 기간을 과소평가하는 경우를 자주 겪었습니다. 심지어는 이 기간은 기본적인 기능 개발 단계까지 도달하는데 필요한 기간일 뿐이고 본격적인 컨텐츠 입력을 통한 게임화 과정은 다음 마일스톤으로 넘어갈만한 넘어갈 만한 규모일 때가 많은데 보통 이를 잘 고려하지 않습니다. 이
마감은 약 2주 정도 잡습니다. 마감 첫주에는 실제로 기능 개발을 마쳐 기능을 발주한 주체 - 보통 기획팀의 누군가 - 에게 돌아가 기능과 에셋을 조립해 이제 겨우 테스트할 수 있는 상태로 만듭니다. 마감 둘째 주에는 이 상태로 QA에 넘어가 본격적으로 통합 테스트를 합니다. 아직 제대로 된 게임화 작업이 일어나지도 않았지만 문제는 수두룩하고 한 주 내내 아무리 초과근무를 해도 마일스톤 마지막날까지 만족할만한 빌드를 만들어내기 어렵습니다. 마일스톤 마지막 날은 항상 월 최대근무시간에 걸려 출근하지 못한 사람들과 이 사람들에게 가야 할 이슈를 대신 처리하는 사람들의 허둥댐으로 가득합니다. 이제 토요일과 일요일이 지나고 월요일이 찾아오면 다시 다음 두 달 짜리 마일스톤의 첫날이 시작됩니다.
다시 원래 하려던 이야기로 돌아가보겠습니다돌아가 보겠습니다. 마일스톤 시작할 때 기획서가 완성되어 있으면 좋겠습니다. 기획자인 제가 생각해도 그러면 참 좋겠습니다. 마일스톤 시작하자마자 기획서를 협업부서에 리뷰하고 바로 개발을 시작하면 기획자 입장에서도 너무 좋습니다. 마일스톤 시작하자마자 바로 개발대응으로 넘어갈 수 있고 이전보다 훨씬 더 이른 시점에 개발이 진행되어 기능을 조립해볼 수 있을 뿐 아니라 더 이른 시점에 QA를 진행해 시간에 쫓기지 않아 기본 기능 뿐 아니라 이게 실제로 재미있긴 한지 의견을 들어볼 수 있을 뿐 아니라 운이 좋다면 실제 컨텐츠로 구성해 게임화하는 단계에까지 도달할 수 있을지도 모릅니다. 그러면 게임화 과정이 다음 마일스톤으로 넘어갈 필요도 적어지고 프로젝트 매니저의 ‘아니 이건 지난 마일스톤에 개발 끝난 거 아닌가요? 왜 이번 마일스톤에 또 진행하나요?’ 같은 멍청한 질문에 답하거나 다음 마일스톤 계획에 ‘길드 2차’, ‘길드 3차’, ‘길드 4차’, ‘길드 추가개발’ 같은 멍청한 목표 이름을 넣지 않아도 될 겁니다.
...
셋째. 여러 작업자들이 멀티태스킹 환경에 놓여있다는 점을 무시합니다. 기획서 작성을 마치고 리뷰 대기중인 대기 중인 기획자 입장으로 잠깐 돌아가 봅시다. 다른 일정, 휴가자 고려, 회의실 섭외 등의 문제를 해결하다 보면 리뷰 일정이 늦어집니다. 그러는 사이에 다음 기획서 작성으로 넘어갑니다. 사람의 주의력과 기억력은 한계가 있어 다른 주제로 넘어간 다음에는 다시 이전 주제로 돌아오는데 어려움이 있습니다. 이번주 이번 주 수요일에 작성한 기획서 리뷰가 다음 화요일 오전에 잡혔군요. 그 사이에 다른 기획서를 쓰다가 화요일 아침에 출근해서 리뷰할 문서를 보니 무슨 소린지 모르겠습니다. 오늘 리뷰를 순조롭게 진행하기는 쉽지 않을 것 같습니다. 위에서 이야기한 개발대응 이슈도 있습니다. 기획서를 쓰고, 다음 기획서를 쓰기로 예정된 시간에 개발대응을 합니다. 기획서 일정이 늦어지고 세상 평화로운 매니저는 왜 기획서 작성 일정이 늦어지는지 물어보러 옵니다. 협업부서에도 똑같은 일이 일어나고 있습니다. 통합테스트도 되기 통합테스트를 하기 전 상태를 급하게 기획팀에 돌려보낸 프로그래머는 바로 다음 작업을 시작합니다. 몇 시간 뒤 기획자가 아예 기능이 동작하지 않는다고 보고하지만 단일 스트림 환경에서 이미 다른 작업을 시작한 다음이라 수정하기가 까다롭습니다. 내일 고치겠다고 말하고 작업을 계속합니다.
...