[SI이야기][산출물] 인터뷰 결과서 작성하기

SI프로젝트 수행 중에 사람들이 모여서 이야기하면 다 회의라고 생각할 수 있지만, 그렇지 않은 경우가 있다. 그 대표적인 예가 프로젝트 분석 단계에 있는데 그건 다름 아닌 '인터뷰'다.

 

'인터뷰'와 '회의'의 차이가 무엇이냐고 의아해할 수 있다. 만나는 대상의 문제라고 생각할 수도 있다. 하지만 꼭 그렇진 않다. SI프로젝트에서 비즈니스 현업을 만나도 인터뷰일 수도 있고 회의일 수도 있다. IT부서를 만나도, 사업주관부서를 만나도 비슷할 수 있다. 그러면 무엇이 이 둘의 차이를 결정하느냐? 그건 '목적'이라고 할 수 있다.

 

이전에 회의록 작성하는 법에 대해 포스팅을 한 적이 있는데 그때 작성 내용 중에 '결정된 내용을 작성'하는 것과 '회의 종료 후 해야 할 일'을 작성하는 게 중요하다고 했고 마지막에 팁 아닌 팁으로 '나에게 유리하게 작성'해야 한다고 썼었다.

 

본 적이 없다면 아래 포스팅을 참고하기 바란다.

2020.03.30 - [슈르의 오피스라이프/오피스라이프 팁] - 회의록 제대로 작성하는 방법

회의록 제대로 작성하는 방법

 

하지만 인터뷰 결과서는 목적이 회의와 다르다. 그래서 인터뷰 결과서라는 산출물은 다르게 작성해야 한다. 오늘은 그 방법과 내용에 대해 소개해보도록 하겠다.

---

1. 인터뷰 결과서는 들으러 가는 자리이다.

 

회의와 달리 인터뷰라는 것은 누구에게 요건을 받으러 가는 것도 아니고, 결정을 받으러 가는 것도 아니다. 누군가가 힘이 있어서 그 사람의 눈치를 보러 가는 자리도 아니다. 인터뷰는 더 많이 아는 사람에게 덜 아는 사람이 궁금한 점을 해소하러 가는 자리라고 볼 수 있다.

 

보통 SI프로젝트에서 인터뷰는 IT만 아는 사람들이 비즈니스를 아는 사람들을 만날 때 자주 하는 일이다. 실제 그 업무를 수행하고 있는 전문가를 만나는 일 말이다. 대충 예를 들어보면 이런 만남들이다. 금융 자문 서비스를 제공해 주는 전문가를 만나서 고객을 만나기 전에 어떤 준비를 하는지, 어떤 자료를 보는지, 어떤 점이 가장 힘든지, 고객이 가장 궁금해하는 게 무엇인지를 물어서 금융 자문 서비스를 제공하는 직원들의 업무 편의성을 증대시킬 수 있는 Idea를 얻는다든지, 그들이 찾고 열람하는 정보를 모아서 보여주는 대시보드를 만들어주는 등의 일을 할 수 있다. 아니면 어떤 물건을 판매하는 영업점에 찾아가서 세일즈 매니저가 고객에게 세일즈 하기 위해 어떤 자료를 보고 어떤 일들을 하고 있는지, 필요한 시스템을 사용함에 있어서 어떤 점이 가장 불편한지 등을 물어보고 현행 시스템의 개선점을 찾아내는 일을 할 수 있다.

 

위의 경우에서는 회의가 아니기 때문에 이 미팅의 끝에 '어떤 시스템을 만들어주세요'라는 결론을 내릴 수가 없다. 그리고 '다음에 만날 때 이런 걸 해오세요'라는 action item도 나오지 않는다. 그래서 '인터뷰 결과서'라는 산출물을 따로 작성할 수밖에 없는 것이다.

 

 

2. 인터뷰 결과서에는 Fact를 쓴다.

 

순수하게 들은 내용이 무엇인지 작성하는 것이 중요하다. 내가 들은 내용을 정리해서 공유하는 것이 중요한 산출물이라고 할 수 있다. 이 인터뷰 대상자들은 대체로 바쁜 시간, 귀한 시간을 내어준 사람들이기 때문에 많은 사람들이 와글와글 갈 수도 없고 여러 번 찾아갈 수도 없다. 하지만 이들의 인터뷰 내용은 중요한 Input 또는 살아있는 Voice로서 역할을 충분히 하기 때문에 정리되고 공유되어야 한다. 그래서 시사점을 도출하거나 아이디어를 붙이는 산출물이 아니라 사실 그대로를 작성하는 것이 가장 중요한 문서다.

 

 

3. 사실적으로 쓰자. live하게!

 

딱딱한 회의록과 달리 인터뷰 결과서는 생각보다 자유로운 형태의 산출물이다. 실제로 슈 과장은 회의실에서 만나서 화이트보드에 그리고 적어가며 작성한 내용을 산출물에 옮기고 뒤에 그 화이트보드 사진을 첨부로 넣은 적도 있다. '그게 더 live 하지 않냐'는 사수의 의견이었는데, 실제로 고객도 매우 좋아했다. 

 

- PPT로 작성해도 되고, 워드로 작성해도 된다.

- Q&A 형태로 작성해도 되고, 일목요연하게 정리해도 된다.

 

 

4. 제개정이 없는 산출물이기도 하다.

 

인터뷰는 하고 끝나기 때문에, 제개정이란 없다. 인터뷰 내용에 첨삭이 있을 수는 있다. 내가 업무 지식이 부족하여 잘못 작성한 경우 고객이 수정하라고 할 수도 있고, 참석한 분은 잘 모르는 내용이라 대답을 틀리게 하셔서 나중에 확인하고 정정해 주는 경우도 발생할 수 있다. 하지만 이 모든 일들은 산출물이 최종으로 종료되기 전의 일이다. "내용 정리했는데 검토 부탁드립니다" 했을 때 오는 피드백이라는 의미다.

 

그렇기 때문에 이 산출물에는 제개정이 없다(없어도 된다. 혹시 고객이 넣으라고 하면 넣어주자). 형식적으로 최종을 찍는 단계를 만들 수 있지만, 인터뷰 내용에 대한 산출물 검수를 사업 주관부서에서 해줄 수 없기도 하고('제가 뭘 보고 OK 하죠?'라고 묻을 수 있다), 대체로 인터뷰 결과서는 working 산출물이기 때문에 정식 검수가 중요하지 않아서 일단 한번 검토하고 오케이 찍고 끝나는 편이다.

 

 

5. 인터뷰 결과서에 필수로 들어가는 내용은 대체로 이렇다.

 

- 인터뷰 수행일시, 장소

- 참석자 : Iterviewee, Interviewer 

- 인터뷰 내용

 

혹시나 인터뷰가 여러 날에 걸쳐서 진행된 경우라면 (예 : 1일에는 실무자, 2일에는 관리자 등) 하나의 산출물에 같이 정리해도 무방하다. 인터뷰 수행일시를 목록으로 쭉 쓰고, 인터뷰 내용을 모아서 쪼로록 써도 된다. 내용이 너무 많거나, 너무 다른 내용이거나, 인터뷰를 수행한 날짜의 텀이 길거나, 인터뷰 참석자가 다 다르다면 파일을 따로 만드는 것이 맞다. 내가 인터뷰를 다 들어가지 않았는데 모든 인터뷰 결과서의 작성자가 나라면 뭔가 안 맞을 테니 말이다.)

 

 

6. 인터뷰 질의서라는 산출물이 필요할 수 있다.

 

정말 바쁜 사람이라거나 정말 일 꼼꼼히 하는 사람을 만나게 되는 경우 '어떤 질문을 하는지 미리 보내주세요'라는 요구가 올 수 있다. 그런 경우 인터뷰 질의서를 만들어서 보내줘야 한다. 그러면 그분들이 그걸 보고 들어오거나 필요한 내용이나 자료를 준비해서 오시기도 한다.

 

이런 요청을 미리 받지 않아도 인터뷰 질의서를 만들어서 미리 주면 상대방이 '아 이런 자리인 줄 알았으면 다른 사람을 보낼 걸 그랬네요'라는 소리를 안들을 수 있다. 미리 알아서 오거나 다른 사람을 보내거나 심지어 아이디어를 미리 준비했다는 듯이 갖고 오는 경우도 있다.

 

인터뷰 질의서는 다음에 기회가 되면 따로 다루도록 하겠다. ^^

---

참고로 인터뷰 결과서 자체에 효력이 그만큼은 없을지라도 실제 "사용자의 Voice나 Needs가 어떠해서 이렇게 했습니다"라는 명분은 C레벨도 무시하지 못하는 당당한 근거가 된다. 그리고 "그런 Voice를 들었냐"라고 C레벨이 물었을 때 "실제로 프로젝트 분석 기간에 사용자를 만나서 '인터뷰'를 진행하고 들었습니다"라는 대답을 하면 99% 넘어갈 수 있다.

 

넘어가지 못하는 1%가 무엇이냐? 그건 C레벨 본인이 과거에 그 사용자였거나 그 Needs를 더 잘 아는 경우에 그 인터뷰를 무시할 수 있다("그 사람의 개인적 의견이고 내가 그 업무 해봐서 아는데 필요한 건 A가 아니라 B야.") 하지만 IT C레벨에서는 거의 불가능한 조건이기 때문에 99%는 엄청난 파워로 이길 수 있다. 대신 반대로 이 Need를 파악하지 못하고 '그냥 타사 사례가 이래요'라든지 '이게 좋아서요'라든지 'IT 의사결정입니다'라고 대답하면 C레벨 마음에 안 드는 결과를 가져갔을 경우 갈아엎게 될 확률이 높다. ^^ 물론, C레벨이 순수 IT인데 그 말 듣고 미리 갈아엎으면 사용자 테스트에서 실사용자 피드백 듣고 또 갈아엎을 수 있다.

 

2023.03.07 23:50