Free Mind Free Web

지난 포스트 방송 작가를 존경하는 4가지 이유 -웹 기획자의 역할이란 뭘까 (1)에 이은 두 번째 포스트입니다.

고객의 요구를 어떻게 하면 정확하게 집어내어 반영하느냐하는 문제는 웹 기획자만 고민하는 문제는 아니다. 외부의 용역을 받아 업무를 수행하는 직업에 종사하는 모든 이들이 이와 동일한 고민을 하기 마련이다. 하기야 외부가 아니라 내부 고객을 대상으로 업무를 수행하는 분들이라 해도 마찬가지다.

상황에 따라 조금씩 달라지겠지만 웹사이트를 구축하는 프로젝트에서 고객과 맨 처음 만나는 역할은 물론 영업자가 담당한다. 잠재고객으로부터 제안요청서를 받아 프로젝트를 시작할 수도 있고, 영업 담당자가 신규 고객을 발굴해서 시작할 수도 있다. 어느 쪽이든 일단 프로젝트가 시작하고 나면 웹 기획자는 고객과 만나 그들의 요구를 파악하는 작업부터 시작한다. 사실 웹 사이트 구축 업무에서 가장 중요한 단계가 바로 이 부분이다. 애초에 사이트의 목적을 파악하는 작업이 제대로 선행되지 않으면 이후에 진행한 모든 일들은 모래 위에 지은 집이 될 수밖에 없다. 문제는, 고객의 요구를 파악하는 것도 쉽지 않을 뿐더러, 설상가상으로 요구 사항을 정확히 파악해 컨셉을 도출해내는데에 주어지는 시간이 결코 많지 않다는 데에 있다.

어쨌든 프로젝트를 진행하는 내내 기획자는 고객과 줄곧 마주칠 수밖에 없다. 기획안을 전달하고, 스토리보드를 작성해서 전달하고, 확인 받고, 수정하고 다시 전달하고. 기획안과 스토리보드 작성은 누구도 부인하지 않는 기획자의 고유 영역이니 이 단계에서 고객과 접촉하는 것은 당연하다. 그러나 일단 스토리보드 작성이 끝난 뒤 디자인과 프로그래밍의 단계에 이르러서는 프로젝트마다 그리고 구축 업체마다 프로세스가 조금 달라진다.

일단 구축 작업이 어느 정도 진행되어 고객에게 1차 버전을 공개하는 단계에 왔다고 가정하자. 대개의 경우 고객에게 1차 버전을 오픈하는 직후부터 수정사항이 쏟아지기 시작한다. 더욱 암울한 것은 사이트에 포함되어야 할 컨텐츠들이 이 시점에서 다시 들어오기 시작하는 경우도 많다는 거다. '왜 진작 주지 않았느냐'고 고객 담당자를 쪼아보지만, 사실 그 사람 역시 내부 고객(고객사 내부의 각 부서)에게 들볶이거나 들볶고 있는 상황인게 대부분이라 별 수 없는 때가 다반사다.

이렇게 쏟아진 수정사항을 전달 받아서 각 작업자에게 다시 전달하는 것은 기획자의 업무인가, PM의 업무인가. 이걸 구분하려면 자연히 PM의 역할에 대한 정의가 선행되어야 한다. 일반적으로 PM(Project Manager)란 프로젝트의 기간, 예산, 인력, 일정 등을 관리하고 배분하는 사람이다. 말 그대로 '매니저', 관리자의 역할을 하는 것이 PM이다. 고객에게서 들어온 수정사항이 오타를 수정하고, 이미지를 보정하는 정도에 머문다면 전체 일정에 영향을 미치지 않을 수 있다. 하지만 스토리보드 작성단계에서 전달받지 않았던 신규 컨텐츠들이 들어오고 있는 상황이라면 당연히 일정과 인력 배분에 영향을 미치게 되고, 이 경우엔 PM의 개입이 불가피하다. 심한 경우 전체 예산에 영향을 줄 가능성도 있다. 이 부분에 대해 얘기하려면 PM이 분명한 역할을 수행하는 경우, 전부는 아니더라도 기획자가 PM 업무의 일부분을 수행하는 경우, 아예 PM이 따로 없이 기획자 한 명이 기획 PL과 PM을 동시에 수행하는 경우 등 세부적으로 나눠야 하는데, 일단 이 얘긴 나중에 하자.

그렇다면 각각의 수정사항에 대해 기획자가 전달받아서 다시 팀 내부에 전달을 하는 방식이 효율적인 것일까. 예전 내 경험 하나를 갖고 살펴보자. 내가 기획자로 업무를 변경하기 전, 디자이너로 일을 하고 있을 때의 얘기다. 당시 수행한 프로젝트는 제안과 시안 작업을 포함해 3개월 정도의 시간이 소요됐다. 작업 상황을 고객에게 공개한 이후 수정사항이 들어오기 시작했다. 처음엔 기획자를 통해 수정 사항이 전달되었으나, 어느 시점에선가 기획자는 어디론가 사라져버리고 디자인 PL을 담당하던 나에게 수정사항이 전달되기 시작했다. 그 뒤의 상황은? 내가 고객을 상대로 열심히 '협상'과 '설득' 업무를 하고 있었다.

고객으로부터 수정사항들이 작업자에게 직접 전달이 되는 경우 발생할 수 있는 가장 큰 문제점은 바로 이거다. 고객의 요구를 모두 들어주는 것은 현실적으로 불가능하고, 작업자의 입장에선 당연히 선별 과정을 거치기 마련이다. 담당 작업자가 설득과 협상에 탁월한 재능이 있어 이 과정이 아주 부드럽게 잘 됐다 치자. 그 다음 단계는? 작업자가 기획자에게 수정된 내용을 전달하는 상황이 벌어진다. 기획자는? 기록한다. 애초에 사이트의 방향을 정하고 기획안을 제작한 사람은 기획자이다. 이 사람만큼 해당 프로젝트의 목적을 잘 알고 있는 사람이 없다. 아니, 없어야 한다. 그런데 이제 기획자는 작업자에게 브리핑을 받아서 그것을 점검하게 됐다.

자신의 요구사항이 제대로 전달되지 못하고 있다고 생각하는 고객은 작업자에게 바로 수정사항을 전달하고자 한다. 때로는 '중간 단계를 굳이 거칠 필요가 있느냐'고 말하는 경우도 있다. 그러나 고객의 요구를 듣고, 그것이 애초 목적에서 벗어나지 않는지를 판단하는 작업은 반드시 필요하다. 설령 때로는 번거롭게 느껴진다 하더라도 프로젝트의 일관성을 유지하기 위해서라도 기획자가 고객을 요구를 듣는 접점으로 작용해야만 한다. 물론 요구사항을 받은 뒤 전체 일정, 인력 관리를 위해 PM과의 협의도 필요할테지만.

그렇다면 외부 고객이 아닌 내부 고객의 경우엔 어떻게 될까. 디자이너, 개발자에게 개발 목표를 설명하고, 구현되어야할 기능을 설명하는 것도 역시 기획자의 몫이다. 기획자가 만드는 스토리보드는 바로 이것을 위한 문서라고 보면 된다.  내부 고객을 상대하는 것이 외부 고객을 상대하는 것만큼 까다로운 경우도 허다하다. 왜 그런지는 기획자로 일하는 사람들은 다들 알고 있을테니 생략. 그것을 최대한 줄이려다 보니 개발 방법론을 공부하라는 사람부터, 최소한 구현 원리는 알아야 한다고 주장하는 사람 등 다양한 의견들이 있다. 이것은 누가 맞다, 그르다를 따지기 애매한 부분이니. 시간 되면 잡담삼아 한 번 하게 될지도.

한 마디로 정리하자. 내가 생각하는 '고객 응대를 잘 하는 기획자'는 다른 게 아니다. 최대한 침착성을 잃지 않고 고객을 상대하면서 애초 프로젝트의 목적을 항상 염두에 두고 있는 사람. 그게 전부다. 말로 하니 쉽다.