잘 통과 되는 제안서 쓰는 몇가지 뻔한 요령

안녕하세요. 뻔한 이야기만 하는 게임기획자 주민석 입니다.

게임디자이너부터 프로젝트매니저, 프로듀서의 업무까지 다양하게 경험하다 보니 여러 상황에서 다양한 사람들에게 제안을 해왔습니다. 그러다 보니 제안서를 쓰는 나만의 규칙도 생기고 제안이 잘 먹히려면 어떻게 해야 하는지 나름의 요령도 갖추게 되었습니다. 

그래서 오늘 말씀 드리고자 하는 것은 제안서를 쓸 때 생각해야 할 가장 핵심적인 부분, 제안서가 제안 받는 사람들에게 잘 통하기 위한 요령에 대해서 입니다. 제안서의 목차나 기술적인 부분보다는 아주 뻔하고, 귀 따갑게 듣는 정론적인 내용입니다. 게임개발포에버에 필자 참여하고 첫글이니 너그럽게 봐주세요. ^^

 

1.

제안서에서 가장 중요하고 명확하게 표현 되야 할 것은 이 제안을 통해 제안 받는 사람이 무엇을 얻는가, 제안 하는 사람은 무엇을 얻는가 입니다. 만약, 당신의 제안이 

1) 당신이 원하는 것이지만, 제안 받는 사람이 원하는 것이 없다면 : 제안 드롭 2) 당신이 원하는 것도 아니고, 제안 받는 사람이 원하는 것도 아니라면 : 그냥 뻘짓 3) 당신이 원하는 것이 아니지만, 제안 받는 사람이 원하는 것이라면 : 고난 시작

이죠. 1)번의 경우는 별 문제가 없습니다. 다시 제안을 하면 됩니다. 문제가 되는 경우는 3)번 입니다. 이렇게 통과 된 제안이 당신의 프로젝트가 되면 이 것을 진행하는 동안 '도대체 왜 이런 일을 해야 하지?' 하는 고민을 수백번도 더하게 됩니다.

그래서 제안은 당신이 원하는 일을 하면서, 제안 받는 사람이 원하는 것을 충족시켜 주는 것이어야 합니다. 하지만 현실이 언제나 이상적이지만은 않더군요. 우리가 원하는 제안은 항상 제안 받는 사람이 원하는 것과 충돌해서 드롭 되기 일수고 우리가 원하지 않은 제안이 통과 되어 고난이 시작 되는 경우가 많습니다. 저도 그런 경험을 많이 했고, 아마 앞으로도 계속 이런 경험을 하게 되겠지요. (T,.T)

그래서 최선은 내가 원하는 것과 제안 받는 사람이 원하는 것이 일치하는 것이지만 이런 경우가 결코 흔하지 않습니다. 그래서 이 제안이 실행 됨으로 제안 받는 사람도 원하는 것을 달성하고 그 과정을 통해 내가 원하는 것도 달성하는 방법을 찾는 것이 차선입니다. 그렇게 되기 위해 내가 원하는 것과 제안 받는 사람이 원하는 것에 대해 심층적으로 고민해야 합니다.

 

2.

여기 제안이 고난이 되는 아주 많은 오해 중 하나가 있습니다. 제안 받는 사람(주로 경영진)에 대해 '그들은 돈 잘 버는 것에만 관심이 있을거야.' 하는 것이죠. 앞서 말했 듯이 윈윈하려면 상대가 원하는 것에 대한 심층적인 고찰이 필요한데, '경영진 = 돈을 버는 것이 목적인 사람'으로 성급하게 결론 내리는 경우입니다. 비슷한 오해로는 '경영진은 일정 단축해주면 무조건 좋아할꺼야.' 하는 것도 있습니다.

제안을 받는 사람들은 사람마다 각각 다른 사고 과정을 거쳐 제안에 대해 결정을 하게 됩니다. 어떤 경영자는 정말로 '돈을 잘 벌 것 같은가'를 우선해서 평가하기도 하지만, 어떤 경영자는 이 제안을 실행해서 우리 조직이 어떻게 변화할 것인가를 우선해서 고민하기도 합니다. 논리적인 경영자는 제안의 결과에 따른 손익을 분석하고, 충동적인 경영자는 즉흥적인 직관으로 결정을 합니다. 정치적인 경영자는 이 제안이 부서나 직원 간 어떤 이해관계를 가지는지에 대해서 고민하고 결정합니다. 같은 경영자라도 저번에는 논리적으로, 이번에는 충동적으로, 다음에는 정치적으로 결정할지 모릅니다. 이건 일관성의 문제가 아니라 사람이기 때문에 당연히 그렇습니다.

그래서 성공적인 제안이 되려면 제안 받는 사람의 성향, 가치관, 현재 관심사부터 제안을 통해 무엇을 원하는지에 대해 심도 깊은 고민과 이해가 필요합니다. 이를 알아내는 방법은 대화를 하는 것입니다. 혹시라도 제안을 결정하는 대표나 직장상사에게 제안서를 다 쓰기도 전에 제안에 대해 질문을 해도 되는지 걱정하시는 분이 있다면 걱정 말고 대화해보라고 말씀 드리고 싶습니다. 왜냐하면 그들은 당신의 일을 평가하는 것보다 당신이 올바르게 일하는 것이 더 중요한 사람들입니다. 당신이 구체적으로 질문해 오면 아마 거의 대부분 친절하게 대화에 임해줄 것이라고 99% 정도 확신합니다. (간혹 1% 정도 비정상적인 사람들도 있어요...)

당신의 제안을 받는 사람이 유명인이라면 인터넷 검색을 해보세요. 최근 인터뷰 기사는 그 사람이 평소 어떤 생각 혹은 가치관을 가지고 있는지 알아내는데 도움이 됩니다.

 

3.

제안서는 제안을 통해 무엇인가 행동을 하게끔 만드는 것이 목적입니다. 즉, 제안서에는 반드시 제안 받는 사람이 내려야 할 결정이 명확하게 담겨 있어야 합니다.

"추가적인 자금 투입을 승인해 주세요.", "일정이 3개월 더 필요 합니다.", "이런 아이디어를 추가하고자 합니다. 구현해봅시다."

제안의 목적이 분명하고 명확하게 구체적으로 제시 되어야 합니다. 그래서 제안 받는 사람이 어떤 결정을 내리도록 유도 해야 합니다. 명확한 목적이 없는 제안은 '생각해봅시다.' 하고 다른 바쁘고, 중요한 일들에 밀려 잊혀집니다. 제안이 행동으로 이어지게 만들기 위해서 제안 받는 사람에게 시간을 제한하는 것도 좋은 방법입니다. 문서로 제안서를 작성하여 이메일로 보냈다면 전화를 하거나 직접 찾아가 제안에 대해 확인하고 결론을 받아 내는 것도 좋습니다.

제안이 여러 사람을 대상으로 할 때에는 특히 구체적이어야 합니다. 서로 제안에 대한 결정을 미루기 때문입니다. 도움이 필요할 때 군중을 향해 "누가 좀 도와주세요." 하는 것보다 "거기 초록색 옷 입은 아저씨는 119에 전화해 주시고, 노란색 옷 입은 아줌마는 이 사람 좀 부축 해주세요." 하고 구체적으로 요청하는 것이 효과적인 것과 같은 이치입니다. 제안을 받는 그룹에서 정확하게 어떤 사람이 어떤 일을 해야 하는지 그룹의 최종책임자는 어떤 결정을 내려야 하는지 구체적으로 명시해야 합니다.

 

4.

제안서를 잘 쓰는 왕도는 역시 많이 써보고 많이 제안해 보는 것입니다. 그렇게 계속 제안이 쌓이다 보면 나만의 폼? 모듈? 서식 같은 것들이 생겨 납니다. 어떤 논리를 전개할 때 주로 쓰는 도해라든지, 어떤 상황에서 사용하는 슬라이드 마스터라든지, 시장 조사 자료를 수집하는 경로라든지, 어떤 주장을 전개하기 위한 논리적 흐름 같은 것들에 규칙이 생겨 납니다.

제가 요즘 제안서를 쓸 때 가장 고민하는 것은 제안에서 논리 전개의 흐름인데, 제 나름대로는 '제안서의 스토리텔링'이라고 부르고 있습니다. 예를 들어 신규 게임에 대해 사업 제안을 할 때 전통적으로 게임 개요, 콘텐츠 소개, 마케팅 계획, 개발계획 같은 큰 목차를 나누고 그 안에서 세부적인 목차를 나누어 작성하는 경우를 많이 보았습니다. 그런데 제 생각에 이 것은 읽는 사람 입장에서 전혀 흥미롭지가 않습니다. (물론 이런 문서가 필요 합니다. 제안이 아니라 정리 차원에서요.)

제안서는 누군가의 마음에 들어 실행이 결정 되는 것이 목적인 문서입니다. 무조건 흥미로워야 합니다. 문서 전체를 보았을 때 목차가 아니라 이야기가 보여야 합니다. 제안을 읽는 사람이 '내가 이 제안을 실행하면 이런 결과가 나오겠구나, 이런 이득이 생기겠구나.' 하는 내용이 이야기로 명쾌하게 보여져야 합니다.

PPT로 제안서를 작성했다면 여러 슬라이드 보기를 꼭 해 보세요. 전체적으로 어떤 흐름이 보이는지 확인 해 보세요. 목차에 따른 전개입니까. 하나의 이야기 입니까. 전체적으로 건조합니까. 아니면 흥미롭습니까. 특히 제안이 구두 설명이나 프레젠테이션 없이 이메일이나 문서로만 진행 되는 것이라면 더더욱 중요합니다.

보편적으로 딱딱해 보이는 제안서보다 재미있는 이야기 같아 보이는 제안서가 채택 될 가능성이 높습니다.

 

요점정리 1) 나도 좋고, 제안 받는 사람도 좋은 제안을 하자. 2) 제안 받는 사람이 결정을 내리는 동기를 파악하자. 3) 제안에 따른 결정, 실행에 대해 구체적으로 요청하자. 4) 제안서도 흥미롭게 읽을 수 있어야 한다. 땡~ 끝!

 

요즘 제가 가장 많이 하고 있는 제안은 '나랑 같이 스마트폰, 태블릿PC로 게임 만들어 보지 않을래요?' 하는 것인데 열번 시도하면 아홉번 정도 실패하고, 그 중에 성공한 한번도 구체적 단계에서 세번 중에 두번은 실패하는 것 같네요. 이런 제안을 같이 일했던 동료들에게 던져 보면서 항상 내가 지금 하고 있는 프로젝트를 어떻게 설명해야 개발자들이 참여하고 싶게끔 매력적으로 보이게 할까 고민을 합니다.

모든 일이 그렇겠지만 경력이 많아지고 직급이 올라갈 수록 업무의 범위가 컨셉추얼 해지고 정형적인 일도 비정형적으로 변해가고, 제안이 필요한 일의 양과 범위가 증가하게 되더군요. 그래서 어느 수준에 이르면 얼마나 성공적인 제안을 계속 할 수 있는가(일단 수행과 결과는 별개로...) 하는 점이 얼마나 좋은 리더인가의 잣대가 되는 것 같습니다.

오늘은 제안에 대한 총론적인 이야기들만 했는데 다음 번에는 제안서에서 많이 쓰이는 도해들을 정리해서 방출하도록 하겠습니다.

 

뻔한 이야기 읽어주셔서 고맙습니다.