이다희 - 최종 갑이 누구인지 처음부터 생각하자.
처음에는 이민구 상무가 모든 것을 리드하는 것 처럼 보였으나, 마지막으로 갈 수록 Tony가 단순한 전달자가 아닌 이번 프로젝트의 성패를 결정하는 인물이 되었다. 여러 stakeholder의 니즈가 섞여 있을 때, 누구에게 장단을 맞출 것인지를 처음부터 좀 더 active하게 파악하는 것이 필요하다. 이민구 상무와 Tony의 관계를 예측하지 못한 것이 마지막까지 힘들었던 것. - 우리가 무엇을 제일 잘 하는지, 그것을 어떻게 하면 가장 잘 전달할지 알아야 한다.
결국 이 프로젝트에서 매우 중요해져 버린 것이 아이디어보다는 그것을 전달하는 비주얼이 아니었을까 한다. 특히 미래적인 이야기를 할 경우, 보통 decision making을 하게 되는 아저씨들은 내 머리속에서 상상하는 아름다운, 그러나 실현 가능한 장면들을 매우 왜곡하여 이해한다. 그래서 디자이너님들께서 멋지게 그림을 그려주셔야만 아아 저런 이야기였구나 라고 한 50% 이해하는 듯 했다. 마지막에 그들은 원하는 수준의 3D 랜더링 돌린 비주얼을 보여주며 이렇게 안 되겠냐고 했는데, 우리는 일단 그런 작업을 하는 사람도 없을 뿐더러 시간도 너무나 촉박한 상황. 여기서 어떻게 하면 더 잘 전달할 수 있을까 고민하다가 거의 한 줄 한줄 수준의 컨셉 스토리 페이지들과 하나로 쭉 연결되는 유저 시나리오를 보여주겠다고 했는데 (마지막에 컨셉 쪽은 그냥 캔슬 되었지만) 우리가 할 수 있는 수준과 주어진 상황에서 가장 잘 선택한 거 같다. - Anger Management System필요하다.
이 상무는 우리를 여러번 열받게 했는데, 마지막에 'feasibility 고려하지 말고 무조건 아이언맨같은 아이디어 내 달라' 라고 할 때는 정말 손이 떨릴 지경..우리가 그 사람의 책임감과 전반적인 위치를 좀 overestimate한 것 같기는 하나, 이렇게 Tony의 말 한마디에 휘둘리고 우리에게 미안한데 어쩔 수 없다 라는 이야기를 할 때는 참기 굉장히 힘들었음. 살다보면 열받게 하는 상황 및 사람들이 계속 많아질텐데 이런거 하나 가지고 (사실 십오분 생각하면 아이디어 낼 수 있는데도) 그렇게 열이 뻗치니 아 더 큰사람이 되어야겠다는 생각을 했다. 그순간 아 우리가 줄 수 있는게 뭐고 그 대신 너네가 sacrifice해야되는게 뭔지 머리를 굴려서 generalized report 는 로고만 빼서 주겠다는 둥 give and take를 정하는데, 이럴때 감정을 조절하며 세련되게 커뮤니케이션할 수 있는 skill을 키워야될것 같다.
김형우- Stakeholder interview
우리가 Tony와 직접 통화해서 이야기를 할 수는 없었을까? 을이 갑인줄 알고 대하다가, 갑에 휘둘리는 을에 휘둘리는 건 정신 건강에 좋지 않았다.
- Image가 중요.
아저씨들에게 아이디어를 전달할 때, 그 아이디어가 혁신적이면 혁신적일 수록, 이미지 없이 전달하는 리스크는 커진다.
정승구 - 내부 킥오프는 꼭 해야 한다
짧은 프로젝트고 바쁘게 시작했기 때문에 내부 킥오프를 생략했다. 내부 킥오프는 멤버의 Role 정하기, 각자의 동기부여 확인, 회사가 기대하는 러닝포인트, 내부 프로세스와 방법론 기획, 성공/실패의 정의 등 중요한 질문을 하는 시간이다. 일종의 Brain sync 역할을 한다. 새로운 멤버들(정은, 지영)도 있었기 때문에 초반에 절차를 잘 밟는 것이 모두의 능력을 끌어내는 데에도 좋았을 것 같다. 만약 내부 킥오프를 했다면 이런 것들을 정했을 것이다. - 각 Phase별 리더가 있다면 어땠을까? (확신은 없음)
조직 구성: PM / 기획 / 디자인
Process: Ideation > Concept > Design
문제는 PM이 모든 것의 중심이 되어, 기획과 디자인이 커뮤니케이션이 부족했음. Phase 넘어갈 때마다 덜컹 덜컹 거림.
-> solution: phase마다 Leader를 정한다. Leader는 자기 phase의 결과물을 다음 Leader에게 확실히 전달하고, 확인한다
박성연 - 아이디어는 Fee는 개수로 count 되어야 한다.
프로젝트 기간도 기간이었지만, 왜 이 프로젝트가 이렇게 힘들었을까? 하는 생각을 해 보니, LG프로젝트와 비교했을 때 가장 큰 차이는 초기 견적 때 SDS의 요청에 따라 산출물이 아닌 인건비 방식으로 fee가 계산되었고, , 이에 따라 무한 아이디어 요청을 거부할 수 없었다. 기간 내에 요청하는 것이니 그들을 정당하다는 태도였다. 따라서, 아이디어는 개수에 따라 Fee를 count하는 방식을 크리베이트 표준으로 하고, 요청이 왔을 때조차 단호하게 대처해야 한다는 사실을 다시 한 번 깨닫는다. 순간의 선택이 십년을 좌우한다. - 초반 교통 정리가 중요하다.
SDSA, SDSK 계약의 주체가 둘 이상인 경우 반드시 어떤 문제라도 생긴다. 반드시다. 이 때 각각의 롤 조정. 가령, 이 번의 경우 SDSA가 돈 내니, 요구사항은 SDSA를 맞춘다. 창구를 단일화한다는 것을 확인하고 SDSK의 역활은 무엇인가? 등등을 확실히 짚고 넘어가야 했어야 했다. 그렇지 않으면, 계약관련 사항은 SDSk와 이야기 하고 프로젝트는 SDSA와 이야기하는 와중에 결국 빈틈이 생기고, 이 빈틈을 이용해 말도 안되는 요구를 하는 것에 당할 수 밖에 없다. - 아이덴터티를 명확히 하라. 나는 누구, 어디는 어디?
아이디어, 컨셉 추상화 단계로 넘어갈 수록 각자 그리는 그림이 달라질 수 밖에 없다. 이 때 나의 역활을 나의 아이덴터티를 명확히하라. 본 프로젝트의 경우 나는 의사였나? 그럼 환자가 하자는 대로 끌려가서는 안된다. 어떻게 하면 좋을지 의사가 리드해야 한다. 니가 하는 그 말이 어떤 결과를 초래할지 조목조목 일러줄 수 있어야 한다. 그런데 나도 문제를 원인을 알고 집도하는 건 아니니 의사는 아닌 것 같고, 그럼 선생님였을까? 선생님이라면 학생에게 이건 이렇게 하는 거야 하고 가르쳐 줘야 하는데...우리의 주장이 너무 약했다. 너무 나이스한 태도를 취해야 된다는 생각에 그들에게 선택의 권한을 너무 넘겼다. 그럼, 트레이너인가? 트레이너는 시키는 대로 안한다고 때릴 수 없지만 선생님은 때릴 수 있다. 실제 우리는 트레이너와 비슷한 상황이나 선생님의 Identity를 가져야 우리는 존경받으면서 프로젝트를 해 나갈 수 있지 않을까 싶다. 아이덴터티를 명확히 하지 않을 채, 선택권을 무조껀 그들에게 넘겼을 때 우리는 해달라는 대로 해 주는 손발이 될 수 밖에 없다. 상대가 아무것도 모를 때를 가정하고 어떻게 리드해 가야 할지에 대한 안내서가 필요하다. - 비주얼의 힘을 알았다면, 자산화시키자.
아이디어는 약하다. 아이디어가 힘을 갖기 위해서는 일관된 컨셉으로 끌어올려져 추상과 구체가 결합되어 스토리를 갖는 것과 그것이 실제로 어떻게 구현될지 보는 비주얼. 이들의 결합으로 좀 더 단단해질 수 있다. 아이디어만 도출하는 프로젝트의 경우 이 부분의 중요성이 커진다. 그렇다면 가장 빨리 가장 효과적으로 비주얼을 표현할 수 있는 것이 우리의 무기여야 한다. 이에 대한 구체적인 system이 필요하다. 그 형태가 아이디어 시나리오 DB가 되든, 빠른 손스케치든 무엇이든 우리의 솔루션을 자산화시키는 작업이 필요하다. 또한 우리 내부에서도 아이디어를 이렇게 비주얼화하여 스토리로 기억하는 것을 통화 즉 체화하는 것이 필요하다는 것을 느꼈다. Part I 파트가 없어져서 좀 아쉬웠다. 우리 내부에서 체화한 형태가 프로젝트 때 우러나오는 것이 가장 자연스러운 것 같다. 그럴 때 힘 빼고 자연스럽게 프로젝트를 숨쉬듯 밥먹듯 소화해 낼 수 있으리....
이세미 - 프로젝트 샘플을 다양하게 활용해, 중간 보고물/최종 아웃풋의 퀄리티 수준을 클라이언트, 내부 구성원들과 합의한다.
우리는 최상의 결과를 내기 위해 숨은 노력을 해야하지만, 그들이 요구하는 아웃풋의 수준이 비용과 시간 대비 너무 무리한 요구가 아닌지 점검해 볼 필요가 있다고 생각한다. 이때 퀄리티란 내용은 물론이고, 아웃풋의 형식도 포함한다. 아이콘이 '팬시해서' ,'세련된'것으로 수정해 달라고 요청을 받았던 일이 많았던 이번 프로젝트처럼, 클라이언트는 디테일한 부분을 이야기하지만 다소 애매한 방향성을 제시하며 더 발전 시켜주길 원한다. 추상적인 개념을 실체화 시키다보면, 보이지 않았던 빈틈들이 드러나고, '조금만 더 그럴싸하게 수정해달라는' 요청이 늘어난다.계속 대응하다 보면 처음 요구했었던 퀄리티 이상의 아웃풋을 원하게 되는데, 그 시간을 좀 더 생산적이고 효과적인 곳에 사용할 수 있었으면 하는 아쉬움이 있었다. (아이디어를 더 탄탄하게 만들기 위해 시나리오 컷을 더 구성한다던지 하는 다른 시각화 방법들이 있었을지도... '빨강을 파랑으로 바꾸어주세요'와 같은 요청을 일일히 다 대응해주는 게 맞는 것인지 의문이 들었다.)
그러한 요구란 한도 끝도 없고, 너무 산발적으로 요구되기 마련인데, 좀 더 우리가 리드할 수 있는 전략이 필요하다.
- 비주얼 커뮤니케이션도 컨설팅 서비스(결혼 패키지)에 포함하고, 결과물에 대한 구체적인 플랜이 가능하도록 일정을 짠다.
이번 McD CEO보고의 경우 중간 전달자가 많아, 입에서 입으로 전달될 정보의 양을 최소한으로 줄여주기 위해 프리젠테이션의 시각적 표현이 다른 때 보다 중요했다. 하지만, 다시 생각해보면 우리는 대부분 보고서와 문서로 커뮤니케이션 하고 있다. 한 때는 보고서 템플릿으로 모든 커뮤니케이션 상황을 대응할 수 있을 것이라 생각해 왔다. 그러나 우리는 매번 다른 컨셉을 전달해야하고, 아웃풋의 형식과 형태도 조금씩 다르다.
상황은 이러하지만 정작 슬라이드 한 장 한 장을 구성하는 개념, 글 ,이미지가 효과적으로 구축되기 위한 논의를 보통, Concept과 Visualization을 나누어 동시에 진행한다. 이렇게 되다 보면 말과 이미지가 어긋나버리는 경우가 생긴다.쉽게 이야기해 부산을 내려가는데, 각자 다른 고속도로를 타고 내려가는 격이다. 말과 글이 구축되는 시간보다 이미지는 상대적으로 Undo/Redo가 재빠르게 실행되기 힘들기 때문이기도 하고, 개념과 글이 구축되지 않은 상태에서의 이미지 작업은 사실 껍데기 작업에 불과하다.
프로젝트의 결과물마다 '최상의' 비주얼 커뮤니케이션을 위해 노력할 수 있을런지는 확실하지 않지만, '최상'을 규정하는 조건을 내부적으로 결정해 놓으면 좋을 것 같다. 단순히 '예쁘고, 그럴싸하게' 보이게 하기 위해 막판에 '서비스'로 제공해 주는 개념이 아니라, 이 보고물/결과물의 용도가 정확이 어떤 것인지, 누구에게 쓰일 것인지, 어떻게 쓰일 것인지 등을 킥오프 미팅 때 논의하고 좀 더 현실적인 결과물 제작 일정과 프로세스를 프로젝트 플랜에 반영하는 것이 필요하다.
김지영 - ideation의 level과 범위.. 처음부터 잡을 수 있었다면?
ideation만 해달라고 했지만 알고보니 결과물로 원한것은 아날로그-디지털을 얘기하는 등 컨셉차원의 level이었고, 처음 나온 것 중 상대적으로 규모가 큰 변화인 movable을 선호하는 등 Tony에 의해 방향이 바뀌기 전부터 우리가 아이디어를 낼 수 있는 제한 범위가 달랐던 것 같다. 처음부터 level과 범위를 정확히 협의한 후에 시작할 수 있었다면 더 좋았을 것 같다. 그리고 이 협의에 관해서는 idea consultant인 우리가 먼저 꺼내고 안내하고 주도해야할 것 같다.
- visual화 시킨 후 그것에 대한 수정사항은 한번에 받을 수 없을까.
일단 visual화 시키면 자그마한 수정도 매우 큰 로드가 되는만큼, 한 번 visual시킨 후 수정사항은 한번에 꼼꼼히 보고 한꺼번에 달라고 할 수 없을까 (나중에 추가 수정사항이 생기더라도 visual을 check하는 태도가 달라질 것 같다)
양정은 - 비주얼 커뮤니케이션은 디자이너와 컨설턴트가 함께 하면 어떨까
프로젝트를 진행하다보면 함께 진행하는 부분이 있고 각자 진행하는 부분이 있는데, 디자인은 함께 진행하는 부분인지 디자이너가 진행하는 부분인지 생각해볼 필요가 있을 것 같다. 디자인 툴을 사용해서 진행해야 하는 부분은 당연히 디자이너가 진행해야겠지만, 툴 이외의 부분은 좀 더 긴밀하게 협업하며 진행한다면 좋지 않을까. 처음 디자인에 들어가기 이전 기획단계까지는 좀 더 냉정한 시각으로 디자인작업을 계획하고 진행 할 수 있지만, 일단 비쥬얼 작업을 진행하다보면 객관적인 시각을 잃게 되는 경우가 많다. 그렇기 때문에 디자인업무에도 디자인을 담당하지 않는 다른 팀원이 필요하지 않을까, 하는 생각이 든다. (물론 크리베이트에서 디자이너가 디자인만 하는 역할이 아니지만 비주얼작업을 하다보면 어쩔 수 없이 디자이너가 되어버리는 경우가 많다. 특히나 급한 일정에서는 더더욱 그렇게 되는 것 같다.)
목표와 범위를 알고 시작했다면? 처음 프로젝트를 시작할 때는 ideation만을 하는 것인 줄 알았는데, 프로젝트를 진행하다보니 결과물의 방향은 많이 달라진 것 같다. MCD프로젝트가 특이한 케이스 이긴 하지만 프로젝트의 성격을 좀 더 자세히 알고 시작했다면 중간과정에서 오는 혼란을 조금은 막을 수 있지 않았을까하는 아쉬움이 남는다. idea의 범위부터 디자인의 범위까지. 해야 할 일들의 범위를 알지 못하고 무작정 시작해서 그런지 일을 하면서도 무엇이 맞는지 계속 의문이 들었던 것 같다. 코앞 밖에 볼 수 없던 일정이었지만 이럴 때 일수록 큰 그림을 보는 것이 중요 한 것 같다.
|
