[프로젝트 경험법칙] 사용자의 말보다 행동을 믿자

0

소프트웨어를 만들 때 사용자의 니즈를 파악하는 방법으로 대면 인터뷰를 많이 사용한다. 모든 일이 그렇겠지만 이 인터뷰를 제대로 하려면 정말 자원이 많이 필요하다. 우선 고객이 제공해 주는 자료나 기초 자료 분석을 해서 인터뷰 때 사용할 질문지를 만들어야 한다. 인터뷰를 효율적으로 진행할 수 있게, 질문지를 완성했다면 인터뷰 대상자들에게 발송하고 미리 질문에 대한 답을 생각해 오게 한다.

인터뷰를 효율적으로 하려고 인터뷰 대상자를 몇 명 씩 모아서 그룹 인터뷰를 진행하면 의견을 적극적으로 말하는 사람 중심으로 흘러가기 때문에, 1회 인터뷰 시  인터뷰 대상자는 가능하다면 1명으로 제한하는 게 좋다. 1회 인터뷰에 1명으로 제한한다면 하루에 진행할 수 있는 인터뷰는 2번 정도다. 한 번에 2시간 정도 필요하다면 인터뷰를 마친 후 정리할 시간을 포함하면 하루에 2번이 적당하다. 내 경우 최대 4번까지 한 적이 있는데 정말 힘들고 집중도 되지 않는다.

인터뷰가 끝나고 나면 인터뷰 내용을 정리해서 인터뷰 결과서를 작성해서 인터뷰 대상자에게 기록한 내용과 본인이 말한 것이 일치하는지 확인한다. 인터뷰 결과서를 토대로 현재 시스템의 문제점을 파악하거나 고객의 요구사항을 도출하는 작업을 시작한다.

앞서 소개한 인터뷰 방법을 사용해 인터뷰 대상자 10명을 상대로 인터뷰한 프로젝트가 있었다. 인터뷰 준비하는 데 1주일, 인터뷰하는 데 1주일, 그 결과를 정리하는 데 1주일. 프로젝트 기간 중 한 달을 거의 인터뷰에 쏟아 부었다. 이해당사자가 많은 프로젝트여서 명확한 요구사항을 도출하는 게 중요하다고 생각했기 때문에, 과도하지만 인터뷰에 집중했다.

이런 인터뷰를 통해서 고객의 공통된 요구사항이 도출되었다. 자신들의 업무를 절차에 맞추서 수행했으면 좋겠다는 의견이 절대 다수였다. 일을 하는 데 체계성이 없이 상관이나 고객부서에서 급하다고 하는 일 중심으로 처리하다 보니까 문제가 많다는 의견이었다. 프로젝트 팀은 이런 인터뷰 결과를 토대로 업무를 절차대로 수행할 수 있는 시스템을 설계하고 개발하였다.

고객의 요구사항대로 시스템을 만들어서 오픈했다. 그런데 막상 오픈하고 나서 절차성이 중요하다고 말한 사용자들이 시스템을 쓰면서 보인 반응은, 시스템이 너무 절차적이라는 평가였다. 사용자들의 기대대로 만들었음에도 그다지 평가가 좋지 않자 프로젝트 팀원들은 많이 당황했다. 우여곡절 끝에 프로젝트는 마무리 되었지만 시스템이 너무 절차적이어서 현실을 반영하지 못하고 있다는 불평을 계속 들었다.

사용자 삽입 이미지

Source : http://www.flickr.com/photos/gabenl/2617316249/

관찰이 대상의 행동을 바꾼다는 말이 있다. 사람들의 속마음과 겉으로 표현되는 게 다르기 마련인데, 타인의 시선을 의식해야 하는 인터뷰 자리에서 질문을 받으면 솔직한 심정보다 좋아 보이는 모범 답안을 말하는 경향이 많다. 프로젝트 경력이 조금씩 쌓이면서 고객의 요구사항을 파악하려고 하는 인터뷰에 대해서 상당히 회의적으로 변했다. 그래서 되도록이면 인터뷰가 아닌 다른 방법으로 고객의 요구사항을 파악하려고 한다.

하지만 어쩔 수 없이 인터뷰를 하는 경우도 있다. 프로젝트 외부에서 일종의 형식성을 원할 때다. 즉 프로젝트를 시작하고 나서 이해당사자들의 참여를 독려하거나 관심을 얻기 위할 때다. 난 요구사항을 도출하려는 수단으로서 인터뷰에 회의적일 뿐, 프로젝트의 내외부 환경이나 이해당사자들의 개략적인 역학관계를 파악하는 데 인터뷰가 효과적이라고 생각한다.

그렇다면 사용자가 정말로 원하는 것을 파악하기 위해서 어떻게 해야할까? 그때는 사용자의 행동을 보는 게 더 낫다. 예를 들어 기존에 사용하는 소프트웨어가 있다면 해당 소프트웨어를 사용해서 일하는 모습을 관찰하는 것이다. 그런 소프트웨어가 없다만 고객이 실제로 일하거나 생활하는 현장으로 들어가 고객이 어떤 식으로 행동하는지 관찰하는 게 낫다. 흔히 말하는 민족지학, 새도우잉(shadowing), 맥락을 고려한 인터뷰(Contextual Interview)를 하는 게 좋다.

사용자를 파악할 때 인터뷰 방식이 적합하지 않는 것은 앞서 말했듯이 사용자의 말에 의존한다는 것과 실제 사용자가 일하는 맥락(context)을 분리한 인터뷰 장소에서 진행한다는 것이다. 이에 반해 맥락을 고려한 인터뷰는 사용자의 행동을 사용자가 일하는 맥락에서 관찰하므로써, 말에 의지하는 인터뷰의 한계를 극복한다.

물론 사용자의 행동을 잘 관찰 기록하는 것만으로 좋은 소프트웨어를 만들지 못한다. 우리가 관찰한 것에서 사용자를 만족시키는 소프트웨어를 만드는 것은 별개의 이야기다. 다만 훌륭한 소프트웨어를 만드는 과정에서 말에 의지하는 인터뷰보다 행동을 관찰하는 방법이, 우리에게 더 좋은 소프트웨어를 만들 가능성을 준다.

글 : 신승환
출처 : http://www.talk-with-hani.com/archives/1418

About Author

/ root@talk-with-hani.com

신승환은 소프트웨어 개발, 프로젝트 관리, 프로세스 컨설팅 등의 업무를 십 년간 수행했으며, 현재는 차량용 임베디드 소프트웨어를 만들고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 지은 책으로는 '시지프스를 다시 생각하다',‘겸손한 개발자가 만든 거만한 소프트웨어’와 ‘도와주세요! 팀장이 됐어요’가 있으며, 다수의 IT서적을 번역하였다.

MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet