2010년 2월 21일 일요일

일정예측의 불확정성 원리

추측할 수 밖에 없는 상황에서

정확성을 고집하지 않는 태도는 자식인의 표시다.

- 아리스토 텔레스

고객이 나에게 묻는다.

“그 프로젝트가 얼마나 걸릴까요?”

“요구사항이 전달되기 전까지는 말씀드릴 수가 없습니다.”

“그냥 대략적인 것도 괜찮아요, 금액은 얼마나 책정되나요?”

나는 주머니 속에서 동전을 몇 개 집어서 보이지 않게 한 채로 고객에게 내민다.

“동전이 몇 개나 있을 까요?”

“네? 그걸 어떻게 알아요?”

“그냥 주먹의 크기로 대략적인 것도 괜찮아요.”

그리고 그 계약은 성사되지 않았다. 영업팀은 나에게 비난의 화살을 던지기 시작했다. 그리고, 나는 확신의 목소리로 대답해 준다.

“아무리 배고프더라도 전 독버섯을 삼키지는 않을 겁니다.”

아마도 여러분들도 이러한 상황에 수없이 빠져봤을 것이다. 그리고, 고객이 요구한대로 부족한 정보만으로 대략적인 일정과 금액을 말하고, 영업팀은 고객과의 협상으로 인해 그마저도 삭감되기가 일수이다. 그리고, 이제부터 여러분들은 “일정사수”라는 엄청난 어드벤처를 시작하게 된다.

일정을 예측하는 일은 정말 어렵다. 더구나 고객과 회사의 경영진, 기획팀, 영업팀이 개발 일정이 얼마나 어려우며 부정확할 수 밖에 없는 지를 이해하지 못한다면 상황은 정말로 심각할 수 밖에 없다. 하지만, 현실은 냉엄하다. 회사가 살아남으려면 우리는 어떻게 해서든 일정과 비용을 예측을 해내야 한다. 그러면, 어떻게 해야 일정을 제대로 예측할 수 있을 까?

A. 대원칙

l 일정은 정확하게 예측할 수 없다.

일정 예측은 근본적으로 부정확할 수 밖에 없다는 사실을 경영자와 고객에게 주지 시켜야 한다. 고객과 경영자는 권위 있는 증거 자료에 약하다. 그들은 되지도 않는 상품이나 기술을 권위 있는 품질 보증서만으로 고가로 구입한 후 만족하게 된다. 매우 잘 숙련된 개발조직도 일정추측의 부정확도가 40% 이상이 된다는 점을 주지시켜라. 물론 드물게는 10%이내의 놀라운 정확도를 가진 조직들이 있다. (주로 항공사관련 조직과 NASA 등) 일반적으로 50% 수준만 유지해도 모범적인 조직이라고 할 수 있다.

l 일정 예측은 프로젝트 진행 중에 꾸준히 이루어져야 한다.

대부분 고객의 요구사항은 아무리 유도를 해도 프로젝트가 마무리되어갈 때만큼 세밀한 자료를 얻을 수가 없다. 고객은 프로젝트의 결과물이 나오기 시작할 때부터 보다 본격적이고 구체적인 요구사항을 내놓기 시작한다. 이러한 것은 당연한 것이다. 더구나 고객이 개발에 대한 깊은 이해가 없는 한은 그러한 현상을 미리 막을 수 있는 해결책은 없다. 따라서, 프로젝트가 진행되면서 모든 일정은 재평가되어야 한다는 것을 개발이해관계자 모두가 공감하고 있어야 하는 것이다.

l 아무리 노력해도 더 이상 줄일 수 없는 일정 한계 수준이 존재한다.

일정에 관해서 경영자에게서 듣는 가장 짜증나는 말 중에 하나는 “필요하면 인원을 더 늘려줄 테니까, 빨리만 끝내”이다. 프로젝트 중간에 개발인원을 늘린다고 도움이 되기는커녕 골치거리만 생기는 것을 모르는 것이다. 이밖에도 갖가지 의견을 통해서 일정에 대한 압박을 시작한다. 프로젝트의 중요도가 높을 수록 이 압박은 높아지게 된다. 한계상황에 대한 인식, 개발조직의 현재 능력에 대한 객관적인 평가를 통해 처음부터 무리한 일정은 모험이 아니라 도박임을 명심해야 한다. 적정 일정보다 짧은 일정계획은 오히려 기간과 비용의 심각한 증가를 불러온다.

B. 일정 예측의 기본 수칙

l 즉흥적인 예측을 피하라.

l 예측에 충분한 시간을 할당한 후 계발계획을 수립하라.

l 과거 유사 프로젝트의 자료를 이용하라.

l 담당 개발자가 도출한 예측 값을 활용하라.

l 검토회의를 통하여 충분히 검증하라.

l 상세한 수준에서 예측하라.

l 평범한 업무라도 빠트리지 마라.

l 소프트웨어 개발 예측 도구를 사용하라.

l 여러 가지 예측 기법을 사용하고, 결과를 비교하라.

l 프로젝트를 진행하면서 예측 기법을 바꿔라.

C. WBS(Work Breakdown Sheet)에 의한 일정 예측

WBS는 본인이 주로 사용하는 일정 예측 방법이다. 우선 모든 일을 트리 구조로 쪼개어 나간다. Top-Down 방식으로 분류를 세분화 시키는 것이다.

 

최대한 세밀하게 쪼개어 나가야 한다. 이 작업이 모두 끝나면 마지막에 있는 박스(업무)들을 리스트로 작성한다. [그림 1]에서는 “…”으로 표시된 박스들이다. 그리고 각 박스에 대하여 예상되는 시간을 최적(Best), 최악(Worst), 예상(Estimated) 세 가지의 예측 기간을 적는다. 이제 모든 업무에 대한 최적의 상태로 프로젝트가 진행되었을 경우에 걸리는 시간 B와 최악의 경우 W, 그리고 보통의 경우 E를 가지고 아래와 같은 공식에 의해 예측 기간을 설정하는 것이다.

프로젝트 예측 일정 = (a*B + b*E + c*W) / (a + b + c)

a, b, c는 상수로 해당 업체의 경험에 따라 가중치를 조절한다. 만약 최적으로 계산한 것이 그런대로 맞는 업체의 경우에는,

프로젝트 예측 일정 = (2*B + 4*E + 1*W) / 7

또는 최악의 경우가 너무 잘 맞는 업체의 경우에는,

프로젝트 예측 일정 = (1*B + 3*E + 4*W) / 8

와 같이 가중치를 이동해 가면서 업체에 맞는 공식을 유도해 나가는 것이다. 또한 기존의 유사 프로젝트의 가중치가 어느 정도 적중했는지를 근거로 해서 작성하기도 한다.

출처 :http://cafe.naver.com/codeway.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=142

댓글 없음:

댓글 쓰기