노지훈 MSP께서 지난 번 수업을한 stakeholder Interview에 대한 내용을 아래와 같이 이해하게 쉽게 풀어서 설명해주셨습니다.


녕하세요! UX Pedia 가 첫 수업을 진행하였습니다. 이름도 다소 생소했던 Stakeholder Interview 라는 방법론에 대해서 철저히 파헤쳐 보았습니다. 스테이크가 나와서 뭐 레스토랑가서 인터뷰하는 거냐? 하고 생각하셨던 분들은 큰 코 다칠 겁니다. 잔뜩 집중하고 읽어 주세요 :^)

수업 방식은 온라인 리서치와 토론하는 과정을 통해 의견을 나누고 생각을 구체화하면서 방법론에 대해 인식해나가는 식으로 전개를 했습니다.

1. What / 정의

소프트웨어나 시스템 엔지니어링에서, 요구사항을 분석하기 위해 쓰는 기법으로 회사 안에서 새로운 프로젝트를 진행할 때 사업성에 관련된 측면이 고려 되어야 하고 이를 위해 회사의 사업적 요구를 파악하여 이해 관계자 혹은 의사 결정권자의 지지를 얻어야만 하기 때문에 프로젝트를 실행하기 위한 가장 첫 번째 단계가 된다. (Stakeholder = 의사결정권자, 이해관계자)

여기서 이해관계자란 클라이언트 중 프로젝트의 특정한 부분에 관심이 있고 그 결과에 직접적인 영향을 받는 사람들을 말한다.

즉, 본격적인 개발에 들어가기 이전에 프로젝트와 관련된 의사결정권자들의 생각을 듣고, 요구사항을 전달받는 과정이며 이들을 설득시켜 참여를 유도하고 1차적인 합의점을 찾아서 관련 아이디어를 창출하기 위해 사업 전략적인 측면에서 이루어지는 프로젝트의 시작점으로써 모든 분야에 앞서 포괄적으로 선행 되어야 하는 절차라고 할 수 있다.

부가적인 논의 (Stakeholder 를 User 로 볼 것인가?)

접기

접기

2. Why / 왜 하는가

• 프로젝트 진행 적합성을 판단하고 비즈니스적 목표를 구체화하여 방향성을 제시하기 위함.

• 투자자 / 클라이언트도 잠재적인 유저 Potential User 가 될 수 있다. 초기 아이디어를 다양한 계층의 Stakeholder 로 부터 검증하고 문제점을 파악한다. 또한 요구사항을 정리할 수 있다.

• 갑과 을의 관계에선 필수적인 절차이기 때문이다. 투자금과 같은 민감한 예산편성 문제에 직접적인 해결책이 될 수 있다. 또한 일정 / 인적자원을 산출하는 배경이 되기도 한다.

• "사장님은 UX를 몰라", "사장님은 헛꿈 꾼다" : 추가적인 리스크가 발생하지 않도록 하기 위해, 프로젝트 초기 진행 방향을 결정할 때 내부 전문가 (동시에 이해 관계자 인) 의 도움을 받아 실패의 확률을 낮출 수 있다. → 경영자에게 제공할 수 있는 객관적인 수치를 확립할 수 있다.

3. How / 어떻게 하는가

외부에 존재하는 잠재적인 사용자들을 조사하는 것이 User Research 라면, 조직 내부의 다양한 소리를 듣는 과정을 Stakeholder Interview 라고 다시금 정의해 볼 수 있겠다.

진행과정은 크게 "인터뷰 설계 - 진행 - 분석"의 흐름을 따라간다.

1. 문제사항의 이해 (프로젝트의 방향 설정) : 문제가 무엇인지 명확하게 정의하고, Interviewee 팀 자체에서 고민을 통해 포커스를 맞춘다.
2. 질문 리스트나 주제를 준비한다. 예상되지 않은 질문까지도 준비해야 한다.
3. 다양한 부서, 다양한 레벨의 Stakeholder 를 섭외한다. (다양한 니즈를 반영하기 위함)
4. 각각의 Stakeholder가 UX에 얼마나 어떻게 영향을 미칠 수 있는지 결정 한다. (예시 1 참조)
5. 인터뷰 진행시, Stakeholder 에게 자신의 Client 를 정확히 소개하고 이해시킨다.
6. 진행자는 어떤 Stakeholder 이더라도 UX를 파괴하고자 하지 않을 것이라는 것을 이해해야 한다. (Stakeholder 는 우호적인 인물이다. 마음가짐의 문제.)
7. Stakeholder 에게 Structure, Not to Structure, Semi-Structure 를 보여주어라.
8. 인터뷰 후에도 반복적이고 지속적으로 피드백을 받는다.

인터뷰 후 산출된 이슈들에 대해 중요도 별로 정리해 볼 수 있다. 이슈의 중요도를 정리하기 위한 방법으로 색이 다른 포스트잇이나 펜을 사용할 수 있다.

인터뷰 결과가 실제 프로젝트 얼마나 반영이 되는 지에 대한 투명한 공개가 필요하다. 이는 이해집단간의 마찰에 대비하는 효과와 프로젝트에 더욱 호의적으로 Stakeholder 들을 끌어들일 수 있는 효과가 있다. 투명한 공개를 위한 방법으로 Stakeholder 들을 직접 인터뷰 분석작업에 참여시키거나, 이들을 위한 공유회를 열 수 있다.

4. Reference

 

(예시 1. Stakeholder 의 영향력과 관련된 지표)
더욱 많은 레퍼런스는 UX Pedia 카페에 있습니다.

참여 UX Pedian : 고은, 김민해, 김우리, 김지수, 김현철, 김희조, 노지훈, 박종국, 신수연, 오민애, 유지형, 윤미영, 이희덕, 정동준, 정영록, 최원석, 황지순

두번째 모임을 가지게 되었습니다. 두번째 모임은 과연 Stackeholeder란 무엇인가 입니다.

앞에서 했던것처럼

what? -> why? -> how 이런식의 순으로 분석해 보려고 합니다.

일단은 .. stackholeder란 무엇인가 what은 우리가 온라인 회의때 찾아본것의 정의는


What

회사의 사업자 요구를 파악하여 이해관계자 혹은 의사 결정권자들의 지지를 얻어야만하기 때문에 프로젝트를 실행

하기 위한 가장 첫번째 단계라고 합니다. 


이것은 온라인 회의 내용을 간략하게 정의 한내용입니다..

다음 내용은 How와 Whay의 대한 스터디한 내용의정리입니다.


Why의 내용은 각 색상별로 그룹화 시켜 본것입니다. 각각의 4가지의 그룹의 주제츨 잡아봤습니다.


Stakeholder를 하는 이유는?

1. 일정/인적자원을 산출
2. 리스크 방지
3. Stakeholder 요구사항 정리
4. 방향성 제시