기획자와 기획 리뷰
[기획 리뷰: 기획자가 자신이 기획한 내용을 개발자/디자이너/사업부서에게 공식적으로 설명하는 행위을 기획리뷰라고 합니다.]
2015년 초에 처음으로 기획 리뷰를 하는 시간을 가졌습니다. 결과는 제 생각과 매우 달랐습니다. 저는 당연히 참여자가 제가 리뷰를 하려는 주제에 대해서 어느 정도 알고 있으리라 생각하고 리뷰를 진행했는데 실상은 그러지 못했습니다. 오히려 다들 자기 업무를 하다가 완전히 새로운 내용을 접한 듯한 표정을 하고 있었습니다. 그런 와중에 수많은 의제들을 주입식으로 전달하고 마지막에 서비스 과금 정책까지 얘기해버리니 어떤 식으로 코멘트를 해야 할지 대략 난감했을 겁니다. 리뷰 주제에 대해서 한 번쯤 미리 생각을 해봐야 좋다, 나쁘다, 어떤 부분이 문제가 있다고 말을 할 수가 있는데 처음 생각해본 주제에 대해서 기획자가 1부터 10까지 다 자신만의 논리로 설명을 해버리니 거부감만 들고 건설적인 코멘트도 하기 힘들었겠죠.
그날 이후로 수많은 기획 리뷰를 하게 되었고 확실히 지금은 처음의 ‘삽질’ 기획 리뷰 때보다 좀 더 ‘의미 있고’ ‘건설적인’ 기획 리뷰를 할 수 있게 되었습니다.
그럼 지금부터 이커머스 사이트 내 상품 목록 정렬 방식으로 ‘자사 랭킹’ 정렬 방식을 새로 도입하는 안건에 대해서 기획 리뷰 회의를 진행한다고 가정하고 리뷰에 대해서 설명드려보도록 하겠습니다.
(자사 랭킹 정렬: 각 쇼핑몰이 본인들만의 기준으로 상품 목록 순서를 정렬하는 것. 쿠팡, 네이버 쇼핑 등의 서비스를 이용해보시면 쿠팡 랭킹, 네이버 쇼핑 랭킹 등이 있는 것을 확인하실 수 있습니다.)
1. 기획서 준비
리뷰를 하기 전 기획서가 준비가 되어 있어야 발표를 할 수 있겠죠. 이때 기획서는 너무 공들인 기획서를 만들기보다는 역시 MVP(최소 존속 제품, 수정의 여지를 열어 둔 기획서) 정도로 준비해두는 것이 좋습니다. 기획자의 생각과 리뷰 참여자들의 생각이 상당히 다를 수도 있기 때문입니다. 어느 정도 반제품 정도의 기획안을 마련해둔 후 리뷰 참여자들의 피드백을 받아 최종 기획서를 완성하는 것이 좋습니다. 기획서에는 대략 아래와 같은 내용들이 담기게 될 겁니다.
- 랭킹 도입의 필요성
- 다른 대안은 없는지?
- 타사 정렬 방식에 대한 고찰
- 타사 랭킹 도입 시 고려 요건들
- 자사 랭킹 도입 시 고려할 요건들과 그 이유
- 대략적인 서비스 정책
- 정책 요건별 적용되는 공식
- 실제 주문 데이터를 기반으로 한 시뮬레이션 결과
- 구축 마일스톤
- 대략적인 와이어프레임
- 참조한 웹사이트, 앱 리스트
이때 와이어프레임의 경우 저는 대략적으로 프로토타이핑을 해서 준비해두는 편입니다. 이유는 잠시 뒤 설명드리도록 하겠습니다. 한편 리뷰 전 기획서를 만드는 도중 종종 유관부서 사람들과 구두 미팅을 통해 대략적으로 기획의 방향에 대한 설명을 해두는 것이 기획 ‘연착륙’을 위해서 좋습니다. 사람들은 처음 접하는 개념에 대해서 쉽게 거부감을 느끼기 마련입니다. 기획 리뷰 전 어느 정도의 공감대를 형성한 후에 리뷰에 임하게 된다면 리뷰 진행 자체를 훨씬 수월하게 풀어갈 수 있을 것입니다.
2. 기획 리뷰 공지
기획서가 대략적으로 완성되면 유관부서 사람들에게 ‘기획 리뷰’ 공지를 해야 합니다. 리뷰 참여자들의 가능 스케줄을 구두로 확인 후 공지 메일을 보내도록 합니다. 메일에는 아래와 같은 내용들이 담겨 있어야 합니다.
- 회의 목적: 무슨 얘기를 할 것인지, 어떤 의사결정을 할 것인지
(예: 랭킹 시스템 소개, 피드백 청취, 일정 협의 등)
- 일시
- 장소
- 참석 요청 인원
- 기획서 초안
기획서는 반드시 첨부되어 있어야 합니다. 또한 꼭 기획서를 확인해줄 것을 요청해야 합니다. 어느 정도 기획에 대한 선 이해를 하고 리뷰 회의에 참여해야 건설적인 회의가 가능해지기 때문입니다. 기획을 처음 시작하는 사람들이 가장 실수를 많이 하는 부분이 바로 이 ‘공지’ 부분입니다. 기획 리뷰 시작 전에 내 기획을 선 공개하지 않아 리뷰 도중에 기획안에 대한 공격을 받는 경우가 종종 있습니다. 반드시 선 공개하여 참여자들이 기획의 전체적인 내용에 대해 숙지할 수 있도록 합니다.
3. 기획 리뷰 시작
시간이 되면 회의실에 사람들이 하나 둘 모이기 시작합니다. 참석자가 모두 도착하면 회의를 시작하게 되는데요. 이때 반드시 오늘 회의는 어떤 회의이고, 무슨 내용들을 소개할 것이며, 어떤 의사결정들이 필요한지에 대해서 한번 짚고 회의를 시작해야 합니다. (회의 목적, 안건, 의사 결정 필요사항) 처음에 중심을 잡고 시작해야 회의 참여자들이 좀 더 건설적인 코멘트, 참여 스탠스를 보여줄 수 있습니다.
이제 본론으로 넘어가서 왜 도입이 필요한지, 도입의 기대효과는 무엇인지, 다른 대안은 없는 건지, 타사의 경우는 어떻고, 정책 및 정책 시뮬레이션 결과는 어땠는지 등 준비한 기획안의 내용을 풀어서 참여자들에게 설명한 후 마지막으로 와이어프레임을 설명합니다.
서두에 잠시 언급했듯이 저는 이때 와이어프레임으로 간단한 프로토타입을 준비해 가는 편입니다. ppt로 만들어진 와이어프레임의 경우 참여자가 한 번에 머릿속에 해당 와이어프레임에 대한 그림을 그리기가 쉽지 않습니다. 프로토타입으로 실사와 유사한 페이지 및 간단한 인터렉션 등을 구현해서 보여주면 개발자/디자이너/실무 관계자 할 것 없이 빠르게 기획을 이해할 수 있습니다. 당연히 몰이해에 따른 비건설적인 피드백이 나올 확률도 줄여주겠죠. 이것이 프로토타입의 장점 중 하나입니다. 커뮤니케이션 비용을 줄여주는 것이죠. 좀 더 자세한 내용은 ‘ppt로 쓰는 기획서 정답일까요?’ 편에서 설명드리도록 하겠습니다.
4. 기획 리뷰 피드백받기
대략적인 설명이 끝났으면, 회의 참석자들에게 피드백을 요청합니다. 참여자들이 본인들의 관점에서 피드백을 해주기 시작할 것입니다. 일단은 ‘오픈 스탠스’로 듣는 것이 중요합니다. 기획자의 의견과 다르다고 하더라도 일단 의견을 끝까지 들어봅니다. 그리고 피드백 제공자의 의견을 정확히 이해했다는 의사표현을 해 줍니다.
이 부분이 굉장히 중요합니다. 분명히 피드백 중에 의미 있는 피드백도 있을 것이고, 그렇지 않은 피드백도 있을 것입니다. 이때 좋은 피드백은 반영하여 기획안에 보충하면 되고 그렇지 않은 피드백 같은 경우는 충분히 듣고 이해하고 공감해준 후, 리뷰 자리에서는 구체적으로 반박하지 않습니다. 의견을 낸 사람이 바로 반박을 받게 되면 다분히 감정싸움으로 번질 수 있기 때문입니다.
이 피드백은 아니다 싶을 때는 ‘한번 고려해보겠습니다’ 스킬을 사용합니다. 그리고 나중에 기획안 완성 후 해당 피드백의 내용은 넌지시 빼버리는 식이죠. (요령이 필요합니다.) 피드백을 해 준 사람도 일단 본인의 의견이 접수되었기 때문에 집요하게 해당 기획안에 대해서 태클을 거는 경우는 많지 않습니다. 본인의 의견을 기획자가 충분히 이해하고 공감했음에도 반영되지 않은 부분에 대해서 묻는 경우가 생기면 기획자가 나름의 설명을 하여 부드럽게 넘기도록 합니다. 기획자에게 찾아와서 그 피드백 내용은 어떻게 된 것이냐고 물어보면, 그 당시 피드백을 받고 이런저런 고민을 해본 결과 이런저런 이유로 현재 상황에서는 조금 더 신중하게 접근하기로 했다고 이야기를 해주는 식입니다. (다시 말씀드리지만 굉장한 요령이 필요합니다. 잘못사용하면 큰 싸움으로 번질 수도 있습니다.)
리뷰 과정 자체는 기획자의 의견을 ‘관철시키고 설득하는 프로세스’입니다. 그 와중에 의미 있는 피드백과 그렇지 않은 피드백을 잘 가리는 것도 기획자의 역할입니다.
5. 기획 리뷰 마무리
이제 피드백까지 다 받았으면, 기획자는 금일 회의에 대해서 다시 한번 정리합니다. 오늘 어떤 내용을 설명했고 어떤 이슈들이 있었는지, 그리고 앞으로 어떤 일들을 어떤 스케줄로 할 것인지 대략적으로 정리한 후 회의를 마치게 됩니다.
6. (필요한 경우) 회의록 송부
회의록 송부는 반드시 필요한 부분이라고도 할 수 있지만 잦은 리뷰 환경 속에서 매번 회의록을 공유하기 어려울 때가 있습니다. 하지만 많은 사람들의 ‘액션플랜’이 요구되는 때에는 회의 내용을 정리해서 유관자들에게 공유하는 것이 좋습니다.
- 회의 안건
- 각 팀 의견
- 향후 액션 플랜 (누가 무엇을 어떤 스케줄로 할 것인지)
등을 간단하게 정리해 회의 참석자들에게 공유합니다.
7. (필요한 경우) 2차 리뷰
회의가 무난하게 종료되고 몇몇 보충할 부분만 남았다면 기획자가 자체적으로 기획서 완성 후 개발 요청을 하면 됩니다. 하지만 아직 의견 조율할 부분이 남아 있다면 1차 리뷰 때 나왔던 이슈들을 정리하여 다시 한번 회의를 진행해야 합니다.
결국 리뷰도 ‘밀고 당기기’ 싸움입니다. 내가 원하는 것을 어떻게 얻어내고 또 상대방이 필요한 부분을 얼마나 내줄지를 조율해 내야 합니다. 물론 회사의 미션에 맞는 의사결정임을 전제로 말이죠. 기획 리뷰를 자주 하시다 보면 결국 이 리뷰라는 행위가 기획의 꽃이라는 것을 아시게 될 겁니다. 해당 회의의 ‘주관자’로서 많은 사람들 앞에서 논리적으로 내 기획을 설명하고 일을 추진해나가는 경험은 누구나 할 수 있는 경험이 아닙니다. 많은 사람들 앞에서 끝내주는 기획 리뷰를 성공시켰을 때 느낄 수 있는 카타르시스는 경험해본 사람만이 알 수 있죠. 사람들로부터 좋은 공감을 이끌어 내어 성공적인 리뷰를 하길 응원합니다.
다음 시간에는 ppt와 기획서에 대해서 한번 이야기해보도록 하겠습니다.
읽어주셔서 감사합니다.
