[코드스테이츠 PMB 14기] 이해관계자를 이해해보자

---

D1에서는 지그재그의 문제점에 대해서 말해보았다. 그 결과 세가지의 개선점을 다음과 같이 정리할 수 있었다. 

 

1. 숨어있는 카테고리 메뉴

AS A <사용자/고객>으로서 : 지그재그를 사용하는 고객은

I want to <~을 달성>하고 싶다 : 메인페이지에서 바로 카테고리 메뉴로 진입하기를 원한다.

So I can 왜냐하면 <이유>때문이다 : 쇼핑할 때 카테고리 메뉴를 매번 사용하기 때문에

 

2. 찜 목록에서 카테고리 분류 미재

AS A <사용자/고객>으로서 : 지그재그에서 '찜' 기능을 사용하는 고객은

I want to <~을 달성>하고 싶다 : 찜 메뉴에서 안에서 카테고리화가 있었음 좋겠다

So I can 왜냐하면 <이유>때문이다 : '찜' 메뉴 안에서도 원하는 아이템을 간편하게 찾길 원해서

 

3. 너무 느린 로딩 

AS A <사용자/고객>으로서 : 지그재그를 자주 사용하는 사용자는

I want to <~을 달성>하고 싶다 : 빠른 로딩 속도로 지그재그를 사용하고 싶다

So I can 왜냐하면 <이유>때문이다 : 느린 속도의 이미지 로딩은 쇼핑하는데에 불편함을 주기 때문에

---

이해관계자란?

https://gitmind.com/kr/stakeholder-analysis.html

이해관계자(Stakeholder)란? 프로젝트에 영향을 주거나 그로부터 영향을 받는 모든 사람들을 말한다. PM, PO, 개발자, 디자이너, QA, 상사나 고위 경영직, 투자자, 협력사, 그리고 고객까지 아우르는 큰 범주를 일컫는 말이다. 

PO는 스크럼 팀을 이끌어가고, 제품이 좋은 퀄리티로 나올 수 있게 책임을 지는 사람이기 때문에 이 이해관계자들과 명확하게 소통하고 목표를 공유하는 것이 중요하다. 

 

---

지그재그의 이해관계자는 누구일까?

 

1. 프로덕트 팀 (개발, 디자이너, CS)

: 내부 이해관계자. 즉, PM이 가장 얼굴을 맞대고 일하는 사람들이다. 개선사항을 고치고자 마음을 먹었을 때, 이 '팀원'들이랑 잘 협력해야만 이 개선 사항들을 잘 해결하고 좋은 결과물을 도출해낼 수 있다.

이해관계자	요구사항
개발자	개발 우선사항 확인 개발 일정 소통 문제에 대한 원인 파악
디자이너	개선 사항에 맞는 새로운 UX, UI 디자인 소통 디자인 일정 소통
CS	지속적인 고객의 불만, 개선사항 소통 새로운 개선 사항 반영시 고객의 피드백 수집

 

2.C-level (경연진)

: 경연진 또한 내부 이해관계자에 속한다. 이들의 가장 큰 이해는 바로 '매출'과 '경영'이다. 좋은 PM은 고객가치와 '사업가치'에서 둘 다 양립할 줄 알아야 한다고 했다. 그 중에서 경연진은 이 '사업가치'에서 많은 이해 관계가 필요한 이해관계자이다.

현 시점에서는 지속적으로 지그재그를 이용하는 고객의 불만을 줄여서 이탈율을 낮추고, 새로운 고객을 수집하여 매출을 늘리는 것을 목표로 삼을 것이라고 보여진다.

그 다음, 분기 별로 업데이트 상황에 따른 성과를 보고하여 가시적인 성과를 보여주고 있는지, 제품이 올바른 방향으로 나아가고 있는지에 대해 보고하고 소통해야한다.

 

3.고객, 입점 쇼핑몰​

:외부 이해관계자. 마지막으로 가장 중요하다고 보면 중요할 수 있다. 커머셜 프로덕트에서는 고객 관리만큼 입점 쇼핑몰 관리가 중요하다고 본다. 아무리 많은 고객이 모여도, 팔만한 상품이 없다면 말짱 도루묵. '고객-플랫폼-입점 쇼핑몰' 이 세가지 삼각형 사이에서 서로에게 아무도 손해가 되지 않고 Win-Win이 될 수 있게 아슬아슬한 줄타기를 잘 수행해내야만 한다!

 

고객 - 지그재그 단독 할인 프로모션(쿠폰, 포인트 등) 제공, 멤버쉽 혜택 제공

입점 쇼핑몰 - 지그재그 단독 프로모션 제공, 플랫폼 수수료 정책, 직진배송(지그재그 자체 배송) 제공

---

이해관계자를 잘 '이해'하는 PM되기

오늘 학습에서 나온 3가지의 문제점을 예로 들면서, 이해관계자와 어떻게 '이해'하면 좋을지 얘기하보도록 한다.

 

1. 내부 이해관계자들이 프로덕트를 제대로 이해하지 못할 경우

-> 첫째도 소통. 둘째도 소통이다. 잘 만드러진 기획서를 들이민다고 해도, 수많은 사람들의 공감과 이해를 한번에 얻기엔 힘든 일이다. 그래서 항상 모든 이해관계자들과 긴밀하게 소통하여, 생각하고 기획한 프로덕트에 대해서 이해할 수 있도록 최선을 다하는 것이 관건이다. 일단 시키니까 해! 이건 아무래도 애자일과 거리가 멀다. 하고 있음 보다는 '왜' 하고 있음에 집중한다.

 

2. 개발 과정에서의 기준이 명확하지 않을 때

->개발자와의 소통이 충분치 않아서 오는 문제. 어떠한 프로세스든지 Done(완료)를 정하는 것은 상당히 중요하다고 느껴진다. 또 일전에 개발자와 소통했던 경험을 떠올려보자면, 사실상 한번에 '완벽한' 코드를 짜내는 것은 불가능에 가깝다는 것...! 이 순간 PM이 나서서 너무 큰 프로세스라면 쪼개주고, 개발 과정을 점검하며, 완료 기준을 정해주면서 일정 조율을 해주는 것이 PM의 역할이라고 느껴진다.

 

3. 고객이 원하는 바에서 점점 멀어지는 프로덕트 개발

-> 항상 잊지 말자. 고객은 언제나 가장 중요한 '이해관계자'이다. 하지만 사공이 많으면 배가 산으로 간다고 했던가. 시작이 고객이었지만 많은 이해관계자의 손을 거치면, 언젠가부터 배가 잘못된 방향으로 흐를 수 있다. 이 변화를 PM이 예민하게 알아채지 못한다면 배는 이미 사공으로 간지 오래. 따라서 PM은 언제나 팀의 목표를 점검하고, 이 목표가 맞는 방향성인지 늘 점검하고 예민하게 받아들일 필요가 있다! 만약 정말로 길을 잃어가고 있다는 생각이 든다면, 여러가지 방법으로 직접 고객의 피드백을 수집하는 것도 하나의 방법일 것이다.

 

 

+) 몸이 안좋아서 퀄리티가 하락했습니다. 추후에 보충할 수 있을 때 보충할 것!