중소IT에서 기획자의 역할

 

오늘 이야기할 내용은 IT회사의 여러 직군중 하나인 기획자입니다.

중소IT회사에서의 기획자의 의미와 역할에 대해서 이야기 해볼까 합니다.

규모가 큰 회사에 가면야 기획부서가 아예 따로 있죠.
하지만 규모가 작은 20명 미만의 중소IT회사의 경우에는 대체로 기획자가 한두명 정도 있어서
개발부서나 기타 부서의 구성원으로 포함된 경우가 많습니다.

그런데, 여러분은 혹시 이런 중소IT회사에서 구인하기 가장 어려운 포지션이 뭐라고 생각하세요?
흔히 생각하기에 개발자 뽑는게 가장 힘들 거라고 생각하는데, 의외로 기획자가 더 뽑기 힘듭니다.

개발자는 그래도 요즘에 개발자 대우가 많이 좋아져서, 한 2, 3년 전 부터는 그렇저렇 뽑을 수 있었어요.
중요한게 진짜 제대로 하는 사람을 뽑는게 힘들어서 그렇지, 그래도 채용공고 내면 지원자가 어느 정도 있습니다.
물론 서울 기준이구요.  지방은 지원자 자체를 구경하기 쉽지 않죠.

그런 서울에서조차, 기획자는 채용공고 내봐야 지원자 1명이나 있을까 말까한 포지션입니다.
그럼 채용공고는 충분히 있냐? 아뇨.  채용공고도 별로 없습니다.

즉 수요와 공급 모두 말라 비틀어져 있습니다.  물론 상대적인 비교일 뿐이고, 규모있거나 좋은 회사는 당연히 그렇지 않겠죠.

그럼 이제부터 기획 포지션에 대해서 하나씩 이야기 해보겠습니다.


대략 직원 10명정도되는 IT회사다.  그럼 사실상 기획자가 없는 경우가 많습니다.
그럼 기획은 누가 하느냐? 사장이 합니다.
왜? 만만 하거든요.  개발처럼 무슨 언어를 알아야 하는 것도 아니고, 디자인처럼 센스를 필요로 하는 것도 아니고.
내 사업 내가 벌리는데, 내가 기획하면 되지, 약간 이런 마인드가 깔려 있습니다.
그래서 기획은 뭐 내가 하면 되지 라는 생각으로 접근하는데, 당연히 정리가 안됩니다.

기획의 가장 중요한 업무가 뭔지 아십니까?  물론 기획에서 가장 중요한 업무는 기획이죠.
그런데 이런 중소IT기업에서 기획자의 포지션은 단순히 거기에 그치지 않습니다.
클라이언트와 실무자 사이에서 서로의 언어를 통역해주는 역할을 하는게 기획자라고 보시면 됩니다.

그게 PPT든, 피그마든, 아니면 말로든, 클라이언트가 원하는 그 무언가를 개발자나 디자이너가 충분히 이해하고 작업할 수 있도록 
커뮤니케이션 해주는 아주 중요한 포지션입니다.

이게 잘못되서 틀어지는 프로젝트가 엄청 많습니다. 대부분 잘못된 프로젝트들 보면 결국 커뮤니케이션이 문제인 경우가 대부분입니다.
그럼 이게 왜 문제냐?

예를 들면, 클라이언트가 말을 합니다.  회원이 개인별로 메시지를 주고 받을 수 있는 쪽지 기능같은게 있었으면 좋겠다.
이 대화를 클라이언트와 개발자가 직접한다고 가정하면, 개발자는 머리속으로 상상을 하겠죠.
아, 개인별로 DB에 메시지 내용 저장하고, 조회하는 화면에서 각자 자기 쪽지를 열람하면 되겠구나.  네이버 쪽지 비슷하게 생각을 할 겁니다.
그런데 클라이언트는 쪽지를 비유했지만, 사실은 카카오톡 같은 메신저를 떠올리며 이야기 한거죠.
그럼 왜 쪽지라고 했냐? 카카오톡 같은 메신저 만들어 주세요 하면 돈을 많이 달라고 할 거 같으니까, 자기가 원하는 기능 중 가장 비슷하면서도 왠지 돈이 얼마 안들것 같은 것을 비유로 들게 됩니다.
분명 쪽지로 둘이서 대화를 하는데, 각자 머리속에 그리는게 다른 거죠.
쪽지기능 구현됐나요?  네 구현됐습니다.  어디요?  여기요.  이게 쪽진가요?  실시간으로 알림이 가나요?  실시간이요? 그런 얘긴 없으셨잖아요?
이런 대화들이 오가게 되는 거죠.  물론 이건 그냥 이해를 돕기위한 예시일 뿐입니다.

사람들이 서로 대화를 나눌때 같은 단어를 쓴다고해서 모두 같은 의미로 이해하는게 아닙니다.
같은 단어인데 머리속에서 그리는 그림이 다를 때가 많아요.  그래서 커뮤니케이션 오류가 발생하는 겁니다.

이때 빛을 발하는게 바로 기획자입니다.
기획자는 말이나 문서등을 통해서 클라이언트가 말한 그 "쪽지"에 정확한 기능의 범주를 확인해요.  기획서로 그림을 그려서 클라이언트의 확인을 받죠.
그럼 클라이언트는 그 문서를 보고 "아 이게 아니라, 난 이런 걸 원한거다." 이야기하게 되고, 그가 자신의 요구사항을 전달하는데 단어선택을 잘못한 것을 캐치하게 됩니다.
"아 클라이언트님, 그건 쪽지라기 보다는 그냥 메신저에 가깝네요.  결국 실시간으로 개인별 대화가 핵심인 거죠?"라면서 확인을 하게 되고, 
이렇게 정리된 내용이 디자이너와 개발자에게 정확하게 전달이 됩니다.
커뮤니케이션 오류를 줄여주는 거죠.

이게 얼마나 크냐면, 잘못된 커뮤니케이션으로 이미 거의 다 만들었는데, 이제와서 "이게 아닌데" 하는 경우가 있어요.
그럼 난리 나는 겁니다.  누가 잘못했냐부터 시작해서, 서로 책임공방이 오가는 거죠.  "이렇게 얘기하셨잖아요." 하면 "아닌데" 이런거죠.
기억을 더듬고, 그때 주고받은 이메일을 확인하니 마니, 그런데 이미 같은 단어로 오가고 있었어요.  쪽지.  문제는 그 단어의 의미를 각자 다르게 해석한거죠.
"아니 나는 당연히 쪽지가 실시간으로 알림이 갈줄 알았다."  뭐이런 얘기가 나오는 거죠.
개발사측은 말하죠.  뭐가 당연한거냐? 도대체 어디서부터 어디까지가 당연한거냐.  이 당연하다는 말이, 말을 안해서 알아서 해주는 걸 의미하는데 그 범주가 개발사는 좁게 생각하고, 클라이언트는 아주 넓게 생각합니다.
그래서 이 당연한 것도 하나하나 확인하고 넘어가지 않으면 나중에 논란이 되요.

그런데 사장들이 기획을 우습게 알고 그냥 대충 자기가 말로 때웁니다.  문서 만드는거는 귀찮으니까, 디자이너한테 말로 설명합니다. 
"이렇게 이렇게 요렇게 요렇게... 기획서 만들면 시간 걸리니까 그냥 내 말 뭔말인지 알겠지? 바로 디자인 고고"
그럼 디자이너는 씨불씨불하면서 디자인 하는거죠.  그래서 대충 이쁘게 뽑아내면 오케이 되는거고, 아니면 사장이 다시 설명하는거죠. "아니 그게 아니라, 이게 이렇게 저렇게..."
그렇게 최종, 최종에 최종, 이번에는 진짜 최종 뭐 이런게 만들어 지는 거죠.

기획은 클라이언트 또는 사용자의 언어를 실무자의 언어로 바꿔주는 겁니다.  이게 얼마나 중요한지, 기획때문에 프로젝트 말아먹고 억단위 손실 나면 실감하게 되어 있어요.
근데 그땐 이미 늦은 경우가 수두룩 하죠.

그래서 기획자는 중요합니다.  기획자 채용이 가능하면 반드시 채용을 해서 중간에서 커뮤니케이션을 조율하게 해야 합니다.  사장님들 그거 만만하다고 자기가 한다고 해놓고 제대로 안해요.
그냥 자기가 듣고 이해한거 대충 이야기 하면 실무자들이 알아서 척척척 할거라고 생각하는데, 기획이 그렇게 만만한 일이 아닙니다.
그러니까 좃소 소리 듣는 겁니다.  문서로 달라하면 그거 이해 못하냐고, 머리나쁜 사람 취급하는 인간들이 진짜 많아요. 척하면 척이지? 개소립니다.
그러다가 막상 문제 되면, 지가 한말도 바꿉니다.  내가 언제 그렇게 얘기했냐고.  니가 잘못 알아들은 거라고.
그리고 또 명대사 하나 있죠.  "니가 한댔잖아.  니가 할 수 있다며." 이런 소리.  아 진짜... 개 빡치죠.  
지가 지입으로 이거 별거 아냐, 쉬워, 간단해.  금방 끝나 라고 해놓고 막상 까보니까 그런 일이 아냐, 그럼 덮어 씌우는 거죠.  "니가 할 수 있다며?" 뭐 이런걸로 말이죠.

기획업무가 쉬워보여도, 이거 하나 잘하느냐 못하느냐에 프로젝트의 생사가 오갑니다.
별거 아닌거 같아 보여도 그걸 문서로 하나하나 정리해 보면, 그일이 생각보다 꽤 많은 일이란 걸 알게 됩니다.
그럼 처음에 그일 하는데 적은 공수를 잡았다가, 문서로 정리해 보니 그 공수로는 답이 안나와, 그럼 다시 조정을 해야하는거죠.

기획은 그처럼, 가려져 있는 공수를 수면 위로 끌어올려주는 역할을 합니다.
요즘은 피그마처럼 좋은 시스템이 있어서, 기획자 디자이너 개발자로 이어지는 파이프 라인이 정말 깔끔하게 정돈이 되죠.  왜? 눈에 보이니까.
말이나 단어로 할때보다 명확하게 나오게 됩니다.

그런데 지금도 그저 말 몇마디로 퉁칠려고 하는 사람들이 많아요.  대부분 보면 사장들이 그럽니다.  제발 그러지 말라고, 그러니까 좃소 소리 듣는거라고 이야기 해주고 싶네요.
이걸로 기획자의 포지션이 얼마나 중요한지 이해하는데 도움이 되셨기를 바라고, 혹시나 제가 기획자가 아닐까 하시는 분들이 있을까봐 이야기 하는데, 저는 개발잡니다.

언젠가 개발에 관련된 이야기도 하나씩 풀어놓을 예정입니다.
특히 창업을 하시는데, 본인이 개발 파트가 아니신 분들, 어떤 개발자와 어떻게 일해야 하는지, 그런 이야기를 하나씩 풀어볼까 합니다.

감사합니다.