얼마전 개발자의 이력서 작성 및 면접 관련 포스팅을 페이스북에 발행했었는데 생각보다 반응이 좋았다. 그런데 아이러니하게도 그 중 어떤 분께서 그 글을 보고 나에게 ‘기획자가 기본적으로 가져야 할 기본적 소양이 무엇이냐’는 질문을 했다. 아무래도 내가 기획자라는 문장을 보고 질문을 한 것 같은데 대답을 어떻게 해야 할지 고민을 하다가 답이 안 떠올라서 나중에 답변을 드리겠다고 했다.
과연 기획자에게 필요한 역량은 무엇일까? 이 질문이야 말로 정말 답이 없는 것 같다. 기획자마다 각자 경험이 다르고 사고방식이 다를테니 말이다. 그래서 질문자가 이제 막 기획을 배우려는 사람이라는 가정하에 ‘기획자로서 일을 해보니 일을 하기 전에 생각했던 것과 많이 다른 점은 무엇인가?’라는 질문에 답을 하고자 한다. 그나마 이 질문에 대한 답이 도움이 될 듯 하다.
*참고로 나는 웹서비스 기획자이다. 그 점을 참고하여 읽어주기 바란다.
1. 아이디어나 창의성보다 더 중요한 것은 본질을 보는 것이다.
기획자를 어떻게 정의할 수 있을까? 난 개인적으로 ‘문제나 현상에 대해 본질을 보는 사람’이라고 정의하고 싶다. (이 관점에서보자면 디자이너나 개발자는 해결사라고 볼 수 있겠다.) 기획자는 자신이 생각한 그 본질을 토대로 방향을 제시한다.
예를들어, 당신이 나이키의 마케팅 기획자라고 가정해보자. 어느날부터 운동화 매출이 떨어지기 시작한다. 그런데 그런 현상은 다른 브랜드에서도 일어난다. 이 시점에서 당신은 어떤 생각을 하겠는가? 다른 브랜드에서도 매출이 감소하므로 이 현상의 원인을 경기둔화로 인한 침체기로 단정할 것인가? 물론 그럴 가능성이 매우 크다. 하지만 이 글의 목적에 맞게본질적인 접근 방법(?)을 한 번 써보자. 일반적으로 사람들은 운동화를 운동 할 때 신으려고 산다. 운동화의 본질은 운동을 할 때 신는 신발이라는 것이다. 그런데 운동화의 판매량이 줄었다면 그 만큼 운동량이 줄어들었을 수도 있다. 만약 그렇다면 평소에 운동을 하던 사람들이 남는 시간에 무엇을 하는지 조사를 해봐야 한다. 이 방식대로라면 운동화의 판매량 저하는 스마트폰의 게임이나 PC게임, 드라마 등의 요소들이 영향을 미칠 수 있다.
기획자는 위의 예처럼(예시가 좀 부족한 면이 있기는 하지만..ㅡ.ㅡ) 직면한 문제에 대해서 본질을 파악하기 위해 다양한 생각을 해야한다. 그래야 올바른 방향이 나오고 그 방향은 기디자이너나 개발자의 능력을 통해 성공으로 이어진다.
그런데 나는 초창기 무조건 새로운 방식, 새로운 생각만을 추구했었다. 그것이 좋은 기획이라고 생각했기 때문이다. 항상 아이디어를 최우선으로 생각하다보니 문제에 대한 본질을 보기보다는 무작정 문제에 대한 새로운 해결방법만을 고민했다. 그리고 그 방법을 찾기 위해 무작정 자료조사부터 하기 시작했다. 그런데 문제에 대한 파악이 정확하지 않는데 답이 나올 수는 없는법이다. 그러다보니 직장 선배가 보기에 나는 열심히는 하지만 생각이 깊지 못한 기획자로 보여지기도 했다. 그래서 선배의 여러 조언을 통해 그런 점을 고치기 시작했고 나름대로 한 단계 성숙해질 수 있었다. 그래서 이번에 Docswave라는 서비스를 기획하는 과정에서 혼란스러운 여러가지 문제점을 잘 해결할 수 있었다. Docswave에 대한 기획이야기는 지난 포스팅을 참고해주기 바란다.
2. 그러면 그 본질을 보는 능력은 어떻게 생기는 것인가?
당연히 나도 잘 모른다. 그걸 알고 있으면서 타인에게 설명까지 할 수 있는 사람이 현 시대에 존재하는지도 잘 모르겠다. 그럼에도 불구하고 단순히 나의 경험담을 이야기 하자면…..
왜?라는 질문을 스스로에게 하면서 조금씩 발전했던 것 같다.
물론 아직도 난 많이 부족하다. 그런데 한 가지 확실한건 내가 그 동안 진행해왔던 일들 중에서 ‘왜?’라는 질문에서부터 깊게 고민을 하며 시작한 일들은 전반적으로 잘 진행되었다는 것이다.
왜? 라는 질문이 왜 중요한지 한 가지 예를 들어보겠다.
만약 당신이 새로운 그룹웨어 서비스를 기획한다고 가정하자. 당신은 일단, 바로 기획서를 작성하기 전에 왜 새로운 그룹웨어 서비스가 과연 필요한지부터 파악할 것이다.(만약 당신이 기능정의서나 스토리보드, 프로토타입부터 작성한다면 아마 이 글은 당신에게 큰 도움이 될 것이다. 그만큼 당신은 아직 경험이 없다는 것이니까…) 그리고 다른 서비스들을 참고하기 시작할 것이다. 그 과정에서 Google 기반의 Workflow 서비스인 Docswave라는 서비스를 분석한다고 가정하자. 아마 경험이 별로 없는 기획자라면 ‘Docswave라는 서비스가 그냥 구글문서로 전자결재를 진행할 수 있는 서비스구나! 아이디어 좋네! ‘라고 하고 언제나 그랬듯 UI나 기능적인 측면을 중점적으로 분석할 것이다. 그런데 제대로 된 분석을 하려면 여기에서 왜라는 질문을 던져야 한다. 즉, ‘왜 Docswave라는 서비스는 구글기반으로 만들어진 것일까? 고객이 구글을 쓰는 기업으로 제한적일 텐데….’라는 질문을 던질 수 있어야 한다. 왜냐면 이 질문이 당신이 기획할 그룹웨어 서비스에 큰 영향을 미칠 것이기 때문이다. 생각해보자. Google Apps에서 제공하는 G메일, Google Drive(파일저장, 문서작성), 행아웃(채팅), 캘린더보다 더 좋고 안정적이면서 저렴하게 제공하는 그룹웨어 서비스를 본적이 있는가? 혹은 당신의 팀이 Google Apps보다 더 좋은 업무서비스를 만들 수 있을까? 나는 확률적으로 많이 어렵다고 본다. 그래서 Docswave는 기업들이 Google Apps의 그 강력한 기능들을 그대로 이용하면서 추가로 워크플로우와 조직관리를 할 수 있도록 기획이 된 서비스이다. 그리고 실제로 Google Apps가 그룹웨어 시장에서 점차 점유율이 높아지고 있는 현실은 당신이 기획할 그룹웨어 서비스의 필요성에 대해서 다시 한 번 생각을 하게 할 것이다. 혹은 비즈니스 모델의 방향을 크게 바꿔놓을 수도 있을 것이다.
이렇듯(예시가 좀 부족하긴 하지만…ㅡ.ㅡ;;) 왜?라는 질문을 내면 깊숙히 하다보면 다른 서비스를 참고하는 과정에서도 현재 내가 기획하고 있는 서비스의 본질을 다시 한 번 확인할 수 있다. 그리고 그 과정은 올바른 방향으로 당신을 이끌어줄 것으로 감히 예상해본다.
3.기획의 가장 좋은 연습은 내 삶에 대한 기획이다.
사실 기획이란 것이 열심히 하고 싶어도 어떤 과정을 통해 연습을 해야하는지 감히 잘 안 잡힌다. 만약 개발자라면 책을 보면서 코딩을 해보면 될 것이고 디자이너라면 자신이 생각한 것을 그려보면 될 것이다. 그런데 기획자는 다른 사람의 기획서를 보기도 힘들뿐더러 아이디어가 있다고 누가 개발해주지도 않을 서비스 기획서를 연습용으로 써보기엔 지루하기 짝이 없다.
그래서 난 내 삶의 기획을 구체적으로 해보곤 한다. 어떻게 보면 내 삶에 관한 것이기 때문에 기획이라기보다 계획에 더 가까울 수도 있다. 하지만 자기 자신의 삶에 대한 것이기 때문에 집중하여 신중하게 기획에 대한 경험을 할 수 있다. 나는 주로 아래와 같은 질문을 던져가며 내 삶에 대한 생각을 정리하곤 한다. 만약 당신이 아직 신입에 가까운 기획자라면…혹은 기획에 대한 경험이 부족하다면 자신의 인생부터 기획을 디테일하게 해보라고 감히 권하고 싶다. 물론 이것도 왜?라는 질문이 많은 도움이 될 것이다. 보다 당신을 솔직하게 바라볼 수 있을테니….
나는 왜 개발자보다 기획자가 되기를 선택했는가? 나는 왜 벤처기업에서 일을 하는가? 내가 지금 이 회사에서 성취하고자 하는 것은 무엇인가? 왜 그것을 성취해야 하는가? ……등등……
4. 재능과 업무관련 지식
난 개인적으로 기획, 개발, 디자인 그 무엇이든지 재능이 상당부분 중요하다고 생각한다. 그래서 개인적으로 ‘천재는 노력하는 사람을 이길 수 없고, 노력하는 사람은 즐기는 사람을 이길 수 없다’는 말을 별로 안 좋아한다. 왜냐하면 내 경험상, 천재가 열심히 한다. 왜냐하면 재미있으니까!! 그래서 즐기면서 한다.
그러나 이 말은 꼭 기획분야의 천재인 사람만 기획을 해야한다는 말은 절대 아니다. 절대 절대 아니다. 다만, 체질적으로 정말 맞지 않는 사람들이 있다는 것을 인정할 뿐이다. 만약 기획자를 하고자 하는데 사람과 의사소통하는 것과 문서작성 하는 것을 굉장히 싫어한다면 적어도 소프트웨어 기획자로서는 능력을 발휘하기 어렵다고 생각한다. 이건 개발을 하고자하는 사람이 코딩을 싫어하는 것과 마찬가지이다. 즉, 기획자도 아무나 할 수 있는 직업이 아니라는 것이다.
그리고 당신이 만약 IT분야의 기획자라면 개발지식은 가능한 많이 습득하는 것이 좋다. (물론 나도 현재 공부중이다.) 일을 하다보면 기획자가 개발자의 업무스타일에 대해 굉장히 답답해하는 경우가 있다. 무슨 기능만 요청하면 개발자가 안된다고 하기 때문에 일의 진행이 어렵다는 푸념과 함께… 그런데 사실 자세히 살펴보면 기획자가 개발에 대한 지식이 없기 때문에 발생하는 트러블도 많다. 즉, 개발에 대한 지식이 없기 때문에 시스템에 대한 구조적인 부분을 무시하고 이것 저것 막 추가만 하려는 것이다. 그러면 당연히 개발자로서는 답답할 것이다.
기획자가 개발에 대한 지식이 어느정도라도 있으면 대부분 개발자도 많이 좋아하는 것 같다. 그리고 개발자와 금방 친해질 수 있고 자연히 프로젝트 진행은 진밀한 분위기로 이끌어 갈 수 있다. 나의 전 직장에서 내가 잘 따르던 선배도 그랬고 나도 지금 회사에서 그렇다고 생각하고 있다. 물론 이것도 내 개인적인 생각이지만…
5. 그 외 도움이 될 만한 책
그 밖에 꼭 기획이 아니더라도 나에게 도움이 된 책들에 대해서 소개하고자 한다.
– 피터드러커의 자기경영 노트 : 당신이 만약 사업기획을 한다면 큰 도움이 될 것이다. 기획과 경영은 많은 부분 공통점이 있으니까..
– 데일카네기 자기관리론 : 기획자의 중요한 역량중 하나가 바로 멘탈이다. 개발자나 디자이너가업무에 지쳐서 부정적인 표현을 하더라도 기획자는 멘탈을 끝까지 붙잡고 있어야 한다. 이 책은 나에게 멘탈을 붙잡는 방법에 대해서 큰 깨우침을 준 책이다.
– 직언(저자: 윌리엄 B.어빈) : 지난 포스팅에서 기획을 함에 있어 선택의 중요성을 언급한 적이 있다. 그런데 선택에 있어 가장 중요한 것이 철학이다. 그것이 본인의 철학이든, 아니면 조직의 철학이든….이 책은 스토아 학파에 대한 이야기인데 ‘철학적인 사고를 삶에 어떻게 적용하며 살아갈 것인가?’에 대해서 잘 나와있다. 개인적으로 난 이 책이 정말 좋다.
6. 그래도 역시나 답은 없다.
위에서 이런 저런 말은 많이 했으나 여전히 답은 없다. 난 그냥 내 경험과 개인저인 생각을 말했을 뿐이다. 사람마다 각자의 스타일과 경험이 다르기 때문에 받아들이는 것도 아마 다 다를 것이다. 각자 자신만의 답을 찾기 바란다.
6 comments
기획자에게 가장 필요한 역량은 문제해결 능력과 이를 위한 의지라고 봅니다. 물론 이 글에 쓰여진 것 처럼 본질을 꿰뚫어 보는 통찰력과 자신의 사업군에 대한 폭넓은 배경 지식도 중요하겠지만.
결국 “일이 되도록” 하는 것이 기획자에게 가장 중요한 임무이자 사명이라고 생각하고, 일이 되게 하려면 지금 주어진 문제를 어떻게 하면 가장 효율적으로 해결할 것인가에 대한 고민과 추진력 등이 기획자에게 꼭 필요한 능력이 아닐까 싶네요.
가장 우수한 기획자는
언제나 새로운 트렌드를 읽는 사람도 아니고, “난 남들과 달라”를 주구장창 외치는 힙스터도 아니고, 항상 고민에 빠져 더 나은 성과물을 내고자 하는 사람도 아니고..
문제를 가장 빠르고 효율적으로 해결해낼 수 있는 사람이라고 봅니다.
그런데 많은 기획자들이 꼭 멋진 아이디어를 내놔야 한다는 강박관념에 사로잡혀 정작 일은 진행이 잘 안되는 경우가 많죠.. 이런 부분에 있어서는 많은 공감을 하게 됩니다.
아이디어는 기획자가 내는 것이 아니고 모두가 함께 내는 것인데 말입니다.
좋은 글 잘 봤습니다.
좋은 의견 감사합니다. 기획자로서 ‘일이 되도록’ 하는 것도 굉장히 중요한 것 같습니다. 참 그러고보면 기획자가 하는 일이 많죠 ㅎㅎㅎ 그리고 말씀하신 내용중에 ‘아이디어는 모두가 함께 내는 것’이라는 말이 참 좋네요…좋은 의견 감사합니다.
새롭게 기획업무를 하게된 IT 개발만 15년을 했습니다. 이번에 회사에서 서비스/솔루션 기획쪽으로 부서발령을 내주셨네요. 연말 오픈을 앞둔 내부 사용자용 솔루션을 기획을 하여 현업/개발 조율을 잘 마무리 하고 기획안이 통과되어 몇일있으면 디자인 부서에서 시안나오고나서앞으로 4개월동안 제가 무엇을 또 해야 할지 앞으로 막막하네요. 기획자로서의 역할 및 어떠한 것들을 챙기고 협의하고 해야 하는지 궁금합니다.
안녕하세요. 최근 바쁜 일이 있어서 이제서야 답변을 남겨드리네요.
그런데 경력이 15년이나 되시는 선배님한테 제가 조언을 해드릴 수 있기나 한지 모르겠네요.
그럼에도 불구하고 감히 저의 개인적인 생각을 말씀드리자면….
첫째로 실무자들끼리 기획에 대한 이해가 제대로 되었는지 확인하는 과정이 필요한 듯 합니다.
즉, 이 기능이 왜 필요한지…어떤 의도로 기획이 되었는지 등에 대해서 서로 동일한 이해가 되었는지 확인이 필요한 것이죠.
이런 이해가 일치하지 않으면 앞으로 이슈가 생길 때마다 의견이 통일되지 않더라고요…
따라서 실무자들에게 기획서 뿐만 아니라 기획의도도 제대로 전달되었는지 확인이 먼저 필요할 것 같습니다.
둘째로 위 사항에 대한 연장선상으로 정기적인 중간 체크 일정을 공식적으로 언급해서 모두가 진행상황을 알도록 해야 합니다.
여기에서 중요한 것은 사전에 공식적으로 언급을 하는 것입니다. 그래야 작업자들이 기획자에게 검토받는 다는 이상한(?) 생각을 하지 않고 진행과정을 공유하게 되며 기획자도 제대로 작업이 진행되고 있는지 합리적으로 체크할 수 있습니다.
그리고 디자인 시안이 나오면…
기획자가 디자인에 대해서 나름대로의 판단을 하고 디자이너와 의사소통을 하게 되는데요…
이 과정에서 2가지의 확인사항이 필요합니다.
– 이 서비스에서 UI를 판단할 때 중요시 되는 기준은 무엇인가?
– 디자이너는 어떤 레퍼런스를 참고하여 어떤 근거로 디자인의 컨셉을 잡았는가?
위 2가지에 있어서 서로간의 합의가 있어야 불필요한 논쟁을 피할 수 있더라고요…
이상 제 이야기가 도움이 되었는지 잘 모르겠네요.
선배님한테 이런 이야기를 하니까 부끄럽습니다.
혹시 도움이 필요하시면 언제라도 다시 연락주시고요~
안녕하세요. 최근 바쁜 일이 있어서 이제서야 답변을 남겨드리네요.
그런데 경력이 15년이나 되시는 선배님한테 제가 조언을 해드릴 수 있기나 한지 모르겠네요.
그럼에도 불구하고 감히 저의 개인적인 생각을 말씀드리자면….
첫째로 실무자들끼리 기획에 대한 이해가 제대로 되었는지 확인하는 과정이 필요한 듯 합니다.
즉, 이 기능이 왜 필요한지…어떤 의도로 기획이 되었는지 등에 대해서 서로 동일한 이해가 되었는지 확인이 필요한 것이죠.
이런 이해가 일치하지 않으면 앞으로 이슈가 생길 때마다 의견이 통일되지 않더라고요…
따라서 실무자들에게 기획서 뿐만 아니라 기획의도도 제대로 전달되었는지 확인이 먼저 필요할 것 같습니다.
둘째로 위 사항에 대한 연장선상으로 정기적인 중간 체크 일정을 공식적으로 언급해서 모두가 진행상황을 알도록 해야 합니다.
여기에서 중요한 것은 사전에 공식적으로 언급을 하는 것입니다. 그래야 작업자들이 기획자에게 검토받는 다는 이상한(?) 생각을 하지 않고 진행과정을 공유하게 되며 기획자도 제대로 작업이 진행되고 있는지 합리적으로 체크할 수 있습니다.
그리고 디자인 시안이 나오면…
기획자가 디자인에 대해서 나름대로의 판단을 하고 디자이너와 의사소통을 하게 되는데요…
이 과정에서 2가지의 확인사항이 필요합니다.
– 이 서비스에서 UI를 판단할 때 중요시 되는 기준은 무엇인가?
– 디자이너는 어떤 레퍼런스를 참고하여 어떤 근거로 디자인의 컨셉을 잡았는가?
위 2가지에 있어서 서로간의 합의가 있어야 불필요한 논쟁을 피할 수 있더라고요…
이상 제 이야기가 도움이 되었는지 잘 모르겠네요.
선배님한테 이런 이야기를 하니까 부끄럽습니다.
혹시 도움이 필요하시면 언제라도 다시 연락주시고요~
조언 감사드립니다. 간혹 이것저것 묻더라도 알려주시면 성실히 받아드리겠습니다^^
한주도 행복하세요…^^