기획자는 대체 어디까지 관여해야 할까
기획자의 KPI에서 알 수 있는 관여의 조건
저도 제가 하고 싶어서
요청하는 거 아니에요
눈물이 왈칵 솟고 가슴에서 욱! 하고 말이 올라왔다. 평소 친하게 지내왔던 개발자와 디자이너의 눈에는 불만만 가득했다.
갑작스러운 기획이었고 개발 검토할 시간도 없이 무리한 일정만 있던 기획건. 나 역시 동료들을 존중하며 이 개발의 필요성을 멋지게 설득하고 싶었지만 사실 그저 '윗분들'의 한마디에서 벌어진 억지 같은 기획이었다. 내 직무의 뿌듯함보다는 사내 정치가 내 목을 조르던 날.
결국 웅얼대며 맘에도 없던 설득을 하다가 마음에서 삑사리가 나버렸다. 다 똑같이 일하는데 왜 나만 설득하고 있어야 되는지 답답했다.
하지만 휑하니 회의실을 빠져나온 그 순간부터 이미 후회는 시작됐다. 몇 번이나 메신저로 사과를 하고, 그들의 불만 포인트를 조금씩 제거해가며 개발과 디자인이 가능하도록 기획을 수정했다. 여전히 속은 상했지만 난 결국은 이 일을 해내야 했기 때문이었다.
성장하지 않고 감정만 쓰는 기분
문득 이런 날도 있다.
나만 뒤쳐지고 정체되고 바닥으로 한없이 가라앉는 것만 같은 기분. 젖은 낙엽처럼 이 회사의 서비스라는 틀에만 매여서 더 이상 기획자로는 성장하지 못할 것만 같은 기분이 드는 날이 있다.
이름만 다른 똑같은 UI의 페이지와 어찌 됐던 매출밖에 목표도 없는 뻔한 프로젝트를 무한 반복하자면 '내가 뭐 나 좋자고 이런 일을 하는 것도 아닌데...'하는 생각이 든다.
그럼에도 기획자는 챙겨야 할 일은 왜 이렇게도 많은 건지 한탄해볼 틈도 없이 이래저래 뛰어다니다 보면 퇴근시간만 되어버리고. 고대로 남아버린 SB작업일 위해 다시 자리에 앉는다. SB 없이는 개발 시작도 못한다는 생각에 마음만 급하다. 집에 갈 시간을 조금이라도 당겨보겠다며 삼각김밥을 입에 물고는 마우스를 잡는다.
메일은 어느새 잔뜩 쌓여있지만 정작 내가 요청한 현업부서 회신은 며칠 째 대답조차 없고, 한참 늦은 밤 하루의 마무리로 최후통첩의 메일을 보낸다. 내일까지 답변 안 하면 이번 기획 건은 드랍시켜버리겠으니 어서 대답하라고 협박이었다.
한 구석 답답해진다. 나 좋자고 하는 일도 아닌데 도대체 이런 것까지 나만 챙기고 있지?
책임님, 대체 왜 기획자만 굽신굽신 해야 하죠?
얼마 전에도 어떤 후배가 볼이 잔뜩 부어 나에게 물었다. 다 같이 진행하는 프로젝트인데 대체 왜 기획자가 이렇게 부탁을 많이 하고 다니는 건지 답답하다고 했다.
몇 년은 일해도 문득문득 드는 질문이지만 곰곰이 이유를 생각해보니 이유는 의외로 간단했다.
기획자의 역할이 바로 그 역할이기 때문이었다.
여기에는 구조적인 이유가 있다.
하나의 개발 프로젝트에는 여러 직무가 참여를 한다. 먼저 업무를 요청한 요청 실무부서, 기획자, 디자이너, 개발자(백엔드, 프런트엔드, 인프라 등), QA, QC 등등 여럿이다. 벌써부터 느낌이 오겠지만 이 중에서 자기 역할이 가장 모호한 사람은 바로 기획자뿐이다.
하나의 프로젝트가 끝나고 나면 평가는 어떻게 해야 할까? 예를 들어 새로운 전시 매장을 개발하는 프로젝트를 진행했다고 해보자. 덕분에 페이지에서 매출이 빵빵 터졌다고 하자. 이 프로젝트와 프로젝트 참여자들의 개인 평가는 어떻게 되어야 할까?
매출이 나오는 것은 마케팅이나 상품 운영 자체가 큰 영향이 미치는 부분이다. 매출이 높다고 잔잔한 오류가 없다는 뜻은 아니다. 화면 부하도 있을 수 있다. 그렇다면 현업 운영 실무자는 놓은 평가를 받아도 개발자와 테스터의 평가는 나쁠 수 있다. 디자이너는 어떠한가? UI는 기획자와 디자이너가 서로 맞드는 영역이지만 결국은 디자이너의 최종 산출물이다. 기획자가 설계를 엄청나게 잘했어도 디자이너의 역량이 산출물에 더 크게 작용한다.
그렇다면 기획자는 무엇으로 평가해야 할까? 사실 기획자에게 가장 중요한 역량은 어디까지나 '커뮤니케이션'이다. 이 프로젝트가 순항되어 정해진 일정에 목표한 만큼의 수준에 맞춰 오픈시킬 수 있냐는 것이 가장 중요한 직무적 목표다.
하지만 평가자의 입장에서 생각해보자. 자신이 참여하지도 않은 세부 과정을 평가한다는 것이 가능할까? 결국 평가자는 기획자를 단 두 가지로만 판단할 수밖에 없다.
미션에 대한 적절한 기획을 했는가?
기획을 얼마나 안정적으로 구현시키는가?
앞의 항목이 기획문서와 스토리보드라면 후자는 프로젝트 오픈 이후 보이는 모든 것이 된다. 구조적으로 좋은 평가를 받기 위해서는 모든 과정에서 기획자가 가장 안달을 부리게 되는 것은 바로 이 때문이다. 최종 개발 산출물이야말로 기획자의 일한 과정 그 자체가 되어버리기 때문이다.
그래서 다 참고 살라고?
아니다. 기획자가 살기 위해 참기만 하라는 뜻은 아니다. 기획자가 느끼는 것과 다르게 다른 시점에서는 기획자가 꼭 굽신거리는 존재가 아니기도 하다.
갑질 요건 철옹성 : 요청자가 보는 기획자
'아 이건 좀~' 까다로운 월권자 : 디자이너가 보는 기획자
'왜 안돼요?' 떼쟁이 : 개발자가 보는 기획자
'이런 것도 꼭 확인해주세요' 테스트도 안 하면서 입만 산 시누이 : QA, QC가 보는 기획자
기획자는 이 세상에 나만 존재하지 않는다. 나와 나의 후배는 부탁을 하느라 친절함을 택했다면 어떤 기획자는 화도 냈고 어떤 기획자는 갑질도 했다. 그리고 개중에는 기획안만 내고 방관하는 이들도 있었다. 게다가 자신의 기억과 다르게 그렇게 받아들여지는 경우도 있다.
'도대체 기획자가 얼마나 관여해야 하나요?'
이 질문은 결국 '일의 고됨'에서 시작되는 질문이다. 다 참견하자니 일이 고되고 협업하는 사람과 마찰이 생길 수 있고, 정말 관여하기 싫다고 생각해서 관여하지 않으면 운이 나쁠 경우 기획자에 대해 평가는 최악이 된다.
완벽할 수 없다
기획자의 일의 핵심은 무엇인가. 나는 '주어진 환경 속에서 최대한의 차선을 찾는 것. 즉, 문제 해결'이라고 생각한다.
주변의 환경도 완벽할 수 없다. 나의 기획이 완벽할 수 없듯이 협업자의 '이해도'나 협업자의 '사상'이 나와 똑같은 모습은 이상적인 꿈일 뿐이다. 이런 환경에서도 문제를 해결해야 하는 것이 기획자일 뿐이다.
흔히 '커피 타는 거 빼고는 다 한다'는 기획자의 관여범위는 그런 면에서 명확해진다. 기획자가 꼭 수정하고 싶고 꼭 바로 잡고 싶은 곳이라면 기획자의 관여범위가 되는 것이다.
이제 그러면 인정해야 한다. 관여범위가 너무 많아서 힘들다는 것은 결국 기획자의 기준이 기획자를 괴롭힐 뿐이다. 잘 해내고 싶고 잘 만들고 싶은 기획자의 목소리일 뿐이다.
그래서 난 차라리 내 욕심을 인정해 보는 것이 오히려 나의 지친 감정을 위로하는 데 도리어 도움이 되기도 한다.
