프로젝트 계획

나는 그동안 알바 경험도 많았고 사회생활을 나름 많이 해봤다고 생각했었다. 그래서 직장을 찾게 되면 적응을 빨리 할 수 있을 줄 알았다.

하지만 그것도 직장이 어떻게 돌아가는지, 일은 어떻게 시작되고 그 일을 하는데 어느 부서가 필요한지를 알아야 어느정도 여유가 생기고 적응을 할텐데, 그것도 모른채로 그동안 해왔던 거랑 뭐가 다르겠어 하면서 대충 생각했었던 것 같다.

이 단원을 공부하며 실제 회사에서는 대부분 이렇게 일을 시작을 하고 일을 하는 과정에는 무엇을 해야하며 어떻게 해야하는지 경험자로서의 노하우를 듣는 기분으로 공부했다.

먼저 프로젝트를 시작하려면 고객(스폰서)의 요구 부터 시작된다. 고객의 요구가 있어야 그에 맞는 제품을 개발하기 위해 프로젝트가 시작 되기 때문이다.

고객(발주자)은 자신이 원하는 요구사항을 정리한 문서인 제안 요청서를 작성한다.

발주자는 제안 요청서를 여러 회사에 제시한다. 이를 입찰공고 라고한다.

입찰공고를 받은 후보 개발업체들은 제안요청서를 기초로 '어떻게 이 제품을 만들것인가' 와 같은 개발 계획을 담은 제안서를 만들어 제출한다.

이런 개발회사들 간의 경쟁을 경쟁입찰 이라고 한다.

발주자는 자신이 원하는 제품을 가장 잘 이해하고 가장 수행능력이 좋을 것 같은 회사와 계약을 진행한다.

이 과정이 저번 글에서 말했던 착수 프로세스 이다. 착수 프로세스를 담당하는 팀은 발주자와 프로젝트 헌장을 작성한다.

이렇게 프로젝트가 시작된다. 다음은 계획 프로세스이다.

계획 단계에서도 단계가 또있다. 책을 보면서 왜 저번 단원이랑 똑같은 것만 나오지 이생각을 했었는데 이걸 보고 아니라는걸 깨달았다. 진짜 정신 나갈거같지만 어떻게 하긴 했다 ㅋ

착수 프로세스에서는 막연한 계획을 세웠다면 계획 프로세스에서는 정말 이것까지 계획을 세워야 하나 이생각이 들정도로 하나하나 모든 것에 초점을 맞추어 계획을 세운다.

당연한 말이겠지만 먼저 계획서를 작성을 한다. 이는 개발 중 계획서와 맞추어 보면서 현재 우리가 시간이 얼마나 남았는지 돈은 얼마가 여유가 있는지에 대한 지표 역할을 한다.

이처럼 계획과 실제 실적을 비교하는 것을 성과 측정이라고도 한다.

프로젝트 통합관리 계획

프로젝트 계획의 목적은 성과 측정의 이유도 있겠지만, 앞으로 가야 할 길을 제시하는 역할도 한다.

프로젝트를 하는 중에는 여러가지의 문제점을 찾을 수 있다. 예를 들자면 팀원간의 의사소통, 위험요소, 범위, 일정, 품질 등이다. 이것들을 모두 통합하여 작성하는 문서를 프로젝트 관리 계획서(PMP) 라고 한다.

프로젝트 관리 계획서는 계획단계의 가장 큰 산출물이라고 할 수 있으며 업무의 누락/중복의 방지, 예산과 기간 준수, 품질수준 유지 등의 역할을 한다.

프로젝트 범위 관리 계획

사실 전 단원에서부터 '프로젝트의 범위'라는 말은 많이 나왔었다. 하지만 나는 프로젝트의 범위 라는 말을 이해하지 못했다.

프로젝트의 범위가 예산을 말하는 건지 기간을 말하는 건지 명확하게 나온것도 없어서 대체 무슨 범위를 말하는 거지? 라고 생각했었는데 정확히 말하자면 해야할 일과 하지 말아야 할 일의 경계 를 말하는 것이다.

다들 한번쯤은 아무생각 없이 무언갈 하다보면 내가 이걸 왜 하고 있지? 하며 불필요한 일에 시간을 낭비 한 적이 있을 것이다.

그런 일을 방지하기 위해서 프로젝트의 범위를 정하는 것이다.

이처럼 범위라는 개념은 2가지가 있다.

먼저 제품범위는 유스케이프 개념을 사용할 수 있다. 이는 내가 사용자가 되어보는 것이다.

이 제품을 사용하는 사용자의 연령층, 직업 등을 고려하여 제품의 기능을 어느정도 까지 만들지를 정의한다.

다음은 프로젝트 범위이다.

소프트웨어의 특징 및 기능을 만족시키기 위해 수행되어야 하는 작업의 모임이다. 이 때에는 작업 분류체계를 작성해야한다.

* 작업 분류체계 : 프로젝트의 목적을 달성하기 위해 수행해야 할 작업을 인도물또는 산출물 중심으로 계층적으로 작성한 구조이다.

Dvelopment blog