쌩초보 신입사원 에이전시로 출근하다.v0.3
03. 첫 프로젝트에서 나는?
여느 날처럼 출근해서 나름의 기획 공부를 하고 있는 중 팀장님께서 부르셨다.
"이번 달 말에 프로젝트 투입 관련해서 회의를 할 예정입니다. 알고 계세요."
회의가 끝나고 글쓴이의 표정은 다소 어두웠다. 이유는 현재 프로젝트가 시작된 지 1달 정도 된 상황인데 투입된 PM의 고객사 관련 지식 및 이해도 부족으로 인해 고객사에서 인원 교체를 요구한 상황이었다. 이런 이슈로 프로젝트 진행이 더딘 상황이었고, 때문에 팀장님이 PL로 투입, 그 밑에 기획자 2명이 추가로 투입하기로 결정됐다. 글쓴이는 그 기획자 두 명 중 한 명이 되었다. 일반적이지 않은 급한 상황의 프로젝트라는 것을 알게 되고 긴장을 많이 했지만 팀장님께서 글쓴이는 신입이기 때문에 공수 산정에 해당되지 않아 부담 갖지 말고 하라는 것만 책임감 있게 완수하라며 조언을 해주셨다.
이렇게 첫 프로젝트에 투입되었고, 지금부터는 프로젝트의 일정 속 신입 기획자는 어떤 업무를 맡았는지에 대해 적어보려고 한다.
프로젝트 명
CX 중심의 홈페이지 리뉴얼
ㄴ홈페이지를 신규 구축하는 것이 아닌 기존 홈페이지를 CX 중심으로 리뉴얼하는 프로젝트
CX(Customer Experience)란?
고객 중심의 경험이다. 비슷한 용어로 UX(User Experience)가 있는데 UX의 경우 사용자 중심의 경험을 칭한다. 고객과 사용자는 비슷하지만 다른데, 간단하게 말하자면 CX는 UX보다 포괄적인 개념으로 이해하면 된다. 예를 들면 A라는 보험에 가입하려고 하는 사용자는 A보험을 선택 후 가격과 보장을 비교하고 결제를 하여 계약을 완료하게 되는데 이렇게 직접적으로 서비스를 경험하는 경우를 UX라고 한다. CX는 이러한 UX를 포함하여 작게는 서비스 이용, 크게는 브랜드와 고객의 접점이 지속해서 이어지며 발생하는 고객 경험의 총체를 칭한다.
프로젝트 기간 및 일정
프로젝트 일정프로젝트의 기간은 6개월이었으며 3월부터 1달 동안은 고객사와의 마찰로 인해 설계 단계에서 수행해야 할 업무가 많이 밀려있는 상태였다. 따라서 PM은 어쩔 수 없이 일정을 변경하여 기존 4월 중순까지 예정되어 있던 설계를 5월까지 연장했고, 뒷 단계인 개발과 테스트 단계도 결국 시간에 쫓기는 신세를 피할 수 없었다.
업무
1) 설계
ㄴas is - to be 분석결과서, 기능정의서를 기준으로 to be 화면을 설계하는 단계
ㄴ화면목록, 메뉴구조도, 화면설계서 작성 및 관리
기획자의 업무 중 가장 중요한 단계이다. 기획자의 문서는 모두를 만족시킬 수는 없지만 모두를 이해시켜야 한다. 대표적인 기획자의 문서로 화면목록, 메뉴구조도, 화면설계서가 있는데 이들의 용도는 각각 다음과 같다.
화면목록: 화면마다 고유 ID를 부여하여 화면의 오류 및 수정사항 발생 시 이해관계자들이 해당 화면을 빠르고 정확하게 확인하기 위함
메뉴구조도: 서비스의 전체적인 구조를 한눈에 확인 및 인지할 수 있음
화면설계서: 기능 구현에 필요한 설계서. 다양한 이해관계자들이 봤을 때 모두 동일하게 이해할 수 있어야 하며 용어, UI 등 설계서를 구성하는 다양한 요소들의 통일성이 요구됨
.
.
.
글쓴이가 맡은 설계 업무를 기획 문서에 따라 적어본다면 다음과 같다.
화면목록: 화면의 추가·삭제에 따른 내용 및 버전 관리
메뉴구조도: 메뉴 간 이동 및 메뉴의 추가·삭제에 따른 내용 및 버전 관리
화면설계서: To be 화면설계서 작성(기여도 50%), 로그인 화면 설계(기여도 100%)
주로 문서의 내용 업데이트 및 버전 관리를 맡았으며 화면설계서는 껍데기만 교체하는 수준이었기 때문에 큰 어려움 없이 작성할 수 있었다. 또한 로그인 화면을 새롭게 설계하라는 업무를 지시받아 이 부분에 중점적으로 시간을 쏟았다.
하지만 투입 전 이미 작성된 화면목록과 화면설계서에 오류가 많아 어려움을 겪기도 했는데 몇 개만 얘기하자면 화면목록 내 화면 ID의 중복 및 오입력으로 인해 화면설계서의 화면 ID가 일치하지 않아 이해관계자들의 일처리가 지연된 경우, 화면설계서에 빠진 화면들이 발견되어 같은 프로세스를 반복적으로 진행하는 바람에 생긴 시간 낭비 등이 있었다.
2) 기능 개발
ㄴ작성된 기획 문서를 바탕으로 디자인, 퍼블리싱, 개발을 진행하는 단계
ㄴ기획문서의 수정, 이해관계자(고객사 - 각 포지션 별 담당자) 사이의 완충 역할
기획자가 작성한 문서를 바탕으로 디자인 - 퍼블리싱 - 개발을 진행하게 된다. 설계 단계가 완벽하면 개발도 순조롭게 흘러갈 수 있지만, 반대로 미비한 설계를 거친 경우 개발에서는 훨씬 많은 이슈에 부딪힐 가능성이 높아진다. 하지만 어차피 설계가 완벽할 수는 없을뿐더러 개발 단계에서도 많은 이슈가 발생하는 것이 일반적이기 때문에 설계보다 더 신경이 많이 쓰이는 단계이다. 또한 이렇게 발생하는 이슈와 이를 마주하는 이해관계자들 사이에서 많은 소통을 통해 프로젝트가 안정적으로 진행될 수 있도록 하는 것이 기획자의 역할이기 때문에 자신의 업무 범위가 아니더라도 적극적인 마인드를 가지고 임해야 한다.
.
.
.
글쓴이가 맡은 개발 단계에서의 업무는 다음과 같다.
디자이너, 퍼블리셔, 개발자의 의견 통일 및 방향 제시
이해관계자들이 설계서를 봤을 때 같은 내용으로 이해했는지 확인
테스트 단계에서 발생할 이슈들을 사전에 예방하는 업무를 맡았다. 예를 들어 말하자면 설계서에 버튼의 기능이 설명되어 있었는데 UI가 단순 이미지로 보여 개발이 되지 않았을 경우 각 이해관계자들에 다시 설명해 주거나, 퍼블리셔와 개발자 간 업무 범위로 인해 마찰이 생겼을 경우 이들을 설득시켜 프로젝트에 차질이 없도록 방향을 제시해 주는 일들이다.
라고 말은 했으나 사실 글쓴이가 가지고 있던 IT 지식으로는 이들의 마찰과 다양한 이슈들을 해결하기엔 역부족이었다. 하지만 이를 해결하기 위해서 회사에서는 끊임없이 질문했고 인터넷에 빠져 많은 정보들을 찾아본 결과 지금은 그때보다는 나은 일처리를 하고 있다.
3) 단위/통합 테스트
ㄴ설계를 기준으로 개발된 기능들에 대한 단위테스트 진행 후 오류 발견 및 조치
ㄴ서비스의 시작부터 끝까지 통합테스트 진행 후 오류 발견 및 조치
글쓴이의 업무 중 기여도가 가장 높았던 단계이다. 설계를 기준으로 개발된 화면에 대한 오류를 발견하고 조치해야 하는 단위테스트를 진행하고 동시에 고객사의 담당자는 각 서비스들의 시작부터 끝까지 프로세스에 대한 정상완료 여부를 확인하는 통합테스트를 진행한다. 단위/통합 테스트는 약 1달 정도의 기간을 두고 최대한 많은 데이터를 활용해서 모든 경우의 수를 염두해 두고 개발된 화면에 대한 오류를 발견하고 조치해야 한다. 이때 발견하지 못한다면 서비스 오픈 후에는 골치 아파질 수 있기 때문이다.
.
.
.
글쓴이가 맡은 테스트 단계에서의 업무는 다음과 같다.
단위/통합 테스트 문서 작성
단위테스트 진행 후 오류 발견 및 조치
고객사에서 진행한 통합테스트 결과 확인 및 조치
단위테스트는 팀 내부에서 진행하기 때문에 문서를 확인하는 이해관계자들의 수준을 고려할 필요가 없지만 통합테스트의 경우 고객사에서도 관여를 하기 때문에 이슈 발생 시 고객사의 수준을 파악하고 그들이 이해할 수 있는 적절한 단어를 사용해 소통을 해야 한다. 글쓴이는 다행스럽게도 그럴 필요가 없었지만 오히려 고객사의 수준이 높아 셀프 공부를 할 수 있었다.
테스트 단계에서는 당연히 정상이어야 할 부분에서 오류가 날 수도 있고, 설계부터 발견되었어야 할 부분이 누락되어 뒤늦게 발견될 수도 있다. 게다가 오픈 전 마지막 단계인데 저런 부분들을 확실하게 끝내지 못한다면... 생각보다 끔찍한 결과를 불러올 수 있다. 그렇기 때문에 설계 - 개발 단계를 거치면서 서비스에 대한 전반적인 이해는 필수로 갖추어 각 기능들과 화면이 어떻게 연결되어 있는지 정도는 머릿속에 떠올릴 수 있어야 한다.
4) 안정화
ㄴ오픈 후 발생하는 이슈에 대해 탄력적으로 대응하는 기간
보통 테스트 단계에서 완벽에 가깝게 마무리를 짓기 때문에 실질적으로 오픈 후 안정화 기간은 프로젝트 종료를 앞두고 정리하는 업무를 했던 것 같다. 물론, 이슈가 발생한다면 즉각적으로 대응해야 하기 때문에 안정화 기간에도 기획자와 개발자는 고객사의 업무 시간에 맞춰 상시 대기한다.
이런 과정들을 거쳐 나름 성공적으로(글쓴이 기준) 프로젝트를 마치고 철수했다. 지금도 그렇지만 철수하고 난 뒤 드는 생각은 '이 때 이렇게 했더라면 어땠을까?'이다. 예전에도 지금도 앞으로도 모든 서비스를 만나고 만들 때 "왜? 어떻게?"라는 물음에 확신을 가지고 대답할 수 있어야 한다. 그러려면 무엇보다 나에 대해 분석해야 한다. 왜 이렇게 설계했었는지, 어떻게 설계하는 것이 더 효과적이었을지 등에 대해서 말이다.
우리는 이유있는 무언갈 기획해야 한다
