자신의 사용 경험만으로는 기획의 근거가 될 수 없다
도그냥 서비스 기획 스쿨에서 뽑은 핵심 파트 109개 (1) 이론편
최근 서비스 기획 쪽 업무를 더 깊게 맡고 있다. 엄밀히 말하면 이미 만들어진 기획을 정리하고 수정하는 일에 더 가깝다. PM 역할을 맡은지도 얼마 안 되고 하니, 어디서 부터 시작해야 할지 상당히 막막했다. 열심히 서비스 기획, 프로덕트 기획 등을 검색하고 여러 아티클을 읽어도 전혀 눈에 들어오지 않았다.
그러다가 문득 도그냥 님이 쓴 서비스 기획 스쿨 책에서 힌트를 얻을 수 있지 않을까 했다. 그리고 그 책은 왠지 회사에 있을 것 같았고. 역시 IT 스타트업에 이 책이 없을 리가 없었다. 바로 책을 집어 들고 집으로 향했다. 퇴근 시간 이후에도 사무실 남아서 업무에 대한 고민을 한 뒤, 책과 함께 집에 도착하니 11시가 넘었다. 평소 같으면 바로 바닥에 쓰려졌겠지만, 왠지 그 책에는 내가 하고 있는 고민을 풀어줄 실마리가 있을 것 같아 바로 책상에 앉아 책을 폈다.
책을 읽으면서 살짝 충격을 받았다. '내가 알던 기획은 정말 기획의 아주 일부분이었구나.' '아직도 모르는 것도 너무 많고, 배워야 할 것도 많구나.' '세상에는 정말 잘하는 사람들이 많구나.' 이런 느낌을 받았다. 그만큼 눈으로는 볼 수 없는 보이는 프로덕트와 서비스 뒤편의 기획에 대해서 더 많이 알게 됐다.
이론편과 실전편, 총 2개의 글로 이 책을 요약했다. 이번 글에서는 이론편을 다룬다. 서비스 기획자나 PM을 꿈꾸는 취준생, 현업에서 일하는 주니어 기획자나 PM은 한번쯤 꼭 읽어봐야 하는 책이다.
서비스 기획자는 뭐하는 사람일까
서비스 기획자는 어디에서 유래한 것인가
1. 무언가를 ‘기획한다'는 말은 ‘목표를 위해 없었던 일을 새로이 만들고, 그것을 세부적인 계획까지 연결하는 사람'이라고 해석할 수 있다.
서비스 기획자는 다른 기획자와 무엇이 다른가
2. 온라인 네트워크를 바탕으로 소프트웨어를 이용하는 서비스를 다루는 서비스 기획자는 ‘현재 시점에서 무엇을 하고 싶다'는 전략을 세우는 것만으로는 업무가 끝나지 않는다. 서비스 기획자는 전략에서부터 끊임없이 되묻는다. “그걸 어떻게 할 건데?”
3. 서비스 기획자의 진짜 일은 상상을 실제로 어떻게 얼마만큼 구현하도록 만들 것이냐에 초점이 맞추어져 있다.
UX와 비즈니스 모델까지 생각한다
4. 기획안 자체로 볼 때 옳고 그른 것은 없다. 하지만 서비스의 논리적 지향점을 기준으로 한다면 그때는 맞고 지금은 틀린 지점은 있을 수 있다.
5. 자신의 이용 경험을 기준으로 추측만 하는 것은 근거 없는 가설일 뿐 논리적인 기획이 될 수 없다.
6. 서비스 기획자가 서비스 개선을 기획할 때는 자신의 경험이나 고객 불만을 근거로 해서는 안되기 때문이다. 자신의 경험이 시작점은 될 수 있지만 궁극적인 서비스 개선은 비즈니스 모델에 대한 전략과 방향에 대한 다각도의 이해를 바탕으로 이루어져야 한다. 겉으로는 별 차이 없고 비슷해 보이는 대안일지라도 그 시점의 상황과 전략에 따라 맞는 것이기도 하고 틀린 것이 되기도 한다.
개발 환경과 비용까지 생각한다
7. 무언가 새로운 기능을 넣고자 할 때도 서비스 기획자는 단순히 기능적인 목표만을 생각해선 안 된다. 서비스 개선 방향이 프로덕트 전체에 미치는 영향과 비용까지 생각해야 한다.
서비스 전체의 선순환을 생각한다
8. 어떤 서비스든 사용하다 보면 불만이 쌓이고 바뀌었으면 하는 부분이 생긴다. 서비스 기획자의 관점은 단지 ‘불편'에 머물러서는 안 된다. 눈에 보이는 페인 포인트는 굉장히 쉽게 접근할 수 있다. 하지만 서비스 기획자는 비즈니스 모델과 전략, 개발 환경과 비용, 그리고 서비스 전체의 순환 구조까지 고려하는 폭넓은 시각을 가지고 있어야 한다.
직장 선택의 기준은 연봉과 네임밸류와 조직문화
9. 아이디어를 구현하려면 자신이 속한 기업의 비즈니스 모델과 정책, 시스템의 한계와 구조를 잘 알고 있어야 한다. 이게 얼마나 큰 파괴력이 있느냐면 시스템을 잘 알수록 크고 도전적인 과제를 누구보다 자신 있게 할 수 있다.
10. 어디에서 일을 하든 처음에는 부끄러움을 무릅쓰고 이 사람 저 사람에게 물어가며 비즈니스 정책과 시스템을 파악해야 한다는 것이다. 일을 잘하려면 필요한 부분이기도 하지만 어쩌면 그게 이 일에 가장 빠르게 애착을 갖는 방법일 수 있다.
포스트잇 없어도 괜찮아
11. 서비스 기획자의 역할은 ‘문제없이 서비스를 구현하기 위해 필요한 모든 것을 할 수 있도록 만드는 것'이다. 여기서 ‘모든 것을 한다'는 말은 UX를 분석하여 얻은 비즈니스 이슈를 해결하고 구현해내는 것이다. 그러자면 법적, 기술적으로 발생할 수 있는 문제를 찾아내고 그것을 적절한 방식으로 해결해나가야 한다.
12. 방법론 자체를 배우는 것보다 ‘해결책을 찾아가는 방법'을 아는 것이 진정한 서비스 기획 역량이다.
서비스 기획을 위해 알아야 할 것들
아이디어 !== 서비스 기획
13. 프로덕트는 과정에 해당하는 프로젝트가 아니라 프로젝트에 의해서 만들어지는 산출물을 의미한다.
14. 서비스 기획자나 프로젝트 관리자 모두 프로젝트를 진행한다. 하지만 서비스 기획자가 프로젝트 관리자와 다른 점은 프로젝트를 서비스 생애주기를 관리하기 위한 하나의 수단으로 진행한다는 점이다.
전략 기획과 서비스 기획 모두가 필요하다
15. 전략 기획자가 방향성에 집중한다면 서비스 기획자는 구현에 집중한다. 새로운 서비스를 도입하기 위한 초기 단계에서는 전략 기획과 서비스 기획 모두가 필요하다.
16. 결국 새로운 서비스가 제대로 런칭되려면 시장과 수익 전략, 그리고 그것을 서비스로 만들어내기 위한 프로세스 모두가 동시에 기획되어야 하는 것이다.
비즈니스 환경에 맞는 서비스 기획
17. 서비스의 프로세스를 상세하게 기획하는 시점에서는 법률적인 부분을 포함해서 여러 가지 비즈니스 환경을 검토하고 반영해야 한다.
18. 우리나라 법은 해야 할 것을 정해놓은 것이 아니라 하면 안 되는 것을 정해놓은 형태의 법제이고, 특히나 정보 데이터 관련해서는 세계 최고 수준의 규제를 가하고 있다. 서비스를 기획하는 입장에서 이를 검토하고 시스템에 반영하는 것은 매우 중요한 일이다.
19. 프로덕트는 서비스로 나타나는 ‘산출물’ 자체를 의미하며, 프로젝트는 그 프로덕트를 만들어내는 ‘과정'을 뜻한다. 서비스 기획자 업무 스펙트럼에서 본다면 프로덕트는 목표이자 결과가 되고 프로젝트는 그 목표를 이루기 위한 과정이 된다.
20. 서비스를 고민하는 부분이 서비스 기획자의 역량과 자질이라면 프로젝트를 순조롭게 진행하는 것은 스킬의 영역이다.
프로젝트의 정의를 다시 보자
21. 프로젝트란 평소에 진행하는 일상적 업무가 아니라 일정 기간 목표를 위해 추진하는 특수한 업무를 말한다.
22. 이 책에서 다루는 프로젝트란 적어도 ‘기획-디자인-개발-테스트-오픈'이라는 다섯 단계를 ‘기획자, 디자이너, 개발자'라는 최소 세 개의 직군이 함께하여 IT 시스템으로 서비스를 함께 만들어내는 협업 업무를 의미한다.
프로젝트 방법론: 워터폴과 애자일
23. 프로젝트 방법론이란 무엇인가? ‘기획-디자인-개발-테스트-오픈'이라는 프로젝트의 작업 순서와 작업 방식을 정의하는 방법을 의미한다.
24. 애자일 방법론은 ‘응용문제'에 해당한다. 워터폴 방법론이라는 ‘기초 문제'를 충분히 익히지 못한 상태에서 애자일 방법론을 사용하는 것은 겉모습만 어설프게 흉내 내는 것이기 쉽다. 그 겉모습조차도 애자일 사상을 반영하기 위해 도출한 몇 가지 툴을 사용하는 것에 국한되어버리기도 한다.
25. 사용자 스토리란 전체 서비스가 갖춰야 할 고객의 목표와 핵심 결과를 사용자 목표에 따라 잘게 나눠 작성한 ‘요구사항 리스트'라고 할 수 있다. 워터폴 방법론에서의 ‘요구사항 정의서'나 ‘화면 설계서'에 포함된 상세 설명과 유사하지만 실제 구현에 있어서는 디자이너와 개발자의 자유가 보장되도록 작성해야 한다.
26. 즉 기획자는 ‘원하는 것'을 최대한 문장의 형태로 기록하고 나머지 시간은 하나의 스프린트에서 어떤 서비스 영역을 개발할 것인지를 고민해야 한다. 스프린트 별로 기획 방향을 끊임없이 검토하고 프로젝트와 프로덕트를 동시에 진행해야 한다는 뜻이다.
27. 기획자는 모두의 사상과 목표를 합치시킬 수 있어야 한다.
기획자에게 방법론은 커뮤니케이션 수단일 뿐
28. 어떤 프로젝트 방법론을 선택하느냐보다는 머릿속에 뭉게뭉게 피어있는 기획을 프로젝트 팀원에게 구체적으로 전달할 수 있어야 하고, 팀원 스스로 자신이 무엇을 만들고 있는지, 무슨 일을 해야 하는지 알 수 있게 해야 한다.
29. 기획자의 기획은 비즈니스 모델에 대한 명확한 이해를 바탕으로 해당 시스템 구조 내에서 구현 가능한 IT 기술과 고객에게 의미 있는 UX를 만들어주는 UI가 포함된 것이어야 한다.
30. 어느 것 하나도 기획자 혼자 만들어낼 수 있는 것들이 아니다. 그렇기에 기획자는 설명하고 또 설명해야 한다. 방법론에 맞는 방법으로 소통하고 또 소통해야 한다. 모르는 것은 이해하고 아는 것은 상대방이 이해할 수 있도록 쉽게 설명하는 능력이 필요하다. 기획자에게 중요한 역량은 기획력이고, 프로젝트 관리는 ‘기술'에 해당한다.
서비스 기획자는 갑질을 한다?
31. 서비스 기획자에게 필요한 덕목은 요청된 사안이 불가능하더라도 현업 실무자가 말하는 요청사항의 배경과 목표를 듣고 함께 대안을 찾으려 노력하는 자세에 있다. 그러려면 먼저 요청사항의 필요성에 공감해주어야 한다.
32. 그다음은 직무적 신뢰감을 주는 것이다. 서비스 기획자가 시스템이 어쩌고 저쩌고 하면 알아듣기 어려워한다. 최대한 상황을 쉽게 설명해주고 대안을 제시할 수 있어야 한다.
33. 서비스가 ‘내 자식' 같으려면 전체 프로덕트가 지향하는 방향 안에서 주어진 미션을 완결성 있는 서비스로 만들어야 한다. 여기서 ‘서비스의 완결성'은 고민의 깊이와 넓이에 의해 결정된다. 그리고 이러한 고민이란 서비스 기획의 3요소인 자사의 IT 구조와 역량, 비즈니스적 이해, 고객의 UX에 대한 분석을 바탕으로 서비스 전략을 만들어내는 과정을 뜻한다.
34. 서비스 전략은 군기가 바짝 든 이등병의 관등성명처럼 누군가 서비스에 대해서 물어보면 툭 하고 나올 정도로 체화된 고민의 결과여야 한다.
35. 기획자 자신이 알쏭달쏭한 전략과 방향성을 가지고 있다면 디자인하는 사람도 개발하는 사람도 알쏭달쏭해지고 결국 서비스를 만드는 사람 모두의 생각이 달라서 완결성 있는 서비스가 나오기 힘들다. 업무의 속도도 중요하지만 그 속도 때문에 고민의 시간을 건너뛰어서는 안 되는 이유다.
기획자가 가장 먼저 해야 할 것은 UX 분석
36. 궁극적으로 UX 방법론은 고객 경험을 통해 서비스의 개선 방향에 대한 인사이트를 얻기 위한 것이어야 한다.
비즈니스와 시스템을 알아야 UX를 활용할 수 있다
37. 평소 판단의 근거가 될 만한 여러 가지 정보를 취합하고 자신의 생각을 일관되게 만들 필요가 있다. 누가 툭 쳐도 항상 의견이 나올 수 있을 만큼 생각의 반복이 필요하다. 기획자의 생각이 굳건하다면 어떤 때는 논쟁하고 어떤 때는 수용하더라도 그것이 바로 서비스 전략이라 할 수 있다.
38. 서비스 기획의 시작도 끝도 시스템에 저장된 디지털 산출물에 있다. 자신이 맡은 시스템 구조를 파악해서 확인 가능한 데이터 지표를 통해 서비스 생애주기와 전략을 체크하고 구현 가능한 서비스를 만들어나가야 한다.
39. 기획에 대한 흔한 착각은 ‘무에서 유'로 세상에 없는 것을 창조해야 한다는 생각이다. 사실 기획은 ‘창조가 아니라 전략의 진짜 실행을 위한 정리'라고 봐야 한다.
40. 좋은 서비스는 아주 간발의 차이로 발생하는데, 시작의 시점보다 중요한 것이 바로 완성도다.
