brunch

You can make anything
by writing

C.S.Lewis

by zabiss May 03. 2018

1.3 기획자 무엇을 해야 하는가

기획자의 포지셔닝과 역할 그리고 주요업무는 무엇인지 살펴보자

<기획자 포지셔닝>

PM/기획자/디자이너/퍼블리셔/프로그래머 모두 마찬가지의 포지셔닝으로 표현이 가능하겠으나, 기획은 프로젝트 구현의 시작(화면UI설계서)이기에 가장 중심에 있다고 말할 수 있다.


클라이언트를 포함하여 PM/디자이너/퍼블리셔/프로그래머의 중간에서 상호간 커뮤니케이션의 주체가 되며, 교두보 역할을 하는 것이 현실이다. 좀 더 명확히 말하면 클라이언트의 요구사항을 디자인하고 퍼블리싱하고 프로그래밍 하는데 필요한 문서화 업무 및 의사결정을 하는 즉, 중계인 역할을 하는 것이 기획자라고 볼 수 있다.


Communication

유능한 중계인이 되기 위해서 내가 가장 중요하게 생각하는 능력은 바로 '커뮤니케이션'이다.

같은 상황에서도 커뮤니케이션을 얼마나 잘 해서 양측이 만족할만한 의사결정을 이끌어 내는지가 매우 중요할때가 많다. 화면UI를 설계하고 기능을 정의함에 있어 사용자에게는 보다 나은 사용성을 제공하고, 공급자에게는 보다 나은 운영환경을 제공하며 그것을 구현하는 디자이너/퍼블리셔/프로그래머에게 주어진 환경(일정, 업무스킬 등)에서 최적의 퍼포먼스를 이끌어 내는 것 또한 커뮤니케이션에 달려 있다고 본다.


가끔 디자이너/퍼블리셔/프로그래머에게 기획자는 '나한테 일을 시키는 사람'으로 인식된다. 중계인의 역할에서 클라이언트쪽으로 약간만 기울어져도 그런 기획자로 정의되어 버린다. 반대로 가끔은 클라이언트에게 '일하기 싫어하는 부정적인 사람'으로 인식된다. 중심에서 이해와 설득의 균형을 잘 잡아서 커뮤니케이션을 해야 모두에게 주어진 환경에서 최고의 결과물을 만들어 낼 수 있다 생각한다.


Architecture

정보구조/화면UI 설계와 기능정의를 비롯한 기획자 실무이다. 기획자는 현재의 단면만을 보고 설계를 해서는 안된다. 본 사업의 목적을 항시 리마인드하고 명확한 요구사항을 바탕으로 확장성 있는 설계안을 만들어 내야만 한다. 즉, 요구사항을 충족하기 위해 고려되어야 할 다양한 경우의 수를 고려해야만 한다.

처음부터 다양한 경우의 수를 모두 고려하기는 불가능하다. 다양한 경험이 기반이 되어야만 기획은 물론 디자인/퍼블리싱/프로그래밍까지의 고려되어야 할 사항을 정의할 수 있다.


Paper work

처음 기획에 입문하게 되면 가장 어려워 하는 것이 문서작업이다. 도데체 문서를 만들라고 하는데 뭘 알아야 만들것인데 말이다. 샘플을 찾고 분노의 구글링을 한다. 사수들에게 샘플 문서를 받아서하면 좋겠으나 사수도 없다면 암울하다. 샘플있다고 해도 그 문서를 이해하고 내것으로 만들기 또한 쉽지 않다.

기획 실무 강의를 하면서 나는 커뮤니케이션과 설계의 방법을 강조하지만 당장 필요한 샘플 문서 받고자 하는 니즈가 강렬하다. 이해는 하지만, 그것이 결코 근본적인 숙제를 해결해 주지는 않는다.

문서를 왜 만드는가? 그 또한 그 문서를 공유하는 모든 관계자들과 커뮤니케이션 하기 위해서 만드는 것이다. 구두로 하는 커뮤니케이션보다 프로젝트에서는 문서를 통한 커뮤니케이션이 더 많기에 문서를 만들때도 무엇을 어떻게 커뮤니케이션 하는 것이 가장 효과적인지를 고민해서 만들어야만 한다.



nonem briefing

문서 또한 커뮤니케이션을 위해 만든다 했다. 가장 많이 공유되는 화면UI설계서(스토리보드)는 누구와 어떠한 커뮤니케이션을 하기 위해서 만드는 문서일까? 디자이너는 화면을 디자인하기 위한 컨텐츠 및 UI요소를 확인하고, 퍼블리셔는 화면구조 및 인터렉션을 프로그래머는 케이스별 기능정의 및 화면전환과 데이터출력 정보를 커뮤니케이션 하기 위해서 화면UI설계서를 보게 될 것이다. 그렇다면 기획자는 설계서를 어떻게 만들어야 할지 고민이 조금은 쉬워지고 명확해 지지 않을까?

다른 문서도 마찬가지이다. 정보구조도, 기능정의서, 화면명세서, WBS, 분석결과서, 회의록 등 기획자가 만들어 내는 모든 문서 산출물은 누구와 어떠한 커뮤니케이션을 하기 위해서 만드는지에 대한 고민을 먼저 해보길 바란다. 또한 정규 산물이 아니더라도 커뮤니케이션에 이슈가 생긴다면 이슈를 해결하기 위한 비정규 산출물 문서를 만들어 보는 것도 좋은 커뮤니케이션 능력을 가지고 있는 기획자라 생각한다.





<기획자 마인드>


선임 기획자로서 후배님들에게 늘 강조하는 기획자의 마인드 3가지가 있다. 나 또한 기획자로서 최선을 다해서 우선하여 지키려고 늘 리마인드하고 노력한다. 기획자로 계속 일을 할거라면...


일정준수는 꼭 기획이 아니더라도 사회생활을 하고 조직생활을 하는데 있어서 꼭 필요한 약속이라고 생각한다. 경험을 바탕으로 해야할 업무에 대한 일정을 수립하는 기획자로서 납기준수는 프로의 약속이다.

우리가 하는 프로젝트는 정해진 기간이 항상 있다. 학업을 배우는 과정이 아니다. 정해진 기간 내 목표를 두고 해 낼 수 있는 방안을 고민하는 전문가라는 것을 잊어서는 안된다. 

일정준수를 위해서 최소한의 본인 스케쥴관리 정도는 철저히 습관해 되길 바란다. 아주 작은 시간약속이라도 지키려 스스로 약속하지 않는다면 과연 프로젝트의 일정을 관리할 수 있는 능력이 될까?


어떻게 보다는 왜를 먼저 생각하길 바란다. 근본적인 문제의 이유를 이해해야 보다 최적화된 방법을 찾아낼 수 있다고 생각한다. 무엇을 어떻게는 왜에 대한 충분한 이해가 없이는 근본적인 문제를 풀기에 오류를 범하기 쉽다. 미션이 주어지면 이유를 먼저 생각해보고 누구나 아는 일반적인 이유라 해도 내가 아는 이유가 맞는지를 항상 확인을 해야 한다. 당신과 일을 하는 모든 사람이 똑같은 생각을 가지고 있을거라는 기대를 버려야한다.


나무를 보지 말고 숲을 봐야 한다는 뻔한 말이다. 기획자가 당장의 솔루션만 생각하고 그로 인해 발생하는 사이드이팩트를 고려하지 않고 설계를 했을 경우 간혹 데미지가 상당할 경우가 있다. 물론 기획자만이 사이드이팩트를 모두 고려할 수는 없지만 경험으로 알게된 이슈에 대해서 최소한 재발은 있어서는 안될 것이다.

간혹 기획자가 설계한 안을 디자인/퍼블리싱/프로그래머들에게 리뷰하게 되면 다양한 딴지의 향연이 벌어진다. 마이너한 딴지들도 있겠으나 기획에서도 놓친 경우의 수가 나오는 경우가 많다.

숲을 보지 못하면 기획PL이나 PM으로 성장하기 어려운 것이 사실이다.



 nonem briefing

기획자는 PM과 기술영업의 포지셔닝을 목표로 업무를 배워 나가야한다. 혹자는 끝까지 화면UI설계 업무만 하고 싶다고 하지만 어느 시점이 되면 나보다 경력도 나이도 많은 PA를 두고 일하고 싶어하는 PL/PM은 없을 것이다. 프로젝트를 수행하면서 기획업무도 중요하지만 발생한 이슈를 어떻게 해결하는지 PM의 커뮤니케이션이나 행동을 잘 봐두길 바란다. 나중에 PM으로의 경험치를 쌓을 시간이 기획PA/PL과 달리 없을 때가 많다.

즉, 바로 PM으로 R&R이 주어질 경우도 많고 실패에 따른 기회를 또 부여받기도 쉽지 않은 포지셔닝이다.

난 개인적으로 기획자로 성장해서 유능한 PM이 되기 위해서는 최선을 다해서 다양한 PM들과 업무를 해보야 한다고 생각한다. 그러고 보니 난 운이 좋게도 수행한 프로젝트에서 PM으로 두번 모신분이 없는 것 같다.




매거진의 이전글 1.2 프로젝트 누가 진행하는가
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari