[현업 기획자 도그냥이 알려주는 서비스 기획 스쿨]
사수 없이 시작하는 웹/앱 프로덕트 실전 입문서
핵심 Summary
UX와 비즈니스 모델까지 생각한다
(...) 서비스 기획자의 관점에서 말하자면, 둘의 의견은 모두 서비스 기획이라고 할 수 없다. 둘의 의견은 그냥 아이디어일 뿐이다. 논리적 지향점이 없기 때문에 기획의 단계로 발전할 수가 없다. 왜냐하면 두 수강생 모두 '본인을 기준으로 한 서비스 이용 목적'이 기획의 근거가 됐기 때문이다.
논리적인 방향성을 설정하고 기획을 진행하려면, 실제 이 앱을 이용하는 다수의 사람들을 대상으로 데이터를 분석하거나, 사용자 조사를 통해 앱 사용 목적을 이해하고 기획의 방향을 결정했어야 한다.
자신의 경험이 시작점은 될 수 있지만, 궁극적인 서비스 개선은 비즈니스 모델에 대한 전략과 방향에 대한 다각도의 이해를 바탕으로 이루어져야 한다.
서비스 전체의 선순환을 생각한다
데이터의 입력과 순환을 통해 서비스 전체의 기반을 잡아가는 것을 선순환 구조라고 한다. (...) 서비스 기획자의 관점은 단지 '불편'에 머물러서는 안 된다. 눈에 보이는 페인 포인트는 굉장히 쉽게 접근할 수 있다. 하지만 서비스 기획자는 비즈니스 모델과 전략, 개발 환경과 비용, 그리고 서비스 전체의 순환 구조까지 고려하는 폭넓은 시각을 가지고 있어야 한다.
서비스 기획자는 UI만을 설계하는 사람도 아니고 고객 분석만 하지도 않는다. 핵심 비즈니스를 IT 기술이 가능한 형태로 UX를 고려해서 만드는 것이 서비스 기획자다.
프로젝트 방법론 : 워터폴과 애자일
프로젝트 방법론이란, '기획-디자인-개발-테스트-오픈'이라는 프로젝트의 작업 순서와 작업 방식을 정의하는 방법을 의미한다. 워터폴 방식의 프로젝트는 '기획-디자인-개발-테스트-오픈'이라는 프로세스 순서대로 진행된다. 이 방법론으로 진행되는 프로젝트의 가장 큰 특징은 앞 단계가 끝나야만 다음 단계로 나아갈 수 있다는 것이다. 애자일 방법론은 '스프린트'라 불리는 짧은 주기의 개발 사이클을 반복해 시장 변화에 유연하게 대처하는 프레임워크이다.
어떤 프로젝트 방법론을 선택하느냐보다는, 머릿속에 뭉게뭉게 피어있는 기획을 (문서가 있든 없든) 프로젝트 팀원에게 구체적으로 전달할 수 있어야 하고, 팀원 스스로 자신이 무엇을 만들고 있는지, 무슨 일을 해야 하는지 알 수 있게 해야 한다.
서비스 기획자는 갑질을 한다?
현업부서는 그저 자신들이 원하는 서비스 기능을 언제쯤 사용할 수 있는지가 궁금할 뿐이다. (...) 그러나 현업부서의 요청사항을 통역해서 개발부서에 전달하는 것만으로 기획자의 역할이 끝나는 것은 아니다. 현업부서에서 서비스 운영 개발 요청서가 들어오면, 이 요청사항의 목표와 방법이 회사 서비스의 거대한 방향성에 부합하는지 제로베이스에서 판단해야 한다. 때문에 현업부서와의 미팅에서 가장 중요한 질문은 방법적인 부분이 아니라, 현업이 요청하게 된 '진짜 목표'를 파악하는 것이다. 서비스 기획자는 현업부서가 원하는 진짜 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민할 수 있어야 한다.
서비스 기획자에게 필요한 덕목은 요청된 사안이 불가능하더라도, 현업 실무자가 말하는 요청사항의 배경과 목표를 듣고 함께 대안을 찾으려 노력하는 자세에 있다. 그다음은 직무적 신뢰감을 주는 것이다. 현업부서 입장에서는 서비스 기획자도 기술직이다. 최대한 상황을 쉽게 설명해주고 대안을 제시할 수 있어야 한다.
서비스 전략이 프로세스 설계로 변하는 과정
(...) 즉, 사용자를 파악한다는 것은 사용자의 문화인류학적 정보인 연령이나 가족관계가 아니라, 사용자가 서비스에서 이루려는 목적이나 상황을 인지하여 적절한 프로세스를 설계해주는 것이다.
서비스 기획의 가장 큰 부분은 사용자의 목적과 기획자의 서비스 전략을 맞추고, 정책을 통해 데이터와 프로세스가 어떻게 흘러가는지를 정의하는 것이다.
목적에 맞는 범위로 좁힐 것
서비스 운영 기획에서 가장 많이 하는 실수가 '범위 설정'이다. 여기서 범위란 프로젝트에 포함되는 범주를 의미한다. 현재 운영 중인 서비스에 새로운 서비스를 만드는 일은 이미 다 만들어진 시스템에서 기능의 일부를 바꾸거나 추가하는 것을 의미한다. 그래서 서비스 운영 중에 진행되는 개선 프로젝트는 개발해야 하는 양을 정하는 것이 굉장히 중요하다.
실무에서도 주니어들이 기획 과제를 해결하면서 '있으면 좋을 것 같은 기능'을 추가하는 경우를 흔히 본다. 어차피 수정 개발을 하게 될 화면이니 기존에 하고 싶었던 개선 사항을 넣는 것이다. (...) 이렇게 되면 프로젝트가 완료된 후 우리가 세운 전략이 효과적이었는지 측정할 수 없게 된다는 문제가 발생한다.
린 UX에서는 필요한 부분을 빠르게 바꾸고 측정하여 올바른 방향으로 계속 나아가야 한다고 강조한다. 이는 연구 가설이 옳았는지 보려면 전략적으로 바꾸려고 하는 부분 외에 나머지 부분은 모든 조건이 동일해야 한다는 뜻이다. 관계없는 개선 사항이 끼어드는 순간, 오픈 후 서비스가 정말 전략대로 수정되었는지 확인할 수가 없다.
기획자 업무의 핵심은
나는 '주어진 환경에서 최대한의 차선을 찾는 것. 즉 문제 해결'이라고 생각한다. 주변 환경이 완벽할 순 없다. 나의 기획이 완벽할 수 없듯이, 협업자의 이해도나 사상이 나와 똑같기를 바라는 것은 이상적인 꿈일 뿐이다. 이런 환경에서 문제를 해결해야 하는 것은 기획자 뿐이다. 흔히 '커피 타는 거 빼고 다 한다'는 기획자의 관여 범위는 그런 면에서 명확해진다. 기획자가 수정하고 싶고 바로 잡고 싶은 것이라면, 그것이 바로 기획자의 관여 범위가 된다.
