by
Jan 07. 2020
이런 업무 요청도 기획자가 주도적으로 수행해야 하나요?
서비스가 B2C 비즈니스 Friendly 일 때 기획자에게 주어지는 일
기획자의 역할에 대해 JD (Job description)를 한 문장으로 정리해보자면
고객과 회사(사업부, 마케팅)의 요구와 아이디어를 영업, 마케팅, 운영, 최신 기술과 트렌드에 맞게
각각의 IT 유관 업무(DB, 디자인, 개발, 운영)가 원활히 수행될 수 있도록
기획 업무수행과 협업 부서 간의 협의ㆍ조정 및 프로젝트 관리 업무 등을 수행하는 직무로,
이를 위해 아이디어 제안/요구분석/요건 정의, IA(메뉴 트리)/스토리보드(화면 기획서) 제작, 디자인/개발 진행과정 검토, 최종 산출물 검수 및 오픈, 효과성 분석 및 개선과제 도출 등을 수행합니다.
라고 할 수 있습니다.
여기서 JIRA나 그룹웨어, 메일, 메신저 등으로 사업부서나 마케터, 고객이 서비스에 대한 요구와 아이디어를 어느 정도 정리한 요청을 해왔을 때, 제가 바라보는 관점이 있습니다.
해당 업무를 요청 하나를 만들기 위해서
업무 요청자가 들인 고민의 깊이와 기간을 우리는 문서만으로는 이해할 수 없다.
하지만 본인이 들인 시간 이상이
우리 IT부서도 들어간다는 사실도 요청자는 이해하기 어렵다.
요청내용이 의도를 10%만 담고 있다면, 나머지 90%는 상호 간의 신뢰를 바탕으로 하는 커뮤니케이션으로 밖에 풀 수가 없습니다.
데이터 중심이 아닌 상급자의 직관과 통찰에서 아이디어와 사업 아이템이 나오고, 인재에 지나치게 의존하면서, 기능 중심의 조직구성으로 업무가 요청되는 경우 중에서(워터폴방식), 오픈 일정이 촉박하거나 명확한 것이 하나도 없는 요청서로 인해 기획서 조차 그리기 어려운 상황이 올때가 있습니다. 문제제기를 하면 되려 반문을 받게 되죠.
이 정도 요청했으면 기획이 알아서 해줘야 하는 거 아닌가요? 제가 어디까지 해 드려야 하죠? (아.. 진짜 열불..)
앞길이 구만리인데 1, 2번 없이 3, 4번이 된다고 생각을.. 그리고 3~10번까지가 매우 빠르게 될 것이라고 생각도 하는.. 게다가 그런 요청을 함께 받은 디자이너와 개발자들은 "기획서 완성되면 그 문서로 다시 논의하시죠."라고 피드백을 주고요. (평소에는 사업부서가 사전에 커뮤니케이션 없어 불만이라고 하면서 말이죠. 다 그렇지는 않지만....)
결국 기획자에게 책임과 권한이 일임되는 상황이 벌어집니다. B2B 서비스는 고객 의뢰에 따라 견적도 내고 소프트웨어 노임단가 또는 확정된 수주금액 기준으로 비용이라도 받고 업무를 수행하지만, B2C의 경우는 서비스가 오픈하고 나서 성과를 의식적으로 분석하고 측정해야 파악이 가능합니다. 반면에 완료가 중요한 B2B서비스에 비해, 제작하는 과정에서 함께 아이디어를 내고, 정책을 수립하는 등 협업자들이 함께 뭔가 만들어 가기에는 좋은 업무이기도 합니다.
그 과정에서 요청자나 기획자가 함께 일하는 동료들에게 앞으로도 새로운 시도와 의견을 많이 낼 수 있도록 동기 부여할 수 부분은 (드라마틱하게 매출 신장이나 고객 확대가 되지 않았다면) 리텐션, MAU/DAU, 시나리오 설정 등 데이터 분석을 통해 성과가 난 부분에 대해서 공유하고 감사도 표현할 때입니다. (수행부서 또는 지원부서에 있는 많은 분들이 설문조사에서 몰입과 재미를 위해 필요성을 매년 어필하는 부분이기도 합니다.)
데이터 분석하는 방법 중에 구글 Analytics의 목표 설정에 따른 로그 분석은 다른 외부요인이 전혀 없다고 했을 때 시나리오대로 경로별 성과를 분석하는 방법을 씁니다. 대신, 경로에 따른 시나리오를 모두 등록해야 정확한 분석이 가능해지지요.
최초에 설계한 고객의 경험대로 성과를 측정하는 예시 이미지. 최근 어도비에서 나온 CX 기반의 Workspace User Flow를 사용하면 거꾸로 역추적이 가능합니다. 예를 들어 회원가입의 최종 결과를 가지고 이전 경로들이 무엇이었는지 명확하게 보여줍니다. 보다 성과를 내거나 실패한 이유를 더 명확히 알 수 있는 기반이 될 수 있겠지요.
<출처 : Adobe Analytics Youtube, https://www.youtube.com/ >아.. 얘기가 조금 옆길로 샜네요. 평소 기획팀장으로서 팀원들을 코칭하던 과정에서 많이 나온 얘기라.. 한번 말씀드려 봤습니다.
다시 주제로 돌아가서 "이런 업무 요청까지 잘 수행해야 하나요?"라는 질문에 대해 계속 얘기해볼까요?
우선 서비스 기획자의 직무를 여러 관점으로 정의해보면 좋을 것 같습니다. 아래 정의는 이견이 있을 여지는 있지만, 그만큼 "역량 높고 인정받는 기획자"는 다방면으로 본인의 직무, 커리어를 개발할 수 있을 거라는 제 개인적인 생각이 녹아 있습니다.
Product Manager (PM -프로젝트 매니저와는 다른 PM) : 구글, 어도비, 오라클 등 글로벌 기업의 채용공고에서 기획자와 유사하게 정의된 직무 중 하나입니다. 링크드인에서 찾아보시면 상세한 내용을 보실 수 있는데요. 우리가 통상 알고 있는 서비스 기획자의 역할에서 전문적으로 세분화되었다고 볼 수 있습니다. 그룹웨어나 인사시스템, 전자상거래 플랫폼 등 제품 관점의 서비스에 대해 각 기능을 설계하고, 이 기능들을 요구사항과 스토리보드 등 제반 문서와 커뮤니케이션을 통해 디자이너, 개발자와 공유하고 산출물을 관리하는 역할이라고 할 수 있습니다.
Business Developer (BD) : 기획업무를 수행하면서, 마케팅, 영업, 홍보,전략 등 다양한 분야의 업무담당자들과 협업을 하게 되면서 새로운 사업에 대한 아이디어를 제안하고, 브랜드의 가치를 높일 수 있는 방안을 고민하고, IT 서비스가 제대로 론칭되도록 하기 위해 많은 부서들의 업무조율에 보다 비중이 높다면 BD 로서의 커리어를 생각해봐도 좋을 것 같습니다. 모호하지만 본인에게 확신이 있다면 도전적으로 실행해보는 데 있어서는 기획자만 한 인재도 없으니까요.
UI/UX 전문가 : 사용자가 보는 화면에 대한 기획은 사용자 인터페이스(UI) 중심, 애플리케이션(PC, 모바일)이 행동하는 방식을 설계하는 것이 사용자 경험(UX) 중심의 기획이라고 봅니다. UX 전문가라면 보이는 부분뿐 아니라 사용자의 경험이 백엔드 시스템 어디로 들어가는가까지도 볼 수 있어야 한다는 얘기죠. 개발자들과의 소통이 중요해지는 이유입니다.
Evangelist (에반젤리스트) : 회사나 시장에서 새롭게 나온 기술을 학습하고 개발자와 같은 전문가 그룹에 비전과 가치를 설명하고 무엇을 준비해야 하는 지를 알려주는 직무 정의입니다. 아울러 시장의 피드백을 내부 개발팀에 전달하여 제품이나 서비스가 개선되도록 돕는 역할도 수행합니다. 실제 고객을 만나거나 강연, 블로그 운영, 기고 등을 통해 본인 회사의 핵심기술을 알아듣기 좋게 소개하고 매력적으로 보이게 하는 부분은 실제 업무에 참여한 기획자가 가장 잘 설명할 것이라고 생각됩니다.
업무 요청자에게는 어려운 IT의 개념을 잘 설명해야 하고, IT 협업부서에는 고객의 모호한 요구사항을 구체적인 문서와 커뮤니케이션으로 의도한 산출물이 나오도록 하는데, 많은 노하우를 보유하고 있으니까요.
Cordnator (코디네이터) : 스마트하게 일하는 기획자의 공통점이 차별화된 역량을 보유하고, 소통과 협업에 능하며, 피드백을 잘한다는 공통점이 있습니다. 직무적인 정의라기보다는 기획자가 갖춰야 할 역할에 좀 더 초점이 맞춰진 얘기겠네요.
결국 IT기업에서 "일이 되게" 만드는 직무가
"서비스 기획자"라고 할 수 있습니다.
어느 날 아래와 같은 업무 요청이 왔습니다.
"OO 브랜드 메인 페이지 전면 개편 요청"
회원이 30만이 넘고, 매출이 50억이 넘어가는 중요한 사이트의 메인 페이지 개편이니 곧바로 가장 Best인 전담 기획자를 배정해서, 프로젝트 팀을 꾸려야겠다는 생각을 하게 되었습니다. 어떤 목표와 기대효과를 가지고, 어떤 정책을 변경하면서, AS-IS와 TO-BE를 그렸을지 기대하면서, 요청 문서를 보았는데요.
그런데 업무 요청 장표가 표지 포함 4장이 왔습니다.
기획안 만으로 페이지를 이어서, 개편 후 고객이 만날 사이트를 만들어보면
이대로 우리 브랜드 사이트의 메인이 제대로 개편될 수 있을까요?
기획자와 함께 이 문서를 검토하면서 월 기준 6만 명의 고객이 월 3~4억의 매출을 기록하고 있는 사이트의 메인에 대해, 주 고객층인 20~30대의 감성에 맞게 우리가 전략적으로 판매하는 상품으로의 접근이 용이하면서도, 고객이 수많은 상품 중에서 나에게 맞는 상품을 찾기 좋게 만들고, 매일 접속할 이유가 있는 무료 콘탠츠 제공을 통해 고객의 가입 전환율, 매출 전환율, 재방문율을 높이는 중요한 프로젝트라고 설명했지만, "이런 업무 요청까지 잘 수행해야 하나요?"라는 담당 기획자의 반문에 딱히 해줄 말을 찾지 못하겠더군요.
제 글 중 워터폴, 그로스 해킹, 애자일 내 공유된 파일 (IT 워터폴 방식 전체 업무 프로세스. ppt) 요청서 항목대로만 정리하고, 차라리 위와 같은 실제 모양을 그리지 않는 것이 더 좋았을 뻔한 요청이었습니다.
요청 할때의 기본 항목결국 이 프로젝트는 1개월여 기획 준비 및 프로토타입을 만들고 부가적인 화면과 서비스 설계까지 스토리보드 1.0을 찍는데 4개월이 걸렸고 100여장의 스토리보드와 함께 개발 완료까지 총 6개월의 기간이 소요되는 대형 프로젝트가 되었습니다.
초반의 고민과 디테일이 있었다면, 기획자가 알아서 해주세요라는 마인드로 업무를 대하지 않았다면, 전략부서에서 업무 요청 후에 의사결정을 다른 일이 바쁘다며 (집중해서 업무에 임하는 동료들 힘 빠지는) 지연시키지만 않았더라도 2개월은 단축되었을 프로젝트였는데 말이죠.
회고 자료 발췌 : 메인 개편 프로젝트 수행 업무 마일스톤 정리그래도 페이퍼 프로토타입을 통해 여러 기획자들의 아이디어들도 모아보고, 서비스 기획서 가이드 제작, IT 워터폴 업무 프로세스 기준을 정립하고, 메인 페이지만큼은 각 마케터나 사업부의 요구에 따라 일일이 변경하지 않고, 톤 앤 매너 유지 및 정책 일관성을 위해 별도 운영자를 통해 업무 일원화를 시키는 계기를 만들어 준 프로젝트였습니다.
페이퍼 프로토타입 예제