웹기획 이야기_프로젝트 개발소요기간 산출 방법과 일정관리

 WBS 

 Work Breakdown Structure 

프로젝트 매니지먼트로 계획을 세울때에 이용되는 수법의 하나로 프로젝트 전체를 작은 작업 단위로 분할한 구성도

[작업분할구성] 또는 [작업분해도]라고 불려집니다. 

WBS에서는 우선 프로젝트의 성과물을 가능한 한 작은 단위로 분해하는데, 전체를 큰 단위로 분할하고 난 후,

각각의 부분에 대해 좀 더 작은 단위로 분해하여, 계층적으로 구성화 해 나갑니다. 

성과물의 세분화가 끝나면, 각각의 부분을 구성하는데 필요한 작업(한가지 이상의 작업일 때도 있음)을 생각하며,

최하층에 배치해 가는데, 각각의 부분을 구성하는 일련의 작업 단위를 [워크 패키지]라고 합니다. 

WBS의 각각의 워크패키지에 담당 인원을 배치하면 프로젝트를 수행하는 조직도가 생성되며, 이것을 OBS (Organization Breakdown Structure)라고 합니다

 WBS의 작성 시점 은 Critical Path를 관리하기 위해 이슈가 생겼을 때 작성하기도 하나 그것보다는 구현단계에 들어가기 전, 

요구사항을 정리한 후 작성하는 것이 타당하다고 생각됩니다. ^^ 

왜냐하면 WBS는 고객과 요구사항/일정/예산을 조율하여 수행범위를 정의할 수 있는 근거가 되기 때문입니다. 

WBS를 정확하게 작성하지 않으면 고객의 요구사항을 모두 작업해야 할 가능성이 크고,

WBS가 제대로 작성되지 못하면 프로젝트 일정산출이 제대로 되지 못할 가능성이 크고,

WBS에서의 업무 우선순위가 명확하지 않으면 어디가 Critical Path인지 명확하지 않을 가능성이 크다고 봅니다.

따라서, WBS의 작성 시점은 요구사항을 정리하고 수행범위를 정의하는 중간이 최적의 시점이 아닐까 합니다. 

WBS를 작성하면, 고객에게 개발우선순위를 요구하고, 고객이 생각하는 개발우선순위와 WBS를 매칭하여 수행범위를 정하게 됩니다. 

즉, 근거를 가지고 수행범위를 고객과 협의할 수 있는데, 근거가 타당하면 예산 또한 추가 될 수도 있습니다.

프로젝트 우선순위 결정기준을 참고로 적습니다.^^ 

개발 1순위: 프로젝트 진행의 궁극적 목적 및 핵심기능으로 당장에 구현 되야 하는 기능.

개발 2순위: 중요한 기능으로 구현 되야 하는 기능.

개발 3순위: 구현되면 편리한 기능이나 향후에 구현 되도 가능한 기능. 

개발 4순위: 필요한 기능이나 중요하지 않고 향후에 구현 되도 가능한 기능

또 하나 간과하지 말하야 할 것은, WBS의 작성을 누가하는가 입니다.

어디에서는 PM또는 기획자가 하는 곳도 있으나, 이렇게 되면 나중에 일정에 문제가 생겼을 때 개발자/디자이너가 이렇게 말할 가능성이 큽니다. 

"이 일정을 내가 짰습니까?, 이 일정은 처음부터 맞추기 어려운 일정이었습니다" ㅠㅠ

이런말을 듣지 않으려면, WBS는 실제 개발을 하는 기획자/개발자/디자이너가 직접 짜도록 하는 것이 좋습니다.

실무자가 직접 일정을 짜도록 하면, 향후 완료되어야 하는 날에 완료가 안되더라도 "당신이 짠 일정인데 왜 완료가 되지 않았냐고" 일명 쪼.을.수. 있습니다.  

이렇게, 한 번 '쪽'을 주면 나중에는 나오지 말라고 해도 휴일에 알아서 나와서 해당 일정을 맞추기 위해 초과 근무를 합니다. 

왜냐하면, 해당 일정은 본인이 하겠다고 한 일정이기 때문에, 이에 대한 의무감 같은 것이 생기기 때문입니다.

개발소요기간을 산정할 때 참고하시라고 "개발일정산정"문서를 공유합니다. 여기에서 비관치, 낙관치, 근사치란 용어가 나옵니다.

비관치란 해당기능 구현에 있어 여러 가지 변수를 감안해 가장 늦게 개발이 될 것 같은 구현일수 이고

낙관치란 해당기능 구현에 있어 여러 가지 변수를 감안해 가장 빠르게 개발이 될 것 같은 구현일수 이며,

근사치란 해당기능 구현에 있어 여러 가지 변수를 감안해 실제적 개발이 될 것 같은 구현일수입니다.

이를 평균을 내면 개발일수가 나오는데, 이 일수를 해당 기능의 개발소요기간으로 잡으셔도 무방합니다. 

  일정관리 (Tip)  

일정관리를 PM이나 기획자는 프로젝트 전체 일정을 짤 때, 일명 "ROOM"을 가능한 한 많이 확보하시는게 좋습니다.

"ROOM"이란 빈 공간, 빈 시간, 빈 일자를 말하는데, 프로젝트를 진행하다 보면 별의 별일이 다 벌어지게 되는 것을 다 아실 겁니다.

기획에서 빠진게 있어 추가기획을 할 때도 있고, 컨펌된 디자인인데 다시 해달라고도 하고, 개발자가 쉴 틈없는 야근에 병원신세를 지기도 합니다. ㅜㅜ 

 "ROOM"은 이럴 때 사용합니다. "ROOM"을 10만큼 확보했다는 것은 전체 프로젝트 일정에서 10일의 여유일을 확보했다는 것과 같습니다.

예를 들면, 컨펌된 디자인을 다시 해달라고 하면, 재작업하는 일정이 필요하게 됩니다. 이럴 때 "ROOM"에서 3을 사용합니다.

이렇게 하면, 전체 일정을 건드리지 않고 재작업하는 3일을 만들 수 있습니다. 이제 "ROOM"은 7개가 남았네요.

비켜갈 수 없는 리스크가 발행되면 또 "ROOM"을 사용합니다. 

"ROOM"을 어떻게 확보하냐 구요?^^ 이 또한 PM또는 기획자의 능력이라 할 수 있지 않을까요? ㅎㅎ

제가 주로 사용하는 방법은 "내부용 WBS는 타이트 하게", "고객과의 협의할 공식 WBS에서 약간의 트릭을" 입니다.

내부용 WBS는 절대 고객에게 공개하지 않고, 공식 WBS 또한 가급적 프로젝트TF에 공개하지 않습니다. 

저만 알고 있는 "ROOM"이 있는 거죠.. ^^

[출처] 프로젝트 개발소요기간 산출방법과 일정관리 tip (WWW를 만드는 사람들)