brunch

You can make anything
by writing

C.S.Lewis

by Keza Nov 03. 2023

서비스 기획자의 용어

지금까지 여러 분야에서 일을 해왔다.

관광, 문화예술, 국제개발협력, 교육 분야에서 프로젝트나 사업을 운영 해왔지만 '무슨일 하세요?'라고 물어보면 나를 표현하는 타이틀이 없어 항상 고민을 했었다.

'여행 콘텐츠를 만들어요' 라고 할 때도 있었고

'우리나라에 있는 예술가들과 해외에 있는 예술가들이 서로 교류할 수 있게 지원해줘요.' 혹은 'ODA라고 개발도상국가들을 지원하는 사업을 담당하고있어요.'라고 할 때도 있었다. 그러면 ODA가 뭔지 국제교류가 뭔지 풀어서 설명하는 상황이 종종 생긴다. 이런 상황이 싫다는 건 아니지만 가지지 못한 것에 대한 로망이랄까? 가끔은 개발자, 디자이너, 사서, 선생님 등 한 단어로 표현할 수 있는 타이틀을 가진 사람이 부럽기도 했다.


나는 굳이 굳이 정의하자면 프로젝트 매니저랄까..

문화예술쪽에서는 콘텐츠를 만들고 운영하고

르완다에 있을 땐 프로젝트를 기획하고 운영했고

국제문화교류 기관에서는 문화교류 사업을 담당했었으니까

에듀테크에서 일할 땐 강사님들을 서포트했었으니까.


그래! 프로젝트 매니저라고 할 수 있겠다.


최근엔 앱/웹 서비스를 기획하는 서비스 기획자의 길을 걷기 시작했다.

나도 이제 누군가 무슨일 하세요?라고 하면 복잡 이것저것 설명할 필요 없이 "서비스 기회자요"라고 할 수 있다.   


교육을 받으면서 IT업계의 대화법을 익히고 있다.


배우면서 든 생각은 용어는 다르지만 어느 산업이나 비슷하다는 것이다(란 건 나만의 생각일 수도^^;;)

국제개발협력 분야에 있을 때 프로젝트 추진 전 PCP(project concept paper)라는 것을 작성하는데

일종의 제안서이다.  왜 그 사업이 필요한지, 타당성 조사도 하고 사업 추진 목적, 성과 지표 파악 등이 포함된 문서이다.

문화예술 사업을 담당했을 때에도 공공기관 양식에 서류를 작성했었는데 가설 검증까지는 아니더라도 사업 추진 배경, 사업 개요, 기대효과 등을 아주 세부적으로 작성해야만 했다.


이렇게 용어만 다르지 하는 일은 다 비슷하다는 것을 느끼며 최대한 이해하려고 노력중이다.

프로덕트 매니저 관련 책을 읽으며  새로 배운 내용을 정리해 본다.


기획서 작성

요구사항 정의서(PRD, product requirements documentation) : 해당 기능 또는 제품을 통해서 무슨 문제를 해결하고자 하는지, 문제의 중요성과 문제가 해결되었을 때의 효과를 어떻게 확인할 수 있는지에 대해서 기술한 문서 *요구사항 정의서와 원페이저를 혼용하여 사용하기도 함

 - 우리가 이 일을 해야 하는 이유는 무엇인가?

 - 이 문제의 접근 방향성은 어떠한가?

 - 이 문제의 올바른 접근인가?  

요구사항 정의서는 직면한 문제를 창의적인 접근으로 새로운 아이디어 내는 역할+요구사항에 대한 대응을 실행 가능한 아이디어로 구체화하는 역할이다.


화면 설계서 : 어떠한 방식으로 서비스를 제공할 것인지 한 단계 더 구체화한 문서, 와이어프레임이나 디자인 시안 포함하기도 함. 핵심은 의도하는 동작을 어떻게 구현할 것인지를 지술 용어로 풀어내는 것이다.


"기획리뷰를 한다", "스펙 리뷰를 한다"라는 표현을 사용하는데 이건 "기획서를 구두로 설명하는 것"이라는 뜻이다.


기획서 작성팁

- 기획서를 작성하기 전에 '누가', '언제', '왜'를 생각한다

- 시각적인 보조수단 활용

- 설명하고자 하는 순서대로 문서를 작성

- 문서 목차와 문서 변경 이력을 함께 제공

-관련 참고 문서에 대한 링크를 모두 제공



프로덕트 매니저는 제품을 만드는 사람이 아니라 그 제품을 통해서 어떤 가치를 사용자에게 전달할지를 고민하는 사람이다. 최선의 결정을 바탕으로 실험해보고 실패한 실험에서 배워서 다음을 진행하는 것이 프로덕트 매니저가 나아가는 방법이다.

프로덕트 매니저에 대한 표현이 있는데 온갖 고뇌와 결정에 무게가 있겠지만 "최선으리 결정을 바탕으로 실험해보고 실패한 실험에서 배워서 다음을 진행하는 것"이란 문구가 참 인상적이다.

비단 프로젝트 매니저 뿐 아니라 다른 분야에서 일을 하거나 일상을 살아갈 때에도 적용되는 말인 것 같다. 우린 수 많은 선택의 길을 마주하고 있고 매일 최선의 결정을 한다. 그것이 옳은 선택인지 아닌지는 당장 알 수 없다. 혹여나 잘못된 선택으로 실패를 하더라도 '인생 끝이야'라고 생각하기 보다는 이번을 기회로 더욱 단단해지고 인사이트를 얻으며 다음에는 더 나은 선택을 하는 것이 바람직한 것 아닐까 생각해 본다.



기본적인 용어들

- PV (pageview) : 특정 페이지의 방문 수(한 방문자가 N번 방문하면 N회로 카운트함)

- UV (unique visitors) : 순 방문자수(한 방문자가 여러 번 방문하더라도 한 명으로 카운트함)

- DAU(daily active use) : 일단위/ MAU(monthly active): 월단위

- 고착도 : 제품에 대한 사용자의 관심도를 DAU, MAU로 나눈 것/ 매월 방문한 사용자 중에서 매일 방문한 사용자의 비율

- 코호트 분석 : 특정 기준을 가지고 동질집단을 정의하고 각 집단을 비교하는 분석 기법

- 고객생애가치 : 한 명의 사용자가 기능 또는 제품을 더 이상 쓰게 되지 않는 이탈 시점 이전까지 제품에서 발생시킬 것이라 예상되는 매출을 의미

-리텐션 : 재방문율

유저스토리 : 사용자 관점에서 기능 또는 제품에 대한 요구사항을 명시하는 방법론(애자일 개발방법론의 하위 개념)

유저스토리와 요구사항의 차이점 : 유저 스토리는 사용자가 제품을 어떻게 사용하고 이를 통해 무엇을 느끼고 얻을 수 있는지에 집중  


제품 구현

제품 구현은 디자인 최종 시안-> 마크업-> 프런트엔드 및 서버 개발-> 테스트 및 QA-> 배포 순으로 이루어짐

마크업 : 이미지로 된 디자인이 코드로 된 웹페이지로 만들어지기 위한 연결고리와 같은 작업/ 마크업 페이지는 실제로 동작하는 것은 아니고 제품의 디자인을 코드 형태로 구현한 것

백로그 : 제품에서 구현이 필요한 기능 또는 프로젝트 안에서 처리해야 하는 과제의 세부 목록, 주로 각 과제를 이슈라고 함./ 각 이슈에 대한 설명 없이 요약만 나열한 목록 형태  


배포

배포는 2가지로 나뉜다.

1) 테스트 시나리오 : 배포 전 테스트에 필요한 사전 준비 사항 중심

2) 배포 시나리오 : 실제 서비스 배포를 진행하기 위한 시나리오 정리와 실제 배포 과정


1) 테스트 시나리오

시기 : 개발 완료 후 사용자에게 배포되기 전에 진행

목적 : 요구사항에 맞게 개발이 잘 진행되었는지, 예상치 못한 오류는 없는지 확인

그러나 모든 테스트에 테스트 시나리오가 필요한 것은 아니다

테스트를 진행할 페이즈

- dev : 최초 개발 작업을 진행하는 단계

- sandbox : 사내 외 유관 조직과 함께 개발/테스트를 진행할 수 있는 단계

- cbt : 실제 서비스에 배포하기 직전, 실제 서비스 환경에서 동작할 때 문제가 없는지 최종 학인할 수 있는 단계(실제 서비스와 동일한 DB를 사용)

- production(real) : 일반 사용자들에게 공개되는, 최종적인 실제 서비스 단계

테스트 케이스(test case): 테스트가 필요한 세부적인 항목을 정의한 것이고, QA명세서라고도 함


2) 배포 시나리오 : 실제 서비스 배포를 어떤 과정으로 어떻게 진행할지 정의한 것

몇 시간, 아무리 길어도 당일 안에 완료함

배포 시나리오에는 정확한 시점, 진행 순서, 배포 직후 문제 발생 시 배포 전 상태로 되돌리는 롤백에 대한 부분, 배포 당일 예상 가능한 이슈에 대한 대응 계획까지 포함

 

처음 보는 단어들 투성이인데

오늘은 여기까지!

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari