고객 외 이해관계자는 어떻게 대응해야 할까? (W8D3)

과제 ) 사용자 스토리와 이해관계자

W8D1 과제에서 작성했던 사용자 스토리에 이어서 작성해보세요.

1. 사용자 스토리는 고객 중심으로 작성하셨을텐데요, 고객이 아닌 이해관계자(Stakeholders)는 누가 있을까요? 최대한 다양한 이해관계자를 생각해 보고 그들의 요구사항은 무엇이 있을지 정리해봅니다.
2. 각 이해관계자의 요구를 해소하기 위해 유의해야 할 점은 무엇인지 생각해 봅니다. 

이해관계자의 입장 중 3가지 이상을 선정해 과제를 수행하였는가?

각 이해관계자들이 제품 개발에 어떤 역할을 하는지에 대해 정의하였는가?

각 이해관계자들이 제품에 어떤 요구사항을 제시할 수 있는지에 대해 정리하였는가?

해당 문제를 해결하기 위해 이해관계자들과 원활하게 소통하기 위한 방법을 제시하였는가?

해당 문제를 해결하기 위해 PM이 수행해야 할 업무에 대해 의견을 제시하였는가?

선정한 요구사항이 제품팀의 업무에 어떤 문제나 리스크를 만들어 낼 수 있는지 고민하였는가?

 

 

⊙ 과제의 핵심 용어(또는 이론)

이해관계자(Stakeholders)
우리가 하는 일, 만드는 것들에 직간접적 영향을 주고받는 사람들 혹은 특정 이슈 
다르게 표현하면, 제품과 관련되어 있으나 생산과 제품 제공에 대한 책임은 없는 사람들
PM은 이해관계자들과 소통하면서 다양한 시각과 요구를 최대한 충족해야 한다.

 

제일 중요한 이해관계자인 고객의 요구사항은 이틀 전 과제로 살펴보았다. 

고객 외에 PM이 소통해야 하는 다양한 이해관계자를 이해하고 그들의 요구사항을 추정해보는 게 오늘 과제의 의도다. 

 

이미지 클릭해보세요 출처로 이동함.

---

오늘 다룰 Product

 

여기 과제와 이어지는 내용이다. 

 

https://coll-intell0.tistory.com/100

티스토리 불편해요 유저 스토리 (W8D1)

2023.02.02 - [PM 부트캠프(22.12.12~23.03.15)/과제] - 티스토리 불편해요 유저 스토리 (W8D1)

 

티스토리를 사용하면서 느낀 불편함을 유저 스토리 관점에서 정리하였다. 

과제에서는 여기 글에 이어서 쓰라고 주문했는데 그냥 내가 따로 뺐지롱? 

 

 

오늘 과제에서는 같은 프로덕트를 다루므로 선정 사유와 프로덕트 설명은 생략함. 

 

과제에서 다루는 프로덕트는 티스토리지만 티스토리 관련한 내용은 실제로는 아래에 없다. 

 

---

| 고객 외 이해관계자

[요약]

이해관계자는 다양하다. 내부 직원, 고객, 관련 업체 등

이 중에서 팀원들은 PM에게 다양한 요구를 할 것이다. 그들을 이해하려고 노력하고, 현직자들의 대응 경험을 물어보자. 

CS팀은 우리가 미처 해결치 못한 채로 쌓이는 부정적인 피드백에 피곤해할 것이다. 제품팀과 합치는 방향을 학습해보자.  

경영진은 우리의 성과와 변경 사항을 물어볼 것이다. 적당한 설득기법을 마련해보자. 좋은 보고 체계도 갖춰야 한다. 

 

 

우리가 소통해야 하는 이해관계자는 꽤 많다. 

• 내부 이해관계자 유형
  임원과 경영진, 우리 제품 팀, 회사 내의 남의 팀(특히 마케팅, CS 팀), 후원자 등

• 외부 이해관계자 유형
  고객, 관련 업체(공급, 계약, 하청 등), 투자자, 특정 이슈나 문제와 관계된 사람

 

나는 거기서 내가 속한 제품 팀, CS팀, 경영진을 뽑았다. 

왜냐면 요구사항을 뽑아내기 그나마 쉬울 것 같아서! 

 

 

⊙ 우리 제품 팀 (내가 PM으로 속해있는 팀)

 

▶ 우리 팀은 나와 함께 임무를 완수해나가는 동지들이다. 가장 의지해야 할 대상이기도 하다. 채택한 업무 프로세스나 구조에 따라 다르게 조금씩 구성되어 있다. 그러나 대부분 개발자, 디자이너와 함께 한다. (기획자는 PM보다도 잘 빠진다..ㅜ) 

 

 

▶ 이들은 PM인 나에게 무엇을 요구할까? / 어떻게 해결할 수 있을까? 

포괄적으로 표현하자면 

개발자: 이걸 어떻게 개발하고 유지, 보수(버그 잡기 등)할지 전반적인 것과 그들을 지원하는 것 . 세부적으로는 프론트엔드 개발자, 백엔드 개발자, 서버 엔지니어 등이 있다. 

UX/UI 디자이너: 전반적인 사용자 경험과 관련된 것. 세부적으로는 UX 라이터, UI 디자이너 등이 있다. 

그 외에 QA 테스트 담당자, 데이터 관리 직군이 있는데 이들은 구체적으로 내게 무슨 요구를 할까…

 

 

구체적인 예를 5 개 들어보았다. 

• 일이 너무 힘들어요. 
  → 작업량이 많으신가요? 그럼 이렇게 관리해보면 어떠세요? 
• 제 경험 상 이렇게 하면 망하던데요?
  → 그 경험과 지금 상황의 배경이 얼마나 유사한지 설명해주세요. 판단에 반영하겠습니다. 
• 저 기한까지 일을 못 마칠 거 같아요. 큰일 났어요. 
  → (검토해봤더니 정말 어쩔 수 없는 사유고, 기한을 미루기 힘든 상황) 일을 다른 팀 사람들 중에 도와주실 분 있을지 여쭤볼게요. 안된다 하시면 프리랜서 사이트 들어가서 찾아보고요. 저한테도 작은 보조 업무 쪼개서 주시면 도와드릴게요. 
• 갑자기 인터넷에서 유행 타서 사용자가 너무 많이 유입이 되었어요. 서버가 폭발하고 있는데요? 
  → 서버용 단기 클라우드를 빠르게 대여합시다.
  그 다음 이 인원들을 우리 서비스에 계속 머물도록 유도하는 방법에 대해 생각해서 대응하는 게 우선 같습니다.
  대여 기간 끝날 동안에도 MAU가 이전보다 유지되면 그 정도를 보고 서버 클라우드 용량을 교체합시다.
• 이 UX 디자인 어떠신가요? (디자이너)
   → 음, 제가 보기에 (나) 버전이 우리 브랜드 이미지에 더 적절한 거 같아요. 
• 이 혁신적인 기능이 있으면 우리 사이트는 동종 서비스에 비해 앞서갈 수 있을텐데 솔직히 개발이 안된다고 하시는 게 안해보고 하시는 말씀 같아요. (내가 PM이고 기획자가 따로 있는 경우)
   → 말씀하신대로 구현은 간단해보이지만, 실제로 구현할 때는 이런 규칙성에 위배되어 ~~ 그래서 생각보다 복잡하다고 하시더라구요. 그러나 이 세부 기능은 구현이 가능할 거 같은데 이것만이라도 넣어보는 건 어떠세요? 개발자분들께 여쭤보고 괜찮다 하시면 다음 업데이트 일정에 추가할게요. 
• 다른 사이트에서는 적용했는데 왜 우리는 못하냐고 따지시던데, 저거 하나 만드는데 얼마나 오래 걸리는지 모르시는 것 같아요. 오픈 API 찾아보니까 없어요. (개발자)
   → 왜 만들기 어려운지는 설명을 들어서 충분히 이해가 되지만, 기획자분 말씀 들어보면 요즘 동종 서비스 거의 다가 적용하는 편의성이라서 저희도 비슷하게라도 하면 좋을 것 같아요. 기한이나 인력이 부족한 걸까요? 만약 난이도가 높다면 다른 팀에서 시니어 개발자분 모셔와서 같이 만드는 건 어떠세요? 

 

솔직히 이런 거 말고 요구사항이 생각 안난다 ... ㅜ-ㅜ 

 

 

 

▶  이들의 요구를 해소하기 위해 유의해야 할 점

이 부분에서 뭐라고 배웠었냐면 "남의 가족에게 친절하게 대하기" 

업무가 바쁘고 피곤하면 몇몇 요구사항은 쫑알쫑알 칭얼대는 거 같아서 피곤하고 짜증날 수도 있겠다. 알아서 처리하면 안되느냐고 화가 날 수도 있을 거 같다. 내가 화내겠다는 건 아니고 사람이 극한상황에 몰리면 스트레스를 받는다는 뜻이다. 

 

그런 상황을 미연에 방지하기 위해 어떻게 하면 좋을까? 

1. 친해지기
   많이 소통하고 술도 마시면서 친해지라고 권장해주셨다. 설마 나랑 친한데 막 신경질 내고 그러진 않겠지?! 
2. 저 사람들이 왜 그렇게 하는지 이해하기 
   사람을 많이 대해보고 많이 싸워보는 게 답이지만 그게 당장 어려우면 소설 많이 읽어보는 것, 심리 이론과 정신분석 이론을 공부해보는 것이 있겠다. 내 겅우는 저 사람들이 왜 그러는지 궁금해하면서 깊게 이해하고 싶어한다. 최대한 그들을 이해해서 화를 덜 내고 싶기 때문이다. 이런 관심을 지속시키자. 
3.  일반 상황 해결 매뉴얼 만들기 
   최대한 많은 경험 아티클을 찾아보며 사전에 문제점과 개선점 메뉴얼로 만들어놓고 즉각 대응하기. 자주 나오는 문제점이 있으니까 현직자들이 분명 해결해본 경험이 많을 것이다. 위에 내가 예시로 든 것들이 그렇다. 이런 거 하나하나 물어보고 어떻게 해결했는지 잘 적어두자. 
   만들어두면, 바쁠 경우 PM을 거치지 않고도 회사 내부에 공유되는 매뉴얼로 몇 가지는 해결될 것 같다. 그리고 이걸 통해 금방 대응책을 제시해줄 수 있으니 덜 우왕좌왕할 거고 감정도 안상한다. 특히 신입한테는 더 필요할듯. 

 

매뉴얼을 만드는 게 굳이 일을 더 추가하는 거 아닐까 할 수도 있겠지만 경험 부족을 보완하는 방법이라고 본다. 

 

 

⊙ CS 팀 

 

▶ 고객의 목소리를 수집, 처리 하는 팀. PM이 단골이 되어야 하는 곳. 고객의 진짜 문제를 해결하기 위한 제품을 만드는 대부분의 서비스한테는 꼭 있어야 하는 필수 부서. 고객 센터 등이 해당한다.
여기서 처리하는 VOC를 가져와서 유의미한 것과 무의미한 것으로 나누고, 종류별로 구분해서 필요한 것을 개선한다. 우선순위가 낮은 요구는 백로그에 쌓아둔다. 

 

 

▶ 이들은 내게 어떤 요구를 할까? 또 어떻게 해결할 수 있을까?

 

2 가지 경우만 떠오른다. 

① "최근에 이런 문의가 빗발치는데요, 무슨 일인가요? 아직 해결 안해주시나요?" 

업데이트를 했는데 반응이 안좋거나, 핫픽스가 터졌을 때 이런 요구를 할 것 같다.

→ 지금 해결 중입니다! 처리하시느라 번거로우시죠? 잠시 후에 공지 띄우면 조금 마무리 될 겁니다. 새로 들어온 문의들 비슷한 건대로 분류해주실 수 있으세요? 저희가 놓친 부분이 없는지 검토하기 위함입니다. 

 

② "이 문제는 주기적으로 문의가 옵니다. 해결하셔야 될 거 같은데 왜 처리가 되지 않나요?" 

계속 우선순위에 선정되지 않고 백로그에 쌓아둔 일에 관한 문의가 CS 담당자가 눈치챌 정도로 누적되었을 때.

 → 아, 계속 긴급 버그가 터져서 수정이 늦어지고 있습니다. 곤란하시죠? 이 안건은 바로 저희 쪽에 넘겨주시면 어떠세요? 저희가 직접 고객님들께 설명 드리겠습니다. 

 

두 경우 다 우리가 당장 어떻게 해줄 수 없는데 CS팀은 스트레스를 받을 일이므로, 예쁘게 양해를 구하는 게 최선 아닐까?

 

 

찾아보니 CS팀과 제품팀은 왜 사이가 좋지 않을까? 이런 글이 있다. 

• CS팀은 버그 리포팅이 어떻게 타팀에서 처리되는지를 알 수 없다. 고객에게 부정적 피드백을 받고 이를 리포팅하는 일을 잔뜩하지만, 제품팀에서 이를 너무 늦게 처리해주거나 아예 처리해주지 않기 때문에, CS팀원들은 더 이상 동기부여를 받지 못해서 팀원들의 퇴사를 야기한다. 
• 반대로, 바쁜 제품팀은 영향력이 크지 않은 일에는 시간을 쓰기 싫어한다. PM들은 '우선순위'와 '사용할 리소스'를 기반으로 짠 업무 리스트를 기반으로 운영을 해서이다.
• 제품팀은 원래 하던 우선순위 업무를 멈추고 CS 관련 일을 확인해주거나 이 피드백을 무시하고 기존의 일을 처리하는 두 가지 방법 중 하나를 결정할 수 있다. 둘 중 하나를 결정하는 패턴은 결국 두 팀 간의 앙금을 만드는 근본적인 원인이 된다. 

이런 문제점이 있다고 한다. 한줄로 정리하면, 제품 팀이 바빠서 우선순위 너머의 일을 해결 못해주니까 CS팀 입장에서는 탈력감을 느낀다.

 

이 글에서 해결책으로 [CS팀을 제품팀의 연장선으로 확장]하는 걸 제안한다. CS팀을 제품팀의 연장선으로 바라보는 것이다. 제품팀 입장에서 장점은, 고객과 더 가까이 가면서 제품 로드맵이 존중 받을 수 있다. CS팀 입장에서는, 회사의 전략에 직접적으로 기여하는 CS 업무를 할 수 있어 무시 받는다는 느낌을 안 받는다. 

 

 

▶ 이들을 대할 때 유의할 점은? 

 

위 아티클에서 제시한 해결책처럼 CS팀과 제품팀을 합치거나 좀더 긴밀하게 소통할 방법을 찾아야겠다. 

그래서 어떻게 확장시켜야 하느냐를 고민해야 한다. 실제로 CS팀과 제품 팀이 긴밀하게 협업하는 조직이 있는지 실 사례를 찾아보고, 학습한 다음 회사에 건의해볼 필요가 있겠다. 

큰 기업이 아니면 제품 팀이 (제품에 관한 얘기를 중심으로) 직접 VOC를 확인한다고도 들었다. 이런 경우 내가 악플 봐도 타격을 안받겠끔 정신 훈련을 해야겠다. 학습 과정에서 제품과 나를 분리하라고 알려주었다. 고객들의 쓴소리는 나를 비하하는 게 아니라 그냥 화나서 일시적으로 저러는 거라고 판단하면 되겠다. 

 

근데 스크럼 프레임워크를 사용하는 조직에서는 CS팀이 VOC를 제품 조직 전체에 전달하면 각 팀의 PO(반장 같은 존재)들이 각자의 백로그로 가져간다고 들었다. 애자일 방식에서도 CS팀은 여전히 스트레스를 받을까? 그렇겠지? 이것도 알아볼까? 

 

 

⊙ 경영진 

▶ 이들은 회사를 전체적으로 살펴보면서 운영한다. 우리 팀의 성과를 본다. 

 

▶이들이 우리에게 요구할 사항은 무엇일까? 애초에 어떤 상황에서 부딪히게 될까? 

사업가치와 고객가치가 충돌할 때, 결정 사항을 보고하고 설득할 때 같다.  

 

"성과가 줄었는데 굳이 왜 이렇게 하셨죠?" 

"왜 이 프레임워크, 이 협업툴을 도입해야 하죠? 돈값 합니까?"

 

전자의 질문에는 고객 가치의 중요성을 설파하면 어떨까? 당장 수익은 줄었지만 고객 충성도가 높아졌고 입소문이 펴져서 브랜드 가치를 공고히 하는데 도움이 된다, 이는 곧 다른 방향으로 서비스를 확장하는 기반이 되어서 장기적으로 볼 때 오히려 수익을 높이는 방향이라고 하면? 사업 가치와 고객 가치 중에서 이번에는 고객 가치를 선택했다고 한다면? 이걸로 설득이 될까? 

 

왜 이걸 도입하냐는 질문에 대해서는 팀원들이 만장일치로 동의했다는 걸 알리고 시범적으로 도입해보는 기간을 갖자고 하면 되지 않을까? 3개월 써야 효과가 나는데 2개월만 쓰게 될 수도 있으니 테스트의 기간과 대상을 잘 설정해야 되겠다.

 

물론 어떤 안건이든 설득 자료를 시각화하여 표현하는 것이 기본이다. 

 

▶ 유의점 

임원은 실무자가 아니기 때문에, 직접 개입할 수 없으며 잘 알지 못한다. 

그렇기에 이들과 소통하는 것 또한 중요한데, 자칫하면 권위가 끼어들어 수평적인 논의 및 보고가 힘들 수도 있다. 

임원진이 팀을 타박하거나 심하면 직원의 고용 안정성을 해치게 될 수 있고 팀 입장에서는 솔직하게 보고하지 못하고 감출 수도 있다. 

 

그렇기에 효율적으로 보고할 수 있는 체계가 필요할 듯 싶다. 

비대면으로 간단히 보고 문서를 제출하면 임원진이 바로바로 확인할 수 있게 말이다. 

보고용 문서를 작성하는데 진을 빼면 안되고, 제품 팀의 업무 권한을 존중하면서도 제대로 된 내용을 알 수 있어야 한다. 

어떻게 하면 좋을까? 팀이 사용하는 협업툴 권한을 주면 될까? 보고용 문서는 괜히 사내 공문 이런 거 쓰지 말고, PM이 문서를 자체 툴(예: Confluence 같은 위키 툴)에 정리하는 김에 외부인이 이해할 수 있도록 조금만 수정하면 어떨까? 이게 최선일까?

 

일단은 협업툴 중에 보고와 확인 절차를 편하게 해주는 게 있었다. 문서를 툴 안에 올리면, 담당자로 선정된 분이 확인 처리하는 것이다. 이건 일단 반드시 도입하도록 하자. 

 

---

위 내용들을 요약 정리한 표다. 

너무 막 정리해서 알아보기 힘들텐데 걍 알아서 봐주시오 

 

---

여담

내부 팀원, 투자자, 경영진들이 티스토리에 대체 무엇을 요구한단 말인가? 

너무나도 어렵다 이거예용~ 

-

나 해결책으로 구조 개선을 잘 내는 거 같은데 구조에 관심 있는 모양 

-

아 내 과제 너무 맨날 깊이 없는 거 같아 

하지만 나는 안경을 쓴 똑똑한 버섯이지 

버섯(머리)치곤 똑똑하니까 된 거다! 

 

그리고 깊이는 얕아도 그래도 나름 꽤 잘했지 않나 하는 뿌듯한 마음이 있어요 ^_^

-

오늘 학습 내용 어제 과제랑 삐까쳐서 이해하기 쉬운 느낌이었다. 

역시 뭐든 많이 접할수록 쏙쏙 들어온다. 

-

야호 오늘은 평소보다 엄~청 빨리 냈다! ^ㅁ^ 1주차 이후로는 처음 아닌지? 

노력이 승리했다. 지속된 노력으로 시간 자체를 앞당기는데 성공했다. ^ㅇ^ 

반드시 승리한다~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!!!

---

분석 참고 글

 

https://asana.com/ko/resources/project-stakeholder

이해관계자 분석과 그 중요성 • Asana

 

https://www.grownbetter.com/article/116

CS팀과 제품팀은 왜 사이가 좋지 않을까?

 

---

W8D3 [코드스테이츠 PMB 16기] 과제

이해 관계자