운영기획건, 프로젝트 범위 잘라내기
목표에 대한 성과측정이 가능하고 자원 효율적이어야 한다
알만한 분들은 아시지만, 패스트캠퍼스에서 벌써 3개 기수째 서비스 기획을 가르치고 있다. 특히, 일반적인 기획 클래스들이 아무 것도 없는 상황에서 '신규서비스'를 만들어서 컨셉팅만 한다면 내가 하는 클래스는 '운영기획'을 가르치는 것을 모토로 하고 있다.
여기에서 큰 차이가 있는데 기업이나 이미 구축된 서비스/시스템이 없고 업무 경험도 없는 상태에서 기획하는 '신규서비스'는 말 그대로 허무맹랑한 상상에 그치는 경우가 많다. 운영기획은 그런 환경에서 할 수 있는 일이 아니다. 이미 기존에 공고히 만들어진 서비스 시스템과 비즈니스 논리 내에서 명확한 목표를 가지고, 시스템 영향도를 최소화하면서 자원효율까지 추구해야하는 것이 운영기획이다. 과거에 매번 만들고 때려부수는 대형 리뉴얼 방식의 웹서비스가 먹힐 때는 운영은 아예 외주를 주거나 잡일처럼 여겨졌다. 하지만 점점 micro UX의 트렌드도 강해져 왔고 A/B 테스트와 같은 방식으로 작은 변화로 큰 흐름을 지속적으로 유지하는 것이 중요해 지고 있기에 디테일한 서비스 기획과 개발이 점점 중요해졌다. 이 방향속에서 분명 조금씩 운영기획자에 대해 요구되는 역량과 인식이 모두 바뀌고 있다.
역시나 시스템이 없는 학원에서 운영기획을 가르치는 것은 쉬운 일은 아니다. 가상으로 시스템에 대한 가정을 만들고, 현업의 요청부터 프로젝트를 기획자가 재분석하고 목표를 만들어서 리딩하며 개발자, 디자이너와 커뮤니케이션을 하는 방법을 실습을 하는 방식으로 체계화 시키기위해 노력했다. 이미 3기까지 진행해오면서 어느 정도 내가 진행하고 있는 방식에 대해 확신이 생기고 있다. 현장에서 일을 배울 때와 마찬가지로 당황하고 놀라면서 계속 발전하는 모습이 눈에 보인다.
실습방식의 수업은 '현업의 요청을 분석하는 것'부터 시작한다. 전에 '오퍼레이터와 기획자의 차이'에 대해서 논했던 글에서도 말했지만 현업의 요청한 '방법'이 중요한게 아니라 진짜 목표를 찾아내서 우리 프로덕트의 전체적인 목표에 맞는 알맞는 방법을 새로 기획하는 것은 많은 연습이 필요하다.
https://brunch.co.kr/@windydog/122
그런데, 이런 설명에서 가끔 오해가 생긴다.
운영개발 프로젝트의 범위
현업의 요청은 생각보다 명확하게 올 때가 있다. 예를 들어, '메인에 기획전 배너를 넣어주세요'라든가 '예약 상품 주문시에 주문서에 홍보문구를 넣어주세요'라는 요청이 들어온다. 이에 대한 목표는 현업 요청자의 설명이 필요하고 진짜 목표가 '기획전으로의 트래픽 강화'라든가, '법적 문제 회피를 위한 안내문구 추가'일 수도 있다.
근데 기획을 위해 기존 서비스 프로덕트를 보다 보면 기존 메인의 고치고 싶은 부분이나 주문서에 대한 아이디어가 퐁퐁 생각날 수도 있다. 물론 이런 현상은 자연스러운 것이며 기획자로서 멋진 소양이다. 그런데 기획 과제를 내주고나면 영 관련없는 개선안을 가져오는 경우도 나타난다. 생각이 타고타고 넘어가서 다른 곳까지 가버린 것이다.
이 개선 아이디어는 처음 요청사항의 목표와 관계가 있나요?
아니요. 근데 이렇게 개선해보면 어떨까 싶어서 넣어봤어요!
이 상황은 우리 클래스에서만 일어나는 일은 아니다. 실제 업무 현장에서도 종종 일어나는 일이다. 정말 다양하고 여러가지 이유와 효과에 대해서 이야기하면서 그 기획 아이디어에 대해서 설명한다. 어떤 때는 의기양양한 표정으로 애초에 목표했던 프로젝트가 아니라 그 아이디어에 더 열을 올리며 설명한다. 사실 정말 마음에 들었기 때문에 여기에 굳이 넣었을 테니.
그럼 원래 목표와는 관계가 없는 거네요?
이 프로젝트 내용에서 뺄께요.
나는 이렇게 대답을 하곤 한다. 의기양양했던 표정이 이내 시무룩해진다. 회사가 아닌 클래스에서 이럴 때는 발끈하기도 한다. 하지만 내용에서 빼는 것은 아이디어의 문제 때문이 아니다. 아이디어는 정말 훌륭하고 좋을 수 있다. 오히려 내가 기획자로 같은 페이지를 보면서 생각지도 못한 탁월한 아이디어도 있다. 하지만, 그 내용이 원래 목표의 범위에서 벗어난다는 사실은 변하지 않는다.
나의 반응에는 두 가지 이유가 있다.
첫째, 프로덕트 매니저는 자신의 기획에 대한 효율을 체크해야 한다.
둘째, 프로덕트 매니저는 프로젝트에 들어가는 자원을 효율적으로 관리해야 한다.
과거의 기획의 감으로 개선하고 경쟁사를 모방하는 방식이 팽배했다면, 요즘의 기획은 데이터를 기반으로 해야할 뿐만 아니라 애자일방법론을 강조할만큼 모든 자원의 투입에 대해서 일목요연하게 예측하고 관리할 수 있어야 한다.
지금 이 프로젝트는 현업의 요청에서부터 시작됐다. 즉, 프로젝트의 목표는 현업의 요청을 제대로 확인하고 이에 대해서 사용자에게 좋은 경험이 되는지와 우리 프로덕트의 생태계와 비즈니스모델에 적합한지에 따라서 기획자가 판단한 것이다. 즉, KPI는 이 과정에서 우리가 최종적으로 설정한 목표대로 개선되었는지를 확인할 수 있어야 한다. 그러려면 관계없는 내용이 이 개선안에 포함되어 개선 전후의 KPI를 동일선상에서 비교하는 것이 방해되지 않도록 해야한다. 그래야 명확하게 이번 개선건의 효과를 확인할 수 있기 때문이다.
또한 프로젝트에는 기획자뿐만 아니라 디자이너, 개발자, QC 등 여러 관련된 사람들이라는 회사의 자원이 모두 포함된다. 그리고 그 사람들 모두 효율적인 스케줄관리와 인적자원 투입을 해야할 필요가 있다. 프로젝트의 목표가 정해지고나면 당연히 이 프로젝트에 대한 중요도 판단이 필요해진다. 그리고 이 중요도에 따라 모든 자원의 투입에 대한 기준도 정해진다. 자원이 많이 투입되면 빠르고 복잡한 것도 개발이 가능하다. 소위 '시간과 돈'만 있으면 이 세상에 안될 개발이란 없다고 한다.
그런데 기획자의 갑작스런 아이디어로 개발건이 눈덩이처럼 불어난다면? 회사차원에서 프로젝트의 우선순위와 자원관리를 하는 것은 점점 어려워진다. 실제로 커뮤니케이션 되지 않은 상태로 기획건에 목표와 관계없는 여러가지 아이디어를 이것저것 더 붙여서 가져가보면 개발에서 화를 내는 경우가 종종 있다. 개발자가 너무 수동적이고 방어적이라면서 욕하기 전에 기획에서도 목표와 관계없이 너무 큰 욕심을 부리는 건 아닌지 생각해볼 문제다. 또, 어떤 경우에는 기획자가 보기에는 요거 살짝 고치는 것처럼 보여도 시스템 구조상 너무 많은 개발 영향범위가 생기는 경우도 있다. 조금만 수정해도 주문서 로직 전체를 흔든다든가 결제수단별로 다 테스트를 해봐야한다든가 하는 경우라면 투입 자산 대비하여 얻을 수 있는 효과가 너무 적어 비효율적인 프로젝트가 되어버릴 수도 있다. 기획을 하면서 자사 프로덕트의 영향범위를 예측하지 못한 것은 요즘 같은 분위기에서 기획자에게 면죄부가 되진 않는다. 개발 코딩을 하진 못하는 기획자라고 해도 어느정도의 영향도는 예측할 수 있도록 충분히 자사 시스템에 대한 공부는 되어 있어야 한다.
아이디어는 분명 개선할 기회가 온다
물론 개발 자원이 넉넉하고, 생각보다 아주 쉬운 개발일 경우에는 한번에 개발 자원을 사용하여 함께 개선을 해볼 수도 있다. "과장님, 같은 페이지 수정하는 김에 이거 하나 더 넣어주세요" 이런 멘트는 충분히 해볼 만한 멘트다. 하지만 앞서 말했듯이 이것이 KPI의 체크를 혼동하게 만든다면 이건 꼭 별도의 프로젝트건으로 처리하는 것이 맞다고 생각한다.
이런 내용들은 모두 따로 노트를 해두면 아이디어를 프로젝트로 발전시킬 기회는 꼭 찾아온다. 내 경우에도 바탕화면의 스티키 노트에 평소 가지고 있던 아이디어들을 계속 기입을 해두었었다. 그러다가 기획 주도적인 개선 리뉴얼이나 연간 개선 기획 아이디어가 필요한 시점에 정리하여 다른 기획자들과 프로젝트에 대한 동의를 얻어서 진행하였다. 운영기획자가 꼭 요구사항을 받아서 진행하는 것은 아니기 때문에 정말 필요하다고 생각하는 것은 목표를 가지고 직접 발의해볼 기회는 만들어 낼 수 있다. 그리고 그 방면이 오히려 기획자로서 자신의 성과 측정에도 유리하다.
애자일 방법론이 성행하면서 무엇이든 빠르게 반영하고, 시도하고 하는 것이 최고의 선(善)처럼 느껴진다. 하지만 관리하고 체크할 수 없다면 그 빠름은 '안절부절'에 지나지 않는다. 어쩌다가 바른 길로 갔어도 다시 누군가에 의해 더 나쁜 방향으로 후진해버릴 수도 있다. 바른 길로 가고 있는지 확인하려면 명확한 목표에 맞는 명확한 KPI를 설정하고 하나의 프로젝트에 들어갈 투입 자원의 양을 모두의 동의속에서 산출할 수 있어야 한다.
서비스 기획자는 아이디어뱅크도, 촉으로 움직이는 혁명가도 아니니까. 그니까 결론은 우리 클래스분들이 아이디어를 제외시키는 내 말에 그만 서운해 하시면 좋겠다.
