'스프린트'의 이해관계자와의 소통을 위한 유의점 (2)
지난 글에서는 '스프린트'를 사용하며 고객이 겪은 문제점을 유저 스토리를 통해 해결하고자 하는 방법에 대해 글을 썼습니다. 오늘 글에서는 과연 '스프린트'의 이해관계자는 누가 있을 것이며, 이해관계자와 소통하기 위한 유의점을 작성해 보려고 합니다.
'스프린트' 사용 후 문제점, 애자일하게(유저 스토리) 개선
1. 애자일이란? 애자일의 대전재는 "가장 강하거나 똑똑한 종이 살아남는 것이 아니라, 변화에 가장 적응을 잘하는 종이 살아남는다." 입니다. 이처럼 애자일하게 일한다는 것은 소비자의 반응을
busybaby.tistory.com
1. 이해관계자란?
먼저 프로젝트 이해관계자는 무엇일까요? 그들은 수행 중인 프로젝트에 영향을 주거나 받을 수 있는 사람입니다. 이해 관계자의 구성은 경영진, 고객, 제품팀, 스크럼 마스터 등으로 구성되어 있습니다. 이해관계자는 개개인부터 고위 경영진에 이르기까지 조직의 모든 수준에서 나올 수 있지만, 프로젝트에 관여하는 모든 사람은 중요합니다. 매일 프로젝트 진행에 직접 관여하지 않고, 발언권을 가진 것은 아니지만 수행중인 업무가 결과에 영향을 미친다면 모두 이해관계자로 볼 수 있겠습니다. 이해관계자를 파악하기 위해서 분석맵을 그려볼 수 있으며, 영향을 식별하는 방법으로 영향이 높고, 낮음을 파악할 수 있는 좋은 방법입니다. 내부 이해관계자의 유형과 외부 이해관계자의 유형 그리고 분석 수행시 이점은 아래와 같습니다.
[내부 이해관계자 유형]
프로젝트 매니저
프로젝트 팀원
프로젝트 포트폴리오 매니저 및 프로그램 매니저
프로젝트 후원자 (해당경우)
임원
기타 여러 부서의 내부 팀
[외부 이해관계자 유형]
고객
계약업체
하청업체
사용자
투자자
공급업체
[이해관계자 분석 수행의 이점]
더 많은 지원 및 리소스 확보
프로젝트 가시성 향상(특히, 임원 이해관계자에게 해당)
프로젝트 주기의 후반부에 비용이 많이 드는 문제 방지
적시에 정확한 채널로 커뮤니케이션
이해관계자와 정확한 정보 수준을 공유
2. '스프린트'의 이해관계자와 역할
'스프린트'의 팀 구성은 3명으로 이루어진 조직입니다. CEO가 대표로 PO와 개발을 겸하고 있으며, 내부 팀은 2명의 개발자로 이루어져 있습니다. 이렇게 소수의 인원으로도 조직이 굴러가는 이유는 극강의 효율적인 업무 방식, 업무 툴 (지라, 클라우드 서비스 등)을 아낌없이 사용하는데에 있습니다. 스프린트는 인간지능 방식으로 음식을 등록하면 100여명의 재택 근무자가 칼로리와 음식을 등록해주고 있습니다. 또 다른 이해관계자에는 투자자, 사용자가 있습니다. 사용자는 인스타그램 채널에서 주로 소통을하며, 약 8만명의 월 사용자의 트래픽을 보유하고 있습니다.
1) CEO 1명 (CEO/PO)
: 창립자로서 스프린트 기업을 운영하며 CEO와 PO의 역할을 공동으로 수행하고 있습니다. IT 프로젝트의 개발부터 출시, 외부 팀과의 커뮤니케이션 및 조율 등 프로젝트 전반을 관리하는 업무를 담당하는 역할을 합니다. 예로 기업의 목표, 계획, 일정관리, 구성원 관리, 기능 수정, 배포, 사용자 목소리 파악 등 모든 일을 통제 관리하는 역할을 합니다.
2) 프로젝트 팀원 (개발자 2명)
: 스프린트의 팀원은 개발자 2명으로 구성되어 있습니다. 개발자는 프론트엔드 개발자/ 백엔드 개발자로 구성되어 있음으로 예상해 봅니다. 스프린트에서 일어나는 기술적 이슈, 버그, 기능추가, 기능개선, 개발 등 앱 내에서 일어나는 기술적인 문제를 해결하는 역할을 할 것입니다.
3) 스프린트 매니저 (음식 데이터 입력 재택 근무자)
: 사용자가 글이나 사진으로 등록하는 데이터를 음식 에너지 데이터로 입력하는 음식 데이터 입력 담당 매니저가 있습니다. 약 100여명의 아르바이트 근무자가 일하고 있으며, 음식을 데이터를 입력하거나 식단에 대한 피드백을 하는 역할을 할 것 입니다.
4) 투자자
: 투자자의 정보의 액수와 투자자수는 기업 내부 정보라 정확하게 알 수 없지만 투자금이 자본금으로 흘러갔다고 가정한다면 2600만원 -> 1억원만큼의 증가분이 투자액이 아닐까 유추해봅니다. 그리고 재무제표에 공시하지 않은 투자액 또한 있을 것으로 예상됩니다. 그들은 기업 경영에 어느정도 참여할 것이며, 발언권이 있습니다. 발언권에 대해서는 기업의 목표와 어긋나지 않을 정도로 요구사항을 들어줘야 겠습니다.
5) 사용자
: 스프린트의 사용자는 앱을 사용하면서 느꼈던 불편함, 실제 이용, 기능 개선, 좋은점을 말하는 역할을 할 것입니다. 그들의 목소리를 꼼꼼하게 들어, 자주 발생하는 키워드 위주로 기능 개선에 참고를 해야할 것입니다.
[소셜분석 : 월버즈량은 4대 SNS(Twitter, Facebook, Instagram, YouTube) 및 카페, 블로그, 포럼 등 온라인상의 해당 기업명/서비스명을 포함한 게시물 수입니다.]
3. 이해관계자와의 원활한 소통을 위한 방법
그래서 PM으로서 이해관계자와 소통하기위해 어떤 방법을 써야할까요? 이해관계자의 요구사항을 주관적인 기준으로 세워 요구사항을 들어주기 보다는 일정 기준이 있어야 한다고 생각합니다. 그것을 도와주는 하나의 도구를 통해 원활한 소통을 하고자 합니다. 스프린트에서는 어떻게 이해관계자의 소통을 위해 일하는지 알 수 없지만 이해관계자의 요구를 해결하기 위해 도움을 얻기위한 방법을 소개하고자 합니다.
MoSCoW는 요구사항의 우선순위를 정하는 간편한 방법론으로
Must Have, Should Have, Could Have, Won't Have의 줄임말 입니다.
1) Must have : 치명적이고 시급성이 있는 꼭 필요한 기능
2) Should have - 매우 중요하지만 시급성이 Must have 대비 낮은 기능
3) Could have - 있으면 좋겠는데 꼭 있어야 할 필요는 없는 기능
4) Won'have - 가장 덜 중요하고, 효과도 미미한 기능
① Must have
이 기능이 없다면 이번 릴리즈를 할 필요가 없어지거나
이 기능이 없다면 이번 릴리즈, 프로젝트, 제품이 크게 훼손되고
이 기능을 대체할 다른 쉬운 방법이 없다면 Must have
예를 들면, 스프린트에서 식단 등록하기 버튼, 식단을 분석해주는 기능을 만드는 것은 Must have가 되겠습니다.
② Should have
나중에 해도 망하지는 않는다는 것이 핵심
이것이 있다면 확실한 가치를 제공하지만 없어도 제품이 동작하고,
지금하면 참 좋은데 리소스가 너무 부족해서 다음으로 미루어도 제품 동작을 못하게 하지 않는 다면 Should have
예를 들면, 성능 개선 같은 요건입니다. 스프린트에서는 식단 등록에 문자 말고도 사진으로도 등록하고자하는 요구사항이 되겠습니다.
③ Could have
흔히들 nice-to-have 라고 부르기도 함
과감하게 제거하더라도 큰 영향을 받지 않는 기능이라면 Could have
예를 들면, 스프린트에서 사람들이 자주 먹지 않는 음식은 등록되면 좋겠지만, 빈도수가 적어서 꼭 지원해야 하는 기능은 아닐 수 있습니다.
④ Won't have
그냥 하지 않아도 되는 중요하지 않고, 효과도 미미한 기능
없는 것보다는 있으면 좋은 구석이 있으니 요구사항으로 등록했을 겁니다.
리소스를 엄청 투입해야 하는데 얻는 효과가 너무 미미한 경우라면 Won't have!
예를들면, 한달을 열심히 개발해서 기능을 추가해야 하는데 무료회원만 사용할 정도거나, 사용자 이용률이 없는 기능이겠습니다. 안그래도 적은 개발 인력을 가진 스프린트에서 인력 소모가 큰 기능은 최소화하여 우선순위를 잘 파악해야겠습니다.
MoSCoW는 이처럼 간단하지만, 단점이 꽤 많기 때문에 주의할 점이 있습니다. MoSCoW는 상당히 일차원적인 시각에서 개별 요구사항의 중요도만 판단한 것이기 때문에 각 요건이 제품에 기여할 수 있는 가치를 종합적으로 평가해서 선정하기 어렵습니다. 수익화가 제품의 목표이겠으나, 사용성이 좋아야 수익화로 이어집니다. 이처럼 우선순위에 참고를 할 도구일 뿐 판단은 pm이 해야 할 업입니다. 특히 스프린트는 인력이 적고 자원이 부족하기 때문에 기껏 만들었는데, 아무도 사용하지 않는 기능을 만드는 것은 아닌지 우선순위를 잘 파악하여 일을 하는 것을 가장 유의해야할 것입니다.