이해관계자와 '한 배'를 타고 목적지에 잘 도착하는 법
[코드스테이츠 PMB 11] Ep30. 스크럼과 이해관계자
스크럼 팀의 이해관계자들은 누구이며
그들은 어떤 요구를 가질까?
이전 포스팅에서 유저 스토리와 백로그의 개념을 알아보고, 마이리얼트립의 카테고리 기능 개선을 위해서 유저 스토리와 백로그를 작성해 보았다.
실제 서비스를 이용하는 고객이 느낄 Pain Point를 해결하기 위한 기능을 개선하는 데에 초점을 맞추었다.
그래서인지 다소 '고객 가치 창출'의 측면에 더 무게를 실은 기능 개선안이라는 생각이 들었다. PM이나 서비스 기획자라면 '고객 가치 창출'과 '사업 가치 창출'을 모두 고려하여 적절한 시간과 인력, 기타 리소스를 투입하여 목표 달성을 위한 최상의 결과를 내야 한다.
이 둘 사이에서 적절한 균형을 이루어 제품 목표를 달성하는 것이 중요할 텐데, '고객'에 집착하여 고객 데이터와 고객의 요구사항을 분석하여 그들의 문제를 해결하는 것이 최우선 되어야 한다는 것은 너무도 당연한 이야기다. 하지만 고객의 가려운 곳을 긁어주는, 훌륭한 제품과 서비스를 지속적으로 제공하기 위해서는 '사업 가치 창출'이 뒷받침되어야 가능하다고 생각한다. 사업을 잘 운영해나갈 수 있는 기반이 갖춰져 있어야 장기적으로, 양질의 고객 서비스를 제공하는 선순환이 가능할 것이기 때문이다. 물론, 이 부분은 CEO가 가장 고민하게 될 듯싶지만, 사업 목표를 이루기 위해서는 제품의 방향과 목표를 모든 조직 구성원들이 동일하게 인지하고 나아가야 한다고 생각한다.
그래서 오늘은 지난 포스팅에서 작성한 백로그 기능을 개발할 때 스크럼 팀의 이해관계자들은 누구이며, 그들의 역할과 요구사항은 무엇일지, 이 요구들을 해결하기 위해 고려해야 할 점들에 대해 생각해 보았다.
1. 스크럼 팀의 주요 이해관계자들은 누구일까?
스크럼 팀의 주요 이해관계자들은 누구일까? 우선, 우리 서비스를 이용하는 고객이다. 고객은 활성 고객(충성고객 포함), 잠재 고객, 이탈 고객이 있을 것이고, 팀 내부적으로는 개발자, 스크럼 마스터, C-level(경영진), PM이 있고 외부 이해관계자는 투자자, 파트너사 등 다양한 이해관계자들이 있다.
IT 제품을 개발하는 과정을 '영화, 드라마와 같은 프로그램 제작 과정'에 비유한다면, 스크럼 팀이 하나의 프로덕트를 완성해가는 여정이 프로그램 제작에 필요한 모든 활동이 된다. PM/PO는 프로그램 제작의 모든 관리를 책임지는 PD의 역할을 한다고 볼 수 있다. 개발자와 디자이너 등 팀 구성원은 저마다의 역할에 충실히 임하는 연기자, 작가나 오디오 감독이 되고, 투자자는 방송 제작에 참여하는 광고주, 경영자는 방송국장 정도로 생각할 수 있을 것 같다.
비단 방송 프로그램 제작뿐만 아니라 행사를 기획하고 추진하는 것, 오케스트라 공연을 하는 것처럼 제 역할이 있는 여러 사람이 협업하여 하나의 '결과물'을 완성해내는 모든 일이 본질적으로는 제품을 개발하는 과정과 동일하다고 생각한다.
많은 이해관계자가 참여할수록 다양한 의견을 수렴할 수 있기에 결과물을 완성해내는 데 긍정적으로 작용하는 측면도 있겠지만, 자칫 방향성을 잘못 잡거나 필요 이상으로 잡음이 많이 포함되는 경우에는 기대에 못 미치는 결과물을 받아들 수도 있다. 따라서 PM은 프로덕트 계획 단계에서 함께 수립했던 비즈니스의 목표를 달성하기 위해, 여러 이해관계자들의 입장을 고려한 커뮤니케이션과 한정적인 리소스를 효율적으로 사용하여 일을 진척시켜 나감으로써 고객의 문제를 해결하고 고객 가치를 창출해내야 한다.
이 요소들을 고려하면서 마이리얼트립 카테고리 기능 개선 작업에 참여하는 이해관계자와 그들의 요구사항을 추측하여 작성해 보았다.
2. 이해관계자의 역할과 요구사항
C-Level (CPO, CTO 및 경영진)
C-Level에 해당하는 경영진들은 '장기적인 관점에서 우리 비즈니스의 목표를 달성할 수 있는가'를 가장 중요한 의사결정의 기준으로 삼을 것이라 생각된다. 월/분기/반기/연 단위로 사업을 바라보고 해당 기간의 사업 목표를 달성하기 위해 팀에게 동일한 목표를 공유하고 향후 문제가 될 수 있는 부분이 있는지, 현재 잘 진행되지 않아 병목현상이 생기는 업무는 무엇인지 파악하고 이를 해결하기 위한 지원책을 마련해야 한다.
CEO는 향후 3년, 5년의 계획과 목표를 수립하는 등 보다 길게 앞을 내다보고 미리 대응하고 준비해나가는 면모도 갖춰야 것이다. 즉, C-Level에서는 조직 구성원들과 목표 달성을 위한 과업들을 짜임새 있게 조직하여 프로덕트의 큰 그림을 그리는 역할을 하는 것이다.
요구사항
· 카테고리 구분 기능 개선에 소요되는 기간과 예산은 얼마나 되는지 알 수 있나요?
· 기능 개선으로 프로덕트에 직접적으로 가져올 수 있는 성과는 무엇인가요?
· 기능과 관련하여 구매 전환율 상승으로 이어질 수 있는 또 다른 방법이 있나요?
스크럼 마스터
스크럼 마스터는 팀이 목표한 주기 내에 우선순위 과업들을 성공적으로 완료할 수 있도록 지원하고, 효율적으로 스프린트를 관리하는 역할을 한다. PM/PO가 제품의 책임자로서 임무를 다하고 팀원들과 합을 맞춰 개발을 진행해 나가는 것을 돕기도 하며, 유연한 분위기 속에서 원활한 협업을 이끌어내는 퍼실리테이터의 역할도 수행한다.
사실 국내의 스타트업에선 보기 힘든 역할이라 현업에서는 다를 것이라 생각되지만, '스크럼 가이드'를 참고하고 추측하여 요구사항을 작성해보았다.
[ 요구사항 ]
· 현재 팀의 우선순위 과업 중에 몇 개나 달성되었나요? 이번 주 목표 과업 중 원활히 진행되지 않는 업무 또는 시작하지 못한 업무가 있나요?
· 첫 번째 백로그는 새로운 CTR 형태와 위치를 정하고 개발에 착수해야 하는 기능이니 PM님과 개발팀에서 충분히 협의하고 진행해주세요.
개발팀
개발팀은 PM과 디자이너, 유관부서와의 협의를 통해 기획한 기능 개선안을 직접 결과물로 구현해내는 중요한 역할을 맡고 있다. 실제 개발에 착수하기 전에 스프린트 주기 내 개발할 기능과 완료 기한, QA 테스트, 배포 시점에 대해 충분히 협의하고 기능에 대한 공통된 합의를 해 두어야 한다.
사전에 이러한 논의를 거친다면 개발이 완료된 후에 방향이 틀어졌다는 것을 확인하거나 처음부터 새로 작업해야 하는 불상사를 막을 수 있을 것이다. 이는 PM에게도 중요한 부분이기에 팀 구성원들과 투명한 정보 공유와 유연한 소통이 이루어져야 한다.
[ 요구사항 ]
· 두 번째 백로그에서 국내여행 카테고리를 전체 여행지 카테고리 첫 화면에 띄우려면 서버에서 국내 DB를 먼저 받아와야 합니다. 이후 클라이언트 쪽에서 작업해야 해서 빠르면 이틀 정도 소요되고, 늦어도 이번 주 금요일까지 가능합니다.
· 첫 번째 백로그에 대한 기능 명세서 수정본을 다시 전달해주세요.
· 유저 스토리를 대시보드에 작업 단위(Sub-Task)로 나누어 두었으니 확인 부탁드립니다.
고객 (충성 고객과 활성 고객/잠재 고객)
마이리얼트립의 고객은 충성고객과 활성 고객, 잠재 고객으로 구분할 수 있을 것이다. 충성 고객과 활성 고객은 서비스의 기능 개선에 가장 직접적으로 영향을 미치는 이들이며, 배포 후 즉각적으로 피드백을 받을 수 있는 창구이기도 하다. 고객의 의견은 결과물에 대한 평가이자, 앞으로 목표 달성과 성과 지표 개선으로 이어지는 만큼 중요하다.
앞으로 우리 서비스를 사용할 가능성이 있는 잠재 고객의 의견에도 귀를 기울여야 한다. 해결해야 할 과업이 적재되어 있는 상황에서는 당장에는 이들의 요구사항에 집중하기 힘들 수 있지만 결국 신규 고객을 확보하는 것은 매출 증대와 지속적인 사업 성장에 있어 필수 불가결한 부분이다.
[ 요구사항 ]
· 카테고리에서 여행 도시명이 '가나다순'으로만 정렬되어 있어 불편해요. 도시의 정렬 옵션을 따로 선택할 수는 없나요?
· 마이리얼트립을 이용하면 어떤 점이 편리한가요? 다른 여행 앱과 비교하여 제가 얻을 수 있는 정보나 혜택은 무엇인가요?
3. 이해관계자들과 한 배를 탄 PM의 역할
이해관계자들의 요구사항들을 반영하여 업무를 진행해 나가는 과정에서 커뮤니케이션이 원활하지 않거나 목표 기한 내 과업을 완수하지 못하는 등의 문제가 발생할 수도 있다.
문제가 발생하는 이유는 무엇일까. 대표적인 이유 중 하나는 이해관계자마다 중요하게 여기는 우선순위가 다르기 때문일 것이다. 가령, C-Level에서는 비즈니스의 목표 달성을 위한 전체적인 시각에서 인력, 예산, 시간 등 모든 요소를 고려해야 한다. 그래서 큰 목표에서 벗어나지 않는 선에서 세부적인 기능 개선에 있어서는 PO나 PM에게 책임과 권한을 위임하길 원할 수도 있을 것이다.
개발팀에서는 명확한 기능 정의를 바탕으로 정해진 기한 내 개발을 완료하는 것을 최우선 순위로 둔다. 하지만 예기치 못하게 자꾸만 PM과 스크럼 마스터가 회의를 소집하고, 화면 설계서를 보니 다시 PM에게 물어봐야 이해할 수 있는 부분이 곳곳에 보이는 상황일 수도 있다.
고객은 어떨까. 이번에 서비스의 새로운 기능이 도입되었다고 해서 앱을 업데이트했다. 카테고리 분류가 구분되어 이전보다 편리해졌고 디자인적인 부분도 업데이트 버전이 더 마음에 든다. 그렇지만 이전에 비해 사용감이 엄청나게 좋아졌다고 느끼지는 못했기에 계속 앱을 사용할지는 모르겠다고 생각하다 어느 시점에 이탈할 수도 있다.
그렇다면 이해관계자들과 한 배를 타고, 다양한 요구사항과 문제를 해결하기 위한 PM의 역할은 무엇일까.
우선순위 설정
각 이해관계자마다 과업의 중요도와 우선순위, 업무 상황이 다르고, 가용할 수 있는 팀의 리소스는 한정적이기 때문에 우선순위를 잘 설정하는 것이 매우 중요하다. 다양한 요구사항과 문제는 언제나 흘러넘친다. 주어진 시간과 자원 내에서 모든 요구사항을 해결하는 것은 불가능하기에 명확한 기준에 따라 우선순위를 정하고 그 순서대로 과업을 완료해야 한다.
우선순위를 정하는 것은 목표한 시점에 임무를 달성하기 위함이기도 하므로 리소스 관리를 잘하는 것으로도 연결된다. 만일 개발이 제때에 완료되지 않을 것으로 예상된다면 꼭 구현해야 하는 필수 기능을 제외하고 몇몇 기능들은 덜어내는 것을 고려할 수도 있다. 더불어, 개발에 필요한 세부사항들을 팀에서 면밀하게 협의하고 공통된 합의를 이끌어 내야 한다.
투명한 정보 공유
이해관계자 간에, 특히 팀원(PM과 개발자, 디자인과 개발자) 간에 투명하게 정보 공유가 이루어져야 한다. 투명한 정보 공유는 기능 기획부터 개발이 완료되고 배포하기까지 모든 기간에서 필요하다.
각 단계를 거치면서 우려되는 점과 서로에게 영향을 끼칠 작업이 무엇인지 충분히 이해하고 공유하고 있어야 한다. 데일리 스크럼과 스크럼 리뷰를 통해 발생한 문제와 문제가 발생한 이유에 대해, 현재 어떻게 해결되고 있는 상황인지 모두가 알고 있어야 한다. 구성원 간의 정보 공유와 신뢰를 바탕으로 한 협업이 이루어져야 성공적인 프로덕트를 만들어낼 수 있을 것이다.
어쩌면 이론적으로는 알고 있는 이야기지만 실천의 영역에서 난항을 겪을지도 모르겠다(...) '일을 수행한다'는 것은 '문제를 해결한다'라고도 볼 수 있다. 그렇기 때문에 프로덕트 개발하는 일에서도 종종 발생할 수 있는 잡음과 문제들을 자연스러운 현상으로 받아들이고 문제 상황에서 한 번쯤은 서로의 입장에서 생각해보고 더 나은 개선안을 찾아 해결해 보자.
좋은 PM은 이해관계자들과 '한 배'를 탔다는 생각으로 그들을 우리의 배에 태워 함께 목적지로 갈 수 있도록 북돋아주고 가이드를 제시하는 사람이 아닐까 한다. 그러려면 목적지를 향해 가는 길을 넓은 시야로 멀리 내다볼 줄 아는 능력이 있어야 할 것이다. 지금은 멀게만 보일지라도 함께 가는 사람들과 차근차근 합을 맞춰 노를 젓다 보면 어느샌가 목적지에 우리의 깃발을 꽂을 수 있지 않을까.
