사용자인터뷰를 진행했다.
이에 대해 회고하며 어떻게 하면 최초의 인터뷰를 잘 구성하고 진행할 수 있을지 정리해 봤다.
분석 단계 최초 인터뷰 구성
인터뷰를 구성하면서 고통스러웠다. 질문은 곧 질문자의 수준을 나타내기 때문이다. 얼마나 고민했는지 드러날 수 있다는 생각 때문에 고통스러웠다. 그러나 생각을 바꿨다. 질문을 던질 수 있는 건 우리 일의 장점이 아닐까 생각했다. 모르는 걸 물을 수 있게 자유이자 곧 의무이기도 하다. 하지만 그렇다고 그냥 궁금한 걸 물을 순 없다. 필요한 질문을 해야 한다는 것이다.
그럼 필요한 질문이란 무엇인가?
가장 먼저 해야 할 것은 개념에 대한 확인이다. 이 개념은 명확히 정의가 되어 있는지 만약 프로세스에 중요한 개념이라면 반드시 개념 확인이 필요하다.
개념 다음은? 우리 일의 목적에서 필요한 질문은 무엇인지 생각해 볼 수 있다. 우리는 결국 AS-IS의 프로세스를 개선시키는 것이다. 프로세스라는 건 시스템에서 진행되던 것뿐 아니라 수기로 진행되던 것을 포함한다. 그래서 AS-IS는 어떻게 진행됐는지에 대한 질문이 이뤄져야 한다. 프로세스는 무엇이 있고, 이 프로세스 전의 프로세스는 무엇이며, 또 이후 프로세스는 무엇이고, 이 프로세스와 저 프로세스는 뭘 기준으로 나눠지는지에 대해 확인하는 내용이어야 한다.
그럼 프로세스만 물어야 할까? 이렇게 생각해 보자. 프로세스에 영향을 미치는 건 프로세스뿐인가? 어떤 사전조건이 있고 뭘 기준으로 프로세스가 나눠지는지로도 나아가야 한다.
사실 이렇게 생각해도 내가 생각하는 가장 좋은 방법은 하나다. 일단 궁금한 걸 적어 보는 것. 궁금한 걸 리스트업 하고 주어진 자료 속에서 답을 또 찾아본다. 자료 속에 답이 있을 수도 있고, 이건 이래서 저럴 것이다라고 추정할 수도 있다. 이렇게 가설을 세워놓고 그 가설에 맞지 않는 내용이 자료 속에서 발견되면 그것도 질문 포인트가 될 수 있다.
인터뷰 시작
인터뷰를 진행 시작하기 전에 해야 할 일은 무엇일까?
상황을 생각해 보자. 현업은 자신의 업무를 하다 구축팀이 요청한 인터뷰에 응하기 위해 시간을 내어 회의실에 참석했다. 지금 현업의 머릿속은 어떨까? 인터뷰 때문에 회의실에 왔다만, 현업 머릿속에는 이전까진 진행하던 업무 내용뿐일 것이다. 결국 현업 머릿속을 업무 맥락이 아닌 인터뷰의 맥락으로 바꿔줄 필요가 있는 것이다. 그렇기 때문에 이 인터뷰의 목적과 내용에 대해 설명해 줄 필요가 있다.
"나는 누구이고 / 오늘 인터뷰는 무엇을 목적으로 요청했으며 / 따라서 오늘 인터뷰는 어떠한 내용을 주제로 / 무엇에 대해 질문할 것이다"에 대한 내용이다.
이러한 과정을 모두발언이라 할 수 있을 것 같다.
인터뷰 진행
현업의 머릿속도 인터뷰 맥락으로 가져왔겠다 그럼 질의서만 읽고 대답을 들으면 될까?
우선 생각해 보자. 질의서는 누가 가장 잘 아는가? 질문을 작성한 사람이 가장 잘 안다. 이 질문을 왜 하고, 나는 어떤 부분을 확인하기 위해 하는 질문인지, 즉 질문의 맥락과 목적은 질문을 구성한 내가 가장 잘 안다. 원하는 답을 얻어내려면 인터뷰어는 이 부분에 대한 설명도 첨언해야 한다.
답변 정리
이렇게 잘 질문했다면? 현업이 모든 질문을 원하는 형식이 딱딱 맞게 답해주면 좋으련만.. 얘기하다 보면 그렇지 않은 게 부지기수다. 따라서 질문마다 원하는 답을 얻었다면, 답변 내용을 요약하며 이와 같이 정리하겠다고 짚고 넘어가는 게 좋다.
인터뷰 종료
인터뷰는 단순 묻고 답하는 역할극이 아니다.
정해진 시간 동안 업무를 진행함에 있어 필요한 정보를 묻고 답하는 시간이다. 나의 시간만큼이나 인터뷰에 성실히 답해준 인터뷰이도 소중한 시간이었을 것이기에 인터뷰의 끝에는 항상 감사 인사와 함께 앞으로 이후 진행할 업무, 예를 들어 세부사항에 대해 어떻게 질의를 이어갈 것인지 또 질문 과정에서 얘기된 자료는 어떻게 전달받을 것인지 등을 정리하며 마치면 깔끔한 마무리가 될 것이다.
내재화
남은 문제.. 이것들을 어떻게 내 것으로 만드냐?
질문을 구성할 때는 생각하기 쉽다. 자가검열과 동료와 소통을 거치며 질문을 발전시킬 여유가 있는 편이다. 근데 인터뷰 진행 과정에서 이런 거 챙기면서 할 수가 없다. 정신이 없기 때문이다. 그렇게 때문에 인터뷰 전 질의서를 꼼꼼히 읽고 시뮬레이션을 해 볼 수밖에 없다. 내가 썼어도 결국 인터뷰하다 보면 내가 이걸 왜 썼지 싶은 순간들이 올 수 있기 때문에 맥락과 목적을 생각하면서 연습하는 것이 더 높은 수준의 질의서를 만들어가는 과정이기도 하다.
회고
오늘 인터뷰를 마치고 파트 시니어분과 기획 PL 그리고 개발 PL님께 좋은 말씀을 들었다. 열심히 한 것 같다고 잘해줘서 고맙다고.
사실 긴장을 엄청 많이 했다. 이전 인터뷰에 거의 삼사십 명이 들어오다 보니 숫자에서 오는 부담과 평가에서 오는 부담이 컸다. 연차가 좀 쌓여서 그런지 일 못한다는 소리는 정말 듣기 싫다..
질의서 만들 때부터 꽤나 고통스러웠는데, 파트 시니어분이 리뷰도 잘해주시고 질문 방향도 함께 잘 잡아주신 덕분에 좋은 질문이 많이 나왔다. 정독해보라는 조언도 그분의 조언이었다. 내 인터뷰 때도 이삼십 명 정도의 사람들이 들어왔지만 초반은 그래도 연습 덕분에 꽤나 순조롭게(?) 흘러갔다. 인터뷰가 진행되며 현업의 태도가 점차 호의적으로 바뀌어갔다. 근데 인터뷰 후반부로 갈수록 체력 이슈와 질의서를 통달하지 못했던 나의 기억력 감퇴(?)로 내가 이걸 왜 썼지 싶은 순간들이 몇 개 있었다. 그래도 망하진 않은 것 같아 다행이다 생각했다. 다만, 파트 시니어분과 기획 PL님이 안 계셨다면.. 이걸 기회로 다음 미팅에는 홀로 리딩할 수 있겠다 스스로 인정할 수 있도록..!
'서비스기획, PM, PO > 일하며 느낀 것들' 카테고리의 다른 글
| 피그마-구글스프레드 시트 연동이 안될 때 (0) | 2023.11.01 |
|---|---|
| SI 서비스기획자에게 성과란? (0) | 2022.05.07 |
| [서비스기획] 요구사항 놓치지 않기 - 개인 버전과 공식 버전 (0) | 2022.05.01 |
| [서비스기획] 수행사의 요구사항 정의서(기능, 사유) (0) | 2022.05.01 |
| [서비스기획] SI 프로젝트에서 수행사 서비스기획자의 산출물 (0) | 2022.04.30 |
