brunch

브런치북 오늘 프로덕트 매니저가 되었다 12화

라이킷 7 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by YB Apr 10. 2021

고객 경험을 중심으로 제품 개발을 관리하자

애자일 기반으로 제품화테스크를관리하는 법

-

고객 경험 중심의 제품 개발방식, 애자일(Agile)

제품 요구사항을 확정 지었다면 본격적인 디자인, 개발을 진행하게 된다. 프로덕트 매니저는 고객에게 제품을 제공할 배포 일정을 정하고, 메이커들이 수행할 테스크를 생성하고 관리한다. 모바일 시장에서는 고객, 기술, 비즈니스의 변화가 빠르다. 점차 많은 IT 조직들이 기획, 디자인, 개발 단계가 단계적으로 구분된 워터풀(Waterfall)이 아닌 고객 경험을 중심으로 유연하게 제품을 구현하는 방식인 애자일(Agile)을 채택한다.

앞선 2가지 방식은 제품의 목적과 특성에 따라 선택이 다를 수 있다. 워터풀은 제품에 요구되는 기능이 매우 구체적이고 변하지 않을 때 적합하다. 모든 요구사항을 기획 단계에서 확정 짓고 제품의 높은 완성도와 진행단계별로 프로젝트를 관리하는데 집중하기 때문이다. 예로 온라인 쇼핑몰에서 욕설, 거래 제재 품목 등 검색되지 말아야 할 키워드를 관리하는 시스템은 워터풀이 적합할 수 있다.

반면 목적을 달성하는데 제품의 특성과 기능이 바뀔 수 있다면 애자일이 적합하다. 애자일은 목표한 고객 경험을 구현하고자 짧은 주기로 기획, 디자인, 개발을 반복적으로 수행한다. 워터풀보다는 유연하게 제품을 구현하며 단계별로 모든 리소스를 투입하지 않아도 된다. 빠르고 다양하게 변화하는 모바일 시장에 적합하며, 소프트웨어를 다루는 프로덕트 매니저라면 애자일에 주목할 필요가 있다.

애자일에서는 에픽, 스토리, 테스크로 업무를 관리한다

애자일은 고객의 요구사항에 맞춰 제품을 점진적으로 개선하는 방식이라고 했다. 제품 개발의 시작과 끝이 정해져 있지 않다. 개선할 문제를 지속적으로 검토하고 제품에 반영하게 된다. 따라서 작업 단위도 고객 경험을 중심으로 생성하고 관리한다.

크게 에픽, 스토리, 테스크로 구분한다. 대게 하나의 요구사항은 스토리에 해당한다. 스토리(Story)는 제품이 달성할 고객 경험을 말한다. 예로 '상품 상세 페이지에 진입한 유저는 구매 이력에 따라 추천 상품을 확인할 수 있다'가 하나의 스토리가 된다. 이런 스토리들이 합쳐져 달성할 목표가 에픽(Epic)이다. 앞선 스토리는 '유저의 탐색 경로에서 다양한 개인화 추천 상품을 제공한다'라는 에픽에 포함된다.

스토리를 제품으로 만들기 위해 필요한 업무를 테스크(Task)라 한다. 앞선 스토리는 '구매이력 기반의 추천상품 알고리즘 구현', '추천 상품을 클라이언트에 전송하는 API 구현' 등의 백엔드 테스크, '서버에 전달받은 추천 상품을 화면에 노출'하는 프런트엔드 테스크 들로 구성된다.

에픽, 스토리, 테스크의 구성체계

스크럼으로 제품 개발을 점진적으로 관리한다

애자일에서는 제품 개발의 명확한 데드라인이 없다. 대신 스크럼(Scrum)으로 팀을 만들고 제품을 반복적으로 개선한다. 스크럼은 하나의 제품 목표를 중심으로 기획, 디자인, 개발 등의 제품 담당자가 소규모로 이룬 팀을 말한다. 스크럼에서 제품 개발은 2~4주 단위로 짧은 호흡이 반복적으로 진행된다. 하나의 개발 사이클을 단거리 질주에 비유하여 스프린트(Sprint)라 부른다.

애자일 개발 프로세스

매 스프린트에서 진행 중인 테스크를 확인하고, 새로운 요구사항을 검토하고, 우선순위를 결정하고, 테스크를 수행하는 과정을 진행한다. 이 과정을 이끌며 의사결정을 내리는 직군을 프로덕트 오너(Product Owner)라고 부른다. 완전히 동일하지 않지만 우리가 알고 있는 프로덕트 매니저, 서비스 기획자 역할을 스크럼에서 프로덕트 오너가 수행한다.

앞서 설명한 에픽, 스토리, 테스크를 스크럼에 적용해서 이해해보자. 프로덕트 오너는 분기/반기 단위로 제품 로드맵을 수립하고 이를 달성할 에픽을 결정한다. 이후 에픽을 구체화하기 위한 스토리를 생성하고 제품 요구사항을 작성한다. 스크럼을 포함해 여러 이해관계자에게 요구사항을 공유하고 대략적인 배포 시점을 정한다. 스프린트를 시작하기 전에 플래닝 미팅으로 진행할 테스크를 생성하고, 매일 10~15분 단위의 스탠드업 미팅으로 가볍게 진행 상황을 체크한다. 리뷰 미팅에서는 이번 스프린트의 전반적인 상황을 파악하고, 잘된 점과 개선할 점을 회고한다.

애자일 선언문에서 첫 번째 원칙은 '공정과 도구보다는 개인과 상호작용'이다. 그만큼 짜인 분업보다는 팀원들 간에 유기적인 소통과 협력이 중요하다. 일을 잘하는 주니어 프로덕트 매니저에서 훌륭한 팀을 만드는 시니어로의 경계가 이쯤에 있다고 생각한다.

프로덕트 매니저가 아무리 뛰어나도 함께할 동료 없이는 사소한 기능도 만들 수 없다. 따라서 디자인, 개발, 세일즈, 마케팅 등 서로 다른 배경과 경험을 가진 사람들이 공통된 목표를 이해하고, 동기를 갖게 하는 게 중요하다. 점차 시니어로 나아가는 필자는 이런 고민을 한다. '나는 나 자신을 넘어서 우리 팀을 성장시키는 존재인가? 탁월한 목표와 성과를 이루는 팀은 어떻게 만들어질까?'. 다음 시리즈는 이 질문에 대한 경험을 쌓으면 시작할 수 있겠다.

지금까지 12화에 걸쳐 프로덕트 매니저에 관한 이야기를 했다. IT 조직에서 어떤 역할을 하는지, 중요한 역량과 그에 따른 준비법이 무엇일지, 누구와 함께 일하며 제품을 만드는지, 제품 기획을 어떻게 하면 좋을지 등을 다루었다. 필자의 이야기가 프로덕트 매니저에 관한 높은 통찰력을 가져다 주진 않는다. 다만 이제 막 프로덕트 매니저를 시작하거나 준비하는 사람들에게 막막함이란 어둠을 밝힐 손전등이 되었으면 한다.