여행 앱 트리플,
기능 개선을 위한 스프린트 진행
[코드스테이츠 PMB 16기] 주간 과제 ⑦
＃ 아래의 내용은 코드스테이츠 PMB 16기 과정 중 주간 과제를 수행하기 위한 학습 과정입니다.
＃ 과제 목표 : 가상의 애자일 팀의 스프린트 플래닝 진행 준비를 위한 절차를 경험해보고 문서로 정리하기
＃ 나만의 여행 가이드북 '트리플(TRIPLE)' 분석 ···· 주간 과제 1편 다시 보기
＃ 트리플은 해외 출발 편도 항공권 발권 기능이 없다? ···· 주간 과제 2편 다시 보기
＃ 트리플 앱에 새로운 기능을 추가해보기 ···· 주간 과제 3편 다시 보기
＃ 여행 앱 트리플의 성장 전략, 고객 유입 분석 살펴보기 ···· 주간 과제 4편 다시 보기
＃ 여행 앱 트리플을 개선하기 위한 지표와 검증 방법 ···· 주간 과제 5편 다시 보기
＃ 여행 앱 트리플은 어떻게 성장(Scale-Up)해왔을까 ···· 주간 과제 6편 다시 보기
-. 생각을 어떻게 실체화시킬 것인가?
지난 6주 간 저는 여행 가이드북 앱 '트리플(TRIPLE)'을 나름의 관점으로 분석하고, 어떻게 성장을 해왔는지 살펴보았습니다. 그동안의 과제에서는 서비스의 성장과 개선점을 찾는데 포커스를 맞춰왔다면, 오늘은 그동안 분석한 내용을 어떤 절차를 걸쳐 개선을 하게될 지 정리해보고 실제 액션을 위해서는 어떤 준비를 해야하는 지 살펴보려고 합니다.
대부분의 개발 조직들은 제품 개발을 위한 방법론으로 워터폴(Waterfall)과 애자일(Agile), 2가지의 방식 중 하나를 선택합니다. 워터폴 방식은 말 그대로 폭포수가 아래로 떨어지듯, 각 기능 조직(기획, 개발, 디자인, QA 등) 별로 프로세스를 거치며 설계를 하고, 구현해서 테스트하고 배포를 하는 방법론입니다.
워터폴 조직은 변경의 여지가 적고, 안정적인 요구사항을 가진 프로젝트에 적합합니다. 하지만 상대적으로 기능 조직 간 피드백이 다소 부족할 수 있습니다. 특히 중간에 요구사항이 변경되거나 하는 경우, 다시 처음으로 돌아가 기획 단계에서부터 시작해야하는 만큼 제품 개발에 유연성이 다소 떨어질 수도 있는 방법론입니다.
오늘 과제에서 주로 다루게 될 애자일 조직은, 개발 프로세스를 진행하면서 지속적으로 팀원들에게 피드백을 받아 결과적으로 검증 가능한 솔루션을 빠르게 제공하며 일하는 방식입니다.
워터폴 조직에 비해 이슈 발생에 대한 유연성이 뛰어나며, 그만큼 시장이나 고객의 요구사항 변화에 빠르게 대응할 수 있습니다. 애자일하게 일하는 방법으로 전력질주를 의미하는 스프린트(Sprint)를 주로 사용하는데, 스프린트를 통해 팀 내에서 스스로 개발 진행 상황을 평가하고 프로덕트 개발이라는 최종적인 목표를 달성할 수 있습니다.
오늘은 코드스테이츠 PMB 주간 과제 7주차로서, 그동안 트리플에 대해 분석하고 개선점을 도출했던 것을 실제로 구현하기 위해서는 어떤 절차를 거쳐야 하는가?를 정리해보려고 합니다.
-. User Story를 기반으로 한 문제 정의
현재 프로덕트의 상황에서 개선해야 할 문제는 무엇인지 정리합니다.
저는 지난 5주차 주간 과제에서 정리했던 트리플의 강점을 강화하고, 약점을 개선하는 방법에 대해 고민했던 내용을 기반으로 이후 과제를 진행해보려고 합니다.
지난 과제에서 저는 트리플의 모든 BM 요소가 핵심 기능인 '여행 일정 만들기'와 연동되어 이루어지기 때문에, 이 기능의 사용성을 좀 더 강화하여 고객들이 처음 앱 설치를 하는 경우 일종의 튜토리얼을 먼저 제공하고, 그 흐름에 따라 고객이 핵심 기능을 체험할 수 있도록 하는 방법을 제안했었습니다.
트리플의 핵심 기능 '여행 일정 만들기'
트리플 기능 개선안 '튜토리얼 만들기' 예시강점을 강화하는 방법을 User Story(*하단 참고)의 관점으로 표현해본다면 아래와 같습니다.
트리플을 처음 이용하는 고객들은
접근성이 높은 여행 일정 만들기 기능을 써보기 위해
낯선 기능에 적응 할 수 있는 새로운 기능(요소) 추가를 원합니다.
경쟁 앱 서비스들은 GNB나 사이트맵처럼 기능 전체를 확인할 수 있는 별도의 페이지(또는 기능)가 존재하지만, 트리플은 홈 화면에 그러한 기능이 존재하지 않습니다. 오히려 가장 눈에 띄는 곳에는 '여행 일정 만들기' 버튼이 존재하고 있죠. 또한 고객들은 다른 서비스와 다른 UI를 가지고 있는 트리플에 다소 낯선 느낌을 가질 수 있습니다.
** 참고 : User Story
User Story는 애자일 개발 방법론을 채택한 기업에서 제품 개발 시 사용하는 도구 중 하나로, 소프트웨어 개발 프로젝트에서 기능 또는 기술을 개발할 때, 최종 사용자가 무엇을 원하는지 명시하는 짧은 글로써 프로덕트 팀이 최종 사용자의 관점에서 제품(또는 기능)을 개발할 수 있도록 돕는 것을 목적으로 합니다.
그렇다면 약점을 보완하려면 어떻게 해야 할까요? 우선 트리플 서비스의 가장 아쉬운 부분은 수익성입니다.
실제로 트리플은 2021년 기준 130억의 영업적자를 기록했습니다.
그만큼 수익성 개선은 서비스의 장기적 운영을 위해 시급히 해결해야 할 과제이기도 합니다.(물론 야놀자 인수를 통해 급한 불은 껐지만, 자체 서비스에서 지속적인 적자가 발생한다면 서비스 지속 측면에서 불투명할 수 밖에 없습니다.)
이러한 기업의 니즈도 유저 스토리의 형식으로 적어본다면 아래와 같습니다.
트리플의 제품 개발팀(또는 비즈니스팀)은
셀프 패키지 활성화를 통해
고객들이 앱 내에서 여행에 필요한 많은 것(숙박, 항공권 등)들을 구매하여 수익성이 개선되길 원합니다.
실제로 강점에서 이야기했던 '여행 일정 만들기' 기능은 트리플의 핵심 기능인 만큼, 대부분의 BM 요소가 여행 일정을 고객이 짜는 것과 연동되어 있습니다. 이를 돕기 위해 여행 일정 기반 패키지 BM인 '셀프 패키지'도 존재하고 있죠.
셀프 패키지 개선안제가 생각했던 아이디어는 사실 큰 변화를 주는 아이디어가 아님에도 불구하고, 효과적일지 모른다는 생각을 했습니다. 다만 왜 그동안 트리플은 이렇게 변화를 주지 않았을까 추론해본다면, 트리플은 광고가 타 여행 그만큼 고객의 입장에서 사용성에 집중한 서비스여서 그런 것이 아닐까 판단했습니다.
그동안의 트리플의 행보를 살펴보면 수익성을 강화하기보다는, 더 많은 고객들이 트리플에 유입될 수 있도록 기능을 추가하고 사용성을 개선하는데 집중해왔습니다. 그렇기에 프로덕트를 고도화하는데 우선순위의 차이이지 않을까 추론해보았습니다. (지난 과제 멘토님 피드백에 대한 답변)
-. User Story를 기반한 세부 기능 작성해보기
정의된 문제와 유저 스토리를 기반으로 개선/개발/구현해야할 기능을 작성합니다.
위에서 다양한 user story를 정리했지만, 실제로 이러한 문제를 해결하기 위해서는 PM 혼자서는 아무것도 할 수 없습니다. 개발자와 디자이너 등 다양한 전문가들이 모인 프로덕트 팀에서 이 문제들을 해결할 수 있습니다.
이런 문제들을 해결하기 위해 애자일 개발 방법론에서는 유저 스토리와 카노 모델(Kano model)을 활용하여 고객의 니즈를 다면적으로 판단할 수 있습니다.
카노 모델** 참고 : 카노 모델(Kano model)
카노 모델(Kano model)은 고객의 니즈와 선호도를 이해하고, 제품 개발과 제품 구성 기능의 품질을 관리하는데 사용되는 모델입니다. 이 툴을 통해 자사 프로덕트 기능과 기능에 대한 품질, 고객 만족도를 파악하고 때로는 새로운 아이디어를 구체화하거나 스프린트 과정에서 우선순위를 정하는데도 활용할 수 있습니다.
유저 스토리와 카노 모델은 고객의 니즈를 파악한다는 점에서 공통점을 가지고 있지만, 카노 모델은 제품의 특성을 기반으로 고객의 니즈를 파악한다는 점에서 약간의 차이가 있습니다.
카노 모델은 크게 5가지 요소로 구성되는데, 자세한 내용은 아래와 같습니다.(출처 : shiftasia, medium)
1. 필수 품질(Must-be Quality)
고객들이 제품에 기대하는 기본적인 요소(기능)입니다. 이는 고객의 요구사항을 충족하기 위해서 필수적으로 있어야 하는 요소이며, 해당 요소를 충족하지 못한다면 고객의 불만을 야기시킬 수 있습니다.
2. 일차원적 품질(One-dimensional Quality)
고객 만족에 직접적인 영향을 미치는 기능입니다. 성능이 우수할수록 고객 만족도가 높아집니다. 기능의 성능에 대한 만족도는 성능 수준에 비례합니다.
3. 매력적인 품질(Attractive Quality)
필수는 아니지만 있으면 좋은 기능을 말합니다. 이 범주에 해당하는 기능이 많을수록 고객들에게 더 매력적인 품질의 제품으로 인식됩니다.
4. 무관심한 품질(Indifferent Quality)
고객의 만족도에 영향을 미치지 않는 요소를 이야기합니다. 예를 들어 개발자가 사용자에게 중요하지 않은 디자인 요소를 변경하는 경우가 해당됩니다. 이와 같은 고객의 관심과 동떨어진 영역에서의 서비스 개선은 고객만족에 영향을 미치지 않으며, 결국 시간과 노력의 낭비가 될 수도 있습니다.
5. 역 품질(Reverse Quality)
제품에 있는 경우, 고객들이 오히려 싫어하는 기능입니다. 예를 들어, 이전에 표시되지 않았던 광고가 내가 쓰는 앱에 표시되는 경우가 적절한 예입니다. 기업이 광고로 인한 매출을 증가시키는 장점이 있지만, 서비스의 평판이 흔들릴 수 있는 문제도 있습니다.
유저 스토리와 카노 모델을 함께 활용한다면, 고객의 만족도에 따라 유저 스토리의 우선 순위를 지정할 수 있습니다. 다시 말해 고객이 무엇을 진정으로 원하는지에 대한 인사이트를 얻을 수 있으며, 스프린트를 통해 고객에게 가장 필요하고 매력적인 기능을 우선적으로 제공할 수 있습니다.
해당 내용을 기반으로 카노 모델을 접목한 PRD(제품 요구사항 문서)를 작성해보았습니다.
다만 여기서 셀프 패키지에 대하여 고객들이 매력적인 품질의 기능(Attractive Quality)으로 생각할 지에 대해서는 과제를 하면서도 고민이 있었습니다. 또한 PRD는 PM이 작성하지만, 작성 이전에 이해관계자들과의 많은 커뮤니케이션을 거쳐 산출물이 나오게 됩니다.
고객에게 BM요소를 소개하는 것이기 때문에 오히려 역 품질(Reverse Quality)로 평가받을 여지도 있지만, 해당 서비스는 서비스를 이용하는 고객들에게 오히려 할인 혜택에 대해 설명하고 알린다는 측면에서 긍정적인 부분이 있다고 판단하고 해당 내용을 작성했습니다.
또한, 해당 PRD에는 서비스 목표와 기능 개선 컨셉, 이번 기능 개선에 대한 서비스 타겟을 설정하여 부족분을 보완하였습니다.
-. 정리한 내용으로 Jira에 정리해보기
위에서 계속 정리한 내용을 실제로 실현시키기 위해 프로젝트 관리 툴인 Jira에 PRD에 적혀있는 요구사항을 등록해보고 스프린트를 진행하기 위한 내용들을 정리해보았습니다.
먼저 스프린트를 진행하기 위해서는 PRD에서 작성한 요구사항을 백로그에 먼저 정리합니다. 이 과정에서 해당 업무 담당자를 설정하고 업무 기한, 상세 설명을 정리합니다.
이렇게 백로그에 정리한 이슈들을 묶어서 스프린트를 진행합니다.
그리고 스프린트를 진행하기 위해 백로그 내 이슈들을 묶어서 스프린트 목표와 스프린트 기간을 설정한 뒤 시작을 합니다.
이렇게 시작된 스프린트는 jira 내 대시보드에서 확인할 수 있고, 스프린트 외에 업무들은 대시보드에 '에픽'을 생성해 백로그 내 이슈를 끌어와 연동할 수 있습니다.
-. 마무리하며
그동안 주간과제를 7주 간 진행하면서, 서비스를 다방면으로 분석하고, 서비스의 문제점(또는 개선점)을 파악하고, 새로운 제안사항을 정리했습니다. 그리고 그 제안사항을 기반으로 PM이라면 어떻게 업무를 하게 될 지 다양한 방법을 통해 학습해보았습니다.
그동안의 과제도 쉽지 않은 여정이었지만, 특히 오늘 과제는 마지막 과제답게 그동안의 내용을 종합해서 해야하는 과제였기에 더욱 쉽지 않았습니다.
또한, 산출물만으로는 제가 생각하고 있는 것을 이해관계자들과 커뮤니케이션 하기가 정말 쉽지 않다는 것을 느꼈습니다. 8주 교육은 마무리되고 이제 팀프로젝트에 들어가지만, 부족함을 많이 느끼고 더 성장을 게을리하지 않아야겠다는 다짐을 하며 과제를 마무리합니다.
