89. 상품개발 일정이 지연되는 이유
상품개발 완료일이 당겨질 가능성은 매우 낮고 단축할 수 있는 기간도 짧지만, 지연될 가능성은 높고 지연기간도 길어질 수 있다. 그 결과 아래 그림과 같이 프로젝트 완료일정의 그래프는 오른쪽으로 치우친 비 대칭형이다.
상품 개발의 완료일정이 지연되기 쉬운 대표적인 이유는 아래 그림과 같다.
추가 설명이 필요한 완료일정이 지연되기 쉬운 이유는 다음과 같다.
① 개별작업에 버퍼를 반영하지만 효과를 보지 못한다.
일정지연을 예방하는 대표적인 방법은 작업에 버퍼를 반영하는 것이다. 프로젝트 관리자가 팀원에게 어떤 작업을 맡기면서 얼마 만에 해낼 수 있느냐고 물었다. 팀원이 “5일의 기간을 주세요” 하고 대답했을 때 5일을 지킬 수 있는 확률은 몇 퍼센트 정도일까? 사람에 따라 다르겠지만 이 대답은, 약속을 지킬 수 있도록 여유시간을 포함했기 때문에 신뢰도가 80~90퍼센트에 가까울 것이다. 이는 50퍼센트의 확률보다 30~40퍼센트 이상의 여유시간(버퍼)을 추가한 것이다. 50퍼센트를 기준으로 삼는 이유는 50퍼센트에서는 납기지연의 기댓값이 0이므로 버퍼가 0이기 때문이다. 프로젝트 관리자가 전체 프로젝트 기간을 50퍼센트 가능성으로 추정하라는 의미가 아니다. 예를 들어 낮 12시에 출발하는 외국행 비행기를 타기 위해 집에서 몇 시에 출발해야 할까? 집에서 도보, 시내버스, 공항버스를 타고 인천공항에 도착한다고 가정해보자. 그리고 각 작업별 예상시간이 아래 그림과 같다면 2시간 45분이 소요된다. 그렇다면 당신은 9시에 집에서 출발할 것인가?
위의 계획에서는 시내버스와 공항버스의 대기시간과 교통체증을 고려하지 않았다. 또한 출국수속 및 심사 시 발생할 수 있는 비상상황도 고려하지 않았다.
변수가 거의 없는 도보를 제외하고 작업별 버퍼를 감안하면 아래 그림과 같이 총 65분의 버퍼가 추가된다. 그렇다면 9시 출발이 아닌 8시에 출발할 것인가?
비행기는 놓치면 안 되기 때문에 위의 버퍼는 교통체증 등을 감안하여 최대한 보수적으로 반영할 것이다. 예를 들어 90%이상 달성 가능한 버퍼를 3가지 작업에 반영했다면 비행기 탑승 지연의 리스크는 천 분의 일(0.1 * 0.1 * 0.1)이 될 것이다. 따라서 위의 일정대로 진행하면 99.9%는 비행기 탑승구 앞에서 대기하는 시간이 발생할 것이다. 집에서 몇 시에 출발할 것인가는 리스크에 대한 개인의 성향, 공항에서 기다리는 시간을 싫어하는 정도에 따라 달라질 것이다.
위의 예에서는 각 작업의 수행기간과 버퍼의 길이가 독립적이다. 즉 공항버스 도착 전에 반영한 버퍼시간(15분)이 실제 공항버스를 기다리는 시간과 공항버스의 주행시간에 영향을 미치지 않는다. 그러나 사람이 개입되면 문제는 달라질 수 있다. 위의 예가 4개 작업과 3개의 버퍼로 구성된 소프트웨어 개발 프로젝트라면 작업별 버퍼와 작업 수행기간이 독립적일까? 즉 프로젝트가 지연될 가능성이 천 분의 일일까? 현실은 작업의 버퍼가 작업 수행기간에 영향을 미친다. 그 이유는 다음과 같다.
- 파킨슨의 법칙(Parkinson’s law)
모든 작업은 주어진 기간을 모두 사용한다(역설적으로 말하면 빨리 끝낼 수 있어도 천천히 수행해서 주어진 기간을 다 사용한다).
- 자기 방어(Self-protection)
작업을 빨리 완료하면 관리자는 다른 업무를 지시하거나 다음 번에는 짧은 납기를 기대하기 때문에 작업을 빨리 완료해도 작업완료를 숨긴다.
- 다음 주자의 준비 부족(Dropped baton)
작업을 빨리 완료해도 후속작업을 수행 할 자원이 준비되지 않아 일정을 단축하지 않으면 (전체 프로젝트 관점에서는) 빨리 완료한 시간이 낭비되어 버린다. 이러한 현상이 발생하는 이유는 후속작업을 수행할 사람이 버퍼를 감안한 일정에 선행작업이 완료될 것이라 생각했기 때문이다.
- 학생증후군(Student syndrome)
많은 학생들이 시험에 임박하여 공부를 시작한다. 업무도 목표일이 다가와야 일을 시작하지만, 일을 해보기 전에는 어떠한 문제가 있을지 알 수 없기 때문에 문제가 발생하면 곧바로 프로젝트의 지연으로 이어진다.
개별작업에 버퍼를 반영해도 효과를 보지 못하고 납기가 지연되는 사유를 정리하면 아래 그림과 같다.
② 기간단축은 반영되지 않고 기간지연만 반영된다.
특정 작업을 착수하기 위해 N개의 작업이 완료되어야 할 때 그중에 한 개 작업만 늦게 끝나도 나머지 N-1개의 작업이 빨리 끝난 효과가 없다. 아래 그림과 같이 실적에서 계획 5일에서 3일로 당겨지는 효과는 없고 5일에서 7일로 지연된 것은 전체 일정에 반영되는 경우가 많다
③ 진행 중인 작업수가 많으면 일정이 지연된다.
앞서 설명한 진행작업수(Work In Process)의 이론이다. 예를 들어 아래 그림의 위와 같이 A를 완료하고 B를 착수하면 C도 동시에 착수할 수 있어 C는 10일 뒤에 착수할 수 있다.
반면, 위 그림의 아래와 같이 A와 B를 교대로 수행하면 진행 작업수는 1개에서 2개로 증가한다. 이 경우 C는 10일 뒤에 착수하지 못한다. 또한 A 작업을 하다 B 작업으로 전환하고 준비하는 시간도 추가로 발생한다.
④ 작업을 수행할 수 있는 자원의 제약으로 일정이 지연된다.
작업을 수행할 수 있는 자원에 대한 제약이 있는 경우 프로젝트 일정이 지연될 수 있다. 아래 그림의 왼쪽은 자원제약을 반영하지 않고 주 경로만 고려하면 5개의 작업을 끝내는데 16일이 걸리지만, 작업을 수행할 수 있는 자원을 고려하면 19일이 걸린다.
⑤ 내부 프로세스 비효율로 상품출시가 지연된다.
상품 요구사항의 요청부터 배포까지의 흐름은 다음과 같다.
'상품개선 요청 → 승인 → 기술검토 → 코딩 & 테스트 → 검증 → 배포'
상품개선 요청부터 배포까지 소요되는 시간은 고객에게 가치를 제공하는 시간과 대기시간과 같은 낭비시간으로 나누어진다. <린 소프트웨어개발의 적용,2007>에서 인용한 아래 그림에 의하면 총 가치시간은 160분이나 대기를 포함한 낭비시간은 '6주+4시간(60,720분)'이다. 따라 프로세스의 효율은 0.3%이다. (160분/60,880분)
반면 대기시간을 최소화하여 효율을 높이면 아래 그림과 같이 33%(160분/485분)까지 향상시킬 수 있다.
상품개발 일정의 지연은 상품개발뿐만 아니라 상품기획부터 최종 배포까지의 전체 일정을 대상으로 비효율 요인을 제거해야 고객관점의 일정지연을 최소화 할 수 있다. 내용은 다르지만 모든조직은 상품개발을 요청받아 배포햐는 프로세스가 있고 각 액티비티를 수행하는 시간과 대기하는 시간이 있다. 이를 가치흐름도로 시각화하고 낭비 요소를 제거하면 상품개발 일정지연을 줄일 수 있다.
<린 소프트웨어개발의 적용, 2007>에서 고객관점에서 파악한 소프트웨어 개발이 오래걸리는 이유를 다음과 같이 설명한다.
- 내(고객)가 원하는 것이 무엇인지 내가 정확하게 알 때까지 나의 문제를 풀지 않고 기다리기.
- 프로젝트 승인까지 수개월간 기다리기
- 개발자가 배정 될 때 까지 기다리기
- 배정된 개발자가 가용한 상태가 될 때까지 기다리기
- 골치 아픈 변경승인 프로세스 (대기시간이 늘어날수록 변경 가능성은 높아짐)
- 전체 시스템이 완성될 때까지 기다리기 - 코드가 테스트를 통과 할 때까지 기다리기
https://brunch.co.kr/@kbhpmp/160
