서비스 기획 (3) – 서비스 기획과 커뮤니케이션
서비스 기획에 대한 마지막 이야기다. 첫 번째는 서비스 기획자가 가져야 할 비즈니스 오너쉽과 매출흐름 이해에 대한 이야기였고, 두 번째는 정보구조 설계, 화면설계, 파이프라인 설계와 같이 서비스 기획에 필요한 실무적인 내용들을 다뤘다.
그리고 이번 이야기는 커뮤니케이션에 대한 이야기다. 서비스는 혼자 만드는 일이 아니다. 여러 이해관계자와 협업해야 한다. 서비스 기획자에게 특히 커뮤니케이션 능력이 중요한 이유는 다음과 같다.
1. 서비스 기획자는 디자인, 개발 그리고 실무진 등 주요 업무 관계자와 대화를 나눌 기회가 잦기 때문에 다른 업무에 대한 이해도도 어느 정도 갖추고 있을 가능성이 높다. 그래서 서비스 기획자는 각 부서를 이어 줄 연결고리다.
2. 서비스 기획자는 실무진 중에서 비즈니스에 대한 이해도가 가장 높다.(높아야 한다.) 또 설명을 잘하는 것은 서비스 기획자에겐 필수 역량이다. 그래서 서비스 기획자는 시장현황, 사업의 방향, 목표 등을 구성원들에게 가장 잘 이해시킬 수 있는 이정표다.
3. 서비스 기획자는 운영 담당자 혹은 CS담당자 다음으로 고객과의 접점이 많을 가능성이 높다. 특히 개발자, 디자이너는 고객과의 접점이 상대적으로 낮은 편이기에 서비스 기획자는 고객의 이야기를 이들에게 전달하는 목소리다.
비즈니스, 실무, 운영에 관여하는 비중이 높은 만큼 커뮤니케이션 역량이 매우 중요하다는 의미다. 그렇다면 서비스 기획자는 어떻게 커뮤니케이션 근육을 키워야 할까? 커뮤니케이션의 핵심은 ‘때'(Occasion)에 있다. 그리고 이 ‘때’에는 항상 커뮤니케이션 대상이 따라온다.
intro. 연결고리
고생물학에는 Missing Link가 존재한다. 우리의 대화도 마찬가지다. ‘개발에 대한 이해도가 전혀 없는 실무/운영진’과 ‘실무/운영에 대한 이해도 가 전혀 없는 개발진’과의 대화는 공룡과 닭의 대화에 가깝다. 서로의 전문 분야가 상이하기 때문이다. 여기서 기획자는 시조새가 되어 둘의 사이를 이어준다.
옳게 되었지만 슬프고, 글러먹었지만 기쁘다.서비스 기획의 초기단계부터 론칭시점 그리고 운영에 이르기까지 기획자의 이러한 역할은 계속된다. 비즈니스 담당자는 서비스 기획자에게 돈 되는 기획을 요구하고, 실무진은 실용적인 기획을 요구한다. 개발자는 개발 가능한 기획을 요구한다. 이들이 서비스 기획자가 아니라 다른 직군에게 요구사항을 어필하는 순간 세상은 요지경이 된다. 왜 그럴까? 이들은 모두 “서비스”에 대해 알고 있다고 생각하지만, 잘 모르고 있기 때문이다.
1. 사업 기획자
경영자와는 다르다. 경영자는 개발진일수도, 운영/실무진일 수도 있으며 사업 기획자 일 수도 있다. 또 그들과의 커뮤니케이션은 조금 다른 결이기에 나중에 기회가 되면 다뤄보면 좋을 것 같다. 여하튼 사업 기획자의 KPI는 언제나 매출향상이다. 물론 이는 북극성 지표로, 다양한 요인들에 의해 만들어지는 것이지만 이들에게 있어서 “매출”이 그만큼 중요하다는 점을 강조하고 싶었다. 매출만큼 중요한 것은 비용이다. 사업 기획자들은 전반적인 업무 프로세스와 프로덕트 판매 추이를 분석하여 비용을 적절히 통제한다.
이들에게 서비스의 기능이나 운영 그 자체는 중요하지 않다. 특정 기능을 개발했을 때 얼마나 많은 비용이 소모될 것이며, 향후 이 기능이 매출에 얼마나 영향을 줄 수 있는지가 더욱 중요하다. 그래서 서비스 기획자는 새로운 기능이 가진 값어치를 정량적으로 측정하고 전달해야 한다. 여기에는 m/m 기준의 비용 산출과 더불어 가상의 사용자를 대상으로 한 서비스의 가치 측정이 수반된다. 사업 기획자와의 대화에 있어서 서비스 기획자에게 “자원”에 대한 이해는 매우 중요하다.
2. 실무/운영진
서비스의 형태에 따라 실무/운영진과의 대화는 굉장히 다채롭게 진행될 수 있다. 쇼핑몰 솔루션의 경우 MD들과 함께 상품을 효율적으로 관리하는 방법을 고민해야 하며, 보험 ERP의 경우 보험 설계사, 영업 담당자들과 이야기를 나눠야 한다. B2C 서비스의 경우 고객과 가장 가까운 곳에서 묵묵히 업무를 수행하는 운영자나 CS담당자와의 대화가 끊임없이 필요하다. 마케터와도 대화의 접점이 매우 많을 것이다.
이들은 분명히 서비스에 바라는 점이 있고, 불편함 점을 느끼고 있다. 그러나 구체적으로 여기에 대해 표현하는 데에는 서툴다. 서비스 기획자가 이들의 업무를 이해하는데 서툰 것처럼 말이다. 서비스 기획자는 이들이 무엇을 원하는지 이해하기 위해 집요함을 갖춰야 한다. 괴롭히는 것이 아니다. 이들이 말하는 요구사항이 맞던 틀리던 조용히 혼자 생각하고, 정리한 뒤 되묻는 과정을 반복해야 한다.
대부분의 사람들은 그들의 설명에 대해 되물었을 때, 정확하지 않더라도 맞다고 하는 경우가 많다. 조용히 생각하고 깔끔하게 정리한 뒤 되묻는 것이 중요한 이유는 여기에 있다. 서비스 기획자는 이런 상황을 절대로 넘어가서는 안된다. 상호 간에 이해가 부족하다는 느낌이 조금이라도 든다면 이해도가 100%에 이를 때까지 이 과정을 반복해야 한다.
3. 고객
사내 서비스를 만든다면, 실무/운영진이 고객이 될 수도 있다. 2번의 연장선이며 3번과도 관계가 있으니 적당히 섞어서 이해해두면 좋을 것 같다. 그리고 실무/운영진이 고객인 경우 VoC를 실시간으로 들을 수 있다는 점에서 업무의 능률이 급격하게 상승한다. 고객 이야기 보다 실무/운영진을 먼저 꺼낸 이유가 여기에 있다.
고객과는 크게 2가지 방식으로 대화를 나누게 된다. 첫 번째는 직접 고객의 의견을 들을 수 있는 방법이다. 그러나 수천, 수십만에 이르는 고객을 하나하나 찾아가서 의견을 물을 수는 없다. 설문조사에도 한계가 있다. 그래서 데이터를 통해 고객의 생각을 추측하는 두 번째 방법이 사용된다. 활발하게 운영되는 서비스에서 서비스 기획자는 상당한 시간을 데이터를 통한 고객과에 대화에 할애한다. 서비스 기획자에게 데이터 기반 의사결정 능력을 요구하는 회사는 대부분 이런 케이스에 해당된다.
고객과의 커뮤니케이션은 우라늄 같다. 제대로 이해하고 다룰 수 있다면 엄청난 에너지를 지니게 되지만, 자칫 잘못하면 서비스 전체를 위험하게 할 수 있다. 개발 단계에서도, 운영 단계에서도 고객의 의견은 매우 중요하다. 하지만 그들은 그들의 의견이 서비스 전체에 어떤 영향을 끼칠지는 고려하지 않는다. 서비스 기획자는 정확한 기준과 함께 그들의 의견을 수렴해야 한다.
데이터도 마찬가지다. 우리는 흔히 이슈를 발견하고, 무엇이 문제일지 추적하고 원인을 분석하여 해결하는 형태의 데이터 기반 의사결정을 한다. 데이터는 자리를 잘 못 잡은 치아와 같아서 언제든 사용할 수 있도록 교정기를 씌워놔야 한다. 이를 하지 못하면 우리는 잘못된 데이터를 통해 의사결정을 하게 된다. 그리고 그 결과는 참혹하다.
그래서 고객과의 대화에서는 어느 경우에서나 정확한 기준이 필요하다.
4. 개발자
많은 주니어 서비스 기획자들이 개발자들과의 대화를 어려워한다. 개발자가 아니라서 개발에 대해 잘 모르기 때문이다. 이로 인한 긴장감은 개발자와의 커뮤니케이션에서 무거운 족쇄가 된다. 사실 모르는 것은 죄가 아니다. 하지만 어려움을 이겨내지 못해 대화를 멈추는 것은 직무유기다.
서비스는 거대한 미로다. 서비스 기획이 거대한 미로의 지도를 그리는 일이라면 개발은 출구를 찾아 나가는 일이다. 정밀한 지도를 만들고 나면, 서비스 기획자는 직접 탐험을 할 수 없기에 미로 어딘가에 달린 CCTV로 개발자가 제대로 주행하고 있는지 지켜보는 것 말고는 할 수 있는 게 없다. 그러다 보니 냉정하게 말하면 이런 문제가 생길 수 있다. 기획자는 길을 제대로 잘 찾아나가지 못하는 개발자의 탓을 할 수도 있고, 개발자는 지도를 제대로 그리지 못한 기획자를 탓할 수 있다.
서로의 역량이 출중해서 이러한 문제가 발생하지 않을 수 있다면 너무나 다행이다. 다행히 개발자와 서비스 기획자가 가장 많이 대화를 나눠야 하는 커플이니 만큼 시간이 지나면 자연스럽게 좋은 관계가 될 수 있을 것이다.
그러나 서비스 기획자는 반드시 명심해야 한다. 제대로 된 개발자라면 초기 설계부터 기능 하나하나까지 오류에 대한 리스크를 떠안고 일을 한다. ‘혹시라도 서버가 죽어버리면’, ‘혹시라도 중요한 순간에 오류가 난다면’ 이런 if들에 대한 심리적 부담감이 크다.
서비스 기획자는 어떠한가? 생각보다 많은 기획자들이 개발자보다 낮은 책임감으로 일한다. 그렇기에 서비스 기획자는 ‘개발에 차질이 생기면 곧 나의 탓’이라는 부담감과 ‘서비스가 망하면 내 탓’이라는 책임감을 가지고 최선을 다해야 한다. 그러면 조금 더 빠르게 개발자와 좋은 팀워크를 만들 수 있을 것이다.
서비스 기획에 대한 3가지 이야기. 적다 보니 결국은 머리말이나 개요 같은 느낌이 되어버렸다. 다양한 이야기를 하고 싶었는데, 하나하나 예시와 함께 설명할 힘이 없었기 때문이다. 그래도 글로 쓰면서 생각이 많이 정리된것 같다. 앞으로는 디테일을 하나하나 채워볼까 한다.
beyes 님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
