컨설팅 프로젝트 초기에 필수적으로 수행하는 활동 중 하나가 인터뷰입니다. 보통 임원, 현업 담당자 등을 대상으로 프로젝트 방향에 대한 의견 청취나 현황 파악 등을 위해서 진행합니다.
고객사 지식이 많지 않고 문제를 파악하여 수행 과제의 방향을 잡길 원하는 컨설턴트에게는 인터뷰는 무엇보다도 중요한 활동 중 하나입니다.
이렇게 중요한 인터뷰를 할 때 쉽게 생각해서 그런 지 자주 범하는 실수가 두 가지 정도 있습니다.
첫 번째, 인터뷰는 질문지 정도만 준비하여 진행하는 손쉬운 활동이라고 생각하는 것입니다.
두 번째는 인터뷰에서 나온 내용을 액면 그대로 믿는 것입니다.
먼저 인터뷰 대상은 자신의 소중한 시간을 할애하여 인터뷰에 참여를 해준 겁니다. 그런 소중한 시간을 컨설턴트가 가지고 있는 간단한 궁금증을 풀어주는 데 쓰거나, 조금만 찾아보면 쉽게 확인할 수 있는 내용을 말해주는 데 보내고 싶지 않을 겁니다.
인터뷰를 하려면 먼저 1. 기본적인 현황 파악 (고객 눈높이 맞추기) 2. 가설적으로 이슈를 정의 (목적성 있는 인터뷰) 3. 기초 데이터 분석을 통한 이상점 파악 (인터뷰 대상에게 꼭 들어야만 하는 질문 준비)이 선행되어야 합니다.
1. 기본적인 현황 파악: 고객사마다 해당 회사가 속한 산업 용어, 회사에서 쓰는 용어들이 있습니다. 그런 용어를 포함하여 직원이라면 기본적으로 알아야 하는 산업 정보, 회사 정보, 제품 정보 등은 당연히 알고 있는 상태에서 인터뷰를 진행해야 합니다. 이렇게 해야 하는 이유는 짧은 인터뷰 시간을 구글링만 해도 얻을 수 있는 정보를 파악하는 데 시간을 보내지 않기 위함이 첫 번째 이유이고, 인터뷰 대상과의 눈높이와 구사하는 언어를 최대한 맞추기 위함입니다. 아무리 인터뷰 대상자가 자신의 대답을 충실히 해줘도 그걸 이해하지 못한다면 그 시간은 서로에게 낭비일 뿐입니다. 질문자가 영어로 질문하고, 답변자는 한국어도 답변하면 서로 의사소통이 되지 않겠죠.
2. 가설적 이슈 정의: 인터뷰 시 활용할 질문지에는 컨설턴트가 얻고자 하는 목적이 명확하게 드러나야 합니다. 무엇을 파악하고자 하고, 무엇이 문제인지 정의하고자 하는 관점이 녹여져 있어야 합니다. 당연하게도 인터뷰 하루 전 날 또는 당일에 숙제하듯이 질문지를 만들어선 안됩니다. 해결하고자 하는 문제를 가설적으로 정해두고, 그에 기반하여 질문지를 만들어야 합니다. 인터뷰 대상은 인터뷰 들어오기 전까지도 정확하게 자신이 무엇을 대답해야 하는지 모를 수도 있습니다. 무엇을 문제로 생각하는지, 무엇을 해결책으로 내놓으려고 하는지를 간단명료하게 표현할 수 있어야 합니다. 당연히 질문지는 사전에 배포해야겠죠? 가장 최악의 인터뷰는 목적성이 없는 인터뷰입니다. 인터뷰를 하는 사람이나, 인터뷰 대상이 되는 사람이나 서로에게 시간 낭비가 안 되는 인터뷰가 되려면 목적성이 명확해야 합니다.
3. 기초 데이터 분석: 앞서 말한 가설적 이슈 정의를 하려면 고객사가 가지고 있는 기초 데이터를 사전에 분석해야 합니다. 정량 데이터일 수도 있고, 정성적 정보가 담긴 보고서일 수도 있습니다. 가설을 사전에 검증할 수 있는 데이터와 보고서를 수집하여 인터뷰 전에 대략적으로 파악하고 인터뷰를 임해야 합니다. 데이터 분석을 통해서 꼭 질문을 통해서 알아야 하는 질문을 만들어 낼 수 있습니다.
이렇게 인터뷰를 준비하고 나서, 질의서를 사전에 배포하고 답변서를 받으면 좋겠지만, 대부분은 인터뷰 시간까지 답변서를 주지 않고, 인터뷰 때 답변할 가능성이 높겠죠.
인터뷰를 마친 후에는 중요한 것은 “팩트 체크”입니다.
반드시 알아두어야 할 것은 “고객은 사실만을 말하지 않는다"라는 겁니다. 일부러 속이려는 경우는 많지 않겠지만, 자신의 입장에서, 자신의 관점에서 답변을 하기 때문에 그것을 있는 그대로 믿는 건 위험합니다. 객관적인 증거를 확인해야 합니다.
인터뷰가 끝나는 후 가장 위험한 보고서가 인터뷰에서 나온 내용을 토씨 하나 틀리지 않고, 그래도 올리는 보고서입니다. 누구나 자신이 겪는 문제가 가장 큰 문제이고, 자기가 아닌 다른 사람이 그 이유가 됩니다. 그렇게 하나하나 의견을 듣고 팩트 체크도 안 하고 그대로 보고서에 올린다면 그게 제대로 된 보고서일까요?
팩트 체크를 어떻게 해야 할까요?
가장 기본적인 건 당연하게도 데이터 분석입니다. 인터뷰 대상자가 어떤 의견이나 사실을 말했다면, 그와 관련된 데이터를 요청해야 합니다. 요청한 데이터를 분석하여 인터뷰 결과와 비교하고 확인해야만 합니다.
해당 인터뷰 대상자의 전/후공정 담당자의 의견도 같이 파악해야 합니다. 예를 들어서, 설계자가 제품 사양 요청이 명확하지 않다는 의견을 냈다고 가정해 봅니다. 그럴 땐 당연하게도 전 공정 담당자인 영업 담당자 의견도 들어야 합니다. 자신이 주는 사양 요청은 명확하지만, 오히려 그것과 제품 구조와의 연결이 모호할 수도 있습니다. 후 공정 담당자인 생산 쪽 의견도 들어봐야겠죠. 물론, 가장 중요한 건 영업에게 제공하는 사양 요청서와 설계가 받아서 정리하는 사양서, 최종적인 설계 결과에 대한 데이터를 파악하는 것이 기본이 되어야 합니다.
팩트 체크를 한 후에는 그에 대한 결과를 다시 인터뷰를 진행한 담당자에게 확인을 받아야 합니다.
그렇게 이중, 삼중으로 확인하여 담당자가 놓칠 수 있는 부분, 컨설턴트가 놓칠 수 있는 부분을 최소화해야겠죠.
인터뷰가 끝난 후에는 녹취록과 회의록을 만들어야 합니다. 녹취록은 말 그대로 인터뷰에 나온 내용을 여과 없이 그대로 옮긴 내용을 말하지만, 회의록은 기본적인 팩트 체크와 추후 확인해야 할 사항들이 정리되어야 합니다. 당연히 회의록은 인터뷰 대상자에게 최종 확인을 받아야 합니다. 옮겨 적는 과정에서 실수가 있을 수도 있고, 빠진 내용도 있을 수 있으니까요. 흔히 녹취록과 회의록을 주니어 컨설턴트에게 맡기는 경우가 많은데, 녹취록은 주니어 컨설턴트에게 맡기더라도 회의록은 인터뷰를 주관한 사람이 직접 작성해야 합니다. 회의록에는 자신이 설계한 인터뷰의 구조가 표현되어야 하기 때문이죠.
마지막으로 인터뷰 시에 나오는 내용 중에 혼동하기 쉬운 현황, 이슈를 구별할 필요가 있습니다.
현황은 말 그대로 현재 벌어지고 있는 현상, 사실을 의미합니다. 이슈는 현상으로부터 파악된 해결할 필요가 있는 문제를 의미합니다. 그런데, 인터뷰할 때는 담당자는 현황과 이슈를 구분 없이 말합니다. 현황과 문제점을 딱히 구별하지 않고 언급하기 때문에 컨설턴트는 이걸 분류해야 합니다.
먼저 현황에는 문제점이 있을 수 있으나, 그것이 이슈가 아닐 수도 있습니다. 이슈는 근본적인, 핵심이 되는 문제입니다.
예를 들어서, 직원이 “야근, 특근이 잦다”라는 문제를 이야기했습니다. 현황이자 문제이죠. 그걸 보고서에 이 회사는 “야근, 특근이 잦다”라고 표현하는 것이 맞을까요? 컨설턴트는 왜 많은 지를 파악해야겠죠. 예를 들어서, 데이터 정합성이 떨어져서 마감까지 최종 정산을 하려면 어쩔 수 없이 야근, 특근을 해야 할 수도 있습니다. 왜 데이터 정합성이 떨어지냐고 알아보니 데이터를 수기로 입력하기 때문에 정확한 결과를 못 얻어서 그럴 수 있겠죠. 마지막으로 수기로 입력하는 이유가 활용 시스템의 노후화가 심해서 입력을 일일이 확인해서 입력할 수밖에 없을 수 있습니다.
자, 그러면 해결할 문제는 야근, 특근이 많은 것일까요? 아니면 시스템의 노후화일까요?
당연히 후자겠죠?
그래서, 현황, 문제점은 인터뷰를 통해서 파악하되, 이슈는 컨설턴트가 팩트 체크하고, 데이터 분석하여 직접 얻어내야 합니다. 그리고, 그것을 해결하는 것이 본 프로젝트의 과업이 되겠죠?
인터뷰는 프로젝트의 시작이라고 표현할 만큼 중요한 활동입니다. 그렇지만, 실제로는 요식 행위처럼 의무적으로 수행하는 경우도 많습니다. 고객과의 눈높이를 맞추고, 진짜 해결해야 하는 문제를 찾는 과정인 만큼 그에 걸맞은 노력과 시간을 보내야 할 것입니다.
