이유있는 웹기획실무 WHY
[1부 개론편]
에이전시 웹기획자들을 위한 경험공유
[1부 개론편] – I. 웹밥쟁이
저자는 에이전시에서 사투를 벌이는 종사자를 비롯하여, 자체 서비스 개발사에서 고객만족을 위해 불철주야 서비스를 운영하는 모든 기획자, 디자이너, 퍼블리셔, 프로그래머, 스크립터, 플래셔, 일러스터, 온라인마케터, 기술영업 등등 모두를 ‘웹밥쟁이’라고 부른다. 앱을무시하느냐고 묻지 마시고, 그냥 ‘웹밥’을 먹고 사는 저자를 포함한 이 땅의 종사자들의 애칭이다. 저자도어쩌다 보니 웹밥쟁이가 된지 15년 가까이 되어 간다.
우리들끼리야 기획자고 디자이너고 프로그래머지 모르는 사람들이 보면 그냥 우리는 ‘컴퓨터 잘하는 사람’으로 통칭되곤 한다. 군바리가 각 잡고 때 빼고 광내고 나와도 그냥 민간인에게는 군바리인 것처럼 말이다. 더 슬픈 현실은 어설프게 우리들의 업을 아는 사람들은 3D 업종에강매시켜 버리는 일도 있다. 자신 있게 말하지만 그렇게 어렵지도 더럽지도 않고 위험한 일은 더더욱 아니다. 하지만 이건 확실하다. 모든 일이 그렇듯이 웹밥쟁이의 일은 ‘재미’가 있어야 할 수 있다. 그래야발전도 기대할 수 있다.
저자는 2006년 2월아주 우연히 웹밥쟁이의 길에 들어서 총 6곳의 에이전시에서 근무를 했다. 첫 회사를 제외하고는 대부분 프로젝트 단위로 업무를 하고 본사 보다는 파견근무가 대부분이었다. 시작부터 지금까지 기획 업무 외에는 해보질 않았다. 다른 업무는할 줄도 모른다. 이제 저자가 짧다면 짧고 길다면 긴 경험에서 웹밥쟁이의 시간 동안에 몸소 배워 온기획자 이야기를 중심으로 프로젝트 수행실무에 대한 이야기를 해보려고 한다. 기획자 중심의 이야기이다 보니 기획자를 제외한 디자이너, 퍼블리셔, 프로그래머는 통칭하여 ‘개발자’로 명시하고자 한다. 작업자라는 말은 사용하지 말자. 우리 스스로를 작업자로 만들지 않았으면 한다.
1. 기획은 정답이 없다.
기획자라는 포지셔닝은 어쩜 우리나라에만 존재하는 자리일 수 있다. ‘웹기획자’가 네이버 지식백과에는 아래와 같이 정의가 되어 있다.
“인터넷 사이트 및 콘텐츠(contents)의구성과 배치 등의 작업을 하는 사람을 말한다. 사이트 마케팅 영역에도 어느 정도 관여한다. 하는 일은 다음과 같다. ① 사이트의 컨셉(concept) 및 방향을 정한다. 정책 입안 당시 어떤 사이트를만들겠다는 것이 대략적으로 확정되어 있기 때문에 사이트의 주제는 이미 설정되어 있는 경우가 많다. ② 사이트를제작하고 총괄해야 한다. ③ 사이트에 필요한 콘텐츠를 설계하고 구성해야 한다. 이를 위해서는 콘텐츠 개발과 개발된 콘텐츠를 체계적으로 구성하는 능력이 필요하다. ④ 사이트에 게시되는 모든 콘텐츠를 감독해야 한다. 사이트의 색상에서앞으로 게시될 배너광고의 형태까지도 사이트의 의도나 방향과 맞는지 생각하고 관리해야 한다.”
[네이버 지식백과] 웹기획자 [web planner, ─企劃者] (두산백과)
설명을 요약하자면 컨텐츠 및 서비스의 방향을 설정하고 총괄하는 사람이 웹기획자라고 말하고 있다. 해외에서 웹기획자는 ‘Architecture Designer’로통용된다. 즉, 우리가 말하는 웹기획자는 UI를 설계하는 디자이너이고 웹디자이너는 UI를 디자인하는 사람이다. 간혹 기획자를 고객과 개발자(디자이너, 퍼블리셔, 프로그래머 등)사이에서커뮤니케이션을 전달하고, 컨텐츠 등 필요한 원천리소스를 정리해서 개발자에게 전달하고 개발된 결과물을고객에게 전달하는 ‘Delivery Man’으로만 생각하는 사람들도 있다. 문제는 몇몇 기획자들 자신도 그렇게 생각하고 업무를 하는 사람들이 있다는 것이다.
의견이든 컨텐츠든 그냥 전달만 하는 사람이 아니다. 의견에는 의도와목적이나 이유를 담아서 커뮤니케이션하고 컨텐츠는 개발에 활용이 가능하도록 가공하는 최소한의 업무를 해야 한다. 그역할을 하기 위해서 트랜드를 공부하고, 의사결정을 이끌어 내기 위한 커뮤니케이션의 스킬을 익히고, 기본적인 개발 프로세스를 학습해야 하는 것이다.
기획자는 정말 많은 공부를 해야 한다. 커뮤니케이션을 하기 위해서는기획업무뿐만 아니라 디자인, 퍼블리싱, 프로그래밍 및 웹서비스의사업에 대한 흐름이나 트랜드에 대한 학습을 꾸준히 해야만 한다. 더욱이 웹을 넘어 이제는 모바일시대로접어들면서 모바일 UX와 환경에 대해서 또 학습해야만 한다. 하지만, 기획은 어디에서도 가르쳐주지 않는다. 대학에 전공분야가 있는 것도아니다. 대부분의 기획자들의 대학 전공을 살펴보면 버라이어티 하다. 저자의대학전공도 물리학이다. 수리물리와 양자역학을 공부하고 지금은 기획자로 일을 하고 이렇게 소박한 꿈을이루고자 책도 쓰고 있다.
현실적으로 웹디자인, 퍼블리싱, 웹프로그래밍의파트와 달리 학원에서도 제대로 된 커리큘럼을 가지고 교육을 하는 곳이 없다. 막상 대학생 친구들을 만나서이야기하다 보면 UX전문가가 되고 싶고, 기획자가 되고 싶다고는하지만 무엇을 어디서부터 어떻게 준비해야 하는지 알지 못한다. 저자도 명확히 뭘 해야 한다고 가르쳐주기 곤란한 것이 사실이다. 그래서 일반적으로 기획자를 준비하는 친구들은 일단 눈에 보이는 디자인 공부를시작한다. 퍼블리싱이나 프로그래밍은 어렵다. 그 결과 디자이너와는알아서 마찰이 생기고 퍼블리싱이나 프로그래밍은 몰라서 마찰이 생긴다.
최근 이러한 기획자들의 교육환경에 조금이나마 도움이 되고자 외부 스터디를 매주 진행하고 있다. 대부분의 스터디에 참여하는 기획자들의 니즈는 동일하다. ‘일을 배울수 있는 사수가 없어서’ 실제로 사내 교육을 진행하는 에이전시가 많지 않다. R&D에 투자의 의지가 있는 몇몇 선두 회사를 제외하고는 기획자에 대한 채용의 기준도 없거니와 신입기획자가 업무 능력을 향상시킬 수 있는 환경이 굉장히 열악하다. 제일 큰 문제는 본인이 한 업무가 맞는것인지 잘못된 것인지에 대한 판단을 못하고 그냥 일정에 끌려 주변 사람들에 휩쓸려 떠도는 기획문서들을 따라서 진행하는 경우가 많다는 점이다.
하지만, 기획에서의 이러한 교육환경이 열악한 이유도 이 책을 준비하고스터디를 진행하면서 이해가 된다. 생각해보면 저자 역시 사수에게 체계적인 교육을 받고 이 자리에 있는것이 아니기 때문이다. 그렇기에 누군가를 가르치고 옳고 그름을 판단 한다는 것이 매우 위험할 수 있다는생각이 지배적이다. 그렇다고 손을 놓고 있을 수만은 없기에 저자 역시도 용기를 내어 이 책을 써 내려가보려 한다.
저자를 포함하여 모든 선임 기획자들은 여러분들이 원하는 정답을 모두 가지고 있지 않다. 그들 역시 다양한 경험과 시행착오를 겪으면서 만들어진 자신들만의 방법론을 가지고 업무를 하고 선임의 역할을다 하는 것이다. 명심해야 한다. 기획에는 정답이 없다. 결과만이 있을 뿐이다.
“기획은 엄마가 좋아? 아빠가 좋아? 처럼 정답은 없고,
상황에 따른 결과를 만들 뿐이다.”
정답 없이 업무를 어떻게 하느냐고 묻겠지만, 프로젝트에 있어서 기획자는없는 정답에 대한 가설을 세우고 그 가설을 정답으로 만들기 위해 설득하고 개발자들과 결과물을 만들어 가는 업무를 한다고 보는 것이 맞다. 때로는 우리가 만든 것보다 더 좋은 결과물을 만들 수 있다. 새로오픈한 웹사이트를 보고 긍정적인 피드백을 하는 사람이 있는가 하면 부정적인 평가나 아쉬운 부분을 말하는 사람들도 존재한다. 우리가 벤치마킹을 하면서 늘 그러한 것들을 반복한다. 벤치마킹의대상들은 나름대로의 기획의도와 디자인컨셉과 방향성을 가지고 심사 숙고하고 다양한 테스트를 거쳐 많은 시간과 땀을 들여 만들어 낸 결과물이다. 하지만, 그에 대한 인사이트는 정말 다양하다.
기획자를 비롯하여 웹밥쟁이들은 그 사실을 인정해야만 한다. 디자인도마찬가지다. 정답이 없고, 매우 주관적인 피드백들 속에서최선의 의사결정을 찾아내기 위해서 노력할 뿐이고 결국은 최선을 다해 합의된 결과물만이 남아 있게 된다. 그것을어디서든 정답이라고 말하지는 않는다.
2. 기획자는 누구인가?
프로젝트를 기준으로 해서 봤을 때 기획자는 중심에 있고, 모든 커뮤니케이션의핵심이고 교량이다. 심지어 이제는 기획자가 없이는 커뮤니케이션이 되지 않아 진행 자체가 어려운 상황도발생한다. 누가 이렇게 정의를 해놓은 것인지 아쉬울 따름이다. 기획자는 커뮤니케이션(Communication)을 잘해야 하고, 문서작성(Paper work)을 잘해야 한다. 둘 다 잘하면 능력 있는 기획자로 인정 받는다. 이 2가지 능력에 따라서 고객을 비롯한 수행TF와 친구가 되느냐 적이 되느냐가결정된다.
[1-1 기획자의 위치와 역할]커뮤니케이션은 그냥 단순히 말을 잘하는, 최악은 말만 잘하는 걸의미하는 것이 아니다. 저자가 말하는 커뮤니케이션에는 목적이 있어야 하고 설득이 가능한 이유가 있어야한다. 또한 고객과 개발자들 사이에서 ‘소통(Communication)의 번역(Translation)’을 하는역할을 한다고 생각한다. 고객은 비전문가 입장에서 요구사항을 말하고 그것을 번역하여 개발자들에게 화면설계서나기능정의서를 통해서 요건정의를 전달한다. 반대로 개발자들로 하여금 결과물이 나오게 되면, 예를 들어 디자이너로부터 메인디자인의 결과물이 나오게 되면 디자인의 컨셉이나 방향성에 대해 적용한 의도를 고객의언어로 전달하는 역할 또한 기획자가 할 수 있어야 한다. (물론, 예로설명한 디자인에 대한 컨셉전달은 디자이너가 직접 하는 것이 좋지만)
문서작성도 단순히 파워포인트의 단축키를 현란하게 사용하고 엑셀의 다양한 서식을 현란하게 다루는 것을 말하는것이 아니다. 모든 문서는 그 목적을 알고 만들어야 한다. 아무리간단한 문서라고 해도 그 이유를 충분히 이해하고 만드는 것과 기존 양식에 이름만 수정해서 만드는 것은 그 쓰임이 다를 수밖에 없다. 요구사항정의서, 기능정의서, 화면설계서, 정보구조도 모두 기획자가 주로 만드는 산출물이지만, 프로젝트의 성격에따라서나 그 목적에 따라서 양식은 충분히 변경될 수 있다. 문서를 만들 때는 이 문서를 ‘누가 어떻게’ 활용할지를 먼저 파악하고 만들어야 한다. 가끔 선임들로부터 처음 접해보는 문서를 만들어 오라는 지시를 받는 경우들이 있다. 보통의 기획자들은 주변 지인들에게 템플릿을 구하기 바쁘다. 왜 그문서를 만들어서 누가 어떻게 쓰려고 하는지를 먼저 생각해보고 선임에게 확인을 받아라. 문서를 만드는습관부터도 우리는 다시 한번 생각해 볼 필요가 있다.
프로젝트를 수행하는 프로세스상 기획자의 위치가 고객의 요구사항을 받아서 가공된 화면설계서를 시작으로 진행되기때문에 불가피하게 디자이너, 퍼블리셔, 프로그래머의 개발자들에게기획자는 ‘일 주는(시키는)사람’으로 인식되기 쉽다. 고객에 의한 의사결정이변경된 사항임에도 기획자는 미안한 마음을 앉고 개발자들을 찾아가 반영을 사정한다. 이때 개발자들 눈에는고객과 기획자가 하나로 보인다.
반대의 경우를 생각해보자. 오늘까지 회원가입의 기능이 구현 완료되기로했다. 고객은 목이 빠져라 기능이 되기만을 기다리고 있다. 프로그래머가완료되었다는 피드백과 함께 실제 테스트를 해보면 뭐가 다 되었다고 하는지 이해를 못하는 경우가 있다. 고객에게찾아가 죄송하다며 내일까지 완료하겠다고 피드백을 한다. 뭐가 죄송한 걸까? 이때 고객의 눈에는 기획자나 개발자나 하나로 보인다.
프로젝트에서 기획자의 역할이나 위치는 결코 간단히 정의할 수 없다. 그만큼중요한 브릿지의 역할과 함께 고객과 개발자들 사이에서 책임도 따른다. 위의 고객과 개발자와 하나가 된다는소리는 불만을 갖고 하는 우는 소리가 아니다. 기획자들이 꼭 알아야 하는 현실이다. 인정하기는 싫지만 우리 분야의 전반적인 사업구조나 업무환경이 바뀌지 않는 한 인정해야 하고 받아들여야 한다. 그래서 기획자는 고객과의 커뮤니케이션과 개발자를 위한 문서화 업무를 잘해야만 한다.
정답도 없는 기획을 중간에 껴서 정말 기획자들 욕본다. 그래도 절망적이라고생각할 필요는 없다. 어느 직업이든 본인이 생각하기 나름이며 경험해보지 않고는 상상도 못할 보람과 재미를찾을 수 있다. 경험상 디자인, 퍼블리싱, 프로그래밍을 하다가 기획자로 전향하는 경우는 있어도 기획에서 개발자로 전향하는 경우는 많이 보질 못했다. 왜 그렇겠는가?
저자는 기획자로 전향하는 많은 개발자들을 언제나 환영한다. 다만, 기획자가 편해 보이고 할만한 것 같아서 기획자로 전향했다고 하면 그걸 느끼게 해준 기획자를 찾아가 원망하라. 여러분이 생각하는 것만큼 편하고 쉬운 업무는 절대 아님을 절실히 깨닫고 있으리라 믿는다.
3. 기획자의 길
기획자의 길을 들어서기 시작하는 경우는 2가지로 크게 생각해 볼수 있다.
에이전시와 같은 대행사에서 시작하는 경우나 자회사 서비스 운영기획자로 시작하는 경우로 나눌 수 있다. 자회사에서 단독으로 개발한 서비스를 기획하고 운영하는 기획자의 경우는 상대적으로 다양한 기획의 경험을 하기어렵고 실제로 체계적인 기획업무를 배우지 못해 단위업무에 익숙해져 있는 경우가 많다. 쇼핑몰이나 게임회사를비롯하여 대형 포털사이트의 기획자들이 그러하다.
상대적으로 에이전시나 SI업체 등의 대행사에 시작하는 기획자는 회사에서수주하여 진행하는 프로젝트에 따라서 다양한 프로젝트를 경험할 수 있다. 일부 대행사는 하나의 분야에서만사업영역을 가져가는 곳도 있지만 상대적으로 다양한 프로젝트의 경험을 할 수 있는 기회는 열려 있다. 에이전시의기획자들만 두고 보면 내부에서도 제안기획자, 웹기획자, 앱기획자, 마케팅기획자로 조직을 구분하고 업무롤을 구분하여 운영하는 곳도 있다. 이러한경우에 본인이 원하는 부서로 이동하여 경험의 기회를 찾을 수 있다. 하지만, 말 그대로 발주사의 요청한 서비스를 구축 대행을 하는 업무이기 때문에 기본적인 영업마인드뿐만 아니라 만족할만한결과물을 만들어 내는 과정에서 많은 감정소모와 스트레스를 동반하기도 한다.
스터디를 진행할 때도 에이전시의 기획자들과 서비스 운영기획자들을 모두 만나보게 되지만, 스터디의 내용을 받아들이는 속도나 질문에 대한 답변을 보면 어느 정도 회사의 전체적인 수준이나 분위기를 알수 있다. 어느 쪽이 더 좋고 나쁘다고 말할 수는 없지만, 꼭조언을 해주자면 에이전시에서 시작해서 중급 이상이 되는 시점에 자사 서비스 운영기획자로 전향하는 것을 추천한다.실제 그렇게 진로를 선택하는 경우가 가장 많다.
기획자로 초급/중급의 경력을 쌓고 나면 기획PL의 역할을 수행하게 된다. 기획PL은말 그대로 기획의 리더이다. 요구사항정의나 기능정의는 물론이거니와 화면설계서에 대한 가이드와 검수도업무롤에 속한다. 뿐만 아니라 기획PA들의 스케쥴관리나 결과물에대한 개런티도 해야만 한다. 그만큼 중책이며 얼마나 효과적으로 정해진 시간에 업무 스케쥴링을 하느냐가가장 중요하다고 생각한다. 저자가 생각하는 기획의 꽃은 기획PL이라고생각한다. 가장 많은 업무를 소화하면서 가장 많은 성장을 하는 시기이며, 이때 만나는 PM이 평생 사수가 되는 경우가 가장 많다. 기획PA를 하면서 배웠던 업무와는 차원이 다른 것이 그 동안 없었던‘책임’이라는 것이 생긴다.
이렇게 기획PL을 소화하고 나면 PM으로프로젝트를 배정받게 된다. 회사마다 차이는 있겠지만, 과장이나차장급이 되면 프로젝트의 경중에 따라 PM역할을 수행하게 된다. PM이되면 한동안은 기획PL의 때를 벗지 못하고 자기도 모르게 기획PL의업무를 하는 경우가 많다. PM업무를 모르기 때문이다. PM은기획자가 아니다. 기획만 신경 써서도 안 된다. 디자인, 퍼블리싱, 프로그래밍에서 진행되는 모든 업무의 진척관리 및 이슈관리는물론 HR(Human Resource-인력관리)까지 담당해야만한다. 그리고 늘 회사를 대표한 영업의 마인드를 심고 있어야 한다.
다양한 프로젝트의 PM을 경험하고 나서 다음은 무엇을 하겠는가? 회사 내에서 기획그룹을 관리하는 관리직으로 가는 경우가 대부분이지만, 저자는기술영업의 포지셔닝을 추천한다. 향후 몇 년 안에 저자도 되고자 하는 목표가 기술영업이다. 고객을 찾아가 현재의 문제점을 컨설팅하고 사업을 제안하는 일이다. 쉽지않은 일이지만, 기획자로서 마지막에 가장 이상적인 포지션이라고 생각한다. 어찌 생각하면 기획그룹을 관리하면서 기술영업을 하는 포지션도 생각해 볼 수 있겠다.
기술영업이라는 포지션으로 고객의 프로젝트 의뢰를 접수 받으면 요구사항과 사업에 대한 평가를 거쳐 제안PM으로 참여하여 프로젝트를 수주하고, 수행PM을 포함한 TF를 구성하여 초기 프로젝트의 요구사항정의와 기능정의시점까지 함께 참여한 후에 프로젝트에서 철수하는 그림을 이상적인 기획자의 최종 업무롤로 그려본다.
4. 기획자의 마인드
저자가 기획자로서 업무에 늘 지키려고 노력하고 후임 기획자들에게 지나치게 강조하여 강요로까지 느끼게 하는 세가지가있다. 첫째는 일정에 관련한 ‘scheduling’ 둘째는업무습관에 관련한 ‘why’ 셋째는 사람과의 관계형성에 관련한 ‘readership’이다.
[Scheduling]
기획자 특히나 PM에게 가장 중요한 요소이며, 업무평가의 가장 중요한 기준이다. 웹밥쟁이들이 하는 프로젝트라는것이 늘 ‘정해진 일정’을 전제한다. 당연하다. 우리는 업계의 전문가로서 정해진 일정 내에 원하는 결과물을만들어내야 하는 미션이 있다. 그 미션에서 정해진 일정이 없다면 누구나 할 수 있을 것이고 그렇다면전문가라는 평가를 받을 수 없게 된다. 특히나 일정은 결과물에 대한 예산으로 직결되는 문제이므로 PM을 비롯한 모든 수행TF는 이를 반드시 명심하고 프로젝트를 수행해야만한다.
수행TF의 입장에서 일정과 타협하는 경우를 만들어서는 안 된다. 그래서 수행TF가 잦은 야근과 주말근무를 자처하는지도 모른다. 하지만, 저자는 1차적으로우리에게서 문제점을 찾고 개선하고자 대안을 마련한다. 물론 경우에 따라서는 외부 요인(의사결정의 변경, 협업업무의 일정지연 등)에 의한 일정 지연이 발생할 수 있지만, 이러한 경우는 사전에 철저히대비하여 발생 전에 상호간 대응이 마련될 수 있도록 협업해야 한다.
모든 프로젝트의 업무의 시작은 기획자의 요구사항 및 기능정의와 화면설계서를 기준으로 시작하게 된다. 그래서 기획자는 결과물에 대한 초반 일정을 철저히 지켜야만 한다. 초반에기획자가 요구사항이나 기능정의의 일정을 지연시키게 되면 후반으로 갈수록 지연된 일정을 만회하기가 더 어려워 진다.초반에 기획자가 1일 일정지연을 시키면 구축 마지막에는 프로그래머가 5일 철야근무를 해야만 한다. 그걸 명심하고 책임감 있게 정해진 일정내에 현업TF와 빠르고 정확하게 요구사항 및 기능정의를 완료해야만 한다.
저자는 이러한 기획자의 일정에 대한 책임감을 키우기 위해 평소 근무태도부터 매우 강조를 한다. 출근시간에 대한 책임과 퇴근시간에 대한 권리를 꼭 함께 가져가도록 지도한다.본인의 일일 주어진 미션을 업무시간 내에 소화할 수 있도록 작은 것들부터 관리를 시키고 그에 대한 피드백부터 결과물에 대한 가치평가까지도소홀히 넘어가지 않는다. 저자가 이러한 일에 많은 신경을 쓰는 이유는 평소의 자기 관리가 습관화가 되지않으면 기획자로 프로젝트에 대한 일정을 책임진다는 것은 불가능에 가깝다고 믿기 때문이다. 항상 약속된일정에 모든 일을 완벽히 소화하라는 이야기가 아니다. 일정이 지연되는 경우 상황에 어떻게 대처하는 것이가장 옳은 판단이고 그에 따른 결과가 어떻게 나타나는지를 알려주고 싶은 이유다.
예를 들어, 오전 10시에 3시간정도 소화가 가능한 업무를 적당한 후임 기획자에게 요청한다. 요청시 반드시 그 결과물의 활용용도를 전달하고, 완료 예상 시간을 요청한다. 완료해야만 하는 시간을 이미 난 알고 있다. 하지만, 본인이 어떠한 일이든 스케쥴링을 하는 습관을 기르고자 늘 완료 일정을 스스로 결정할 수 있도록 요청한다. 내일 아침10시까지 하겠다는 피드백이 온다면 다른 기획자를 찾는다. 물론 이유를 묻겠지만, 결과는 내가 원하는 시간 안에 하겠다는 피드백이올 것이고, 원하는 결과를 기대하기 어렵다. 일정에 대한타협은 여기서부터 이루어진다. 오후4시까지 완료하겠다는 피드백을받는다면 가능한 무리가 없는 시간의 비율만큼 당겨서 목표시간을 전달한다. 오후3시까지 결과물을 요청한다. 오후3시이전에 결과물의 피드백이 온다면 결과물의 품질을 따지기 전에 우선 칭찬 리워드를 선물한다. 저자는 칭찬을남발하는 편이다. 칭찬만큼 후임들에게 달콤한 선물은 없다. 문제는오후3시가 되어서 피드백이 없는 경우다. 오후3시가 지나면 난 반드시 진행상황을 확인한다. 그게 나의 업무가 되었기때문이다. 저자가 생각하는 최악의 대답은 “하고 있는데 아직마무리를 못했습니다. 30분정도면 마무리 할 수 있을 것 같습니다.”이다. 무엇 때문에 최악의 대답이라고 했을까? 과연30분의 시간이 더 필요하다는 것을 그 기획자는 내가 오후3시가되어서 확인했을 때 알았을까? 만약에 요청한 결과물이 오후3시이후에는 생명을 다하는 결과물이라면 문제는 더욱 커지게 된다. 물론 그런 경우에는 사전에 대안을 마련했겠지만예를 들어 말이다.
이러한 경우를 우리는 아주 쉽게 저지르고 쉽게 받아들이는 경우가 많다. 그러한습관은 프로젝트를 수행하는 과정에서도 빈번이 벌어지게 된다. A라는 화면설계서를 오늘까지 완료해야만한다. 오늘 오후6시가 되었는데도 완료 피드백이 없다. 어떠한 피드백이 올 것이라 예상하는가? 수행PM으로 TF의 기획자를 비롯하여 모든 개발자들이 이런 식으로 업무에대한 피드백을 한다면 PM에게는 대안을 마련할 기회도 없이 그냥 리스크로 바로 연결된다. 아무리 우리가 전문가라고 하더라도 우리도 사람인지라 늦어질 수 있고 실수 할 수도 있다. 하지만, 우리는 협업을 해야만 하는 구조이고, 모든 업무는 꼬리에 꼬리를 물고 연결되어 있음을 잊어서는 안 된다. 일정내 주어진 업무를 완료하지 못하겠다는 판단이 드는 그 순간, 상황에 대해 공유하고 대안을 함께 마련해야만한다. 최소한 대안을 마련할 수 있는 기회 정도는 줄 수 있어야 한다는 것이다. 그러한 판단은 경험이 쌓이고 많은 시행착오를겪으면서 점점 빨라진다. 그래서 시작도 하기 전에 가능여부를 판단하는 많은 선임들이 탄생하는 것이다.
“프로젝트 관리는 본인의 스케쥴 관리부터가시작이다.”
기획자뿐만 아니라 개발자 모두 본인의 일정관리에만 집중하면 된다. 출퇴근시간의근태를 시작으로 과업에 대한 일정준수를 위한 노력과 이슈가 발생할 지점에서의 빠른 판단과 대응이 얼마나 중요한지 하나하나 경험을 하면서 더욱 느끼게된다. 출근시간의 책임은 지지 않으려 하고 퇴근시간의 권리만을 누리려는 조직원이 되지 않길 바란다. 그런 수행TF가 과연 무엇을 관리할 수 있을까?
[Why]
앞서 스케쥴 이야기의 예를 들어 설명하면서 업무요청 시에 결과물에 대한 활용용도를 함께 전달한다고 했다. 사실 대부분의 선임들이 후임에게 업무요청 시에 정확한 가이드를 제시하는 경우가 많지 않다. 직접 찾아서 알아보고 해야 한다는 나름의 업무철학을 가지고 있는 선임들도 있지만 본인들도 그렇게 업무를 해온경험에서 무의식적으로 하는 습관인 경우가 더 많을 것이다.
먼저 선임들에게는 업무요청 시에 반드시 ‘왜 이 결과물을 만들어야하는지’와 ‘이 결과물은 어떻게 활용할 예정인지’를 전달하는 습관을 들였으면 한다. 설마 업무요청을 하는 본인도 이걸모른다고는 하지 않을 것이다. 후임들은 생각하는 만큼 잘 훈련된 사람들이 아니다. 선임인 그대들도 그렇게 성장해 오질 않았는가? 그걸 군대처럼 대물림하지 않았으면 하는 바램이다. 특히나 기획자는 어디서 업무를 배우고 지금 당신 앞에서 일을 하고 있는 사람들이 아니다. 지금까지 배워서 알고 있는것이라고는 선임인 당신이 알려준 것이 전부일 확률이 매우 크다. 적당한 동기부여를 위한 목표를 잡아주는것은 아주 좋다. 하지만 회사는 학원이 아니라는 이유로 후임들을 궁지로 내몰지 않았으면 한다. 그렇게 시작된 악순환이 지금 계속되고 있는 것은 아닌가 하는 생각이 든다.
이에 후임들은 업무요청을 받으면 제일 먼저 ‘왜 이걸 만들고, 어떻게 사용할지’를 먼저 생각해 버릇하라. 설마 ‘이걸 왜 내가 해야 하나요?’라고먼저 생각하지는 않길 바란다. 선임도 놓치고 말해주지 못했거나 아니면 본인도 아직 그 이유를 찾지 못했으나우선 해야만 하니까 요청하는 경우도 종종 있다. 말해주지 않는다고 혼자 상상하지 말라. 그게 가장 위험한 결과물을 얻는 가장 확실한 방법이다. 왜 이걸만들어야 할지나 어떻게 쓰게 될지에 대한 고민의 결과는 ‘그렇다면 이렇게 만들어야겠구나’라는 결론을 얻기 위함이다. 가끔 선임이 요청한 결과물을 가져가면이유도 없이 아니라고 하거나 선임을 일순간에 당혹함에 빠뜨리는 경우가 있다. 후임인 본인도 몹시 당혹스러울것이다.
‘왜요?’를 남발하면서따지라는 것이 아니다. 쓰임의 목적이 있고, 원하는 결과물에최선을 다해 근접하기 위해서 확인하라는 의미이다. 이는 앞으로 프로젝트를 수행함에 있어 계속되는 반복이다. 현업PM의 요청이든 선임들의 요청이든 기획자가 만들어야 할 산출물은정규산출물 외에도 매 순간순간 요청된다. 비슷한 양식을 참조해서 만드는 것도 원하는 결과물에 도달하기위해 나쁘지 않은 방법이겠지만, 이유와 용도를 확인해서 상황에 맞는 최적화된 결과물을 만드는 습관을들여야 한다. 그래야만 무엇을 만들든 그 과정 속에서 자신의 결과물을 계속 생산해 낼 수 있고 성장이가능하다.
여기서 한가지 조심해야 할 것은 본인이 먼저 이유를 생각하고 확인하는 커뮤니케이션을 먼저 해야만 한다. 본인은 생각도 해보지 않은 상태에서 왜를 질문하게 되면 듣기 좋아할 사람은 아무도 없을 것이다. 예를 들어, “지금 요청하신 문서는 타 부서 담당자들에게 기획의도를전달하고 추가 의견을 받기 위해서 요청하신 것이 맞나요?”가 되어야지 “이거 왜 만들어요?”는 전투의 시작을 알리는 질문이나 다름없다.
[Readership]
‘Readership’의 사전전인 의미를 이야기하는 것이 아니라, 팀을 이끌어 가는 Leadership도 중요하지만, 프로젝트를 이끌어 가는 PM과 기획자는 수행/현업TF의 ‘마음을 읽어주는능력’을 가져야 한다는 것이다. 프로젝트를 끌고 가는 힘에있어서 Leadership보다 ‘Readership’을 먼저갖길 바란다.
아무리 최신 디자인 트랜드를 반영하고 신기술을 도입하여 새로운 사용자 디바이스 환경에 맞추어 크리에이티브한결과물을 얻는다고 해도 결국 ‘사람’이 한다는 것을 잊어서는안 된다. 현업이 요구하는 사항이 무엇인지, 과업범위에서벗어난 요구사항이 발생했을 경우에 무슨 이유로 인해서 요구사항이 발생했는지, 요구사항이라는 fact에만 집중하지 말고 때로는 요청한 사람에 집중하라는 의미이다. 의외로그곳에 답이 있는 경우를 자주 경험하게 된다.
나아가서 PM은 프로젝트의 일정과 품질도 중요하지만, 기본적으로 팀원들의 Emotional Care도 매우 중요한 롤이라고생각한다. 물리적인 좋은 환경을 마련해주듯이 정신적으로 업무에 집중할 수 있는 환경 또한 고려를 해야한다는 것이다. 공과 사를 논하기 전에 우리 업무가 정답 없이 새로운 것을 만들어 내는 일이다 보니산술적으로 1+1=2라는 공식만으로는 설득이 되지 않는 경우가 있다.남자 친구와 헤어진 팀원이 그날 일에 집중할 수 있겠는가? 오늘 여자친구와 1주년이 되는 기념일인데 야근을 한다고 해서 무엇을 얻을 수 있겠는가? 가화만사성이라고했다. PM을 비롯하여 모든 PL급 선임들에게 당부하고자한다. 현업의 요구사항에는 귀를 열고, 팀원의 말에는 마음을열어라.
저자는 기획자로서 프로젝트를 수행에 있어 납기준수, 품질보증의 목표외에 개인적인 목표를 하나 가지고 있다. 바로 프로젝트를 마치고 나서 현업/수행TF를 남기는 일이다. 현업TF와는 가능한 지속적으로 연락을 유지하면서 개인적인 친분의 관계로 이어질 수 있도록 하고, 수행TF와는 ‘다시 프로젝틀같이 하고 싶은 PM’이 되려고 한다. 어쩌면 저자에게는웹어워드의 대상보다도 더 큰 목표이고 커다란 리워드라고 생각한다. 리더로서 사람을 남기는 일은 쉬운일만은 아니다. 무조건 잘 해주고 편의를 봐주면서 호감을 얻으라는 말이 아니다. 수행PM과 팀원으로서 인정을 받고 존경을 받는 리더가 되라는 말이다. 존경은 자신이 스스로 만드는 것이 아니라 주변 사람들로부터 만들어지는 것이다.존경 받는 리더가 되도록 노력하자.
[1부 개론편] – II. 프로젝트 개론
기초편에서는 프로젝트의 탄생배경에서부터 프로젝트의 각 단계별로 어떠한조직들이 무슨 일을 하게 되는지에 대한 전반적인 프로세스를 중심으로 알아보는 프로젝트 개론을 이야기하고자 한다.초급 기획자의 경우에 프로젝트의 일부에 잠시 투입되어 단일업무만을 소화하는 경우가 있다 보니 프로젝트의 시작에서 끝까지의 프로세스를알지 못하고 중급이 되고 고급이 되는 경우들이 있다. 실제로 5년차이상의 중급 기획자들 중에도 각자 알고 있는 프로젝트 프로세스가 상이한 경우가 많다. 왜냐하면 본인이경험해본 프로세스가 그러했기 때문에 이후에 모든 프로젝트들은 경험한 프로세스 안에서만 진행의 반복이 이루어지는 경우가 대부분이다.
에이전시는 기획자 입장에서 보면 아주 커다란 프리랜서 집단이다. 처음에는그렇게 보이지 않았지만, 시간이 흐르면서 회사에 대한 소속감보다는 프로젝트 단위의 수행TF들과의 관계에서 형성되는 ‘우정’‘전우애’ ‘의리’ 등의 감정에 묶여있는 경향이더 강해진다. 그 시점이 되면 조용히 에이전시를 떠나 프리랜서로 전향하는 웹밥쟁이들이 발생하기 시작한다.
상황이야 어찌되었든 가장 중요한 것은 프로젝트의 전반적인 프로세스를 잘 알지 못하거나, 다르게 알고 있는 경우가 있어 저자가 생각하는 프로세스에 대해서 탄생배경부터 이야기를 해보고자 한다. 이 기초편의 내용을 이해하고 나면 이후에 실전편의 각 단계별 실무에 대한 이야기들을 이해하기 더욱 용이 할거라는생각으로 시작해 본다.
1. 프로젝트의 탄생
여기서 말하는 프로젝트라 함은 PC웹사이트, 모바일웹사이트, 모바일앱의 사용자 환경에 따른 플랫폼 구축 및 리뉴얼뿐만아니라 온라인 프로모션, 바이럴마케팅 채널(블로그, 카페, 트위터, 페이스북등)구축/운영, 연간유지보수 등 모든 온라인 서비스를 위한 각종 플랫폼의 구축/운영을 의미한다. 저자는 운영보다는 구축에 초점을 맞추어 설명을 하고자 한다.
일반적으로 에이전시에서 수행하는 프로젝트는 발주사에 계획하는 사업목적을 달성하기 위한 여러 목표들 중에 하나인경우이다. 이해를 돕고자 하나의 상황을 이야기해 보자.
『남성화장품을 전문적으로 판매하는 ㈜맨스킨은 전국 500여개의 오프라인매장을 가지고 있으며, ‘맨스킨I’, ‘맨스킨II’, ‘맨스킨III’ 이라는 3개의대표 브랜드를 가지고 각 브랜드별 프로모션 사이트를 운영 중이며, ㈜맨스킨쇼핑몰(shop.manskin.co.kr)을 운영 중이다. 20대 중반~30대 중반의 직장남성을 고객층으로 하여 지면광고 및 CF광고를 연단위로집행 중이다. 2012년 ~ 2013년 연속영업매출이 하락세를 보이고 있는 ㈜맨스킨의 경영전략실은 2014년도 ‘매출증대’라는 사업목적을 세워 몇 가지 수행 목표를 세웠고, 경영진들의 보고를마치고 승인이 이루어졌다. 사업의 수행일정은 2014년도10월30일까지이며, 12월결과 및 성과보고를 예정하고 있다. 사업목적을 달성하기 위한 주요 목표는 아래와 같다.
1) 여성화장품 브랜드런칭: 남성화장품 외에 20~30대 중반의 직장여성들을 위한여성화장품 브랜드 ‘우먼스킨W’를 신규 런칭하여 사업영역을확장하여 10%의 추가적인 매출증대를 기대한다.
2) 고객소통 채널 마련: 타겟층의 최근 트랜드 SNS를 통해 고객과의 소통의 채널을 마련하여브랜드 인지도를 강화하고 서비스 만족도 및 충성도 향상으로 매출증대를 기대한다.
3) E-커머스 플랫폼 강화: 온라인 쇼핑몰의 리뉴얼과 함께 모바일 쇼핑몰 플랫폼을 신규 구축하여 고객유입 증대로 인한 매출증대를 기대한다.
4) 오프라인 매장 개편: 500여개의 전국 오프라인 매장에 대한 디자인 리뉴얼을 통해 남성화장품 전문 브랜드라는 이미지를 탈피하고 남/여성 명품 코스메틱 브랜드 이미지로의 탈바꿈을 통한 Re-branding
5) 영업 조직 개편: 여성 고객들을 위한 신규 영업라인 구축을 위해 기존 조직에 대한 구조조정 및 신규 영업조직을 개설하여 폭 넓은온/오프라인 마케팅 전략 수립의 지휘부로 탈바꿈』
[2-1 온라인 사업목표 예시]위와 같이2014년도 영업매출 증대를 위한 목적을 달성하기 위해서 5가지의 주요 목표를 세웠다. 이러한 목표를 이루기 위해서 담당부서를지정하고 이 중에 ‘온라인사업부’에 주어진 과업과 목표가전달된다.
영업조직을 개편하고 신규 영업조직을 개설하는 과업은 담당 부서가 별도 지정될 것이다. 위는 이번 사업목표 중 온라인사업부가 진행해야 할 과업의 내용들이다. 온라인사업부가2014년도 계획된 일정에 맞추어 수행해야 할 과업들이며 이 과업들의 내용을 기반으로 담당자는 RFP(Request For Proposal)를 만들고 예산확보를 위한 사업계획서를 마련한다. 품의를 통해 결정된 총 예산금액을 기준으로 하여 수행사를 검색하게 되고, 일반적으로공신력을 인정받고 있는 웹어워드코리아의 최근 수상실적을 지표로 수행 요청사를 1차 선정하고 본 사업에대한 설명회를 공지한다.”
에이전시 입장에서 프로젝트가 시작되는 시점이 위의 RFP배포 및설명회 참여요청을 받는 시점이 된다. 저자가 그 이전에 일반적인 발주사에서 온라인사업이 탄생하는 배경을전달하는 이유는 목적을 달성하기 위한 제안 및 기획을 하는 과정에서 절대로 변하지 않고 흔들리지 않는 것이 ‘사업의목적과 목표’이기에 반드시 확인을 하고 기획에 임해야 한다.
위의 예시에서 보듯이 우리가 의뢰 받아서 진행하는 프로젝트가 2014년도전체 사업이 아니다. 궁극적인 목적인 ‘매출증대’를 위해서 타 부서에서도 병행되어 진행되는 많은 프로젝트들이 존재를 한다. 우리가하는 프로젝트도 그 중에 하나일 뿐이다. 성공적인 프로젝트의 수행을 위해서는 전반적인 프로젝트의 목적과병행되는 목표들을 위한 프로젝트들을 알아 볼 필요가 있다. 물론 이러한 요소는 RFP를 통해서 판단해보거나 영업마케팅을 통해서 알아 볼 수 있도록 한다.
프로젝트의 RFP를 수령하고 설명회에 참석하여 제안참여 요청을 받은에이전시는 RFP의 요청사항과 제한사항은 물론 시장상황까지도 고려하여 본 프로젝트에 대한 내부평가를진행한다. PMO와 PD그룹을 포함한 임원진들의 사업평가를토대로 진행여부가 결정되고 나면, 제안PM이 지정되고 제안서준비를 시작한다. 전쟁이 시작된 것이다.
저자가 제안PM이 되면 제일 먼저 RFP를 몹시 많이 읽어보고 현재 AS-IS의 분석을 최대한 빠른 시간안에 완료하여 RFA(Request For Answer)를 작성한다.주로 RFP의 요청사항이나 AS-IS분석을 통한질문을 중심으로 답변을 요청하는 문서를 전달하고 가능한 담당자 미팅도 함께 요청한다. 이러한 수행사의적극적인 자세만으로도 발주사에게 좋은 점수를 받을 수 있음은 팁으로 알아두자.
일반적으로 제안서를 준비하는 기간은 1주일~2주일정도의 짧은 기간 동안 진행되므로, 제안TF가 구성되고 나면 세심한 일정을 세워서 일정시간 내 최선을 다하여 컨셉과 전략을 중심으로 제안서와 디자인시안등을 준비한다. 제안서 작성에 대한 내용은 실전편에서 추가적으로 다룰 예정이다.
제안서 작성과 함께 제안PM과 PD그룹에서는제안의 실행안과 요구사항을 중심으로 투입공수를 산정하고 견적서를 작성한다. 제안서와 견적서가 준비되면지정된 일자에 프리젠테이션(Presentation-PT)을 준비한다.PT발표자는 보통 제안PM이 하는 경우가 일반적이긴 하나 수행PM이 발표를 하길 원하는 경우도 있어 제안PM과 수행PM이 다를 경우에는 수행PM에게 PT발표준비를 사전에 요청해야만 한다.
중급 기획자 이상이 되면 PT발표 능력을 쌓아두길 권한다. 기획자가 업계에서 성장해 가면서 기획PL과 PM업무를 진행하게 되면 다음 단계에서 요구되는 업무롤이 바로 제안PM과PT발표이다. 저자를 포함하여 많은 기획자들이 PT발표에 심적 장애를 가지고 있는 경우가 많다. 에이전시에서 기획자로서의길을 계속 가고자 한다면 반드시 해야만 하는 미션이니 평소에 다양한 연습과 준비를 소홀히 하지 않길 바란다.
PT발표를 마치고 발주사 현업담당자들은 주어진 평가표에 의해서 제안참여사의평가를 마치고 난 후 ‘우선협상대상업체’를 선정한다. 이것을 보통 ‘제안수주’라고보는 경우가 많으나 엄밀히 말하면 우선협상 대상자라는 의미이다. 우선협상대상자가 되면 현업PM과 제안평가의 피드백을 중심으로 제안내용에 보완해야 할 내용이나 견적금액이나 일정에 대한 조정 의견들을 전달하고수렴여부에 따라서 계약진행 절차를 시작한다.
[2-2 프로젝트의 탄생]2. 프로젝트 주체와 프로세스
프로젝트는 누가 어떻게 진행을 하는가? 먼저 프로젝트를 수행하는TF의 직책을 기준으로 하여 수행 시작에서 완료까지의 흐름을 살펴보자.여기서 중요하게 봐야 할 부분은 진행상황에 대한 이전과 이후의 단계와 동시에 다른 직책의 사람들은 무엇을 하는지에 대해서 알아야 한다. 프로젝트의 성격에 조직의 특성에 따라서 다를 수 있겠지만, 일반적인모습에 대한 저자의 생각을 정리해 본다.
[2-3 프로젝트의 주체와 프로세스]앞서 말했듯이 에이전시 입장에서의 프로젝트 시작은 AE(AccountExecutive)로 부터 시작을 한다. AE는 보통 광고회사에서 사용하는 직책으로 광고주(발주사)와의 커뮤니케이션을 담당하고 광고주의 요구사항을 중심으로 수행TF와 협업을 대행하는 직책이다. 일반적인 에이전시에서는 ‘영업관리’(Sales Manager)로 불리기도 하지만, 통합 온라인서비스 구축 및 마케팅까지 사업범위를 포함하는 에이전시에서는 AE라는직책으로 활동한다.
저자가 생각하는 에이전시의 영업은 ‘기술영업이 가능한 영업인’이 자리 해주길 바란다. 온라인서비스에 대한 일반적인 지식도 없이제조업의 영업경험으로 종사하시는 분들도 있지만, 남다른 노력이 필요하다고 본다. 물건을 파는 업종이 아니라는 것을 알게 되는 순간부터 개인적인 업무수행에 어려움이나 영업결과에 대한 수행조직과의불화가 시작되는 경우가 많기 때문이다. 단순히 만들어진 물건을 판매하는 것이 아닌 전문인력들의 ‘고유기술’과 ‘지적가치’를 파는 일을 하는 사람으로서 준비된 자세가 필요하다.
AE를 통해 ‘영업접수 및초기미팅계획’이 세워지면 PD/PM그룹에서 ‘초기미팅 및 요건분석’을 위한 업무지원을 수행한다. 이후의 미팅결과를 토대로 PMO(Project ManagementOffice)와 미팅에 참여한 PD와 담당AE가사업의 참여여부를 결정한다. 참여여부의 결정에 있어 고려해야 할 요건으로는 현재 가용인력의 상태, 예산대비 사업의 수익률, 과업범위에 대한 수행능력여부, 향후 영업의 지속성여부, 제안사로서 자사경쟁력 등 다양한 방향에서의검토를 진행 후에 최종 의사결정을 한다. 의사결정을 위해 대안마련이 필요한 사항에 대해서는 즉각적인대응마련의 가능여부를 확인한다. 예를 들어 모든 요건이 충족하지만, 적절한가용인력이 부족한 경우에는 외부인력의 가용여부나 컨소시엄형태의 협력사의 참여가 가능한지를 확인하는 추가절차를 신속히 진행하여 빠르고 합리적인 의사결정이될 수 있도록 움직인다.
참여결정이 이루어지면 제안PM을 결정하고 ‘제안진행 및 인력구성’을 진행한다.제안PM은 가용인력을 중심으로 적절한 제안TF를구성하고 RFP분석, 제안서작성, 디자인시안준비 일정과 R&R을 수립하여 제안진행을 총괄하고, 수행TF에 대한 조직도를 구성한다.이때의 조직도는 예상인력으로만 구성을 하되 수행PM만큼은 변경이슈가 발생하지 않도록 확정하는것이 중요하다.
제안사업이 수주하여 수행사로 결정되면 수행PM을 중심으로 수행TF를 최종 확정하게 되며, 부족한 인력들은 담당AE를 통해서 외부인력소싱이 이루어지도록 필요한 급수와 보유기술요건을 전달하고 개별면접을 진행한다. 그 사이 제안PM과 수행PM이다를 경우에 제안PM은 결정된 수행TF를 대상으로 내부킥오프를통해서 제안서 및 진행사항에 대한 전체리뷰를 통해서 수행TF가 초기 요건사항이나 히스토리를 학습할 수있도록 인수인계의 과정을 진행한다.
수행PM은 제안내용을 토대로 하여 수행계획을 수립하고 기획, 디자인, 퍼블리싱, 프로그래밍의모든 수행TF는 각 파트별 PL그룹이 중심이 되어 요구사항및 AS-IS분석을 진행한다. 이후에 정보구조 및 화면설계를진행하고 디자인, 퍼블리싱, 프로그래밍의 본격적인 구축단계에접어든다. 단위별 프로그래밍까지의 구축이 완료되는 시점이 되면 단위테스트와 통합테스트를 수행하고 PM을 비롯하여 내부 PD/PM그룹의 지원을 받아 ‘품질검수’를 진행한다. 내부에QA(Quality Assurance)조직이 운영되고 있다면 품질검수를 위해 QA팀이 산출물에서부터 결과물에까지 품질테스트를 병행하지만, 일반적으로QA팀이 에이전시에 별도 존재하는 경우는 많지 않고 PD/PM그룹에서병행하는 것이 일반적이다.
모든 검수가 완료되고 나면 서비스를 오픈하고 완료보고 후에 프로젝트 종료와 함께 파견지 프로젝트의 경우에는본사복귀를 진행한다. 동시에 PD/PM그룹에서는 수행TF들의 업무평가와 함께 프로젝트 완수에 따른 리워드를 빠짐없이 받을 수 있도록 관리해야 한다. 또한, 수행PM이 주관이되어 수행TF 전체를 대상으로 프로젝트 수행 리뷰를 위한 AAR(AfterAction Review)를 진행한다. 정식 프로세스로 진행하는 회사가 많지는 않지만 그결과는 생각하는 수준 이상의 성과를 기대할 수 있으므로 개인적으로라도 자체 리뷰는 반드시 진행이 되었으면 하는 바램이다.
프로젝트 종료 이후에 PD/PM그룹은 자사 포트폴리오관리 및 경우에따라 외부 언론매체의 홍보활동을 진행한다. 그리고 AE는발주사와의 사후 미팅을 통해 수행결과 및 만족도에 대한 의견을 수렴하고 향후 추가적인 사업을 이어갈 수 있도록 지속적인 영업활동이 필요하며, 최종 프로젝트 수행비용에 대한 정산집행도 마무리를 수행한다.
이렇게 하나의 프로젝트가 AE로부터 시작하여 AE로 끝나는 저자 생각의 이상적인 프로세스를 살펴 보았다. 에이전시를조직이 인력을 기반으로 운영되는 회사이다 보니 영세한 에이전시들도 무수히 많다. 반대로 이보다 더 세분화된프로세스를 구축하고 있는 대형 에이전시들도 존재를 한다. 다만, 에이전시에서의오랜 경험을 바탕으로 일반적인 프로젝트의 주체와 프로세스를 세워 보았다.
대부분의 초급 기획자들은 분석è설계è구축è검수 단계만을 경험하고 들어왔기에 그 이전과 이후의 프로세스들을 알지 못하고 지금도 화면설계서를 가지고현업TF와 사투를 벌이고 있을 것이다.
3. 프로젝트 시작에서 준비까지
프로젝트 주체와 전체적인 프로세스에 대해서 한번 살펴 보았다. 이제핵심 단계(착수, 분석, 설계, 검수) 에서 기획자가 해야 할 업무를 중심으로 ‘프로젝트에 대처하는 우리의 자세’에 대해서 저자의 생각을 정리해 보려한다.
[2-4 프로젝트의 시작에서 준비]프로젝트를 시작하게 되면 제일 먼저 파악하는 것이 ‘무엇을 해야하는가?’하는 과업범위에 대한 확인이다. RFP의 요구사항이나제안서의 내용을 토대로 하여 수행PM을 비롯한 기획팀에서는 고객의 요구사항을 파악하기 시작하고, ‘요구사항정의서’라는 산출물을 작성하기 시작한다. 매우 중요한 산출물 중에 하나이며, 필수 산출물 중에 하나이다.
일반적으로 RFP를 통해 전달되는 고객의 요구사항을 보면,
(1) CS채널 강화: 온라인문의및 FAQ 관리자 기능 개선
(2) 정보구조 개선: 사용자 편의를 위한 정보구조 개선
(3) 교안작성 솔루션 도입: 경쟁사에서 서비스 중인 기능으로 솔루션 도입
(4) 사용자 참여컨텐츠 확장: 커뮤니티 메뉴 신설로 다양한 참여형 게시판 구축
(5) CMS모듈 전면 구축: 모든 일반컨텐츠 페이지의 CMS도입으로관리자 기능 강화
예를 들어, 위와 같은 5가지의요구사항이 포함된 RFP를 검토하고 인터뷰를 시작한다고 하면 기획자인 여러분은 현업담당자에게 무엇을질문할 것인가? 그리고 어떻게 구축방향을 잡을 것인가?
요구사항을 위와 같이 요청 받게 되면 기획자는 요구사항을 기준하여 기능정의 목록을 도출해 낼 것이다. 기능목록에는 온라인문의관리, FAQ관리, 교안작성관리, 커뮤니티게시판관리,CMS관리 기능을 기준으로 현업담당자들과의 인터뷰에서 각각의 기능에 대한 구체적인 요구사항을 질의하고 정리하게 된다. 온라인문의에는 무엇을 등록하게 하고 관리자는 어떻게 고객에게 피드백을 주길 원하는지, 커뮤니티게시판으로 어떤 게시판을 생각하고 있는지, 교안작성 솔루션의관리기능에는 어떤 기능이 필요한지, CMS를 도입하게 되면 HTML편집기는어떠한 기능까지 필요한지, 첨부되는 이미지는 별도 관리가 필요한지 등 가장 중요한 것을 놓치고 정해놓은기준에서 기능정의를 위한 요구사항 인터뷰를 시작한다.
기획자에게 묻는다. (1)~(5)까지의 요구사항에서 ‘왜’ 그렇게 하길 원하는지를 정확히 아는 것이 있는지... 대부분의 기획자들은 가장 중요한 왜 그렇게 하길 원하는지에 대한 근본적인 니즈를 파악하는 일에 소홀하다. 안타깝게도 무엇을 원하는지에 대해 좀 더 구체적인 요구사항을 끌어 내 원하는 것에 가장 근접한 결과물을 만들어추후에 이견 없이 검수를 받기 위해 집중한다. 왜 그렇게 요구하는지에 대해서 한번씩 고민하라. 그 고민에 대한 대답에서 기획의 방향이 달라지는 경우를 적지 않게 경험한다.
현업담당자들도 많은 고민과 경험에서 나온 판단으로 ‘어떠한 문제점’을 해결하고자 위와 같은 요구사항을 우리에게 전달했을 것이다. 그판단을 무조건 의심하라는 것이 아니라 보다 전문가인 우리가 문제점의 중심으로 들어가 요구사항보다 더 효과적인 개선책이 있다면 그 부분을 제안하고구축해 나가야 한다. 그게 기획자의 존재 이유이다. 우리는현업이 만들어달라는 대로 만들기 위해서 화면설계를 만들어 내는 사람들이 아니다. 스스로를 ‘작업자’로 만들지 말고, 전문가의시선으로 폭 넓은 시선을 가져야 한다.
경쟁사들이 서비스 하고 있다는 이유만으로 교안작성 솔루션을 도입하자는 결론으로 어떻게 하면 원하는 기능을 문제없이구축할 것인가를 고민하기 이전에 과연 ‘교안작성 솔루션 도입 이대로 좋은가?’를 한번쯤 검토해 보는 업무의 습관을 길렀으면 한다. 실제로 저자의경험으로 타사에서 서비스 되는 교안작성 솔루션의 일부 사용자들의 설문조사를 진행하고 타사의 벤치마킹 결과를 토대로 재검토를 요청하여 교안작성 솔루션을도입하지 않고 그에 대응이 가능한 서비스를 신설하여 구축을 진행한 경험이 있다.
현업담당자들의 판단을 모두 믿고 요구사항에만 집중하여 진행하는 것은 기획자로서 올바른 태도가 아님을 명심했으면한다. 더불어 많은 기능들의 요구사항들도 해당 기능이 왜 필요한지에 대한 근본적인 니즈를 파악하여 보다개선된 기능구현을 기획하는데 매진해 주길 많은 후임 기획자들에게 바라는 바이다. 최소한 요구사항에 대해서기획자 본인이 판단한 이유를 언급하여 확인하는 과정이라도 반드시 필요하며 프로젝트 중간에 요구사항이 변경되는 경우의 대부분은 이러한 근본적인 니즈에대한 고민 없이 진행된 미스커뮤니케이션에서 비롯되는 경우가 많다.
4. 현실에 존재하지 않는 분석단계
저자가 스터디를 할 때도 가장 강조하는 단계가 분석단계이다. 하지만현실의 프로젝트에는 존재하지 않는 경우가 많다. 간단한 요구사항분석이나 AS-IS분석만을 진행 후에 도출된 인사이트만을 가지고 기능정의와 화면설계를 시작한다. 즉, 요구사항에 의한 기능정의를 기준으로 TO-BE를 설계하는 경우가 대부분이라는 말이다. 그래서 벤치마킹(Benchmarking), 케이스스터디(Case Study), 마인드맵(Mind Map)이나 스왓분석(SWOT Analysis)과 같은 브레인스토밍(Brain Storming)을 통해서 인사이트(Insight)를 도출해내는 과정이 대부분의 기획자들에게는 낯설고 서툴다. 하지만 놓치지 말고 평소에 다양한 분석의 스킬들을꾸준히 학습하여 현실에 맞서야 한다. 주어진 환경을 이유로 회피하기에는 기획자에게 너무나 중요한 과정이기에저자도 스터디시간에 과제의 대부분을 분석을 위한 방법에 투자를 한다.
먼저 프로젝트가 시작되는 착수단계에서 수행PM에 의해 과업범위를기준으로 개발우선순위를 고려하여 업무단위 일정을 수립한다. 그 대표적인 산출물이 WBS(Work Breakdown Structure)이다. WBS에주요 산출물에 대한 의사결정일정이나 업무난이도까지도 감안하여 전체적인 스케쥴링이 수립된다.
[요구사항분석]
이에 맞추어 기획팀은 요구사항정의서를 중심으로 제약사항들을 포함한 환경분석을 시작한다. 요구사항정의서를 작성함에 있어 인터뷰나 설문조사를 실시하게 되는데 이때 중요한 사항은 ‘MUST DO’의 파악도 중요하지만, ‘NEVER DO’의 파악이더 중요하다. 사전에 제안과정을 통해서나 착수 이전에 준비단계에서 ‘MUSTDO’를 중심으로 분석이 되었다면, 수행 분석단계에서는 요구사항의 항목별로 ‘NEVER DO’의 파악이 선행되어야 한다. 디자인을 하는데 있어서사용하지 말아야 할 컬러나 실사 이미지는 없는지, 프로그램 개발에 주의해야 할 사항은 없는지 등 운영이나자사 보안정책 등의 이유로 개발의 제약사항이 존재하게 되며 이를 파악하여 기능정의에 명확히 전달하는 것이 중요한 포인트이다.
[타겟분석]
설정된 타겟의 행동패턴이나 소비성향 등을 분석하는 것도 물론 중요하다. 이전에정확한 타겟을 설정하는 것이 더 중요할 것이다. 저자의 생각은 서비스에 대한 타겟은 현업PM이 가장 정확하게 알고 있다는 판단이다. 그래서 보통의 경우 설정된타겟의 속성을 현업에 요청한다. 사실 타겟에 대한 분석만큼은 일반적으로 수행TF보다 더 명확히 되어 있는 것이 사실이다. 왜냐하면 그 타겟에 대한분석을 전제로 지금 수행하는 프로젝트의 목표가 설정되었을 것이고 요구사항이 발생했을 것이다.
물론, 설정된 타겟들의 성향이 온라인서비스에서는 다른 행태나 피드백을보일 수 있다. 그러한 상황이라면 수행TF에서 별도의 리서치조사 결과를 토대로 타겟에 대한 분석결과를 도출해 내야 한다. 기획자가 집중할 것은 사용자가 무엇을원하고 어떤 목적으로 서비스에 방문하는지에 대한 해답을 기준으로 그렇다면 우리는 무엇을 전달하고 어디에 집중해야 하는지를 인사이트로 찾아내야만한다.
[AS-IS분석]
시스템의 물리적인 서버환경을 포함하여 현재의 온라인서비스가 어떠한 구조로 운영되고 있는지에 대한 사용성, 확장성, 가독성, 일관성, 명확성의 관점에서 분석을 진행한다. 정보구조(IA)를 기준하여 모든 페이지를 살펴보고 현재의 상태와 TO-BE에서개선해야 할 사항을 도출해 내 수행기획안에 빠짐없이 반영해야 하며, 개선해야 할 사항들은 경쟁사와 우수사의사례분석을 통해서 기획안을 준비한다.
[벤치마킹]
벤치마킹을 하기 전에는 반드시 계획을 세워서 진행한다. 요구사항정의서, 타겟분석내용, AS-IS분석내용을 중심으로 개선/추가 되어야 할 항목별로 벤치마킹대상, 일정, 담당자를 정하여 계획적인 벤치마킹을 통해서 인사이트를 정리해야만 한다. 그렇지않고 기획팀과 디자인팀에서 사전 논의 없이 벤치마킹을 하다 보면 가장 중요한 인사이트를 도출해 내지 못하는 경우가 매우 많다.
경쟁사와 우수사를 구분하고 각각의 벤치마킹 항목을 정한 후 기획자들의 업무스킬과 경험을 고려하여 담당자를 먼저지정한다. 그리고 정해진 일정에 벤치마킹을 진행하는 것이 현실적으로 부족한 분석일정에 최선의 결과물을얻어 낼 수 있는 방법 중에 하나이다. 사전에 벤치마킹에 대한 결과는 수행기획안에 포함하여 작성을 해야하므로 벤치마킹 문서에 대한 템플릿 양식을 공유하여 문서개발을 다시 하는 일이 없도록 주의하자.
일반적으로 벤치마킹을 한다고 하면 UI에 대한 벤치마킹이 대부분이다. 문제는 이것보다도 벤치마킹을 정리한 내용에 Fact만이 존재 한다는것이다. 어떠한 UI든 기능이든 간에 벤치마킹을 위해서 기획자가취사를 했다면 그에 대한 인사이트를 명시해야만 한다. 단순히 현재 보여지는 사항에 대한 Fact만을 명시하는 것은 아무 의미 없는 벤치마킹이 될 수 있다. 결론적으로인사이트를 얻어 내지 못하는 벤치마킹은 꼭 할 필요가 없다는 것이다. 가끔 기획자들이 벤치마킹을 참많이도 했지만 TO-BE의 컨셉이나 전략과 연결이 되지 않는 이유가 이러한 경우에 발생하게 된다.
벤치마킹을 반드시 해야 하는 것은 아니다. 벤치마킹의 필요성과 목적을명확히 하고 벤치마킹에 대한 계획을 세워 진행해야만 원하는 인사이트를 얻어 TO-BE에 컨셉이나 전략을수립하는데 든든한 지원군의 역할을 해 줄 수 있을 것이다.
[수행기획안]
‘분석단계말 보고서’라고도하고 프로젝트의 중간 진행사항을 보고하기 위한 보고용도로도 활용이 가능하다. 앞서 진행한 요구사항, 타겟, AS-IS, 벤치마킹의 모든 분석내용의 인사이트를 기준으로하여 주요 서비스에 대한 TO-BE 수행기획안을 작성한다. 기획자는이 문서를 훌륭하게 만들어 낸다고 하면 이후의 설계단계에서의 모든 산출물은 수행기획안을 기준해서 작성하면 되니 커다란 이슈는 없다고 봐도 좋다. 물론 설득력 있고 타당한 TO-BE안이 설계되어야 하는 것이 전제이긴하다.
수행기획안의 초안은 제안서의 내용을 토대로 하여 고도화를 한다는 생각으로 시작해도 좋다. 사실 제안서의 경우에는 RFP만을 가지고 제안사에서 상세한 분석없이 표면에 노출된 조건만을 기준으로 컨셉이나 전략을 수립하고 그에 대한 실행안들을 기획하지만, 여기에구체적인 조건들이나 상세 분석내용을 통해서 보다 구체적이고 현실적으로 구현 가능한 범위에 대해서 명확히 기술하는 문서라고 생각하면 된다. 수행기획안과 함께 보통 준비되는 것이 서비스의 가장 중요한 메인페이지의 기획컨셉과 그에 따른 디자인 시안이준비되어 수행기획안 리뷰와 디자인 시연이 함께 진행되는 경우가 일반적이다.
5. 기획의 꽃 설계단계
대부분의 기획자들이 가장 익숙한 업무를 진행하는 단계가 설계단계일 것이다. 요구사항과수행기획안을 중심으로 구체적인 기능정의서를 만들고 그에 따른 정보구조도(IA)와 화면설계서(SB)를 개발하기 시작하고 결과물의 스케쥴에 따라서 디자인, 퍼블리싱, 프로그래밍이 본격적으로 움직이기 시작한다. 전투의 시작이다.
[기능정의서]
요구사항정의서 분석을 통해 구현할 기능목록을 작성하고 각 기능별로 상세 기능정의 및 제약사항을 관리하는 문서를작성한다. 기능정의서에는 기능정의 외에 요구사항ID를 명시하여추후에 요구사항이 변경되는 사항에 따라 기능정의도 동시에 관리되고 요구사항 추적이 가능하도록 관리를 한다.
기능정의서는 프로그램 개발자들을 위한 요구사항정의서라고 생각하자. 프로그래머들은결정된 기능정의서를 기준으로 ERD를 만들고 그에 따라 DB설계를시작한다. 그리고 구체화된 화면설계서를 기준으로 클라이언트 개발을 진행한다. 그러므로 기능정의서는 가장 구체적으로 명시할 것을 전제하고 특이나 제약사항에 대해서는 반드시 현업과 수행 프로그래머사이에 합의가 이루어져야 한다.
[이슈리스트]
사실 이슈는 프로젝트 시작 자체가 이슈가 되는 프로젝트도 있다. 설계단계에서이슈리스트를 논의하는 이유는 이전에 분석단계에서 요구사항을 정의함에 있어 미결된 사항들을 설계 단계부터는 이슈로 관리하여 해결을 해야만 하기 때문이다. 미결된 모든 의사결정사항들을 명확히 클로징하여 현업과 수행TF간에미스커뮤니케이션이 일어나지 않도록 수행PM이 주관하여 관리하는 것을 권장한다.
이슈사항을 대하는데 있어 간혹 필요이상으로 부정적으로 반응하는 기획자들을 볼 수 있다. 그럴 필요가 없다. 우리는 대행사이고 현업의 요청에 의해서 수행을하러 온 에이전시임을 인정하고 명심해야만 한다. 그런 입장에서 요구사항에 대해서 수용여부만을 결정할것이 아니라 수용 가능한 부분에 대한 수행TF 모두의 검토와 적극적인 대안마련의 마인드를 필요로 한다. 오히려 전체적으로 프로젝트를 수행함에 있어 일부 요구사항을 수용 거부하는 것보다 대안마련이나 가능한 범위를협의하여 진행하는 것이 다른 이슈들을 발행시키지 않는 방법이 될 수 있다. 저자도 상당한 시행착오를겪으면서 정신적인 스트레스도 받아 왔지만, 가장 중요한 것은 인정하느냐 못하느냐의 차이가 굉장히 컸음을깨달았다.
[의사결정 내역서]
비정규 산출물로 저자가 기획자들에게 권장하는 문서이다. 물론 요구사항정의서에의사결정사항들을 명시하긴 하지만 프로젝트를 한참 진행하다 보면 다양한 이슈들에 따라 의사결정사항들이 발생하고 몇 차례 변경되는 되는 이력들이 발생하게되며 결과물이 원하는 바로 나오지 않을 경우에 미스커뮤니케이션에 대한 감정싸움으로 변질되는 경우들이 있다.
저자는 이러한 리스크를 줄여보고자 의사결정 내역서라는 문서를 통해 현업과 수행TF간에 협의된 의사결정사항들 특히, 차후에 변경이력이 발생할 경우리스크 요인으로 발전할 여지가 있는 의사결정사항에 대해서 내용을 별도 기록하고 변경이력 등을 문서화하여 관련TF에게공유 관리하도록 요청한다. 물론 문서 배포 이전에 관리 목적을 현업과 공유하여 오해가 없도록 해야 함은당연한 일이다. 회의록과 요구사항정의서로는 의사결정사항들을 관리하는데 어려움이 발생할 여지가 많다. 반드시 작성해서 사용하라는 문서는 아니지만 비정규 산출물로 활용한다면 효율적인 관리가 될 수 있다고 생각한다.
[정보구조(IA)]
모든 기획자들이 가장 먼저 접해보는 문서가 정보구조(IA)가 아닐까생각한다. 정보구조(IA)는 모든 페이지를 기준하여 정보를그룹핑하고 위치를 결정한 후에 순서를 정하고 네이밍을 결정하는 과정으로 설계하며, AS-IS에서 분석된정보구조(IA)를 기준으로 메뉴변경, 추가, 삭제를 통해서 TO-BE 정보구조(IA)를만들어 가는 것이 일반적이다.
정보구조(IA) 문서를 만드는 양식은 기획자들 마다 조금씩 상이하게작성되고는 있다. 아마도 어떻게 문서를 활용하느냐에 대한 차이에서 비롯되지 않았나 생각한다. 다만, 궁극적 목적인 정보에 대한 구조를 파악하고 관리하는데 집중해야만하며 각 정보들의 속성을 파악할 수 있는 페이지형식, 접근권한, 업데이트주기, 컨텐츠종류 등을 필요에 따라 추가적으로 명시하여 정보구조(IA)에대한 심층분석 및 관리가 가능하도록 한다.
[화면설계서(SB)]
화면설계에는 화면에 대한 레이아웃이나 UI설계를 포함하여 기능정의및 사용자 이벤트 정의까지를 모두 담아 두어야 한다. 간혹 UI화면설계에만집중하는 경우가 있지만 보다 중요한 것은 사용자 경우의 수에 대한 처리가이드를 상세설명(Description)에담아 내는 것이다.
모든 화면을 빠짐없이 작성해야 하며, 화면설계정의서와 커뮤니케이션가이드에맞추어 가이드를 준수하고 있는 그대로 모든 것을 포함하여 설계해야만 한다. 개발자들이 알아서 해주는것은 없다. 기획자 본인이 만든 화면설계에 기준하여 모든 개발이 진행되도록 노력하라. 폰트스타일, 띄워쓰기, 버튼크기, 컬러, 정렬, 철자 등표현하는 모든 것에 의미를 두고 작성해야만 한다.
화면설계에서는 디자이너, 퍼블리셔,프로그래머를 포함한 모든 개발자와 현업담당자들까지 프로젝트에 참여하는 모든 TF가 공통적으로결과물에 대한 정의나 요건에 대한 모든 커뮤니케이션을 하기 위한 수단이다. 그러므로 기획자는 화면설계를작성하는데 집중하고 많은 고민을 해야만 한다. 그래서 화면설계가 기획자의 유일한 포트폴리오가 될 수있는 이유이기도 하다.
다시 말하지만, 화면설계를 누가 어떻게 활용할지를 고민하고 작성하면보다 효과적이고 완성도 높은 화면설계서를 개발 할 수 있을 것이다.
[진척관리표]
진척관리표가 만들어 지는 시점이 되면 본격적인 구축이 진행되었음을 의미한다.저자는 진척관리표를 통해 화면설계의 진척관리부터 프로그램 개발완료까지의 산출물 중심의 진척관리를 진행한다. 진척관리의 단위나 업데이트 주기는 전체적인 수행TF의 진척현황이나업무능력을 고려하여 결정한다. 진척현황이 일정에 리스크요인으로 발생할 여지가 있다면 주단위가 아닌 일단위로진척현황을 체크하고 2뎁스 기준의 메뉴단위를 기준으로 하되 세분화된 단위로 관리가 필요하다면 수행TF와 협의하여 관리를 진행한다.
한가지 중요한 점은 메뉴나 페이지 단위로 진척관리를 할 때 단위별로 가중치를 적용해야만 한다. 가중치를 적용하지 않으면 전체 진척율이 현실적이지 못한 결과로 나올 수 있다.메인페이지 1페이지와 CEO인사말 1페이지는 논리적으로 가중치가 다름을 반영해야만 한다.
6. 오류와의 전쟁 검수단계
다양한 이슈들 속에서 구축을 한창 진행하고 나면 어느덧 단위별 출산의 기쁨을 맛보게 된다. 물론 그사이에 디자인, 퍼블리싱 단위별 검수를 진행하지만, 영혼 없는 그림보다는 프로그램 개발이 완료된 단위 결과물에 대한 테스트를 진행하게 된다. 이렇게 진척관리표를 바탕으로 진척현황에 목표 시점이 오면 테스트 준비를 시작한다. 단위, 통합테스트로 크게 구분되는 테스트도 반드시 테스트 계획을세워 진행하고 테스트 결과에 대한 보고 및 디버깅에 대한 프로세스까지 계획을 세워야만 한다.
[테스트계획서]
테스트일정, 대상, 장소, 범위, 환경, 시나리오에대한 준비와 계획을 수립하여 현업PM을 통해 현업담당자에 공문으로 업무협조를 요청한다. 또한, 테스트 결과에 대한 디버깅 계획을 테스트 진행 과정별로 수행TF와 협의하여 수립하고 디버깅 후 완료확률 95%이상 시 그랜드 오픈에대한 일정을 협의 한다.
[테스트 시나리오]
일반적으로 단위테스트는 수행TF 내부에서 진행하여 디버깅 결과를별도 관리하고 통합테스트를 외부 테스터를 선정하여 공개적으로 진행을 한다. 테스트를 위해 테스트 시나리오를작성하게 되는데 테스트 시나리오의 작성 기준은 사용자의 주요 방문목적과 목적달성을 위한 사용자 행동패턴을 시나리오로 나열하고 각 스텝별 테스트계정 및 데이터까지 모두 제공한다.
테스트 결과의 FAIL 항목에 대해서는 디버깅을 진행 한 후에 테스터에게는문서로 결과를 통보하고 현업PM에게는 수정된 사항을 직접 재 테스트할 수 있도록 피드백 한다.
[오류체크리스트]
일반적으로 통합테스트 결과서라는 정규산출물로 관리를 하지만 저자의 경우에는 단위테스트 이후에 수행TF내부에서 진행한 테스트 결과까지를 모두 통합하여 오류체크리스트라는 문서로 관리를 진행한다. 통합테스트를 진행하면서 발생되는 오류사항들에는 실제 오류항목이 있는가 하면 변경, 추가, 개선사항들도 포함되어 있으므로 현업PM과 수행PM은 오류항목에 대한 상태 구분을 명확히 하여 디버깅 일정에리스크 요인으로 발생하지 않도록 사전에 협의한다.
오류체크리스트에 명시된 오류사항은 100% 디버깅을 원칙으로 하고이후에 가용한 시간이 확보되면 수행TF는 개선, 변경, 추가사항의 순으로 오류체크리스트의 항목들을 처리해 나간다. 이후에프로젝트 일정상 처리가 되지 않은 개선, 변경, 추가사항들은처리방법을 명시하여 운영팀에서 이후에 진행이 될 수 있도록 인수인계 시 전달한다.
[최종산출물]
최종산출물 목록은 분석단계말 시점에 현업PM과 협의하여 준비할 목록및 산출물 양식을 반드시 사전에 협의하여 이후 개발 완료 후 산출물 준비를 위한 일정을 최소화 할 수 있도록 준비해야만 한다. 일반적으로는 산출물 목록은 운영팀과 협의를 진행하고 양식의 경우는 수행TF에서사용하는 양식으로 제출을 요청하지만 일부 관공서나 대형SI업체의 경우에는 내부 품질사업부에서 관리하는문서 양식이 별도로 존재하여 해당 양식으로 산출물이 제출되지 않으면 최종 검수확인이 지연되는 경우도 발생하므로 반드시 확인을 거쳐 진행해야만 한다.
7. 현실 속의 프로젝트
어쩌면 이제까지 저자의 이야기를 포함하여 이후의 모든 이야기도 현실과 너무 동떨어진 이야기가 아니냐는 의문을가질 수 있다. 저자도 실제 해야만 한다는 과정을 다 하지는 못한다.결론은 현실 속의 프로젝트 상태를 인정하고 최선의 프로세스를 만들어야 하는 것이 첫 번째 과업이 될 것이다.
[2-5]의 도형이 저자가 생각하는 현실 속의 일반적인 프로젝트의 상태이다. 수행사가 볼 때 과업범위(Scope)와 품질(Quality)에 대한 요구사항은 굉장히 크게 받아들여지고 실제로도 크다. 이것이크다라고 판단하는 이유는 상대적으로 나머지 개발환경(Condition), 개발일정(Time)과 개발비용(Cost)가 작아도 너무 작기 때문이다. 그래서 수행사에서는 변경사항이 없는 개발환경, 일정, 비용을 기준하여 과업범위를 조정하고 협의하는 일을 진행한다. 물리적으로가능한 범위에서의 합의점을 찾는 과정이며, 이 요건정의를 명쾌하게 잘 정리하는 기획자가 요즘에 가장인정 받는 기획자 중에 하나가 되었다.
다만, 기획자의 한 사람으로서 물리적인 과업범위를 협의하고 대안을제시할 수는 있지만, 개발품질에 대해서는 타협하고 시작하지 않았으면 한다. 그것만큼은 원하는 만큼 최선을 다해서 도달하고자 노력할 수 있는 열정은 스스로에게라도 개런티 할 수 있는 기획자뿐만아니라 웹밥쟁이가 되었으면 한다.
[2-5 현실 속의 프로젝트]에이전시 시장도 앞으로 어떠한 모습으로 변화할지 모르겠지만, 소비자의사용환경이 PC웹에서 모바일로 변화함에 따라서 영향을 받지 않을 수 없다. 한때 소규모 에이전시들이 기획자, 디자이너, 퍼블리셔, 프로그래머, 마케터, 영업까지 종합적으로 서비스에 대응하기 위해 몸집을 부풀렸다면 이제 다시 분업화/전문화의 방향으로 잘할 수 있는 분야에 집중하여 협업하는 시장 구조로 변모하지 않을까 조심스럽게 짐작해 본다.
한편 기존의 대중매체를 통한 광고대행사들이 온라인과 모바일 플랫폼으로 소비자들이 이동함에 따라서 시장의 변화가발생하다 보니 한때는 TV광고를 진행하면서 부가적으로 진행했던 모바일서비스를 에이전시에 하청을 주던구조에 이상현상이 발생하고 있다. 아직은 시장규모에 차이가 있어 구조상의 확연한 변화는 볼 수 없지만, 기존 광고대행사들이 온라인과 모바일사업에 대다수 사업영역을 확장을 준비하고 있다. 이제 더 이상 광고주가 TV나 지면광고만으로는 소비자에게 전달이부족하다는 걸 알고 있기 때문이다.
이처럼 기획자는 최근 트랜드가 되고 있는 플랫디자인이나 반응형웹에만 집중해서는 안 된다. 근본적으로 우리가 종사하는 사업분야는 소비자가 무엇을 사용해서 보느냐에 매우 민감하게 반응한다. 모바일 시장이 이렇게 성장한 것에 비해 시작 된지는 불과 5년전이다. 지하철을 타면 요즘에 책을 들고 보는 사람을 찾아보기 힘들다 남녀노소 모두다 고개를 숙이고 스마트폰에 빠져있다. ‘이게 현실이고 미래이다.’ 우리가 무엇에 집중해야하는지에 대한 답은 우리가 매일 이용하는 지하철 안에서도 찾을 수 있다.
하지만, 5년 전의 휴대폰을 생각하면 지금의 스마트폰이 미래라는확신이 없는 것이 사실이다. Google에서 ‘GoogleGlass’를 만들고 Apple에서 ‘iWatch’를 개발하고 있다. 국내에서도 삼성전자와 LG전자에서도 개발에 힘을 쓰고는 있지만 결국 또 후발주자가 되는 것은 아닌지 아쉬움이 앞선다. 앞으로 5년 아니 1년 후에 어떠한 세상이 올지 누구도 장담하기 힘든 것이사실이다. 모바일 플랫폼에 대해서 모두 공부하고 나면 또 다른 것이 나오겠지? 그때는 정말 이 일을 그만둬야 할지 모르겠다.
