brunch

You can make anything
by writing

C.S.Lewis

by 감자윤 Nov 19. 2021

이해관계자들의 수많은 요구사항은
어떻게 관리해야 할까?

[코드스테이츠 PMB 8기] 8주차 Daily project (3) 


프로덕트 개발에 있어서 가장 중요한 것을 하나 이야기하라고 하면 '문제 정의'라 말할 수 있다.


아무리 좋은 솔루션이 있어도 사용자의 니즈를 관통하는 문제 정의로 시작하지 않았다면, 해당 솔루션 디자인은 시장에 외면을 받을 확률이 높기 때문이다.


그만큼 프로덕트에게 '고객'은 매우 중요하다.


그러나 프로덕트를 개발하거나 개선하는 과정에서 '고객'만 고려되는 것은 아니다.

성공하는 프로덕트는 고객의 니즈를 충족시키는 것과 동시에 사업 가치를 충족시킬 줄 안다. 그래서 프로덕트 하나에는 수많은 이해관계자들이 존재하며, PM은 그들의 요구 사항과 상황을 함께 이해하고 있어야 한다. 




제품 개발에서의 이해관계자란?



이해관계자는 프로덕트에 영향을 주거나, 영향을 받을 수 있는 개인, 집단, 조직 등 모든 관계자를 의미한다.

여기에는 고객과 사용자뿐만 아니라 투자자, 협력사, C-level 등이 속할 수 있다. 


이를 조금 더 자세히 풀어 설명하면 다음 3가지 집단으로 나눠 볼 수 있다.



1. 프로덕트 팀 및 후원자

- 프로젝트의 소유자 및 직접적인 수행자들이다.
- PO/PM과 함께 고객에게 가장 적합한 제품을 만드는데 도움을 주는 사람들이다.
- 프로덕트에 대해 누구보다 잘 알고 있어야 한다. 

예) PM, 프로젝트 관리 팀, 기타 프로젝트 팀원들, 스크럼 마스터 등  


2. 고객 및 관련 조직

- 고객 및 협력 조직들을 포함한다.
- 고객과 사용자는 잠재 고객, 이탈 고객 등으로 더 세분화되어질 수 있다. 
- 프로덕트 개발 및 개선 과정에 직접 참여하여 자신의 니즈가 잘 반영되었는지 확인할 수 있다.

예) 고객, 사용자, 공급자, 하청업체  등  


3. 기타 이해관계자

- 프로덕트와 상당히 관련 있는 기타 개인, 집단, 조직들이 포함된다. 
- 각자의 입장 및 상황, 그리고 프로덕트로 인해 받거나 주게 될 영향력을 잘 고려해야 한다. 
 
예) 경영진, 타 부서 및 팀, 운영/기능 관리자, 주주, 정부, 지역 사회 등  





카카오톡 멀티 프로필 기능 개선과 

관련된 이해관계자는?



 <카카오톡 멀티 프로필 기능의 사용성을 강화하는 방법>에서는 사용자 관점으로 현재 멀티 프로필 기능에서 개선이 필요한 부분과 그에 대한 개선 방안까지 도출했었다.


이에 해당 글에서 작성했던 사용자 스토리(유저 스토리, User Story)를 기반으로 관련 이해관계자들은 누구인지 고민해 보았다. 그리고 그들은 어떤 요구사항을 이야기할 수 있을지 추측해 보았다. 


카카오톡 멀티 프로필 기능 개선과 관련된 이해관계자 요구사항



A. 경영진

우선 카카오톡 멀티 프로필 개선에 대한 이해관계자는 경영진이 될 수 있다.

경영진은 사업적 가치를 항상 염두할 수밖에 없기 때문에, 결국 멀티 프로필 기능 개선에 대해서도 실리를 추구할 것이라 생각한다. 


현재 카카오는 '카카오 지갑' 서비스를 운영하며 지갑 기능을 이용하는 사람들에게만 다양한 추가 서비스를 제공하고 있다. 멀티 프로필도 그중 하나이다. 그렇기에 경영진 입장에서는 해당 기능 개선을 통해 더 많은 사용자들이 '카카오 지갑' 서비스에 등록되기를 희망할 것이라 추측할 수 있다. 



B. 마케터 (마케팅 팀)

위와 같은 경영진의 요구로 PM과 프로덕트 팀의 또 다른 이해관계자는 타 부서인 마케팅 팀이 될 수 있다. 

마케팅 팀은 기능 개선 후 이를 시장에 효과적으로 알리고 홍보하는 역할을 담당할 것이라 예상할 수 있다. 


이에 PM과 프로덕트 팀에 마케팅 팀은 기능 개선이 언제 완료되는지, 구체적인 일정을 요청할 수 있다. 

그리고 기존 마케팅 일정이 있을 것이기에 마케팅 팀 입장에서 먼저 기한을 제안할 수도 있지 않을까 싶다.



C. 사용자

마지막 이해 관계자는 사용자가 될 수 있다. 보다 세부적으로 잠재 고객, 이탈 고객 등으로 나눠서 생각해 볼 수 있다. 그러나 여기서는 이미 앞서 문제 정의와 사용자 스토리를 작성하기 전에 인터뷰를 했던 사용자 집단으로 가정해 보았다.


이 과정에서 사용자들은 보다 구체적으로 자신들이 원하는 기능과 요구 사항을 이야기하게 될 것이다.





PM은 이해관계자들의 요구사항을 

어떻게 받아들이고 관리해야 할까?



카카오톡 멀티 프로필 기능 개선에 대해 간단하게 관련 이해관계자들과 그들의 요구사항을 생각해 보았는데, 실제로는 이보다 더 많은 이해관계자들의 관계가 얽혀있을 것이다.


문제는 이해관계자들 간의 요구사항이 상충되어 갈등을 일으키는 상황이 발생할 수 있다는 것이다. 

또한 이해관계자들이 실제 프로덕트 팀이 가진 리소스보다 더 많은 것을 요구하게 될 것이다. 


예를 들어 카카오톡 멀티 프로필 기능 개선과 관련해 '마케팅 팀'은 2주 안에 기능 개선이 완료되어야만 마케팅을 차질 없이 진행할 수 있다고 한다. 하지만 PM과 프로덕트 팀이 생각하기에 더 기간이 소요될 것이라 생각될 때 해당 요구사항은 프로덕트 팀의 입장과 충돌될 수 있다. 


더불어 사용자들은 항상 다양하고 많은 기능 개발과 개선사항을 원한다. 

그것이 잘못된 것은 아니지만 제한된 리소스 안에서 모든 요구사항을 받아들일 수는 없다. 


결국 PM은 수많은 요구사항들을 듣고 받아들일 때 이를 잘 관리해야 할 책임이 있다. 


이에 PM이 이해관계자들과 그들의 요구사항을 관리할 때는 다음을 고려해 볼 수 있다.



01.

이해관계자 명확히 설정하기



프로젝트에 관련 있는 이해관계자 명단 구체화하기

각 이해관계자의 역할과 영향력 정의 내리기

각 이해관계자와의 커뮤니케이션 계획 수립하기


간접적인 관계까지 고려하기에는 너무 많은 이해관계자들이 존재할 수 있다.

이에 개발 및 개선의 정도를 가늠해서 이해관계자의 범위도 결정하는 것이 좋고, 그 범위에 맞게 이해관계자들을 구체적으로 정하는 것이 필요하다.


정해진 이해관계자들 마다 역할과 프로덕트에 끼칠 수 있는 영향력이 얼마나 되는지도 미리 정의하는 것이 필요하다. 이후에는 각 관계자와 언제, 어떻게, 어떤 정보를 제공하며 커뮤니케이션할지 정해야 정확한 니즈가 반영된 요구사항을 얻을 수 있다. 


특히 사용자들의 요구사항을 들을 때에는 반드시 모든 요구사항이 구현되는 것이 아님을 전달할 필요가 있다.

사용자들은 요구사항을 이야기할 때 자신의 모든 요구사항이 프로덕트에 반영될 것이라 기대하기 때문이다. 



02.

우선순위 설정하기



팀 Capacity(캐퍼, 업무 가능 역량) 파악하기 

Scope(업무 범위) 정하기 

영향력을 고려해 이해관계자 우선순위 설정하기

유저 스토리와의 연관성 파악하기

프레임워크 활용하기 (ex. MoSCow)


PM이 요구사항에 대한 우선순위를 설정하는 것은 해당 과정(애자일에서는 스프린트 진행 전)에서 가장 중요하다고 말할 수 있다. 모든 요구사항을 현실적으로 다 반영할 수 없기 때문에 우선순위가 높은 순으로 차례대로 반영하거나, 혹은 최우선 기능만 선택해 개발할 수 있기 때문이다. 우선순위를 설정할 때는 이해관계자의 영향력과 유저 스토리와의 연관성을 고려해 설정하는 것이 좋다.


그런데 우선순위 설정 전에는 미리 팀의 역량인 Capacity를 PM이 제대로 파악하고 있어야 한다. 그래야만 우리 팀의 Scope를 정하고, 그에 맞는 개발 및 개선할 기능의 양을 정할 수 있다. 팀의 캐퍼(Capacity)가 크다면 더 많은 기능을 개발할 수도 있지만, 캐퍼가 작을 때는 최우선 순위 2~3개의 기능만 반영해야 한다. 




우선순위를 정하는 프레임워크 : MoSCow

반면 요구사항의 우선순위 설정에 사용되는 '프레임워크'들도 다양하게 존재한다.

그중 가장 간단하고 쉽게 적용 가능한 프레임워크는 MoSCow라 한다.


이미지 출처 : https://techbizinsight.tistory.com/



MoSCow는 Must Have, Should Have, Could Have, Won't Have를 의미한다.

각 요구사항을 4가지로 나눠 우선순위를 설정하는 것이다. 


- Must have : 없어서는 안 될 기능
- Should have : 매우 중요하지만 시급성이 Must have 대비 낮은 기능
- Could have : 있으면 좋지만 지금 꼭 있어야 할 필요는 없는 기능
- Won'have : 가장 덜 중요하고 효과도 미미한 기능


그러나 해당 우선순위를 정할 때도 위에서 언급한 유저 스토리와의 연관성과 이해관계자의 영향력, 그리고 개발 난이도 등을 다각도로 함께 고려해 기준을 정하는 것이 필요하다.






※ 참고 자료

- CIO, <결과에 득이 되는 '이해관계자 관리 계획 4단계'>, Moira Alexander

- 브런치, <백로그(제품 개선 일정) 관리하기>, tree, 2021/05/05

https://techbizinsight.tistory.com/13





매거진의 이전글 스크럼 팀이 일하는 방식과 PM이 경계해야 할 것

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari