*해결책 - 10/10/10 텐텐텐 - 작업상황의 초반 구조세우기 10%,
- 작업 초반상황 10%에서 팀 전체와 같이 공유하며 workscope와 내용을 조율한다. 절대 50% 80% 까지 달리고 나서 다시 처음부터 ~~~ 이런 사태를 막자.
- 후반마무리 10%를 고려하여 일정을 잡는다.
Project R&R 정의
Do : 프로젝트 시 각자의 역활에 대해서 정의한다. 정의해야 할 역활은 다음과 같다.
- 클라이언트 컨택 - 이메일, 전화
- 스케쥴링 - 전체 일정
- 보고서
- 회의록
- 외부로 나갈 문서 점검 - 내용, 맞춤법, 일정
- 서버&인트라넷 - 구글 스케쥴, 버전 관리, 중간 과정 archive
- 소비자 컨택
Don't :
Better Kick off
Do : 프로젝트 시작 전에 미리 kick off를 해서 우리 내부적으로 문제에 대해서 생각해 보고, 오히려 kick off 시간에 질문을 통해 문제를 파악한다.
1) 킥오프 사전 질문은 미리 클라이언트에게 전달한다.
2) 킥오프 시 미리 준비한 질문을 자료 형태로 보고 함께 토론한다.
3) 킥오프에서 나온 question 들은 모두 나열하고, 그것을 A4 한 장씩 적어둔다.
Don't :
Scheduling
Do :
Don't :
Project 단계
Recruiting 단계
Do :
1) 보통 8~10명 내외의 인원을 리쿠르팅 하는데, 각각 어떤 이들을 리쿠르팅 할 지 미리 퍼소나 형태로 세팅해 둔다. 즉 가장 두드러진 특성을 뽑아서 뽑는 기준을 마련해 둔다.
2) 아는 인맥부터 배치한다. 오히려 context 상 더 많은 내용을 파악 할 수 있기 때문에 지인이 더 효과적이다.
3) 리쿠르팅 스케쥴 배치 시 초반에 말을 잘 하는 똘똘이들을 배치한다. 클라이언트가 안심한다. 우리가 인터뷰 하는 데 감 잡기가 편하다.
4) 리쿠르팅 이후에 리쿠르팅에 대해서 이슈를 삼지 못하도록 해야 한다. 질적 연구 방법에 익숙하지 않은 클라이언트는 항상 리쿠르팅이 잘못 되었다는 지적을 한다.
- Request : 현대 자동차 - 40대 남자가 소렌토 타다가 하얀색 비틀을 하비라는 별명을 붙이고, 아침마다 이름을 부른다는 데, 이 게 정상적인 대한민국 40대 남자는 아닌 것 같아요. 리쿠르팅 다시 해 주시지요.
- Answer: 별명을 붙이고, 이름을 부른다는 행위는 특수합니다. 특이한 사람들은 단지 일반인도 가지고 있는 니즈를 명확하게 실천하고 있을 뿐이라는 것. 차에 이름을 붙이는 것은 흔한 일은 아님. 그러나 차를 하나의 소통가능한 인격체로 인식하고 애착을 지니는 것은 표현에 있어 정도의 차이이지 보편적인 니즈였음을 보여줌. 이를 통해 얻은 아이디어는 일반적인 소비자들도 애착을 형성하면 차에 대한 만족도가 올라간다는 사실이었다. 따라서, 너무 염려하지 마세요.
- Request : 디아지오 - 우리가 보려는 트렌드 세터가 아니에요. 다시 리쿠르팅 해 주세요.
- Answer : 무엇에 관한 트렌드 세터인가. 패션, 술 어떤 것을 기준으로 하느냐에 따라 달라진다. 일단 다른 인터뷰도 지켜보자. ~~~ 술먹는 것을 리딩하는 측면에서 트렌드 세터라면, 그러한 성향을 보인 사람들이 있으니 트렌드 세터가 없다고 할 수 없다. 그러한 성향을 가진 사람들을 내용을 분석에 포함시키겠다.
Don't : 인터뷰가 주 discover 방법인 현재 상황에서는 interviewee의 communication 능력이 중요하다. 따라서, communication 능력이 떨어지면 아무리 좋은 조건의 리쿠르팅이라도 포기하라.
Interview & Observation & Activity 단계
Do : 다음의 세 명은 반드시 필요함. 우선 순위는 다음과 같음.
1) 주진행 : 주 진행.
2) note taker : post it. 주요 멘트. 한 장에 하나씩 노란색 포스트 잇에. 인사이트는 분홍색에 쓰기. 2시간 동안 70~80여개의 포스트잇이 생성됨.
3) 보조진행 : 녹화, 녹음 체크. 밖에서 온 메시지 카톡 확인. 간식 및 음료 확인. 액티비티 준비물 챙기기. 주진행이 놓친 부분 질문.
Don't : 단 한명의 멤버도 빠지지 마라. 프로젝트 멤버들은 최소한 크리베이트에서 진행 되는 인터뷰 인 경우에는 (외부에서 진행하기 때문에 참여가 어려운 경우를 제외하고는) 꼭 다 들어라. 멤버 간 경험에 차이가 생기면 같은 수준의 토론이 진행되기 어렵다.
Debriefing 단계
Do : 인터뷰가 끝나면 반드시 한다.
1) 프로세스적인 것 - 유효한 질문, 무의미한 질문,
2) 인사이트 - 말이나 행동으로 부터 얻은 인사이트, conflict 지점
3) 재미있는 포인트들. 알게된 finding
Tip
1) 디브리핑을 쉽게 하지 위해서 미리 Insight frame을 만들어 두면 효과적이다.
2) 클라이언트가 참여하는 경우, 제대로 된 디브리핑이 안 될 수 있다. 이 때에는 클라이언트 참여 이후에라도 반드시 해야 한다.
3) 휴일이거나 너무 늦은 시간에 디브리핑을 빠뜨릴 수 있다. 아무리 늦어도 단 15분간이라도 디브리핑은 해야 한다.
Don't : 말로만 하지 않는다. 반드시 서기를 둔다. 가급적이면 인트라넷(손으로 쓴 것이 아니라 digital화) 에 정리해 두는 것이 가장 좋다. 말로만 하다 보면 잡담처럼 흐를 수 있는 경향이 있다.
분석 단계
Do : 모든 인터뷰가 끝나고 시작하는 것이 좋다.
1) 커멘트--> explicit needs --> latent needs --> Design Principle (~해라. 왜냐면, 예를 들면 - 3단 구조로 정리하기)
2) Frame --> insight --> Design Principle
3) Kick off Question --> Answer --> Design Principle
대략 Design Principle이 10개~20개 정도 나온다.
Analyze Hierarchy
Design Principle : 행동 지침. 방향성. Direction. ~ 해라.
Insight : 인사이트란 Design Principle의 근거이다. 왜냐하면 ~~~, insight가 아닌 것 : Direction으로 연결 될 수 없다면 insight가 아니다.
Comment & Behavior : 인사이트의 근거이다. 예를 들면 ~~~,
Don't : 시간이 없다고 빼먹고 가면, 다시 처음부터 과정을 거쳐야 한다.
보고서 Storyboard 단계
Do :
Don't :
Workshop 단계
Do :
Don't :
Prototype 단계
Do :
Don't :
Story Scenario 단계
Do :
Don't :
Project Review
Do : 프로젝트 완료(final 보고서가 나간)된 시점에서 프로젝트를 다시 돌아보고, 반성한다.
1) 각자 프로젝트 점수를 매긴다. 1점~10점중에 X점. 그리고 그 점수를 준 것에 대해서 설명한다.
2) 프로젝트 성공과 실패에 대해서 재정의한다. 이전에 논의했었던 것들이 얼마나 달성되었는지도 체크해 본다.
3) 실질적인 output에 대해서 정의할 수 있어야 한다. 무엇이 문제였고, 그 답이 무엇인지. 어떠한 과정을 거쳐서 그 답을 찾았는지.
4) 시간을 되돌린다면, 바뀌었을 것에 대해서 논의한다. 그 문제는 왜 이번에 이런 방식으로 생겼났는지 flashback해 본다. 무엇이 원인이었을지 유추해 본다. 그리고, 그것이 원인이었다면, ~하지 않겠다는 lesson으로 삼는다.
Don't :
클라이언트 피드백 참여를 어떻게 유도?
Project Lesson
Do : 프로젝트의 lesson을 정의한다. lesson이란, 다음 번에 "이것 만은 ~하지 않겠다 혹은 ~~하겠다"라고 하는 것으로 정의한다.
1) 프로젝트 Review 후에 Lesson은 따로 적는다. 이처럼 하는 이유는 그만큼 중요하기 때문이다.
Don't : OO 해서 좋았다. OO해서 나빴다는 lesson이 아니다. Don't를 정의할 수 있어야 lesson이다.
Project Finishing
Do : 일주일 이내 정리한다.
1) 인트라넷을 정리한다.
2) 서버에 파일을 정리한다.
3) 프린트물이나 종이 output을 정리한다.
4) Homepage 프로젝트 리뷰에 올린다.
Don't :
