사수 없이 시작하는 웹/앱 프로덕트 실전 입문서
서비스 기획 스쿨
현업 기획자 도그냥이 알려주는 서비스 기획 스쿨 / 저자: 이미준(도그냥) / 출판:초록비책공방 / 발매: 2020.06.10.이 책을 읽어야 하는 이유
서비스 기획에 종사하거나, 준비를 하고 있다면 도그냥이라는 이름을 한 번쯤은 들어봤을 것이라고 조심스럽게 말해본다. 이 책은 이미준 작가, 도그냥님이 제작한 책으로 실제 주니어 서비스 기획자들의 고충을 해결해 주고 싶은 마음으로 집필하셨다고 한다.
최근 내가 읽는 PM 관련 책들이 그러했듯이 이 책도 역시 추천을 받아서 읽게 되었다. 물론 나에게도 좋은 책이지만 이 책은 서비스 기획 현업으로 종사하는 분들이 읽었다면 더할 나위 없이 좋았을 것 같다는 생각이 들었다. 내가 지금 할 수 있는 것이라고는 상상에 상상을 더하는 것뿐이기 때문이다. 좋게 말하면 이미지 트레이닝을 열심히 하고 있는 것 같다.
이 책에서도 역시 다른 실무서와 비슷하게 협업에서 올 수 있는 고충과 그 과정에서 얻을 수 있는 진리에 대해서 말해주었다. 책이란 이런 게 좋은 것이 아닐까 싶다. 실제로 작가가 경험한 내용을 우리가 미리 간접 체험함으로써 지식을 더 쌓을 수 있다는 것. 그런 의미에서 이 책 역시 좋이라고 말할 수 있을 것 같다.
강연을 하면서 수강생들이 했던 질문들을 중심으로 주니어들이 가질 수 있는 니즈를 확인하고, 책으로 풀어내었다. 역시 좋은 PM은 사용자의 의견을 중요하게 생각하나 보다. 각종 기획서들을 작성하는 방법과 프로젝트를 진행하는 방법 등 뭐 하나 빼놓을만한 게 없네. 글을 쓰다 보니 마치 홍보대사가 된 듯하다. 홍보하고 있는 것은 아니고 내가 읽은 책이 이 글을 읽는 분들에게도 도움이 되길 바라는 것이라고 이해해 주면 좋을 것 같다.
서비스 기획자는 다른 기획자와 무엇이 다른가서비스 기획자는 다른 기획자와 무엇이 다른가
서비스 기획자의 진짜 일은 상상을 실제로 어떻게 얼마만큼 구현하도록 만들 것이냐에 초점이 맞추어져 있다. 기술은 없지만 기술을 가진 이들과 협업하고 이끌어야 한다. 온라인 네트워크를 사용하여 만든 서비스라면 구현 속도와 기술적 환경, 시시각각 변하는 사용자 경험에 맞추어 계속해서 방향과 속도를 기술적 환경, 시시각각 변하는 사용자 경험에 맞추어 계속해서 방향과 속도를 조정해야 한다. 전략도 상황에 맞게 수정시켜야 하고 원하는 산출물이 나올 때까지 현실적인 구현에 훨씬 초점을 맞추어야 한다.
서비스 기획자가 하는 일
서비스 기획의 핵심이 '어떻게 구현할 것인가'라고 입이 닳도록 말해줘도 감을 잡지 못한다. '백문이 불여일견'. 그래서 사전 과제를 내주고 '어떻게 구현할 것인가'라는 관점에서 서비스 기획자의 사고 과정을 직접 보여주는 방식을 택했다.
자신의 이용 경험을 기준으로 추측만 하는 것은 근거 없는 가설일 뿐 논리적인 기획이 될 수 없다. 논리적인 방향성을 설정하고 기획을 진행하려면 실제 이 앱을 이용하는 다수의 사람들을 대상으로 데이터를 분석하거나 사용자 조사를 통해 앱 사용 목적을 이해하고 기획의 방향성을 결정했어야 한다.
서비스 개선 방향이 프로덕트 전체에 미치는 영향과 비용까지 생각해야 한다. 만약 씀이 비즈니스 모델을 바꿔 임시저장된 글을 활용할 것이라 하더라도 발행되지 않은 글에 대한 저작권 문제는 없는지 법률까지도 검토해서 활용해야 한다.
데이터 입력과 순환을 통해 서비스 전체의 기반을 잡아가는 것을 선순환 구조라고 한다. 서비스 기획자의 관점은 단지 '불편'에 머물러 서는 안된다. 눈에 보이는 페인 포인트는 굉장히 쉽게 접근할 수 있다. 하지만 서비스 기획자는 비즈니스 모델과 전략, 개발 환경과 비용, 그리고 서비스 전체의 순환 구조까지 고려하는 폭넓은 시각을 가지고 있어야 한다.
아이디어 ≠ 서비스 기획아이디어 ≠ 서비스 기획
프로덕트는 과정에 해당하는 프로젝트가 아니라 프로젝트에 의해서 만들어지는 산출물을 의미한다. 예를 들어 이커머스 사이트 내에서 '검색'이나 '주문'도 하나의 프로덕트가 된다. 이런 점에서 국내에서는 프로덕트란 단어를 '서비스'라고 치환해서 불러도 의미가 상통한다. 즉 서비스 기획에서 말하는 서비스란 '무언가 목적을 가지고 있는 이용자에게 목적을 이룰 수 있도록 도와주는 프로덕트 전체'를 총칭한다.
서비스 성장을 고려한 서비스 기획
사용자들이 만들어내는 가치가 커지면서 플랫폼의 가치도 커지고 자연스럽게 규모의 성장이 일어난다. 하지만 자생적으로 작동하고 성장하는 플랫폼 서비스를 만들려면 네트워크 효과를 고려하여 서비스 사용 및 유입을 순환시키는 구조로 설계할 필요가 있다.
워터폴 프로젝트 방법론
워터폴 방식의 프로젝트는 '기획-디자인-개발-테스트-오픈'이라는 프로세스 순서대로 진행된다. 이 방법론으로 진행되는 프로젝트의 가장 큰 특징은 앞 단계가 끝나야만 다음 단계로 나아갈 수 있다는 것이다.
워터폴 프로젝트는 정해진 기간이 명확하기 때문에 기획에서부터 아예 오픈 가능한 범위로 프로젝트를 줄일 수 있다. 국내 대기업에서는 여전히 워터폴 방법론으로 프로젝트를 하고 있는데, 그 이유는 바로 대기업 CEO들이 오픈 일정을 중요하게 여기기 때문이다. 이런 특징 덕분에 워터폴 프로젝트는 선봉장이 기획 단계에서 IT적 설계와 UI까지 빠르게 파악한다면 웬만큼 괜찮은 프로덕트가 나온다. 비록 오픈 시점에는 올드한 구닥다리로 변해 있을 수 있지만 말이다.
애자일 프로젝트 방법론
애자일 사상의 가장 큰 핵심적인 골자는 기존 워터폴 방법론의 선형적인 프로세스가 빠르게 변화하는 IT 세상에는 적합하지 않기 때문에 대안적인 프로세스가 필요하다는 것이다. 애자일한 프로젝트란 기획 문서를 준비하는 기간을 줄이고 개발 기간을 2~3주 정도의 스프린트 단위로 잘라서 서비스의 기획과 검토를 여러 번에 걸쳐 수행하는 것을 말한다. 그러면 중간중간 변화하는 시장의 흐름을 기획에 포함시킬 수 있다고 보는 것이다.
워터폴 프로젝트는 개발 방식이나 기술, 심지어 UI까지도 기획자가 먼저 숙제처럼 고민해야 하지만 애자일에서는 '사용자 스토리'라는 백로그만을 작성한다.
사용자 스토리란 전체 서비스가 갖춰야 할 고객의 목표와 핵심 결과를 사용자 목표에 따라 잘게 나눠 작성한 '요구사항 리스트'라고 할 수 있다. 백로그만을 디자인, 개발 테스트하는 스프린트 단위로 작성한다. 하나의 스프린트는 2~3주 정도에 해당한다. 즉 기획자는 '원하는 것'을 최대한 문장의 형태로 기록하고 나머지 시간은 하나의 스프린트에서 어떤 서비스 영역을 개발할 것인지를 고민해야 한다. 스프린트별로 기획 방향을 끊임없이 검토하고 프로젝트와 프로덕트를 동시에 진행해야 한다는 뜻이다.
기획자에게 방법론은 커뮤니케이션 수단일 뿐기획자에게 방법론은 커뮤니케이션 수단일 뿐
기획자의 기획은 비즈니스 모델에 대한 이해를 바탕으로 해당 시스템 구조 내에서 구현 가능한 IT 기술과 고객에게 의미 있는 UX를 만들어주는 UI가 포함된 것이어야 한다. 어느 것 하나도 기획자 혼자 만들어낼 수 있는 것들이 아니다. 기획자에게 중요한 역량은 기획력이고, 프로젝트 관리는 '기술'에 해당한다.
현업과의 인터뷰: 듣고 질문하고 이해하자
서비스 운영 개발 요청서가 들어왔을 때 기획자가 현업 실무자와 따로 만나 미팅을 하는 첫 번째 이유는 '통역' 때문이다. 같은 한국말이라도 한국말이 아니다. IT 업무를 하지 않은 사람들은 시스템에 관한 대화를 힘들어한다.
정제되지 않은 요청사항은 IT 적으로 판단하는 개발과 디자인 부서에게 혼동을 주기 쉽다. 불분명한 서비스 요청사항이 전달되면 서로 다른 외국어로 소통하듯 이해하기가 어려워 현업부서와 실행 부서 간에 마찰이 생긴다. 때문에 웹/앱 서비스가 주력인 회사에서는 현업부서와 개발부서 사이에서 기획자가 통역사처럼 조율하는 것이다.
서비스 기획자의 역할은 '서비스 관리'이다. 서비스 관리는 전체 서비스의 방향성이 비즈니스와 IT, UX의 관점에서 일관되게 유지·운영될 수 있게 하는 것이다. 현업부서에서 서비스 운영 개발 요청서가 들어오면, 이 요청사항의 목표와 방법이 회사 서비스의 거대한 방향성에 부합하는지 제로베이스에서 판단해야 한다.
회사 서비스의 비즈니스 전략과 맞지 않을 수도 있고, 애초에 기술적으로 불가능할 수도 있다. 서비스 기획자는 현업부서가 원하는 진짜 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민할 수 있어야 한다.
기획자가 가장 먼저 해야 할 것은 UX 분석
기획자가 가장 먼저 해야 할 것은 UX 분석
모든 연구의 과정이 그렇듯 UX 분석도 '관찰'과 '추론'으로 이루어진다. 관찰에는 감정에 공감하거나 이해하는 '정성적 분석'과 수치화된 데이터를 기반으로 분석하는 '정량적 분석'이 있다.
즉 정성적 혹은 정량적 분석을 하기 전에 미리 가설을 세우고 그 가설이 적합한지 판단하는 연역적 방식이 있고, 조사를 하고 그 결과를 해석하면서 UX 결론을 이끌어내는 귀납적인 방식이 있다.
개발부서와 공감대를 형성해야 하는 이유개발부서와 공감대를 형성해야 하는 이유
기획자가 요구사항 정의서를 리뷰하면 개발 리더는 다음과 같은 두 가지 질문을 꼭 던지는 것이다.
기존 시스템에 있는 기능으로는 구현이 불가능한가?
기존 시스템에 영향도를 최소화할 수 있는가?
개발부서의 태도는 무조건 배척하는 것이 아니라 수정으로 인한 시스템 오류 가능성을 최소화하고 싶은 것이다. 이런 입장 차이를 이해하지 못하면 개발 부서는 마치 방어적이고 일하기 싫어하는 것처럼 보일 수 있다.
화면설계서 작성법화면설계서 작성법
화면설계서는 전방위로 사용되는 커뮤니케이션 문서다. 디자이너에게 화면을 설명할 때도 사용되고, 개발자에게 원하는 기능을 설명할 때도 사용되며, 테스트를 함께할 QC나 QA 인력에게 기획 내용을 설명할 때도 사용된다. 프로젝트 기간 동안 아마 수십 번은 화면설계서를 리뷰해야 할 것이다. 만약 지금 작성한 문서에 빠뜨린 부분이 있더라고 리뷰 과정에서 피드백을 받으면서 업데이트해나갈 수 있다. 처음부터 완벽한 문서를 만들 수는 없다.
사용자 스토리 작성법
사용자 스토리는 앞서 정리했던 요구사항 정의서와 비슷해 보이지만 본질적으로는 다르다. 사용자에 대한 페르소나 개념이 포함되고, 서비스의 목표가 그 사용자의 과업이 되며, 마지막으로 비즈니스 모델에서의 목표나 중요성이 포함된다. 주의할 점은 절대로 어떠한 로직으로 그렇게 만들 것인지 UI적인 부분을 고정하여 적성하지 않아야 한다는 것이다.
워터폴 방식에서 작성하는 요구사항 정의서나 화면설계서는 모든 개념을 기획자가 정리하지만 애자일 방식의 사용자 스토리는 개발자와 디자이너가 최대의 창의력을 발휘할 수 있게 하는 것이 핵심이기 때문이다.
디스크립션의 완성도를 더욱 올리는 방법
예외 처리
정상적이지 않은 예외적인 상황에 대해 대응할 수 있도록 처리하는 것을 예외처리라고 한다. 기획에서는 개발적 예외 처리가 필요한 경우 함께 고민하여 화면설계서에 추가할 수 있다.
분기 처리
분기 처리는 애초에 다른 유형이 여러 가지가 있어서 한 개의 페이지가 유형에 따라 다르게 나와야 하는 경우를 의미한다.
정합성 체크
정합성 체크란 데이터 처리에서 규칙에 맞는지를 보는 것을 의미한다. 보통 입력하는 폼이 있는 경우, 숫자가 들어가는 항목에 글자를 넣는다거나 필수적으로 입력해야 하는 항복을 입력하지 않았을 때 이에 대해 체크하여 다음 프로세스로 넘어가지 않도록 확인하는 절차인데, 꼭 막아야 하는 실수에 대해서는 아예 정합성 체크에 대한 기준을 정하여 디자인 요소로 포함시키고 개발에서도 거를 수 있도록 해주는 것이 중요하다.
비주얼 디자인(UI 디자인)의 역할비주얼 디자인(UI 디자인)의 역할
디자이너는 맨바닥에서 시작하지 않는다. 사내에는 대부분 기본 UI와 인터랙션 가이드가 있고 사용한 폰트와 컬러 레벨 등을 갖춘 스타일 가이드가 있다.
디자이너는 정해진 기능의 UI를 만들기 우해 기존에 만들어놓은 디자인 가이드를 활용하여 구성요소의 레벨을 정리하고 통일성을 갖도록 작업한다. 여기에서 UI 요소의 레이아웃은 마치 문장의 들여 쓰기처럼 화면 전체의 정돈됨과 균형을 만들어 심미성을 가져온다. 기획에서 정해진 구성요소를 바탕으로 디자이너가 UX와 이용자의 편의성 측면에서 다양한 드래프트 시안을 만들어내면 그다음 단계에서는 기획자와 함께 앞으로 좀 더 발전시킬 시안을 논의하게 된다. 선택된 시안은 스토리보드 내에서 표현된 모든 종류의 케이스에 대응하기 위해 세분화하는 작업이 필요한데 연장에서는 이를 베리에이션(Variation) 작업이라고 부른다.
배우고자 하는 태도가 최고의 역량배우고자 하는 태도가 최고의 역량
실전에서 쓰는 용어들을 그때그때 정리해두면 일을 해나가는 데 있어 도움이 된다. 현장에서 쓰는 개발 용어를 접할 때마다 정리하다 보면 자사에 가장 적합한 용어집을 만들어낼 수 있다.
모르는 건 죄가 아니다. 하지만 모르는 용어를 듣고도 왜 사용됐는지 고민해 보지 않는다면 그건 잘못이다. 기획자는 누구보다 프로젝트 대상에 관심이 있어야 하고, 항상 신경을 써야 하는 직무임을 잊지 말자.
