코드스테이츠 PMB 11 | 나는 나와 싸운다

애자일 VS 워터폴

애자일(Agile) 프로세스는 빠르게 발전해야 하는 소프트웨어의 등장과 함께 대두된 제품 개발 방법론 중 하나이며 전통적인 방식인 워터폴(Waterfall) 프로세스와 비교된다. 이름 그대로 폭포수처럼 Top-Down 방식으로 진행되는 워터폴 방식은 제품 기획부터 출시까지 미리 설정된 전반전인 계획에 따라 제품을 개발한다. 이에 반해 애자일 프로세스의 경우 고객의 니즈, 상황에 맞추어 유연하게 계획을 수정하여 필요한 부분부터 차근차근 만들어간다. 

 

애자일을 프로세스의 핵심적인 3가지 도구인 스크럼, 유저 스토리, 칸반을 잘 활용한다면 반복적이고 사람 중심적으로 제품의 지속적인 향상을 도모할 수 있다. 

 

이름	내용
스크럼	목적지 도달을 위해 하나로 뭉쳐 움직이는 형태를 나타내며 럭비 용어에서 유래되었다.
유저 스토리	해결해야하는 고객의 문제를 프로덕트 팀의 입장이 아닌 '고객'의 입장에서 '누가, 왜, 무엇을' 순으로 서술한 것
칸반	해결해야할 문제를 카드를 통해 시각화한 프로세스. 왼쪽에서 오른쪽으로 진행상황을 표현하며 효율적인 작업 조율 기대가능

 

애자일 프로세스 적용하기 

코드스테이츠 PMB 11기 | '샤잠'하다

지난 과제에서 샤잠의 실제 사용자의 입장에서 불편한 UX를 직접 꼽은 적이 있다. 이번 학습에서 배운 애자일의 대략적인 프로세스를 활용하여 나의 불편함을 내가 직접 해결해보겠다. 

 

| 샤잠의 불편한 UX

샤잠은 오디오 기반 음악 검색 서비스이다. 샤잠은 사용자가 전화기에 '2508'이라는 다이얼을 누르고 노래를 들려주면 SMS로 결과를 알려주는 서비스로 시작되었다. 앱스토어의 등장과 함께 2008년 앱으로 출시된 샤잠은 10년이 넘는 시간 동안 약 10억 명 이상의 사람들이 사용하였고, 2018년에는 애플에 인수되었다.

 

애플에 인수된 샤잠은 IOS의 제어센터에 '음악 인식'이라는 이름으로 한 자리 차지했고, 검색 결과를 애플의 음악 스트리밍 플랫폼인 애플뮤직에서 곧바로 재생될 수 있도록 하는 등 사용성이 크게 좋아졌다. 또한 '음악 검색'이라는 본연의 기능에 집중하여, 한 번의 버튼 클릭이라는 직관적인 방법을 통해 다양한 음악을 빠르게 찾아주는 것이 샤잠의 강점이다.

 

샤잠으로 검색한 음악은 검색한 날짜와 시간, 제목, 아티스트의 정보를 담은 히스토리로 남아, 사용자가 과거 검색한 음악을 쉽게 찾을 수 있도록 하였다. 해당 기능과 비슷한 맥락으로 최근에는 검색한 곡의 아티스트만을 따로 모아서 보여주는 기능을 추가했다. 자신의 취향인 음악을 흘려보내지 않기 위하여 샤잠을 이용해 음악을 검색하는 사용자라면 아티스트에 대한 관심도 있을 것이다. 사용자의 특성을 고려하여 잘 만들어진 기능이었지만 한 가지 문제점이 발견되었다.

 

샤잠의 사용자는 자신의 음악 검색 히스토리를 직접 삭제하는 식으로 관리할 수 있었지만, 아티스트 목록에서는 해당 기능이 부재했다.  자신이 검색한 아티스트 목록을  들여다보는 사용자라면 이것을 능동적으로 관리하기를 원할 것이다. 

 

 

| 문제 해결을 위한 유저스토리 정의

 

해당 문제점을 유저 스토리 형식으로 정의해보았다.

 

 

[샤잠의 아티스트 목록 기능을 이용하는 사용자]는
[선호하는 아티스트를 관리하기] 위하여
[아티스트 목록 관리 기능]을 원할 것이다. 

 

 

애자일 프로세스에서 유저 스토리를 정의할 때, 프로덕트 팀과 더불어 다양한 이해관계자들이 개입되기 때문에 해결해야 할 문제를 모두가 이해할 수 있는 언어로 확실하게 표현하는 것이 중요하다.

 

프로덕트 팀이 제품 배포 과정에 있어서 해결해야 할 유저 스토리의 개수를 Capacity라고 일컫으며, 전반적인 프로세스를 염두한 채 시간, 리소스와 같은 기준으로 Capacity의 범위를 올바르게 설정해야 한다. 

 

 

 

 

| 유저 스토리 해결 위한 백로그 정의

유저 스토리를 해결하기 위한 백로그를 정의했다. 

 

기능	내용	담당	우선 순위
화면 디자인	선택 버튼, 삭제 버튼 디자인	디자인	2
프론트엔드 작업	선택 버튼 클릭 시 삭제와 추가 버튼 클릭할 수 있도록 설계	프론트엔드	2
팝업 문구 작성	삭제 시 확인 팝업 문구 작성	PM	3
API 개발	삭제 시 사용자의 아티스트 목록에서 제거	백엔드	1

 

만일 프로덕트에서 해결해야 할 백로그가 쌓여 있다면, 적극적인 커뮤니케이션을 통해 우선순위를 확실하게 정하는 것이 중요하다.

 

 

마지막으로 유저 스토리를 해결하기 위하여 칸반 형식으로 작성하여 작업 프로세스 전체를 팀원들과 공유하면서 현재 업무 양, 진행 정도, 목표 달성 정도를 모두가 확인할 수 있도록 했다. 

 

 

| 이해 관계자 (Stakeholder)

프로덕트의 이해관계자란 기획부터 출시까지 전 범위에 걸쳐 프로덕트와 관계를 맺은 모든 사람을 의미한다. 잠재고객, 이탈 고객을 모두 포함한 고객군부터 경영진, 제품팀, 투자자까지 한 프로덕트에는 수많은 이해관계자가 얽혀있다. 다양한 이해관계자들의 의견을 적극적으로 수집하여 프로덕트가 올바른 방향으로 나아갈 수 있도록 조율하는 것이 필요하다.

 

stakeholders

 

각 이해 관계자의 요구

프로덕트팀 

본질적으로 기능을 추가하는 것이기 때문에 가장 직접적인 이해관계자가 될 수 있다. 백엔드 담당자는 추가/삭제 API를 개발하여 클라이언트와 서버가 올바르게 데이터를 주고받을 수 있도록 해야 하며, 프론트엔드 담당자는 사용자의 행동에 따라 목록이 정리가 될 수 있도록 기능을 올바르게 구현해야 한다. 

 

PM과 더불어 고객의 요구사항을 직접적으로 수행하는 입장이기 때문에, 이들 또한 문제 해결의 당위성을 요구할 것이다. 가장 우선적으로 해결해야 할 문제로 선정된 것에 대한 충분한 설명이 동반되어야 그들을 설득할 수 있다. 이때 유용하게 사용할 수 있는 것이 유저 스토리 기법을 활용한 의사소통이다. 

 

경영진

경영진의 요구사항은 PM과 마찬가지로 '문제 해결로 인해 최종적으로 사업가치와 고객가치가 증가할 것인가?'일 것이다. 잠재고객부터 현재 고객, 이탈 고객을 포함한 고객군의 행동 파악과 데이터 분석을 통하여 가설을 수립하고, 기대되는 지표의 긍정적인 개선을 근거로 경영진을 설득할 수 있어야 한다. 

 

 

이해관계자의 요구를 해소하기 위하여 유의해야 할 점

각 이해관계자의 요구를 프로덕트에 도움이 되는 방향으로 해소하기 위해서 반드시 유념해야 할 점은, 각 이해관계자의 요구는 모두 다르고 모두를 만족시킬 수 없다는 점이다. 각 요구사항을 고객가치, 비즈니스 가치와 같이 명확하게 설정된 목표에 따라 우선순위를 정렬하여 진짜 문제를 해결하는 것에 집중해야 한다. 

 

또한 각 이해관계자들의 요구를 올바르게 이해하기 위하여 PM은 의사소통을 위한 공부를 계속해야 한다. 각 이해관계자의 입장을 충분히 이해하고 시선을 놓치지 않아야만 커뮤니케이션 과정에서 범할 수 있는 오류를 줄이고, 모두가 공감할 수 있는 합리적인 우선순위를 설정할 수 있다. 

 

 

---

참고자료

애자일 vs 워터폴··· 프로젝트 방법론 비교하기 | https://www.ciokorea.com/news/166830