일정계획 세우기

  자 그럼 일정 계획을 세워보자. 가장 힘든 작업이다. 단순 패키지를 커스텀마이징하는 것과는 달리 미래예측이기 때문이다. 가장 큰 이유는 그 주체가 '사람'이기 때문이다. 그래도 계획은 세워져야 한다. 그나마 다음과 같은 경우는 근미래(?)를 예측할 수 있다. 따라서 아래와 같은 사업을 계획했는데 큰 변경이 일어난다면 그 PM은 혼나야 한다.

 

1) 연차사업으로 해당 업무를 개발한 경험이 있는 경우

2) 타 기관에서 동일한 사업을 수행한 경험이 있는 경우

3) 이미 개발된 시스템을 재개발하는 경우

 

  사실 위 1)번 사업을 제외하고는 2), 3) 번도 나름 리스크가 존재한다. 그래도 처음으로 개발되는 사업에 비하면 그 정도가 매우 낮다. 더 쉽게 설명하자면 경험이 중요하다는 것이다. 이 부분에 대한 모순을 해결하고자 정부에서는 Function Point 산정 방식으로 사업규모를 파악하고 예산을 책정하게 하지만 현실은 전혀 다르다. 아무리 많은 다른 방식을 내 놓아도 사업진행방식이 바뀌지 않으면 똑같을 것이다. 이 부분은 다음에 다루도록 하겠다. 결론만 얘기하자면 업무를 사전에 파악하는 예산이나 진행이 없기 때문에 예산에 Function Point를 역산하여 맞춘다. 따라서 그렇게 산출된 값은 무의미하다. 수행사가 예산에 맞춰 몸으로 떼워야하는 슬픈 현실은 여전한 것이다. 아니다 수행사는 나름대로 배불리니 개발자만 불쌍하다. ㅠㅠ

 

  우선 이상적인 경우를 들어보자. 알다시피 정확한 일정 계획을 세우는 것은 곧 얼마나 인적자원이 들어가는냐와 직결된다. 각 개발자들의 능력을 게임 캐릭터처럼 각 공력(코딩능력, 업무파악능력, 산출물작성능력 등)으로 수치화 할 수 있으면 발주처가 제시하는 기간안에 완료할 수 있는 인력을 정량적으로 계산할 수 있을 것이다. 개발자는 기분 나쁘게 들릴 지 모르겠지만 개발자를 일정한 생산능력을 가진 기계처럼 생각하는 것이다. 불가능한 일지만 전혀 불가능한 것은 아니다. 어느정도 근사치를 가질 수 있다.

 

  자 첫번째 일정계획 작성 요령이다. PM은 각 개발자의 능력을 파악하고 있어야 한다. 훌륭한 PM은 프로젝트 제안단계에서 부터 이미 그 업무에 적합한 개발자들을 머리속에 리스트업하고 있는 자이다. 그러니 PM은 개발 중에 끊임없이 참여한 개발자의 평가를 해야한다.

 

 

  두번째를 살펴보자. 요즘의 거의 대부분이 WBS(Work Breakdown Structer)방식을 택한다. 제일 먼저 적용하기로한 방법론의 프로세스에 따라 교과서적인 일정기간을 잡는다. 이때 프로젝트 중간에 특이한 이벤트가 존재하는 지 유의해야한다. 처음부터 일단위까지 자원 분배를-사실 불가능하다-하는 어리석음을 범하지 말자. 월단위와 대강의 주단위의 구간정의를 하고 위의 첫번째에서 언급한 인력을 배분한다. 그러나 익월은 반드시 일단위로 세분화(Breakdown) 되어야 한다.

사실 시간단위로 세분화하면 더할나위 없이 좋겠지만 내 경험상 시간낭비다. 일 단위로만 할 수 있어도 그 PM은 대단한 것이다.

 

  상세설계가 끝나면 프로그램 목록이 나오게 되고, 그럼 본격적인 프로젝트 일정을 완성할 수 있다. 이 일을 게을리하면 PM 자격이 없다. 자 프로젝트 시작에는 그 시작하는 달 일정계획이 구체적으로 나와야 한다. 나머지는 주단위의 대강계획이다. 이번달 하순에 다음달의 계획을 세분화할 수 있어야한다. 이때 그 계획은 거의 신의 경지에 다다른 예언적중율(?)이 있어야 한다. 주 5일 하루 8시간을 기준으로 타스크를 할당해야한다. 다음달 수정계획에는 업무량의 변화, 이슈의 발생 등도 고려가 되어야 하지만, 개발자의 능력파악이 중요하다. 미리 파악된 인력이면 모르겠지만 그렇지 않은 인력이 투입되었다면, 분명 중요 요소로 작용할 것이다.

  두번재 일정계획의 요령은 당월의 여러요소(개발자 능력,업무량,이슈 등)를 바탕으로 세분화되고 정확한 차월의 계획을 세우는 것이다.