기획을 처음 시작하는 사람에게 건네는 기본기

 

기획 일을 시작한 분들에게서 "무엇부터 공부하면 좋을까요" 하는 질문을 가끔 받습니다.
저도 처음에는 툴 사용법이나 유행하는 방법론부터 찾아봤는데, 시간이 지나고 보니 오래 남는 건 기본기 몇 가지였어요.
그래서 오늘은 제가 이 일을 하면서 점점 중요하게 여기게 된 기본기를 네 가지로 정리해 봤습니다.
정답이라기보다 지금까지의 경험에서 나온 개인적인 순서라고 생각해 주세요.

 

첫째, 문제를 먼저 정의하기

초보 기획자가 가장 자주 하는 실수는 해결책부터 말하는 것입니다.
"이런 기능을 넣으면 좋겠어요" 하고 출발하면, 그 기능이 어떤 문제를 풀려는지 아무도 설명하지 못하는 순간이 옵니다.

저는 일을 시작할 때 세 줄을 적어 봅니다.
지금 무엇이 문제인가.
누가 그 문제를 겪고 있는가.
문제가 해결되면 무엇이 달라지는가.

가정 예시를 들어 볼게요.
"앱에 알림 기능을 추가하자"는 요청이 들어왔다고 해 보죠.
그 뒤에는 "신청한 사람이 일정을 자주 잊어서 당일에 오지 않는다"는 문제가 숨어 있을 수 있습니다.
문제를 이렇게 적고 나면 알림 외에 일정 확인 화면이나 사전 안내 메시지 같은 다른 해법도 비교해 볼 수 있어요.
문제가 정의되어 있어야 해결책을 고를 기준이 생깁니다.

문제가 정의되지 않은 상태에서는 아무리 열심히 만들어도 평가 기준이 없습니다.
일이 끝난 뒤에 잘했는지 못했는지 판단하려면 처음에 적어 둔 "달라질 모습"이 있어야 하거든요.

 

둘째, 사용자를 구체적으로 떠올리기

"사용자"라는 단어는 편하지만 너무 넓습니다.
20대와 50대, 처음 쓰는 사람과 매일 쓰는 사람은 같은 화면을 전혀 다르게 씁니다.
그래서 누구를 위한 기획인지 한두 명의 구체적인 모습으로 그려 보는 연습을 했어요.

예를 들어 "퇴근 후 지하철에서 한 손으로 예약하려는 직장인"이라고 적어 보는 겁니다.
이렇게 쓰면 한 손으로 누르기 쉬운 위치인지, 좁은 시간 안에 끝나는 흐름인지 같은 질문이 저절로 따라 나옵니다.
실제 사용자의 이야기를 직접 들을 수 있다면 더 좋고, 그게 어려우면 고객 문의나 후기를 읽는 것만으로도 시작은 됩니다.
다만 소수의 의견을 전체로 일반화하지 않도록 조심해야 해요.

 

셋째, 문서는 읽는 사람을 위해 쓰기

기획서는 내가 생각을 정리하는 용도이면서 동시에 다른 사람이 일하는 기준이 되는 문서입니다.
쓰는 사람 입장에서는 다 아는 내용이라 빼먹기 쉬운데, 읽는 사람은 모르는 것이 많아요.

몇 가지 원칙을 지키려고 합니다.
맨 앞에 목적과 범위를 먼저 쓴다.
용어는 한 가지만 쓰고 필요하면 정의를 붙인다.
정상 흐름만 쓰지 않고 예외와 오류 상황도 같이 쓴다.
바뀐 내용은 이력으로 남긴다.

그리고 문서를 쓴 뒤에는 한 번 소리 내어 읽어 보거나, 개발자의 눈으로 훑어봅니다.
"이 문장대로 만들면 어떻게 되지"를 상상하면 모호한 부분이 금방 보여요.
문서의 분량보다 읽고 나서 질문이 얼마나 줄어드는지가 더 중요하다고 느낍니다.

예를 들어 환불 정책을 문서로 쓴다고 가정해 볼게요.
저에게는 당연한 "사용 전 환불 가능"이라는 문장도, 읽는 사람은 "사용 전이 언제부터인지", "부분 사용은 어떻게 되는지"를 물을 수 있습니다.
이 질문들을 미리 문서에 답해 두면 되묻는 시간이 줄고, 그 시간만큼 다른 일에 쓸 수 있어요.

 

넷째, 커뮤니케이션은 습관으로

기획자는 직접 무언가를 만들기보다 사람들 사이에서 일을 굴리는 역할이라, 커뮤니케이션이 곧 실력이 됩니다.
다만 말을 잘하는 것보다 확인을 습관화하는 쪽이 더 효과가 있었어요.

예를 들어 개발자에게 요청을 전달할 때는 요청 내용을 내 말로 한 번 되물어 달라고 부탁합니다.
"그러니까 이렇게 이해했는데 맞나요" 하는 확인 한 번이 며칠짜리 재작업을 막아 주는 일이 많았습니다.
이견이 생기면 사람을 향하지 않고 문제를 향해 이야기하려고 합니다.
"누가 틀렸나"가 아니라 "무엇이 우리의 목표인가"로 돌아가면 대화가 풀리는 경우가 많았어요.

일정이나 범위가 흔들릴 때는 숨기지 말고 빨리 알립니다.
나쁜 소식도 일찍 공유하면 선택지가 남아 있지만, 늦으면 줄어듭니다.

회의 후 정리도 같은 맥락입니다.
결정된 것과 해야 할 일을 짧게 보내 두면, 회의에 없던 사람도 같은 정보를 갖게 돼요.
이런 작은 공유가 쌓일수록 "기획자가 알려 주겠지"가 아니라 "기획자에게 물으면 확실하다"는 신뢰가 만들어집니다.

 

 

네 가지를 한 줄로 줄이면 "무엇이 문제인지 알고, 누구의 문제인지 알고, 그것을 다른 사람이 이해하게 쓰고, 계속 확인하며 일한다"입니다.
화려한 방법론은 이 위에 쌓을 때 비로소 힘을 낸다고 생각해요.

처음 시작하는 분께는 한 가지 연습을 권하고 싶어요.
지금 쓰는 서비스 하나를 골라 화면 하나를 보면서 "이 화면이 풀려는 문제는 무엇인가, 누구를 위한 것인가"를 세 줄로 적어 보는 겁니다.

정답이 있는 연습은 아니지만, 열 번쯤 해 보면 기획 요청을 받았을 때 질문하는 방식이 달라집니다.

아직 제게도 남은 질문이 있습니다.
기본기는 연습으로 늘어나는데, 실무에서는 연습할 시간이 따로 없다는 점이 늘 고민입니다.
작은 일 하나에서라도 문제 정의 세 줄을 적어 보는 것으로, 일단 오늘부터 다시 시작해 보려고 합니다.