실제에 가까운 일정 산출
끝나지 않는 줄다리기
일정이라는 것은 말 그대로 프로젝트가 시간별로 어느 지점에 도달해 있을 것인지 예측해보는 것이다. 프로토타입은 언제쯤 만들어질 것이며, 전체 콘텐츠가 포함된 알파 버전은 언제 완성될지, 테스트는 언제 하고, 그래서 최종적으로 언제 제품이나 서비스가 고객과 만나게 될지를 예상하여 기록으로 남기게 된다. 그런데, 이런 일정을 두고 참 말이 많다. 일정에 여러 팀이나 사람의 이해관계가 얽혀 들어가기 때문이다.
어떤 사람은 가급적 빠른 시일에 제품을 완성시키고 싶어 한다. 일정은 곧 비용이라는 인식이 있기 때문에, 비용을 줄이기 위해서 일정을 단축시키고 싶어 한다. 반면, 어떤 사람은 일정을 여유 있게 잡고 싶어 한다. 일정은 제품의 완성도를 높이기 위해 투자하는 자원이라고 인식하기 때문에, 보다 높은 품질의 제품을 위해 일정을 더 많이 확보하고 싶어 한다. 이 외에도 일정을 바라보는 시각이 다양하고, 일정을 잡는 기준도 제각각이기 때문에, 일정을 잡을 때면 잡음이 일어나기 쉽다.
이번 글에서는 그런 다양한 시각은 일단 제쳐두고자 한다. 그것보다는 최대한 객관적으로 일정을 예측하고, 프로젝트 진행 상황과 예상 일정 사이에 발생하는 격차를 줄이기 위해 어떤 것들을 고려해야 할지 살펴보고자 한다.
작은 단위로 나눠서 생각하자
일정을 예측한다는 것이, 결국은 미래를 점치는 것과 비슷하기 때문에, 처음부터 정확히 예측한다는 것은 사실상 불가능하다. 따라서, 정확히 맞춘다기보다 오차를 줄인다는 개념이 더 정확할 것이다. 그리고 무엇이든 오차를 줄이고자 할 때는 작은 단위로 나누어 생각하는 것이 도움이 된다.
가능하다면 하루나 반일 분량의 작업으로까지 일을 나누어 놓고 일정을 계산하면 좋을 것이다. 물론, 어떤 일은 그렇게 나누기 어려운 것들도 있다. 그럴 때는 어쩔 수 없이 큰 단위로 예측을 하는 수밖에 없다. 어쨌든 최대한 나눌 수 있을 만큼 나눠 놓고 각각에 대한 일정을 고려해 보면 좀 더 실제에 가까운 일정을 산정할 수 있다.
작은 단위로 일정을 세분화하면, 일정과 관련된 현재의 상황을 비교적 정확히 파악할 수 있는 이점이 있다. 처음 프로그래밍 팀의 팀장을 맡았을 때의 일인데, 당시 매주 작업이 어디까지 진행되었는지 보고하는 회의가 있었다. 보통 그런 회의에서는 이번 주에 어떤 작업을 했고, 다음 주에 어떤 작업을 할 예정이라는 보고를 했다. 그런데, 문득 사업팀이나 경영진 입장에서는 개발팀이 어떤 작업을 했는지보다, 일이 얼마만큼 진행되었고 언제쯤 끝날지가 더 중요하고 관심 있는 정보가 아닐까 하는 생각이 들었다. 그래서, 완료된 작업들이 가진 예상 일정의 합과 현재까지 실제로 소요된 일정을 보여주고, 그에 따라 전체 일정에 어떤 변화가 예상되는지를 매주 보고했다. 예를 들면, 이제까지의 작업에 38일이 소요될 것으로 예상했는데, 현재 34일이 지난 시점에 그 작업들이 완료되었으므로 예상보다 4일 빠르게 작업이 진행되고 있다는 보고를 하는 식이었다.
뻔히 예상되는 공백은 계산에 포함시키자
프로젝트 일정을 잡다 보면 주말을 제외한 모든 날을 일하는 날로 계산하는 경우가 있다. 단순하게 계산하다 보면 그런 실수를 할 수 있는데, 작업자들에게는 하루하루가 소중한 시간이기 때문에, 좀 더 세심하게 일정을 짤 필요가 있다.
일단 공휴일처럼 평일이지만 쉬는 날은 일정에서 제외시켜야 할 것이다. 이것은 달력에서 눈에 잘 띄기 때문에 많이 고려되고 있을 것이다. 다음으로는 작업자들의 휴가를 생각해야 한다. 1년에 주어지는 휴가가 15일이고, 전체 일정이 8개월 정도 된다면, 프로젝트에 참여하는 모든 사람들이 그 기간에 10일 정도는 휴가를 사용한다고 계산해야 한다. 작업자들의 휴가를 고려하지 않고 일정을 짜는 경우가 꽤 있는데, 34주 정도의 프로젝트에서 2주는 매우 큰 오차가 된다.
다음으로는 회사에서 진행하는 각종 행사를 생각해야 한다. 매년 열리는 체육대회나 창립기념일 행사가 있을 수 있다. 여름과 가을에는 직원 건강검진이 실시되기도 한다. 이런 행사는 휴가만큼은 아니더라도 프로젝트 일정에 분명한 영향을 미친다. 가끔은, 일회성으로 발생하는 이슈들도 있다. 백신 휴가 같은 것을 예로 들 수 있을 것이다. 회사에서 백신 휴가를 3일로 정했으면, 주말과 겹치는 경우를 고려한다고 해도 모든 참여자가 2일 정도는 공백을 갖는다고 생각해야 한다.
일정을 논의할 때, 작업자들이 알아서 이런 사항을 고려하여 예상 일정을 얘기하기도 한다. 하지만, 작업자조차 이런 사항을 생각하지 않고 일정을 예측하는 경우도 많기 때문에, 일정을 정리하는 사람이 '뻔히 예상되는 업무 공백'을 포함하는 일정을 작성하는 것이 좋다.
예비 일정을 반드시 준비하자
많은 프로젝트를 진행해 봤지만, 1, 2개월 걸리는 짧은 프로젝트가 아니고서는 계획대로 진행되는 프로젝트가 없었다. 프로젝트에 소요되는 기간이 수개월 이상이면, 늘 처음 생각하지 못했던 작업들이 발생했고, 그래서 더 많은 시간이 필요하게 되었다. 그래서 프로젝트 일정에는 예비 일정이 반드시 존재해야 한다.
간혹 '가능한 최단 일정'을 요구하는 사람들이 있다. 전체 일정이 8~10개월 걸릴 것 같다고 얘기하면, 그냥 8개월로 단정 짓고 업무를 진행해 버리는 사람들도 있다. 이런 사람들은, 특별히 어떤 업무가 배정되어 있지 않은 '예비 일정'을 무시하는 일이 많다. 하지만, 예비 일정이 사용되지 않는 프로젝트는 많지 않다. 특히, 게임 제작 프로젝트 같은 경우는 무조건 사용된다고 생각해도 틀리지 않다. 따라서, 예비 일정에 할당된 업무가 없는 게 아니라, 무엇인지 아직 모른다고 생각하고 예비 일정도 다른 일정과 똑같이 취급하는 것이 필요하다.
예비 일정에는 확정된 업무가 없기 때문에 기간을 어느 정도로 잡아야 할지 예측하기 어렵다. 그래서 비슷한 프로젝트를 진행해 본 경험이 많은 사람들의 직관에 의존해야 하는 경우가 많다. 나 같은 경우는 게임을 제작할 때 예상되는 소요 시간의 20% 정도를 추가로 잡아놓는 편인데, 그것도 많이 만들어 본 장르와 생소한 장르의 경우에는 또 조금씩 달라진다.
실제 작업자를 기준으로 하자
같은 작업이라도 사람에 따라 소요되는 시간이 달라질 수 있다. 경력이 많고 실력이 좋은 개발자가 1주일 만에 만들 수 있는 기능을, 이제 막 경력을 시작한 개발자는 3주 만에 만들어 낼 수도 있는 것이다. 그런 차이가 있기 때문에 좋은 실력을 갖춘 사람을 우대하고 더 많은 보상을 지급하게 된다. 팀으로 봐도, 레이싱 게임을 만들어 본 경험이 있는 팀은 새로운 레이싱 게임을 제작하는데 1년 6개월이 걸리지만, 레이싱 게임 제작 경험이 없는 팀에게는 2년 이상의 기간이 필요할 수도 있다.
일정을 비용의 측면에서 접근할 때, 이런 면을 간과하기 쉽다. 게임을 제작하는데 직접 참여하지 않는 사람들은 종종 다른 팀이나 다른 회사에서 소요되었던 일정과 비교를 하고, 그중에서도 가장 짧은 기간에 완료된 프로젝트와 비교를 한다. 그래서 누군가 3개월 만에 만들어 낸 적이 있으면, 세상의 모든 사람과 팀이 그것을 3개월 만에 만들어내야 한다고 생각을 한다. 그것은 명백히 잘못된 생각이다.
역량이 출중한 사람과 팀에게 과업을 맡겨서 일이 빨리 끝나도록 하는 것은 나쁘지 않은 일이다. 하지만, 일단 어떤 사람이나 팀에게 과업이 주어졌다면 그 사람이나 팀의 역량과 생산성을 기준으로 일정을 정해야 할 것이다.
정확히 예측하려고 노력해야 한다
일정에 대한 부정적인 생각 중 하나는, 일정 예측은 어차피 틀리게 되어 있고, 대충 정한 후에 그때그때 맞춰나가면 된다는 생각이다. 틀린 말은 아니고, 이런 접근이 필요한 프로젝트들도 있다. 하지만, 프로젝트에 소요되는 시간이 얼마가 될지 예측하는 것은 프로젝트를 진행하는 사람들에게 꼭 필요한 일 중 하나다. 누군가에게 보고하기 위해서뿐만 아니라, 프로젝트가 올바른 방향으로 나아가게 하는 데에도 일정 예측은 중요하다.
농구를 하는 사람이 공을 아무렇게나 던진다면 공과 림과의 거리는 줄어들지 않을 것이다. 림에 공을 정확히 넣으려고 노력해야 던지는 자세를 올바르게 수정할 수 있고, 공을 좀 더 림 중심에 가깝게 던질 수 있게 된다. 일정을 정확히 예측할 수는 없다. 하지만, 정확히 예측하려고 노력해야 한다. 그래야 예측과 실제 사이에 존재하는 오차를 줄일 수 있고, 좀 더 프로젝트에 도움되는 일정 예측을 진행할 수 있게 되기 때문이다.
1. 작은 단위로 나눠서 생각하자
작은 단위로 나누어 예측하면 예측과 실제 사이의 오차를 줄일 수 있다.
작은 작업 단위로 일정이 예측되어 있으면, 프로젝트 중간에도 예측과 실제 사이의 차이를 정확히 파악할 수 있다.
2. 뻔히 예상되는 공백은 계산에 포함시키자
모든 평일을 작업일로 계산하여 일정을 정하는 경우들이 있다.
공휴일, 휴가, 회사 행사 등 미리 알 수 있는 업무 공백들은 반드시 일정 계산에 포함해야 한다.
3. 예비 일정을 준비하자
대부분의 경우, 원래 예상했던 것보다 많은 일을 하게 된다.
예비 일정은 업무가 없는 일정이 아니라, 업무가 존재하지만 무엇인지 아직 모르는 일정이라고 생각하자.
프로젝트 경험이 많은 사람들의 직관에 의존해서 기간을 정하게 된다.
4. 실제 작업자를 기준으로 하자
같은 작업이라도 작업자에 따라 필요한 시간이 달라진다.
다른 사람이나 팀이 소비한 시간을 똑같이 적용해서는 안 된다.
실제로 업무를 담당할 사람이나 팀을 기준으로 일정을 예측해야 한다.
