2009년 11월 11일 수요일

조엘따라하기 #1

조엘따라하기 #1

이 번에는 프로젝트 일정 관리에 대한 이야기를 해 보고자 합니다.

이전글에서 프로젝트 일정은 여러가지 변수가 있어서 정확히 구할 수는 없다고 했습니다.
때문에 프로젝트가 진행 되면서 일정에 영향을 미치는 변수들이 하나씩 없어지게 되면
점점 더 정확한 일정을 알수가 있게 되는 것이지요.
만약 진행이되면서 일정을 더 알 수 없게 되는 상황이라면 정말 심각한 상황이라고 판단하시면 됩니다. ^^;

그러면 프로젝트가 진행중에는 어떤 식으로 일정을 관리해야 될까요.

이전글에서 일정은 아래와 같은 방식으로 구해질 수 있다고 했습니다. 예)

 Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

일정에 영향을 미치는 변수들 간에는 서로 영향을 미치는 경우도 있습니다.
예를들어 분석단계에서의 결과가 이후의 단계들에 영향을 미치게 되고 , 품질의 제약조건이 강화가 되면
반대로 구현 테스트 단계의 일정에 영향을 미치게 됩니다. 또한 분석, 설계, 구현, 테스트등의 각 단계의
내부도 자세히 보면 간단한 구조가 아님을 알게 됩니다.

일정이 이렇게 복잡한 구조로 되어 있는데 그러면 어떻게 관리하시나요.
혹시 아래와 같이 하시거나 해보지 않으셨나요 ?

- 세부적인 업무는 신경쓰지 않고 일정을 줄일 수 있는 일이라면 뭐든지 한다.
- 최선을 다하면 일정을 맞출 수 있다는 각오로 팀원을 독려하고 열심히 야근한다.
- 그래도 안되면 예정 일자가 다되기 전에 고객, 영업들과 일정변경 회의를 한다.  

물론 극단적인 예입니다만, 위와 같은 경우는 다음과 같은 것들이 문제들로 나타납니다.

  --> 스펙변경, 추가가 불가하고 무조건 줄이려는 성격이 까칠한 PM이 완성된다.
  --> 프로젝트가 끝나면 팀원들이 이직을 심각히 고려한다.
  --> 개발팀의 신뢰가 떨어지고 프로젝트 관계자들의 비용이 상승한다.

사업을 계속 할려고 한다면 위와 같은 상황이 발생해서는 안되겠지요.
일정관리에 좀 더 과학적인 방법이 없을까 하여 궁리해 봅니다.
먼저 일정을 구하는 방식이 아래와 같습니다.

Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

기본 원리만 빼서 보면 다음과 같이 바꿀 수 있습니다.
일정 예측치 = 분석단계 예측치 + 설계단계 예측치 + 구현단계 예측치 + ....

수식으로 써볼까요.

E(S) = E(A) + E(D) + E(C) + ...
S : Schedule , D : Design , C : Construction ( Coding )

어디서 많이 보던 수식이 나오네요. ^^
A, D, C 가 정규분포를 따른다면 t-분포와 유사하게 되는군요.

복잡하게 통계 모형을 이용하여 설명드리지 않겠습니다. 직관적으로 설명드리겠습니다.
분석단계의 기간이 10일이 걸린다고 예측했다면 그렇다면 실제로 이 기간이 8일에서 12일 사이에 있을
확율은 99%라고 할 수 있습니다. 그리고 계속해서 설계기간이 20일 이라면 99% 확율로 16일에서 24일
사이에 있을 것입니다. 물론 예상 확율을 낮춘다면 일정변동의 폭은 좀 더 줄어 들 것입니다.

이 두가지만 가지고 일정을 예측해보면 예상 일정 E(S) 는 24일에서 36일 사이에 있을 확율이 9X% 입니다.
즉, 분석 , 설계의 기간은 9X% 확율로 24일에서 36일 정도 걸립니다. 이렇게 말 할 수 있는 것입니다.
변동폭이 너무 큰가요 그러면 확율을 90% 로 낮춰 계산해 봅니다.
9.5 <= E(A) <= 10.5
19 <= E(D) <= 21
그러면 "분석 설계의 기간은 28.5 일에서 31.5 일 사이에 끝나고 예측의 정확도는 90%입니다."
라고 말 할 수도 있겠지요.

오늘은 여기까지만 말씀드리고 최초 예상치 , 현재 예상치 , 진행율 등에 대해서는 다음으로 미루겠습니다.

댓글 없음:

댓글 쓰기