PMB_15기/DAILY

[코드스테이츠 PMB 15기_W8D3] PM이 이해관계자들과 '함께' 스크럼 진행하기

메리트리 2022. 12. 7. 16:23
사용자 스토리와 이해관계자

 

해당 과제는 [코드스테이츠 PMB 15기_W8D1] 아래의 글과 이어지는 글입니다. 

 

[코드스테이츠 PMB 15기_W8D1] 야놀자의 라이브커머스 전용 카테고리, '야놀자 라이브'

문제 or 개선점을 사용자 스토리 형식으로 작성하기(+우선순위 고려) 안녕하세요:) 7주차가 지나가고 8주차 다가왔습니다. 오늘 과제를 수행하기 위해 제가 관심있는 프로덕트를 선정해야하는데

03minji13.tistory.com

 

지난 과제에서는 야놀자 라이브의 문제 or 개선점을 찾고 이에 대해 사용자 스토리 형식으로 작성을 해보았습니다. 

이어서 오늘은 야놀자 라이브를 개선하기 위해 야놀자의 PM의 입장에서 다양한 이해관계자의 요구사항은 무엇인지 예상해 보고, 각 이해관계자의 요구를 해소하기 위해 유의해야 할 점은 무엇인지 생각해보고자 합니다. 

 


이해관계자는 누구일까?

 

이해관계자는 프로젝트 성공에 이해관계가 있고 어떤 형태로든 목표 달성에 기여한 사람입니다. 이해관계자는 개개인부터 고위 경영진에 이르기까지 모든 수준에서 나올 수 있습니다. 쉽게는 가장 핵심이 되는 고객부터 이외 운영 주체, 운영 관리자, 개발자, 고위 관리자, 투자자 등 수많은 사람들이 있습니다. 아래 조금 더 자세하게 살펴보겠습니다. 

 

출처 : Congruent Agile / [LeSS #4] 제품 책임자(PO, Product Owner)

 

  • PO와 스크럼 팀의 관계
    팀은 PO가 고객에게 가장 적합한 제품을 만드는 데 도움을 주는 존재들입니다. 팀은 다음에 무엇을 개발할지, 이미 개발했던 것이 목적을 이루었는지 그리고 PO는 팀에게 무엇이 필요하고, 어떻게 하면 팀을 도울 수 있는지 알아야 합니다.

 

  • PO와 고객과의 관계
    PO와 스크럼 팀은 고객에게 가장 적합한 제품을 만들려고 노력합니다. 고객은 관심 있는 기능을 언제 얻게 될지, 그리고 우선순위이면의 이유와 왜 그렇게 되는지 그 이면이나 우선순위가 정해진 배경과 그 이면에 대해서도 궁금해합니다. 그렇다면 PO는 이러한 궁금증에 답을 줄 수 있도록 설명도 해야 합니다. 그리고 고객의 진짜 문제를 파악하고 업무의 중요도나 우선순위를 결정하는데 도움 되는 정보를 얻을 수 있어야 합니다. 필요에 따라서는 고객을 프로덕트 개발과 개선에 직접 참여시켜 해결해 나는 것도 방법입니다.

 

  • PO와 고위 경영진의 관계
    제품 그룹 위쪽의 고위 경영진(포트폴리오 관리자, C-레벨 임원 등)은 PO를 제품 성공에 대한 최종적인 책임과 의무가 있는 사람입니다. PO에게는 개발 상태를 가시화하고 바람직한 영향(예를 들어, ROI 및 시장 점유율)을 최적화하기 위한 고위 경영진의 (아마도 암묵적인) 지시 사항을 실현시키는 모습을 보여줘야 합니다. 

 

  • PO와 스크럼 마스터와의 관계
    위 관계들은 “제품 책임(product ownership)”과 직접적인 관련이 있지만, PO와 스크럼 마스터와의 관계는 다른데요. PO의 지식 및 행동과 관련이 있습니다. 스크럼 마스터는 PO를 도울 수 있도록 그들의 관심, 질문, 장애물을 알아야 합니다. 그러니 좋은 스크럼 마스터는 이야기를 잘 들어주는 귀가 될 수도 있고, 기대어 울 어깨가 되어줄 수도 있어야 합니다. 그리고 PO가 적응할 수 있도록 가르치고 피드백을 줄 수 있는 역할을 합니다. 

 


1. 야놀자 라이브 스크럼 팀의 이해관계자(Stakeholders)의 요구사항!

🤔 다양한 이해관계자를 생각해 보고 그들의 요구사항은 무엇이 있을지 정리해봅니다.

 

 

이전 유저 스토리 중에서 우선순위 1순위에 '라이브 미리 보기 캘린더 기능과 알림의 도입'에 대해 이해관계자의 요구사항을 정리해보겠습니다. 이때 우리의 목표는 라이브 미리보기의 캘린더 기능의 도입으로 '라이브 예정일'을 쉽게 확인하고 싶어 한다는 것입니다! 따라서 우리의 목적은 '라이브 미리보기로 고객의 라이브 시청 유입수를 늘이자'입니다. 

 

1. 팀의 요구사항

 

팀은 누구보다 고객에게 적합한 제품을 만드는 사람들로 구성되어 있습니다. 따라서 위의 사용자 스토리에 대해 다양한 요구사항이 존재합니다. 팀은 개발자, 디자이너, 스크럼 마스터로 나눠서 요구사항을 정리해보았습니다. 

 

  • 개발자

       - 기존의 개발언어, 개발도구로 작업을 진행하면 되나요?

       - 주간 캘린더로 한 줄로만 보이게 하되, 딱 일주일만 나오게 할까요? 아님 10일 정도 나오게 할까요? 

       - 미리 알람이 줘야 할까요? 아님 라이브 시작 전 5분 전에 알람을 보낼까요?

       - 해당 요일에 라이브가 없다면 나타날 안내문구는 어떻게 해야 할까요? 

       - 구체적인 기능 명세서 전달해주세요

       - 어떤 방식으로 캘린더와 알람 아이콘이 들어갈지 화면 설계서 요청하기

 

  • 디자이너

       - 알람을 설정하기 위한 아이콘과 디자인에 대한 요구사항 

      - 해외여행, 호텔, 레저에 해당하는 야놀자 아이콘이 불필요해 보이면 각 해당하는 카테고리 아이콘에 맞게 변경할 것인지

      - 어떤 방식으로 캘린더와 알람 아이콘이 들어갈지 화면 설계서 요청하기

      - 알람 캘린더 중 어떤 디자인부터 완료하면 될까요?

 

  • 스크럼 마스터

       - 팀에 업무적으로 어려움은 없는지

       - 팀 외적으로 어려운 점은 없는지

       -  일일 스크럼 회의 주관하기

       - 프로젝트 마감일을 인지하고 빠르게 도달할 수 있도록 촉진

       - 팀 전체의 지속적인 성장을 위해 지침을 마련하고 가이드를 제시한다.

 

 

1. 경영진의 요구사항

   

   - 해당 기능을 개선함으로써 신규 고객 유입을 증가할 수 있는지?

   - 기능 외에 현재 야놀자 라이브에서 보유하고 있는 라이브 커머스 상품 유치와 홍보가 더 필요한 건 아닌지?

   - 라이브로 참여하는 고객의 수가 증가와 함께 구매까지 이어질 수 있는지?

 

 

 

2. PM 요구를 해소하기 원한다면?

🤔 각 이해관계자의 요구를 해소하기 위해 유의해야 할 점은 무엇인지 생각해 봅니다.

 

  • 내부 이해관계자들이 프로덕트를 제대로 이해하고 있는지 확인해주세요!

PM이 기획서를 작성하여 전달을 한다고 하여도 내부 이해관계자들이 프로덕트를 제대로 이해하고 있지 못할 경우도 많습니다. 그러니 내부 이해관계사들에게 먼저 개발 착수하기 전 프로덕트에 대한 공감대와 이해를 얻는 것은 필수적입니다! 왜냐하면 만약 공감대와 이해를 얻지 못하고 개발을 먼저 들어가게 된다면 개발 후에 이견을 제시하는 일이 발생한다면 큰 혼란을 가져오기 때문입니다. 

 

 

  • 개발 및 디자인 기준에서 명확한 기준을 제시해주세요!

PM이 각 팀의 자율성을 최대한 보장하더라도, 가장 기본적인 규칙은 정해져야 합니다. 개발에서는 개발 언어, 빌드 주기, 개발 도구 그리고 디자인에서는 작업 사이즈, 색상 전체적으로는 프린트의 주기, 작업을 완료하였다는 기준 등은  반드시 지켜야 하는 가장 기본적이고도 중요한 문제가 될 수 있기에 명확한 기준을 제시해준다면 이후의 혼란을 줄일 수 있습니다. 

 

 

  • 👏🏻 (집중 집중) 고객의 요구사항을 잊어서는 안 돼요!

우리가 제품을 개선하고 개발하는 이유는 무엇보다 고객의 문제를 해결하기 위함입니다. 하지만 내부 조직의 다양한 이해관계와 외부요인 등을 고려하면 의사결정이 쉽지 않을 때가 발생하고, 팀 사이에서도 갈등이 생기기도 합니다. 하지만 PM은 항상 고객의 문제를 해결하기 위해 우리가 현재 제품을 개선하고 개발하고 있다는 그 목적을 절대 잊어서는 안됩니다. 

 

 

  • 각 이해관계 원활한 소통을 위해 노력하기!

W8D2 과제에서 스크럼 가이드를 요약했는데요. 이때도 언급된 부분이 프로덕트 목표를 세우고 명쾌하게 소통하는 것, 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것이라고 했습니다. 스크럼 과정에서 소통은 빼놓을 수 없는 중요한 요소인데요. 각 이해관계의 요구사항과 상황이 각자 다르다 보니 PM은 니즈에 맞게 소통하고 상황을 고려해야 합니다. 이때 PM은 분명하게 의사를 전달하는 것 이 중요합니다.

 


| 출처

 

https://congruentagile.com/2020/03/09/product-owner/

 

[LeSS #4] 제품 책임자(PO, Product Owner) - Congruent Agile

이 글은 공식 LeSS 사이트에 있는 Product Owner를 옮긴 것이다. 예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 […]

congruentagile.com