> [!abstract] Introduction > 프로젝트가 지금 몇 퍼센트 진행되었느냐는 간단한 질문처럼 보이지만, 측정 방식에 따라 답이 크게 달라집니다. 이 글에서는 WBS 기반의 진척율 계산, 90% 신드롬이 발생하는 원인, 가중치를 적용한 보정 방법, 그리고 진척율의 기준을 어디에 둘 것인지를 살펴봅니다. # Progress 프로젝트 진척율이라는 것은 말그대로 프로젝트가 어디까지 이루어졌는지를 수치로 나타낸 것인데, 이 진척율이라는 수치는 측정 방식이 다양해서 실제 진척율이 얼마인지에 대한 논쟁이 있을 수 있다. ## Case Study : WBS 우선 [[Work Breakdown Structure|WBS]]에서 프로젝트 진척율을 어떻게 계산하는지 알아보자. WBS 구조에서는 최하위 작업*leaf level task*에 진척율을 입력해 상위 작업으로 집계한다. 예를 들어 최하위 작업이 3개를 하나의 작업으로 묶인다면, 그 작업의 진척율은 전적으로 최하위 작업의 진척율에 의해 결정된다. 최하위 작업 1개가 완전히 끝났고 나머지 2개를 시작조차 하지 않았다면, 그 상위 작업의 진척율은 33%로 계산되는 식이다. ## 90% Syndrome : 진척율 산정의 문제 문제는 규모가 더 큰 실전 상황에서 발생한다. 90% 증후군*90% Syndrome*이라 불리는 상황이 있다. 이상하게 대부분의 조직에서 프로젝트의 진척율이 90%부터 잘 올라가지 않는 문제가 생기는 것이다. 90%까지는 잘 해결됐는데 10%가 이상하게 오래 걸리는 이 문제의 근본적인 원인은 진척율을 산정하는 기준이다. 현재의 정보로 작업을 세분화하기 어려운 영역이 있고, 작업별로 투입되는 노동력과 수행 기간이 다르면 똑같이 한 개의 작업이라고 해도 비중이 다를 것인데, 앞선 WBS 사례의 경우 이러한 현실이 진척율 산정 기준에 반영되지 않았다. ## 가중치 적용하기 당연히 이걸 해결하기 위해서는 작업에 가중치를 부여해야 한다. 상위 레벨에 가중치를 부여하고 하위 레벨에는 필요할 때만 부여할 수도 있다. 예를 들어 아래에 있는 표3-22에서 분석, 설계, 구현, 전개 단계별로 가중치를 부여할 수 있는데, 당연히 이때는 가중치의 기준이 관건이다. ![[FunctionPointWeightByDevPhase.png]] 또다른 방법으로는 최하위 작업부터 가중치를 부여해서 상위 레벨로 올라오면서 합치는 방식이 있다. 다만 이 방식은 모든 작업이 식별되어야 적용할 수 있는 방법이다. 앞선 방법은 하위 작업을 식별하지 않아도 적용할 수 있는 방법이다. ## 진척율의 기준 그런데 도대체 어떤 작업의 진척율은 어떻게 계산되는 걸까? 0부터 100 중에 작업 담당자의 판단에 따라 임의의 값을 입력하면 되는 것일까? 바로 이 지점에서 진척율에 대한 여러가지 기준이 등장한다. ### 0/100 Rule 가장 엄격하게 계산하자면, 모든 일이 끝나기 전에는 안한 것과 다를 것이 없다고 치고 그냥 0%로 유지할 수 있다. 이 규칙을 0/100 Rule이라 부르고, 이 규칙에서는 해당 작업이 완전히 종료되어야 진척율이 100이 된다. ### 50/50 Rule 그보다 더 가벼운 기준으로 50/50 Rule이 있다. 이 규칙 하에서는 일단 시작하면 진척율이 50%다. 시작이 반이라는 말이 여기서는 현실이 된다! ### 그 외 기준을 조금 더 세분화할 수도 있다. 예를 들어 개발자의 코딩/단위 테스트가 끝나면 진척율이 50%가 되고, PL의 검토가 끝나면 70%가 되며, 마지막으로 테스트팀의 검증이 완료되면 진척율이 100%가 된다. 혹은 개별 활동별로 진척율의 기준을 정의할 수도 있다. 예를 들어, 설계 단계에서 인터페이스 설계의 진척율을 계산할 때 전체 인터페이스 건수 기준으로 산정하고, 구현 단계에서 프로그램 목록을 작성해 개별 프로그래별로 진척율을 추적하도록 할 수도 있다. 이 방법에서는 구현 난이도/복잡도/소요공수에 따라, 유형(등록/단순조회)에 따라 프로그램별 가중치도 함께 적용할 수 있다.