프로젝트 우선순위를 검토하는 법
"OO 기능이 꼭 필요합니다. 우선순위 높여서 진행부탁드려요" by 사업
프로덕트를 담당하고 있다면 매우 흔하게 받을 수 있는 요청이다. 오늘도 어김없이 사업부서에서 [중요도 높음]의 우선순위로 지정된 업무 요청이 들어왔다.
"경쟁사에서도 이 기능을 도입하는 추세고,
효과도 좋다고 하니 우리 서비스에도 도입되면 좋겠어요"
경험이 많지 않은 상태에서 이 요청사항을 접하게 되면 이런 생각이 떠오를 수 있다.
1) 경쟁사에는 있는 기능인데, 우리 서비스에는 없다니 얼른 만들어야겠다!
2) 경쟁사에서 이미 도입했고, 효과까지 있다고 했다면 우리 서비스에서도 효과를 볼 수 있겠는걸?
이렇게 떠오른 대로 생각하고 바로 프로젝트 진행을 확정 짓고 착수한다면 당신은 아직 프로젝트 우선순위를 설정 하지 못하는 레벨이라고 생각하면 된다. 각각의 프로젝트에는 한정된 리소스가 들어가므로 프로젝트 우선순위를 깊이 있게 고민하고 진행 여부를 확정해야 한다. 그렇지 않으면 '꼭 필요한 기능도 아닌 프로젝트'에 소중한 리소스를 투입해 아무런 성과를 거두지 못할 수 있기 때문이다.
오늘은 사업, 마케팅, 경영진 등 다양한 stackholder를 통해 들어온 요청 건의 진행 여부와 우선순위를 선정할 때 어떻게 해야 하는지에 대해 공유하고자 한다.
1. BRD(Business requirements document) 작성 요청
당연하다고 생각하지만 생각보다 당연하지 않다. 업계에 10년 넘게 있으면서 BRD를 작성해서 프로젝트 진행을 요청하는 케이스를 흔히 볼 수는 없었다. 그래서인지 BRD를 요청하지 않았는데 먼저 작성해서 요청 주시는 경우 감동을 받기도 했다. BRD 작성을 요청하는 이유는 다음과 같다.
1) 요청자가 어떤 배경을 통해 이 프로젝트를 발의했는지 알 수 있다.
2) 요청자가 해당 프로젝트를 요청한 목적과 비즈니스 목표를 알 수 있다.
3) 요청자가 생각한 프로젝트의 요구사항과 우선순위를 알 수 있다.
4) 요청자가 생각한 프로젝트의 ETA(Estimation)를 예상할 수 있다.
BRD를 보고자 하는 목적이 위와 같다는 건 즉, BRD에 위와 같은 내용이 명확하게 담겨야 한다는 뜻이다.
1) 요청 배경
2) 요청 목적과 정량적 목표
3) 기능 정의 및 우선순위
4) 오픈 희망하는 날짜
프로젝트 진행 요청이 왔는데, 위와 같은 내용이 작성되어 있지 않다면 요청자에게 위와 같은 내용을 포함하여 BRD를 작성해 달라고 요청한다. BRD 작성을 어려워한다면 PO가 템플릿을 만들어줘도 좋고, 미팅을 통해 각각의 내용을 확인해도 좋다. 이 부분은 본인인 속한 조직이 일하는 방식에 맞게 진행하면 된다. BRD 템플릿은 노션 템플릿(출처:Bayu Herdiawan)에 간단히 만들어져 있는 것도 있으니 시간이 없다면 이 템플릿을 활용해도 좋을 것 같다.
2. 프로덕트의 미션 및 주요 지표 확인
내가 담당하고 있는 프로덕트의 미션이 무엇인지 다시 한번 생각한다. 담당 서비스 미션이 "이용하기 편한 쇼핑 경험을 제공한다."이고, 주요 지표가 '구매전환율'이라고 가정해 보자.
BRD를 통해 들어온 요청사항은 <제휴 광고를 PLP에 상품카드 형태로 노출하여, 클릭 시 외부로 랜딩 되게 해 달라>라면 우리가 정의해 둔 미션과 주요 지표를 상승시키는데 기여하기는 어려운 프로젝트라고 판단할 수 있다.
이유는...
1) 제휴 광고를 PLP에 노출하면, 고객이 상품인 줄 알고 클릭했다가 광고로 이동되는 경험을 하게 되고 이러한 경험은 부정적으로 학습되어, 쇼핑을 불편하게 한다.
2) 합의된 주요 지표가 구매전환율인데, 클릭하면 외부 광고로 이동되어 수수료를 받는 구조라면 구매전환율과는 연결되지 않는 지표라고 판단된다. 따라서 해당 프로젝트를 진행하면 구매전환율을 상승시키는데 기여하지 못한다.
요청사항이 우리 프로젝트의 미션과 주요 지표를 상승하는데 긍정적인 기여를 할 수 없다면, 해당 프로젝트는 이를 근거로 <진행하지 않음>으로 답하거나 우리 미션과 주요 지표를 올리는 방향으로 역제안을 해볼 수 있다. 프로덕트 관점에서 충분히 고민해 보고 우리 미션과 주요 지표를 올릴 수 있는 다른 방법이 있다면 요청자와 다시 한번 논의해 보고 방향 잡기를 추천한다.
3. BRD 검증
BRD 검증을 하는 이유는 요청자를 믿지 못해서가 아니다. 요청자가 생각하지 못한 부분을 프로덕트 관점에서 생각해 보고 더 좋은 방향이 있는지를 고민하기 위해서이다. 이때 주요하게 봐야 하는 부분은 BRD에 기재된 목표와 기능정의가 되겠다. 아래 예시로 확인해 보자.
요청사항: 홈 ATF 내 광고 구좌 확보
비즈니스 목표: GMV 상승, 광고비 수취, 서비스 내 체류시간 증가
기능정의: 홈 ATF 내 광고 구좌 컴포넌트 추가
BRD 내 위와 같이 요구사항이 정의되어 있다면 한 문장씩 뜯어보며 딥다이브 한다. 요청사항이 '홈 ATF 내 광고 구좌 확보'인데, 왜 광고구좌를 가장 메인 지면인 '홈'에 그것도 'ATF(Above the fold)' 내 노출해야 하는지에 대해 생각해 본다. 깊게 생각해 봤는데도 답을 내릴 수 없다면 요청자에게 이 부분을 문의하여 확인해 보는 것이 필요하다. 그다음은 요청사항과 비즈니스 목표를 연결해서 본다. 홈 ATF 내 광고 구좌를 확보하게 된다면 GMV가 정말 상승할 것인지? 광고비 수취는 어느 정도 가능할지? 서비스 내 체류시간이 증가할만한 요청사항인지 등을 검토한다.
생각해 봤을 때 홈 ATF 내 광고 구좌를 확보하는 게 '서비스 체류시간 증가'와 전혀 관련이 없다고 생각하면 이 부분에 대한 근거 데이터를 확인해 본다. 근거 데이터는 주로 기존 진행했던 프로젝트 중 유사한 프로젝트에서 가져오는 것이 좋다. 예를 들어 이전에 특정 지면에 광고 컴포넌트를 추가했었다고 하면 실제 그 지면에서의 체류시간이 늘어났는지를 볼 수 있다. 또는 홈 지면에 특정 컴포넌트를 추가했었다면 홈 지면의 체류시간이 늘어났는지를 보는 것도 근거로 활용할 수 있다. 완벽하게 동일하지 않아도 참고할 수 있는 데이터가 있다면 근거로 가져와 나의 의견을 뒷받침하는 데 사용한다. 근거 없이 감으로 '이거 추가해도 체류시간 증가에 영향 없을 것 같은데요?'라고 말한다면 요청자를 설득하기 어렵다.
따라서, 작성된 BRD를 꼼꼼하게 뜯어보고 요청자가 원하는 기능을 추가하면 정말 비즈니스 목표를 달성할 수 있는지의 관점에서 검토한다. 이 과정은 요청건을 반박한다는 과정이라기보다는 '논리적인 요청인가?' '그렇지 않다면 어떤 부분을 어떻게 보완해서 진행해야 할까?'의 관점으로 고민하는 과정이라고 생각하면 된다.
4. 의견전달 및 수렴
3번까지 충분한 시간을 들여 검토를 끝냈다면, 이제 요청자에게 검토 피드백을 전달할 차례다.
우선 현재 진행 중인 프로젝트와 진행 예정 프로젝트의 우선순위를 공유하고, 프로덕트 관점에서 검토한 해당 프로젝트의 진행여부와 우선순위를 공유해 준다. 그리고 검토하면서 추가로 확인이 필요했던 부분에 대한 문의사항을 적고 검토하면서 참고했던 데이터와 추가 의견을 덧붙인다. 그럼 아래와 같은 포맷으로 전달할 수 있다.
예시
1) 결론 : 우선순위 '낮음'으로 진행하지 않음
2) 문의 : 홈 지면에 광고 구좌를 추가해야 하는 이유가 있을까요?, 광고비 수취 관련 프로세스 및 예상 수익
3) 의견 : 해당 건은 저희 주요 지표인 '구매전환율' 상승에는 크게 기여하지 못할 것으로 보여 우선순위를 '낮음'으로 판단하였습니다. 현재 진행 중인 과제의 우선순위는 모두 '구매전환율 상승'의 임팩트 순이므로 주요 지표를 올릴 수 있는 기존 과제를 우선적으로 진행하도록 하겠습니다.
4) 참고사항 : 데이터 대시보드, 기존 성과분석 자료 등
위와 같이 정리해서 검토 의견을 전달하고 요청자에게 추가적인 피드백이 있는지 등을 문의한다.
5. 의사결정
전달 의견을 확인한 요청자가 추가 의견을 주실 경우, 해당 의견을 검토하는 시간을 갖고 이견 없이 전달 의견을 수용할 경우 최종적으로 의사결정 한다. 이러한 과정들은 슬랙이나 지라, 컨플루언스 등에 히스토리를 볼 수 있게 모두 기록해 놓는 것이 좋다. 그렇지 않으면 이후 동일한 요청이 또 들어올 확률이 있고, 그때 또 리소스를 써서 다시 의견을 드려야 하므로 검토한 프로젝트의 히스토리는 필히 남겨두는 것을 추천한다.
만약, 요청자가 프로덕트에서 검토한 의견을 수용하지 못하고 계속해서 우선순위 높음으로 과제 진행을 요청할 경우엔 아래와 같은 두 가지 방법으로 의사결정을 할 수 있다.
1) 우선순위를 높여서 진행해야 하는 정량적 근거 제시 요청
2) 해당 과제의 우선순위를 높여 진행하게 될 경우, 진행 중&진행 예정 과제가 홀딩되어 로드맵 수립 시 세웠던 목표를 미달성할 수 있음을 알리고 이러한 리스크에도 우선순위 변경 후 진행할 것인지 확인.(만약, 본인이 의사결정에 책임을 질 수 있는 단계의 레벨이라면 결정에 책임지고 프로젝트 진행. 그렇지 않다면 리더에게 에스컬레이션)
마치며
오늘은 프로젝트 우선순위를 검토하는 법에 대해 자세하게 다뤘다. 쓰다 보니 길어졌는데 사실 이러한 검토 과정은 반나절 정도 집중해서 투자하면 생각보다 빠르게 의사결정 할 수 있다. 처음에는 우선순위를 결정하거나 변경하는 게 어렵다고 생각할 수 있지만, 위 과정들을 여러 번 거치다 보면 점점 우선순위를 결정하는 게 처음만큼 어렵지 않다는 것을 알 수 있을 것이다.
또, 요청자가 쓴 BRD를 확인하며 요청자의 논리가 맞는지, 목표를 잘못 설정했다거나 지표를 잘못 설정하지는 않았는지, 목표한 지표 달성을 위해 해당 기능을 어떻게 구현해 주는 게 최선일지 등을 고민하며 딥다이브 하는 시간을 가질 수 있다. 또, 딥다이브 하며 서비스에 대해 몰랐던 히스토리까지 알게 되어 추후 프로젝트에 참고할 수 있다. 이런 시간들이 차곡차곡 쌓이면 프로젝트를 깊이 있게 고민하고, 문서를 쓰는 시간이 눈에 띄게 짧아지는 것을 느낄 수 있을 것이다. 그럼 양질의 프로젝트를 더 빨리, 더 많이 할 수 있게 되니 결국은 나의 성장과 서비스의 성장에 모두 기여할 수 있다. 그러므로 stackholder가 요청한 프로젝트의 우선순위를 검토할 땐 '결국 모두의 성장에 도움 된다.'라고 생각하며 기쁜 마음으로 검토해 보도록 하자!
