가상 클라이언트와의 미팅 진행하기
신입 기획자와 디자이너들을 훈련시키는 실험적인 방법
신입교육 직원 훈련을 위해 진행한 가상 클라이언트와의 미팅을 진행해봤다. 개개인이 한 서비스를 만들기 위한 클라이언트 역할을 하고, 다른 사람이 미팅에 입찰한 파트너 역할을 하는 방식이다. 신입 입장에서 클라이언트와 파트너 입장이 되는 건 쉽지 않은 일이지만, 중간에서 '진행자' 역할을 해주며 가상 미팅을 진행해보았다.
1. 클라이언트 : 나는 이런 서비스를 만들고싶어요
클라이언트 역할을 맡은 사람은, 임의로 만들어진 상황극처럼 자신이 원하는 서비스의 구성을 이야기한다. 어떤 서비스 분야에, 어떤 플랫폼의 서비스를 만들고 싶은지. 그리고 어떤 기술들이 들어가는지를 대략적으로 설명한다. 이후 파트너 역할은 이 서비스를 실제로 만들어내기 위해, 어떤 기술이 필요한지. 제약사항은 어떻게 되는지 등을 하나씩 물어보게된다. 서로가 무엇을 만들고 싶어하는지를 잘 알지 못하기 때문에, 초반에는 어색한 탐색전이 이어지게된다. 하지만 시간이 지나면서 서로 '어떤 것을 물어봐야하는지'를 깨닫게된다.
체크포인트
- 해당 서비스는 어떤 목적을 갖고있나요?
- 주요 사용자는 어떤 특징을 갖고있나요?
- 유사한 서비스로는 어떤 서비스가 있나요?
- 외부에서 가져와야하는 정보나, API가 있나요?
- 꼭 사용해야하는 디바이스 기능이 있나요?
2. 파트너 : 그 서비스는 이런 방식으로 만들 수 있을것 같아요
파트너 역할을 맡은 사람은 클라이언트의 대답을 듣고 여러 정보를 정리하게된다. 그리고 실제 서비스를 만들기 위해 어떤 정보들이 필요한지. 또 어떤 정보들을 더 확인해야하는지를 물어보게 된다. 만약 파트너 역할의 인원이 이 부분을 잘 캐치하지 못할 경우, 진행자가 부족한 지점들을 물어봐준다. 이때, 클라이언트는 자신의 상황에 맞게 고유한 설정이나, 기준점을 이야기해주게 된다. 이 기준점을 바탕으로 '얼마나 많은 정보'를 끌어낼 수 있는지가 파트너의 정보분석 능력을 판가름하게 된다.
체크포인트
- 파트너가 서비스를 만들기 위해 필수적인 정보나, 기술을 확인했는가?
- 파트너가 클라이언트의 이야기에서 빠져있는 지점들을 캐치하여 꼼꼼하게 파악했는가?
- 파트너가 서비스에 대한 충분한 이해도를 바탕으로, 효과적인 질문을 던졌는가?
- 파트너가 클라이언트로에게 실제 서비스 구현을 위한 중요한 지점을 충분히 설명해주었는가?
3. 클라이언트와 파트너의 커뮤니케이션에 대한 피드백
클라이언트 역할과 파트너 역할을 맡은 인원들이 각자 어떤 기술에 대해 이야기했는지. 서로 커뮤니케이션 과정에서 오해나, 답답함은 없었는지. 상대가 물어본 내용이나, 설명해준 내용을 통해 상대에게 충분히 신뢰를 줄 수 있었는지. 이러한 내용들을 각자 서로에게 피드백을 해주도록 유도한다. 클라이언트 역할에게는 파트너 역할을 한 사람에 대해서 물어보고, 파트너는 반대로 클라이언트가 어떤 사람이었는지. 다시 한 번 정리하도록 시간을 준다. 대부분 첫 시도에서는 서로 어색해하는 경우가 있긴 하지만, 자신이 '해당 서비스를 만들기 위해' 무엇을 모르는지에 대해 파악하게 된다.
체크포인트
- 클라이언트와 파트너에게 각자의 역할이 어떤 모습 / 느낌이었는지 이야기해보기
- 클라이언트는 파트너가 신뢰할만한 사람이었는지 / 그 이유는 무엇인지 이야기해보기
- 파트너는 클라이언트가 충분한 이해도를 갖고있었는지 / 그렇지 않다면 무엇이 부족했는지 이야기해보기.
- 진행자는 클라이언트와 파트너 역할을 한 인원들이 어떤 지점에서 실수를 했는지 이야기해주기.
실제 진행한 후기
- 클라이언트 입장에서 바라보니, 파트너가 기술에 대한 이해도가 떨어질 경우, 너무 답답하게 느껴졌다. 또한 반대로 파트너 입장이 되어보니, 클라이언트 입장에서 파트너가 무엇을 준비해야할지. 어떤 방식으로 이야기해야 설득력을 가질 수 있을지 알 수 있을것 같았다.
- 파트너 입장에서 클라이언트가 만들려는 서비스를 '어떻게 알아내야하는지, 어떤 부분까지 질문해도 될지 알기가 어려웠다. 그래서 계속 질문을 던지니, 클라이언트 입장에서는 전문가가 아니라, 마치 챙겨줘야하는 사람처럼 느껴졌다. 이런 경우 파트너에 대한 신뢰도가 생겨나지 않았다. 그래서 서비스 견적이나 개발언어 같은 자세한 정보까지 이야기를 할 수가 없었다.
- 미리 주제가 정해져있고, 여기에 대해 조사할 수 있는 시간이 있었다면 더 좋았을 것 같다. 즉석에서 상대가 원하는 내용이 무엇인지를 확인해야하다보니, 내가 아는 상식 레벨에서 밖에 답변을 할 수 없었다. (물론 이 지점이 중요하다는 것은 알 것 같다.) 다만 충분히 조사를 하고 클라이언트와 대화를 한다면, 더 나은 결과를 낼 수 있을 것 같다.
- 진행자 입장에서 상대가 어떤 지점을 실수했는지. 중간중간 이야기를 해주다보니 대화의 맥락이 끊기는 경우가 생겼다. 하지만 이야기를 해주지 않을 경우 이야기가 갈피를 잡을 수 없는 상태로 진행되는 경우도 생겼다. 그래서 이야기의 단계를 정해두고, 각자 그 다음단계의 이야기로 나아갈 수 있는지. 그렇지 않다면 어떤 단계에서 진행이 멈추게되는지를 체크한다면 더 좋을것 같다.
오늘은 일단 초기의 놀이 형태로 즉흥적인 클라이언트 / 파트너 역할놀이를 진행해봤다. 나중에는 본인이 공부한 내용을 바탕으로 상대방에게 클라이언트 역할을 해주는 - 대리체험을 시켜주는 방식도 상당히 괜찮은 방식일듯 하다. 이 부분에 대해서는 추후 실험을 해본 이후에 다시 내용을 남겨보겠다.
