해 본 적 없는 일의 기간을 잡았다

처음 하는 종류의 일에 기간을 잡아야 했다. 비슷한 것을 해 본 적이 없어서 감이 없었다.

Open Table of contents

감이 없던 일

이런 상황에서 숫자를 내려면 짐작할 수밖에 없다. 그런데 짐작으로 낸 숫자는 대개 크게 빗나간다.

빗나가는 방향도 정해져 있어서 거의 항상 짧게 잡는다. 모르는 부분이 얼마나 걸릴지를 모르니 그것을 작게 잡게 된다.

그래서 먼저 일을 쪼개고 각 조각을 세 부류로 갈랐다. 해 본 것과 방법은 아는 것과 아예 모르는 것이다.

앞의 둘은 기간을 잡을 수 있다. 해 본 것은 경험에서 나오고, 방법을 아는 것은 SVN 이력에서 비슷한 작업이 착수부터 커밋까지 며칠 걸렸는지를 찾아 쓰면 된다. 문제는 세 번째뿐이었고 그것이 몇 개인지가 이 산정의 불확실성이었다.

모르는 것에 기간을 붙이는 대신 그것부터 조사하기로 했다. 며칠을 써서 문서를 읽고 작은 코드로 한 번 돌려 보면 그 뒤에는 기간을 잡을 수 있다.

모르는 채로 잡은 숫자는 근거가 없으므로 숫자가 아니라 희망에 가깝다. 조사에 쓴 며칠이 전체 산정을 훨씬 정확하게 만들었다. 조사 자체도 시간이 드는 일이므로 그것을 일정에 넣었다.

조사해도 안 풀리는 것이 하나 남았다. 그것은 어떤 전제를 두고 진행할지와 그 전제가 틀렸을 때 어떻게 되는지를 적었다.

여유를 붙일 때도 전체에 일률적으로 붙이지 않았다. 확실한 항목에는 여유가 필요 없고 불확실한 항목에 크게 붙이는 것이 맞다. 전체에 같은 비율로 붙이면 확실한 것이 늘어지고 불확실한 것은 여전히 모자란다.

시작하고 나서 중간에 다시 쟀다. 첫 몇 개를 끝낸 SVN 커밋 날짜를 보면 우리 속도가 나오고 그것으로 남은 것을 다시 계산할 수 있다.

늦어질 것 같으면 그때 바로 알렸다. 끝나고 나서 처음 산정과 실제를 CSV 한 장에 나란히 놓고 비교해 봤는데 어느 종류를 과소평가하는지가 드러났다. 그 기록이 다음 산정에서 쓰였다.