웹뷰어 탐색과 이해관계자, 그 관계성 살펴보기
[코드스테이츠 PMB 10기] 스크럼과 이해관계자
리디북스 웹뷰어
이해관계자들에게는 어떤 요구가?
1. 이해관계자들과의 소통
(*이번 글은 위의 포스팅과 이어집니다.)
이전 포스팅에서 리디북스의 뷰어 기능을 탐색하면서 왜 이 기능을 추가했을지를 유저스토리와 백로그를 기반으로 생각해보았다. 그래서 이번에는 해당 기능을 개발할 때에 이해관계자는 누가 있을지, 그리고 그들의 요구사항은 무엇일지 수집해보도록 하겠다.
여러 이해관계자들
그렇다면 애자일 팀에 주요 이해관계자들은 누가 있고, 그들은 보통 어디에 관심을 가질까?
C-Level (경영진)
프로덕트의 고위 경영진 (C-레벨 임원 등)은 PM를 프로덕트 성공에 대한 최종적인 책임과 의무가 있는 사람으로 인정하고 바라본다. 그리고 이들이 PM에게 최종적으로 원하는 것은 프로덕트가 고객가치를 만족하는 동시에 기업가치 또한 만족시키도록 만드는 것이다.
그러므로 이들은 주로 ROI나 시장점유율처럼 프로덕트의 성공 척도를 요구할 것이며 원활히 개발되고 있는지에 대해 관심이 많을 것이다.
Scrum Team (스크럼 팀)
팀은 PM이 고객에게 가장 적합한 프로덕트를 만드는 데 도움을 주기 위해 존재한다. 그러므로 팀원들은 PO가 다음에 무엇을 개발해야 할지를 알고, 이미 개발했던 것의 목적은 이루었는지를 확인하고 싶어 할 것이다.
Scrum Master (스크럼 마스터)
스크럼 마스터는 PM을 적극적으로 도와 스크럼 팀의 업무가 원활히 진행될 수 있도록 해야 하고, 업무에 방해가 되는 요소들을 알고 개선해야 한다. 또한, PM이 프로젝트에 잘 적응할 수 있도록 도움과 피드백을 줘야 한다. 그러므로 이들은 프로젝트에 문제가 없는지, 방해되는 요소는 없는지를 확인하고 싶어 할 것이다.
Customer (고객)
프로덕트의 성공 여부는 결국 고객에 의해 결정된다. 그러므로 프로덕트를 개발할 때에 고객의 의견을 듣는 것은 매우 중요하다. 고객들은 자신이 필요로 하거나 관심 있어하는 프로덕트를 언제 얻게 될지를 궁금해한다. 그리고 만일 백로그의 우선순위가 정해졌다면 그 배경이 어떻게 되는지, 그 이면에 대해서 의문점을 가질 것이다.
2. 리디북스에 대입하기
유저스토리와 백로그
그렇다면 실제 리디북스의 사례에는 어떻게 적용이 될지 알아보도록 하겠다. 이전 포스팅에서 정의한 유저스토리는 다음과 같다.
간략히 그 배경에 대해 설명을 하자면, 리디북스에서는 원래 다른 새로운 소설을 탐색하고 싶어도 해당 기능이 없어 모바일 웹으로 리디북스 홈페이지를 이용해야 했다. 또한 iOS와 안드로이드를 개별적으로 개발하는 네이티브앱 형 형식을 이용했기 때문에 두 버전간 업데이트 차이도 심했다. (*실제로 아이폰 유저인 나의 경우, 리디셀렉트의 기능을 앱 내에서 사용할 수 없었다. 하지만 웹 서칭을 해보았을 때 안드로이드 버전에서는 해당 기능이 앱 내에 포함된 것으로 보인다.)
이러한 기능적 차이는 고객들에게 새로운 웹소설을 더 많이 보여주고 구매하도록 만들어야 하는 리디북스 입장에서 마이너스적인 요소이다. 그래서 리디북스 팀은 앱 내에서도 웹소설 탐색을 할 수 있도록 리액트 네이티브를 활용하여 모바일 웹 기능을 가져오고자 하였다.
그리고 그들이 해당 기능을 구현하기 위해 작성한 백로그를 나름대로 가정하여 다음과 같이 만들었다.
하지만 이 백로그는 많이 잘못되었을 가능성이 다분한데, 기능적으로 해석이 부족한 부분이 많기 때문이다. 일례로, 리디북스가 탐색 뷰 연동을 위해서 API를 사용하고 리액트로 여러 기능들을 구현했을 텐데 이를 단순히 '탐색 뷰 연동'의 task로만 만들면 기한적으로 부족할 가능성이 높다.
그래도 리디북스 앱의 코드를 까볼 수는 없기에 뭉뚱그려 표현을 해놓았다.
리디북스 웹소설
탐색 기능 속 이해관계자
위의 유저스토리와 백로그를 기반으로 리디북스의 특성에 맞게 이해관계자를 뽑고 요구사항을 정리해보았다.
C-Level (경영진)
C-Level들에게 해당 웹뷰어 기능은 어떤 시사점을 줄 수 있을까. 웹뷰어는 유저의 사용편리성을 위한 것이기도 하지만, 결국 소비자들이 더 많은 작품들을 탐색하고 구매를 하도록 유도하기 위해 구현한 것이다. 그러므로 C-Level은 유저들이 앱 내에서 더 많이 머물고, 더 많이 결제가 되었는가를 확인하고 싶지 않을까?
요구사항
이번 기능으로 리디북스 사용자들이 앱 내에서 더 많이 머물렀으면 좋겠습니다.
사용자들이 앱 내에서 더 많은 작품들을 만날 수 있도록 큐레이션이 되어 있나요?
모바일 웹에 비해 앱 내에서 결제한 비율은 얼마나 되나요?
Scrum Team (스크럼 팀)
스크럼 팀은 어떨까? 스크럼 팀은 주로 개발자들이 포진해있기 때문에 앞서 말했듯 기능의 개발이 잘 끝났는지, 그리고 앞으로 무엇을 개발해야 할지를 PM에게 많이 요구할 것이다.
백로그에서 API 연결이 조금 시간이 걸릴 것 같아요. 일정 조율 가능한가요?
우선순위 부분로 로맨스판타지 웹소설과 e북 모두 먼저 되어야 할 것 같아요. 논의해볼 수 있나요?
웹탐색을 할 수 있다면 결제 기능도 불러올 수 있어야 할 것 같아요. 이 부분에 대해서 논의된 게 있나요?
해당 웹뷰에서 다운로드되었을 때 내서재에서 바로 볼 수 있도록 기능조치를 해야 할 것 같아요. DB 연동관련해서 발생할 수 있는 오류가 있을까요?
Customer (고객)
리디북스는 웹소설 IP를 작가들에게 가져와 독자들에게 파는 것이므로 고객군은 작가와 독자로 구분 지을 수 있다. 작가의 경우, 자신의 웹소설이 잘 큐레이션이 될지, 또는 독자들의 눈에 잘 띌지를 알아보고 싶을 것이다. 반대로 독자의 경우, 해당 기능이 언제 출시되는지 그리고 기능의 편리성이 가장 큰 관심사가 아닐까?
작가
큐레이션은 어떤 식으로 되나요?
왜 웹소설 뷰어를 연동하는게 더 우선이 되어야 하나요?
독자
웹뷰어 탐색 기능은 언제 릴리즈되나요?
어떤 버튼을 눌러 앱에서도 소설을 탐색할 수 있나요?
키워드로 검색하기가 불편한 것 같아요. 제가 원하는 키워드를 따로 선택할 수는 없나요?
이해관계자들과
원활하게 소통하기 위해
하지만 위처럼 수많은 요구사항이 나온다하더라도 그 모든 요구들을 다 들어줄 수는 없다. 왜냐하면 해당 기능을 만드는데 시간도 걸릴 뿐더러 인력이나 리소스 차원에서도 부족할 수 있기 때문이다.
그래서 이해관계자들과의 소통 중 유의해야할 점을 정리해보고 PM은 어떤 태도를 가져야 할 지 생각을 해보고자 한다.
프로덕트의 철학
첫째로 프로덕트의 본질, 그 철학을 잊어서는 안된다. 스크럼 팀이 프로덕트를 개선하고 개발하는 이유는 무엇보다 고객의 니즈, 고객의 문제를 해결하기 위해서이다. 이 말은 곧 프로덕트가 처음 출시되었을 때 어떠한 문제점을 해결하고자 하였는지를 망각해서는 안됨을 의미한다. 만일 프로덕트의 기본 철학을 잃어버리게 된다면, 기존에 추구하고자 했던 방향성이 사라지고 그저 여기저기서 좋다는 것을 이어붙인 누더기 손수건과 다름 없을 것이다.
리소스 관리
둘째로 리소스 관리에 신경을 써야 한다. 애자일하게 일한다는 것은 곧 예상 시점에 목표를 달성해야 한다는 것이다. 만일 개발이 제기간이 끝날 수 없을 것 같다면 린하게 정말 중요하지 않는 몇몇 요구사항들을 덜어내야 한다. 또한 더 원활한 리소스 관리를 위하여 개발 언어, 빌드 주기, 개발 도구 등 스크럼 팀의 가장 기본적인 규칙을 내부에서 협의해야 할 것이다.
투명한 정보 공유
마지막으로 모든 이해관계자들은 투명하게 정보 공유를 해야 할 것이다. 이는 첫 기획부터 개발이 완료될 때까지 모든 기간에 해당하는 말이다. 즉, 기획을 할 때에는 프로덕트의 컨셉이나 방향성에 대해서 이해가 되지 않는 부분이 없이 충분한 논의가 진행되어야 하고, 개발 기간 중에는 어떤 문제사항이 있는지 기간 내에 개발을 할 수 없다면 그 이유는 무엇인지에 대해 서로 상세히 알아야 한다. 왜냐하면 내부에서 혼란이 생긴다면 프로덕트가 원활히 개발될 수 있는 확률은 요원하기 때문이다.
참고 자료.
