구축의 기본 절차 (1) 착수
로디 기획 서비스 실무 트레이닝 내용을 기반으로 정리한 내용
운영과 전략은 각각의 일하는 프로세스를 갖고 있지만, '구축'은 거의 일반화된 방법론을 지니고 있다.
우선 착수, 설계, 구현, 검수라는 단계로 나누어진 이 방법론은 오래된 소프트웨어 방법론.
구축 프로세스
워터폴
이러한 방법론의 특성을 '워터폴(Waterfall)'이라고 부르는데, 앞 단계가 끝나야 뒷단계가 시작되므로, 앞 단계가 지연되면 뒷단계까지 영향을 받아 늘어질 수밖에 없다. 이러한 약점을 보완하기 위한 애자일(Agile) 방법론도 있지만, 현 시점에서는 가장 범용적으로 사용되는 방법론이라고 할 수 있다. SI 프로젝트나 구축 프로젝트에 참여했을 때 흔히 만나게 되는 방법이다.
착수의 근거 : 계약
착수의 근거
- RFP(Request for Proposal, 제안 요청서)가 착수의 근거가 될 수 있다.
- RFP는 고객사가 수행사에게 "우리가 이런 것을 하려고 하는데 제안을 보내 달라"고 요청하는 문서이다.
하지만 이는 착수 이전의 단계에 해당한다.
RFP
RFP를 받은 기업은 제안을 보내고, 고객사는 이를 검토하여 수행할 기업을 선정한다. 선정된 기업과 계약을 체결하게 되는데, 계약이 성사되면 착수가 시작된다.착수는 계약 또는 지시로 이루어진다. 에이전시 측에서는 계약을 착수의 근거로 본다.
- 인하우스(In-house)에서는 프로젝트 시작이 지시로 이루어질 수 있다. 본부장이나 팀장이 "이거 시작해"라고 지시하면, 그게 시작의 근거가 되는 것이다.
- 프로젝트가 시작되면 PM(Project Manager)이 선정된다. 프로젝트 매니저는 프로젝트에서 주도권을 가지고 진행하게 된다. 착수 시점에서 PM이 선정되면, PM이 프로젝트를 준비하는 과정에서 가장 먼저 만드는 문서가 '수행 계획서'이다.
- RFP가 중요한 이유는 이 문서에 프로젝트의 요구 사항이 담겨 있기 때문.
- 이 RFP에는 상품 전시 분야에서 구매 결정을 유도하기 위한 UI 개선 요구가 포함되어 있다.
(리스트 페이지, 상세 페이지, 검색창 변경 요청 등 다양한 요구사항이 담겨 있다. 주문, 배송, 신규 서비스에 대한 요구사항도 포함되어 있다.)
=> 이처럼 다양한 요구사항이 담긴 문서를 받은 기업은 제안서를 작성해 제출하게 되고, Bidding을 통해 선정되는 구조이다..
- 선정된 후에는 RFP에 있는 내용을 바탕으로 계약이 이루어지기 때문에 이 요구사항들을 수행하는 것이 첫 번째 과업이 된다. 이 때문에 RFP가 중요한 것이다.
=> 기획자가 프로젝트에 참여했을 때 반드시 확인해야 하는 문서 중 하나가 RFP이다.
수행 계획서
이 내용을 바탕으로 PM은 '수행 계획서'를 작성하게 된다.
PM이 수행 계획서를 작성할 때 중점적으로 고려하는 것은 두 가지이다.
첫 번째는 프로젝트의 범위를 명확하게 하려는 것이다.
- 프로젝트 범위는 자주 분쟁의 원인이 되기 때문에, PM은 요구를 준 쪽과 수용하는 쪽이 서로 합의하여 진행할 수 있도록 범위를 명확히 구분하려고 한다.
- 수행 범위를 정의할 때, 프론트엔드만 작업하는지, 백오피스까지 포함하는지, 아니면 프론트엔드에서 기획, 디자인까지 할 것인지 퍼블리싱과 개발까지 할 것인지를 나누어 정의한다.
- 또한, 앱도 포함할지 여부도 결정한다.
- 시스템적으로 우리가 다룰 범위는 어디까지이며, 그 외의 범위는 수행하지 않는다는 점을 미리 명확히 하지 않으면 나중에 오해가 생기기 마련이다.
- 예를 들어 (1), 프론트엔드를 변경하면서 내부 인트라넷의 시스템도 변경해야 한다면, 이것을 우리가 할지 말지를 명확히 정해두지 않으면, 나중에 누가 비용과 노력을 부담해야 할지를 두고 논쟁이 생길 수 있다.
- 예를 들어 (2), 무료 솔루션이 있을 수 있지만 유료 솔루션이 더 나은 경우가 많다. 유료 솔루션을 사용해야 한다면 사전에 구매 결정을 내려야 하고, 이를 수행 계획서에 포함시켜야 한다. 특히 통합 검색 기능 같은 경우, 돈이 많이 든다. 이런 비용이 필요한 솔루션들을 미리 정리해서 포함시키는 것도 수행 계획서의 중요한 부분이다.
- 예를 들어 (3), 크로스 브라우징 문제나 앱 해상도 문제도 사전에 협의하여 결정해야 한다. 다양한 디바이스에서 어떻게 구현할지 미리 결정하지 않으면, 나중에 추가적인 문제가 발생할 수 있다.
=> PM의 역할은 이러한 문제들을 미리 협의하고, 결정된 사항을 수행 계획서에 담아 프로젝트를 진행하는 것
산출물
- 산출물이 어떤 단계에서 어떤 형태로 나오는지를 미리 정해놓고, 제공하는 것이 좋다.
심지어, 어떤 산출물로 제공될지까지 구체적으로 정해서 협의하는 것이 좋다. - 프로젝트 조직에 대한 내용, 프로젝트 일정(간략⇒ 상세는 WBS 사용)에 대해서도 쓴다.
- 이를 바탕으로 수행 계획서를 작성하고, 수행 계획서가 완성되면 PM은 이를 기준으로 프로젝트를 관리한다.
소통 체계
- 프로젝트 조직과 소통 체계도 담겨 있어야 한다.
- 예를 들어, 우리가 누구와 어떻게 커뮤니케이션을 할 것인지, 위기에 어떻게 대처할 것인지, 주요 일정의 마일스톤을 어떻게 설정할 것인지 등을 모두 포함해야 한다.
=> 이러한 내용을 바탕으로 PM은 착수 단계에서 수행 계획서를 통해 프로젝트의 범위와 업무 구조를 명확히 한다.