소프트웨어 프로젝트 일정을 추정할 때 Iouri Khramtsov는 과거의 유사 프로젝트를 기준으로 초기 추정치를 잡고, 프로젝트가 얼마나 익숙한 영역인지에 따라 불확실성 범위를 덧붙이는 방법을 제안한다. 이는 사업 우선순위와 인력 배치를 판단하는 데 추정치를 활용하되, 정확한 예측인 것처럼 제시하지 않기 위한 접근이다.
Khramtsov는 근거가 부족한 직감에만 의존하는 방식과, 큰 프로젝트를 몇 시간에서 며칠 단위의 작은 작업으로 나눠 각각 추정한 뒤 합산하는 방식을 경계한다. 전자는 핵심 기능 구현 외에 통합·조정 등 완료에 필요한 일을 놓치기 쉽다. 후자는 한 달 안팎의 소규모 작업에는 유용할 수 있지만, 여러 분기에 걸친 프로젝트에서는 요구사항 변경이나 팀 간 마찰처럼 사전에 크기를 가늠하기 어려운 변수를 놓칠 수 있다. 세부 작업 추정에는 시간도 많이 들어 전체 계획이 직감에 기대게 될 위험이 있다고 설명한다.
대신 지난 프로젝트의 실제 규모와 구성을 비교 기준으로 삼는다. 예를 들어 개발자 4명이 6개월 동안 진행한 프로젝트가 총 24인월이었고, 그중 일반 기능 개발에 약 6인월, 은행별 연동 6곳에 약 18인월이 들었다고 하자. 새 기능이 같은 프런트엔드와 백엔드를 다루지만 은행 4곳만 연동한다면, 일반 기능 개발 6인월과 연동 작업 약 12인월을 더해 약 18인월로 추정할 수 있다. 재사용으로 일부를 줄일 근거가 있더라도, 추정치 자체가 최소 약 25%의 불확실성을 가진다면 작은 조정에 지나치게 공을 들일 필요는 없다고 덧붙인다.
적절한 비교 사례가 없으면 덜 비슷한 프로젝트를 조정해 참고하거나, 다른 팀·회사의 사례를 살펴볼 수 있다. 그것도 어렵다면 큰 단위의 작업 묶음을 각각 유사 사례와 비교할 수 있지만, 구성 요소를 결합할 때 생기는 돌발 상황을 놓칠 가능성은 커진다.
익숙함에 따라 범위를 제시한다
Khramtsov는 불확실성 수치를 엄밀한 과학적 방법으로 산출하기보다 과거 경험에 따른 기준으로 제시한다.
- 팀이 자주 다루는 영역이고 신뢰할 만한 비교 사례가 있는 경우에는 추정치가 약 ±25% 오차를 보일 수 있다.
- 좋은 비교 사례는 없지만 대체로 익숙한 영역이라면 실제 작업량이 초기 추정치의 최대 2배가 될 수 있다.
- 처음 해보는 일이라 개념검증(POC)이나 개별 작업 추정에 의존했다면, 초기 추정치보다 최소 4배 더 걸릴 수 있으며 4~8배가 현실에 가까울 가능성이 있다고 본다.
특정 마감일을 묻는 경우에도 이 범위를 기준으로 판단하되, 현재 시점이 아니라 실제 작업 시작 시점부터 마감일까지를 계산해야 한다. 일정이 빠듯하다면 범위를 줄이거나, 전체 팀 투입이 필요하다는 식으로 조건을 함께 설명할 수 있다.
이 기준은 Khramtsov의 실무 경험에 바탕을 둔 제안이며 모든 프로젝트에 적용되는 검증된 공식으로 제시되지는 않는다. 핵심은 추정치를 현실의 비교 사례에 연결하고, 불확실성을 솔직히 밝혀 더 나은 결정을 돕는 데 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요