PO린이라면 꼭 겪게되는 '요구사항 수집' 과정
프로덕트 오너의 요구사항 수집 프로세스
저는 커피를 딱히 좋아하지 않습니다.
그래서 한겨울이든, 한여름이든 업무 시작 전 커피 한잔을 준비합니다.
오늘은 기분이 걸쩍지근하니, '뜨거운 아아'가 땡기네요.
그래서 스타벅스에 가기로했습니다.
스벅에서 저는 이렇게 행동을 하겠죠.
고개를 돌리며 내 주문을 웃으며 받아줄 바리스타를 찾는다.
바리스타 앞에 선다.
QR코드 인증을 한다.
따뜻한 아아 한잔을 주문한다.
다른 요청사항은 없냐는 바리스타의 말에 아아 위에 휘핑크림을 올려달라한다.
주문번호가 적힌 종이를 받습니다.종이를 보고 언제쯤 커피가 나올지 예상한다.
내가 주문한 따뜻한 아아가 나왔고, 커피를 받는다.
바리스타와 인사 후, 스타벅스를 탈출합니다.
저는 방금 바리스타에게 '따뜻한 아아'를 달라는 요구사항을 전달했습니다.
바리스타는 저를 한번 째려보더니 '알겠다'고 합니다.
어찌보면 프로덕트 오너(Product Owner)는 '바리스타'와 같습니다. 수많은 유관부서에선 프로덕트 오너 PO에게 '따뜻한 아아'와 같은 요구사항을 전달합니다. 비즈니스 목표 달성, 성공적인 마케팅, 그리고 프로덕트 자체 고도화를 요청하기 위함이죠.
아무리 '따뜻한 아아'가 상식적으로 존재하지 않더라도 '요구사항 수집'은 프로덕트 오너의 업무에 중요한 요소 중 하나입니다. 그리고 특정 시즌엔 가장 많은 시간을 쏟는 업무이기도 하죠.
왜 도대체 뭣때문에, 프로덕트 오너는 '요구사항 수집'을 중요하게 생각할까요? 요구사항 수집은 어떤 프로세스로 이루어지까요? 수집 이후엔 어떤 프로세스를 밟는 것일까요? 각각의 질문에 대한 답을 여기서 이 자리에서 피하지 않고 해보겠습니다.
1. 유관부서로부터 요구사항을 왜 수집해요?
기업의 목표는 이윤 추구입니다. 돈을 벌어야합니다. 기업은 돈을 벌기 위해 매년, 매분기 비즈니스 전략을 짭니다. 이렇게 짜여진 비즈니스 전략 하에 기업의 전 조직은 일사분란하게 움직입니다.
그리고 여기 프로덕트라는 놈이 있습니다. 프로덕트의 주 역할은 고객 만족이며, 프로덕트 오너는 고객의 대리인이 되어야합니다. 그러나 고객만 만족시키기엔 한 가지 문제가 있습니다. 프로덕트의 주인이 '기업'이라는 것이죠. 기업의 목표는 뭐라고했죠? 이!윤!추!구!
자, 여기서 기업과 고객에 한 발씩 걸칙고 있는 프로덕트 오너는 묘책 하나를 냅니다. 고객과 기업을 만족 시키는 방법을 찾은 것이죠. 유관부서들의 요구사항을 받되, 이 요구사항을 실행했을 때 고객 만족도도 상승 시킬 수 있는 과제들을 진행하는 것입니다.
그래서 우선 프로덕트가 어떤 역할을 그리고 무엇을 해야하는지 알기위해 유관부서로부터 요구사항을 받습니다. 프로덕트 조직에 있는 PO 보다는 사업조직, 경영 조직에 있는 담당자들이 비즈니스 전략을 더 깊게 고민할 것이기 때문입니다.
물론 유관부서의 요구사항 없이, 프로덕트 오너 스스로 '요구사항'을 도출 할 수 있습니다. 그러나 이렇게 진행한다면 문제가 생깁니다. 기업의 방향성과 align되지 않는 과제들이 나올 가능성이 있기 때문입니다. 아무리 기업 관점의 고민을 해본다해도 프로덕트 오너가 모든 내용을 알고있지 못하기 때문입니다.
그래서 유관부서로부터 요구사항 수집을 합니다.
2. 요구사항 수집 프로세스와 수집 주기는?
요구사항 수집은 정기적, 비정기적으로 진행합니다. 특정 시즌마다 주기적으로 요구사항을 수집하는 것을 정기적인 수집, 그리고 정기 수집 기간 외에 이슈가 생길 때마다 수집되는 요구사항을 비정기적 수집이라고합니다.
정기적 요구사항 수집 주기는 기업마다 다르겠지만 짧게는 분기별, 길게는 최소 1년에 한번씩 진행합니다. 최소 1년에 한번씩 진행하는 이유는 매해 기업의 비즈니스 방향성과 전략이 만들어지기 때문에 프로덕트의 개선도 비즈니스의 방향성과 align해야하기 때문입니다.
정기 요구사항 수집 시즌이 되면 프로덕트 조직은 유관부서들에게 '요구사항 전달 요청'을 합니다. 보통 요청의 목적, 회신 기안까지 함께 안내하며 유관부서는 프로덕트 조직에 요청할 사항을 정리하여 회신 기간 내에 제공합니다.
이렇게 수집된 요구사항에 대해 프로덕트 오너는 요구사항 요청자와 커뮤니케이션을 시작합니다. 요구사항의 목적과 핵심 내용에 대해 빠르게 파악하는 과정을 통해 하나씩 검토를 진행합니다. 검토를 통해 로드맵 반영, 서스테인성 과제 진행, 보류, 제외와 같은 검토 결과를 도출합니다. 이런 과정을 통해 프로덕트오너는 기업의 비즈니스 목표를 인식해 프로덕트 개선 과제와 비즈니스 목표를 align합니다.
비정기적 수집은 말 그대로 기준 시점이 없습니다. 아무리 연말, 연초에 유관부서로부터 일괄로 요구사항을 받았더라도 업무를 진행 하다보면 비즈니스 전략이 바뀌기도 하고 사업에서 프로덕트 관련 이슈가 발생하기도합니다.
즉각적인 반영이 필요한 경우 유관부서에선 프로덕트 조직, 특히 담당 프로덕트 오너에게 요구사항을 전달합니다. 프로덕트 오너는 요청자와 논의하여 해당 이슈 해결을 위해 로드맵 우선순위를 변경할지, 아니면 보류 후 장기적인 관점에서 개선을 논할지 결정을 합니다. 보통 작업 범위가 크지 않은 task성 과제는 주요 프로젝트를 진행하는 중간에 함께 진행하여 빠르게 해결을 합니다.
3. 요구사항은 누가 주나요?
앞단에서는 요청의 주체를 유관부서(eg. 사업부서, 마케팅부서)로 한정지어서 말씀드렸습니다. 그러나 면밀히 분류해보자면 프로덕트에 요구사항을 전달하는 주체는 다양합니다.
크게 4그룹으로 분류 할 수 있습니다.
ㄱ. 유관부서(eg. 사업부서, 마케팅부서)
ㄴ. C레벨 경영진
ㄷ. 프로덕트 오너 Product Owner
ㄹ. Maker(개발자, 디자이너)
ㄱ. 유관부서(eg. 사업부서, 마케팅부서)
가장 많은 요구사항을 보내주는 파트너입니다. 아무래도 매년 새로운 사업, 전사적 마케팅 프로모션을 진행하기 때문입니다.
아무래도 요구사항의 대부분의 내용은 신사업을 진행을 위한 신규 기능 출시, 기존 사업 진행에서 불편한 요소 개선등에 집중되어있습니다. 마케팅 조직에선 프로덕트를 활용하여 고객에게 효율적인 마케팅을 하기 위한 신규 구좌/영역 개설, 데이터 기반 마케팅 툴 도입과 같은 사항들이 주를 이룹니다.
사업이 다양해질수록 마케팅이 필요한 영역이 많아지기 때문에, 마찬가지로 사업부서의 요구사항과 직간접적으로 연계되어있는 요구사항이 주를 이룹니다.
ㄴ. C레벨 경영진
대부분의 경우는 사업부서를 통해 C레벨의 의중이 반영된 비즈니스적 요구사항이 넘어오지만, C레벨로부터 직접적으로 요구사항이 전달되기도합니다(이름하야 K-탑다운!). 타운홀 미팅과 같이 전사 관점의 정보 공유 자리에서 간접적으로 요구사항이 만들어지기도 하며, 기타 채널이 활용되기도합니다.
C레벨로부터 만들어지는 요구사항은 전사관점(eg. 페이 사업 진출, 멤버십 서비스 제공)이 많습니다. 그러나 모두 그런 것은 아닙니며 때때로 상당히 디테일한 요구사항이 전달되기도합니다. 아니 뭐 C 레벨이 째째하게 이런 것 까지 챙겨,,, 하고 생각할 수도 있지만 반대로 생각하면 프로덕트 하나하나에 관심의 끈을 놓지 않고 있다고 해석할 수도 있습니다. 디테일하기 때문에 그들이 능력을 인정받고 있는 것일수도 있구요.
ㄷ. 프로덕트 오너(Product Owner)
프로덕터 오너 역시 요구사항 제공 주체입니다. 프로덕트와 가장 가까운 포지션이기 때문에 누구보다도 많은 요구사항을 낼 수 있죠. 특히 PO는 고객들의 반응을 아주 중요하게 고려합니다.
정량적, 정성적 데이터 분석을 통해 고객들이 불편함을 느끼는 부분을 캐치하고 이를 개선하기 위한 요구사항을 도출합니다. 디스커버리(전시영역), 검색, 추천, 상품 정보, 필터기능, 구매 경험 관련된 항목이 주를 이루겠죠. 고객이 원하는 상품을 빠르게 찾게 하기 위해 검색 기능을 강화한다거나, 추천 알고리즘을 개선해 선호할 것 같은 상품을 추천해준다거나, 프로덕트 이용에 불편함이 없도록 UIUX 개선을 하는것 말이죠.
ㄹ. Maker(개발자, 디자이너)
프로덕트 오너와 가장 밀접하게 일하는 개발자, 디자이너 역시 요구사항을 전달 할 수 있습니다. PO와 같이 담당하는 역할에 관련한 요구사항을 주로 도출합니다. 디자이너의 경우 프로덕트의 디자인 통일성, UIUX 개선 아이디어를 도출합니다. 개발자는 아무래도 코드의 품질 관리 관점에서 과제를 도출하게됩니다.
4. 수집된 요구사항은 어떻게 반영되나요?
앞서 1번 질문에서 프로덕트 오너는 기업과 고객을 만족시킬 수 있는 '묘책'을 냈다고 말씀드렸습니다. 그 묘책을 이 과정을 통해서 '합리적'으로 만듭니다.
요구사항 반영은 크게 3단계의 과정을 거칩니다.
ㄱ. 필요성 : 과제의 필요성에 대해 검토한다.
ㄴ. 정합성 : 로드맵성 과제가 맞는지 판단한다.
ㄷ. 액션 : 로드맵에 따라 과제를 진행한다.
우선 과제들의 '필요성'에 대한 검토를 진행합니다. 이 과제가 고객에게 이익에 저해되지 않는지 회사에 정말 필요한지, 프로덕트의 미션과 본질을 흐리진 않는지 판단합니다. 필요성이 증명됐지만 요구사항 정의가 부실한 경우 발제자에게 추가 설명을 요청하기도합니다. 문득 '검토'라는 단어의 의미가 권위적이랄고 느껴지 수도 있습니다. 그런 의미는 아니며 '정말 이 과제의 진행이 필요한가, 어떻게 진해할 것인가'라는 의미에 더 가깝습니다.
다음으로 '정합성' 검토를 합니다. 로드맵성 과제라고 판단되면 로드맵에 반영될 것입니다. 그러나 과제의 사이즈가 작거나 영향도가 적다면 로드맵이 아닌 task(회사에 따라서는 sustain 이라고 부르기도함) 수준의 과제로 분류합니다.
필요성과 정합성에 의해 진행하기로 결정했다면, 프로덕트 오너는 정해진 일정에 Maker들과 과제를 진행합니다. 과제 진행 전 요구사항을 구체화 하기 위해 요청자와 미팅을 진행하기도 합니다. 과제를 진행하며 유관부서와 지속적으로 소통하며 중간 점검을 하는 것도 필수입니다. 무사히 과제가 완료된 이후엔 오픈 공지와 내용 공유를 통해 과제의 마무리를 알립니다.
고객과 기업에 꼭 필요한 요구사항을 수집하는 것은 프로덕트 오너에게 중요한 업무입니다. 요구사항에 따라 프로덕트의 개선, 성장, 고객의 인식이 달라지기 때문입니다. x10배 성장하는 프로덕트가 될 지, 고객이 줄어느는 죽어가는 프로덕트가 될지 알고 싶으신가요?
판단의 근거는 '요구사항의 수집 및 선택' 에 반 이상의 지분이 있다고 말씀드리겠습니다.
