프로젝트를 진행할 때 검토받는 것보다 힘든 것은 없다. 대부분 기업에서 이루어지는 검토는 ‘발전적인 검토’보다는 CEO에게 월급을 받고 일하고 있다는 것을 보여주기 위한 중간관리자들의 ‘한마디 툭 던지기’가 대부분이다. 프로젝트가 어떤 것인지도, 결과가 어떻게 되더라도 그들은 관심이 없다. ‘잘되면 내 탓, 안되면 네 탓’이다.
중간관리자들의 검토하는 태도에 대해 미국의 발명가이자 과학자인 찰스 케더링(Charles Franklin Kettering : 1876~1958) 다음과 같이 말했다.
사람들은 새로운 무언가가 나타나면 좋은 것보다 나쁜 것을 찾는데 관심을 집중한다. 새로운 아이디어를 평가위원회에 제출하면 이런 사실이 금방 입증된다. 그렇게 해서 새로운 무언가를 발견하면 그들은 그 10%의 단점을 위해 나머지 90%의 장점을 무시해 버린다. 새로운 아이디어의 잠재 가능성을 이해하지 못하는 것이다. 왜냐하면 그 가능성을 내다볼 수 있는 사람은 1천 명 가운데 1명도 안 되기 때문이다.
스티브 잡스(Steve Jobs)도 기업에서 너무 많은 중간관리자로 인한 부작용에 대해 1985년 2월 Playboy지 인터뷰에서 이렇게 말했다.
회사를 운영하는 사람들과 그 안에서 실무를 처리하는 사람들 사이에 너무나 많은 중간관리자가 있습니다. 열정적이고 창의적인 사람이 자기가 옳다고 생각하는 일을 하기 위해 5단계의 경영층을 설득해야 하는 상황에 놓인 것입니다.
미국이나 우리나, 회사에서 벌어지는 상황은 똑같다. 이렇게 불합리하다고 생각되는 일이 일어나는 이유는 ‘회사’라는 조직이 가지는 본질적인 속성 중 하나일 것이다. 그럼 디자이너가 일하는 회사는 어떻게 검토할까?
디자이너도 남에게 검토받는 것을 싫어한다. 며칠 밤을 새우고 찾아낸 아이디어를 남이 검토하는 것은 마치 내 알몸을 보여주는 기분이 들기도 한다. 하지만 혼자 하는 작업이 아닌 이상 디자이너도 동료나 상사에게 검토를 받아야 한다. 하지만 디자인 회사에서 이루어지는 검토는 일반 회사보다 생산적인 검토가 이루어지는 몇 가지 다른 요인이 있다.
디자이너는 텍스트로 가득한 문서가 아니고 스케치나 다이어그램, 스터디 모형 등을 가지고 검토한다. 검토할 내용이 한눈에 보이기 때문에 검토하는 도중에 옆길로 빠질 염려가 없다. 스케치에 스케치를 더하거나, 모형의 위치와 크기를 바꾸는 행동을 통해 결론을 내린다.
초기 개념을 잡을 때, 디자인 발전 단계, 최종안 확정단계 그리고 고객에게 제출하기 전 최종 디테일을 확인하는 단계 등 단계별로 검토가 이루어지기 때문에 디자인은 점점 발전된다. 때론 디자인이 70~80% 진행되었는데 디자인 개념이 바뀌는 일이 발생한다. 제일 어려운 순간이다. 하지만 디자이너는 바뀐 개념이 더 적절하다면 새로 시작하는 것을 두려워하지 않는다. 그동안 작업한 도면, 모형들이 모두 쓰레기통으로 버려지더라도 바뀐 개념의 최종 결과물이 더욱 좋다는 것을 확신하기 때문이다. 디자이너는 디자인 교육과 실무 경험을 통해 이미 지불한 비용이 아까워서 다른 합리적인 선택에 제약을 받는 ‘매몰 비용의 오류(sunk cost fallacy)’에 빠질 확률이 낮다.
‘매몰 비용의 오류’는 우리 주변에서 많이 볼 수 있다. 영국과 프랑스가 추진한 ‘콩코드 여객기’ 프로젝트는 처음부터 초음속 여객기의 사업성이 높지 않다는 것을 알고 있었으나 오로지 국가의 체면을 유지하기 위해 지속하다가 2003년 비행을 마지막으로 역사 속으로 사라졌다. “돌아가기에는 너무 멀리 와버렸다”라든가 “나는 이 프로젝트에 1년이나 매달렸다”라고 말할 때는 이미 매몰 비용의 오류가 한구석에서 뱀처럼 똬리를 틀기 시작한 것이다.
내가 대학 졸업할 당시(1980년대 후반), 건축과에서 디자인을 전공한 학생들은 졸업 논문 대신 설계 작품으로 평가를 받았다. 졸업 작품 전시회가 이틀밖에 남지 않았는데 지도교수님이 늦은 밤에 오셔서 전시할 작품 패널에 수정할 곳을 빨간 유성 사인펜으로 점검하셨다. 그 때는 모든 도면 작업이 수작업으로 이루어 졌기 때문에, 요즘처럼 컴퓨터로 수정한 후 프린터로 출력하면 되는 상황이 아니었다. 10시간 동안 그린 도면위에 교수님은 낙서를 하고 가신다. 우린 눈물을 머금고 다시 그렸다. 신기하게 2시간 만에 다시 그렸다. 전시 날짜를 맞추기 위해 집중과 몰입을 했겠지만, 그동안 작업 과정을 머리와 손이 기억하고 있어 작업이 빨리 이루어진 것이다. 이처럼 디자이너는 그동안 작업이 물거품이 되더라도 다시 시작하는데 주저함이 별로 없다. 새로운 아이디어가 기존 것보다 좋다면 기꺼이 처음부터 다시 시작하는 훈련을 학교와 직장에서 배운다.
프로젝트 책임자가 다른 사람들에게 검토를 받는 것은 짜증 나고 힘든 일이다. 하지만 프로젝트의 성공 확률을 높이려면 ‘생산적인 검토’는 꼭 해야 한다. 이런 검토라면 몇 번이라도 받아야 한다. 하나의 프로젝트에 너무 집중하다 보면 주변 상황에 대한 인식이 떨어져 놓치는 것이 많기 때문이다.
일반 기업에서 기획이나 제안 프로젝트의 검토가 생산적으로 되려면 다음 세 가지를 꼭 지켜야 한다.
프로젝트의 검토자는 시작 단계부터 적임자를 선정해야 한다. 적임자 선정은 단순히 직급이 높거나, 학력이 높은 사람을 선정하면 검토가 제대로 이루어지지 않는다. 프로젝트의 특성에 따라 그 분야의 경험과 코칭 역량 그리고 조력자 역할을 할 수 있는 사람을 선정해야 한다. 검토자 지정이 되면 프로젝트의 정보, 진행 상황을 지속해서 메일 등을 통해 커뮤니케이션함으로써 검토자에게 프로젝트 소속감을 주어야한다. 아무런 사전 연락과 정보 제공도 없이 검토회의를 소집하는 것은 전형적인 관료주의다. 그건 검토를 통해 더 좋아지는 아이디어와 개선점을 찾는 것이 아니라 하나의 요식행위에 불과하다.
기업의 관리자는 프로젝트 전략 수립단계에는 ‘한 번 해봐’라고 하다가 눈에 보이는 결과물이 나오면 ‘이건 저거고, 저건 이거다’라고 간섭하기 시작한다. 전략에 대한 단 한 번의 고민도 해보지 않은 사람이 나온 결과물만을 가지고 전략을 뒤집으려 한다. 이런 현상을 방지하기 위해선 검토는 단계별로 이루어져야 한다. 크게 전략수립단계, 세부 콘텐츠 80% 완성단계, 그리고 최종 제출단계 등으로 구분하여 이루어져야 한다. 전략수립단계에서 검토는 기획이나 제안의 방향과 이길 수 있는 전략인지를 검토한다. 세부 콘텐츠 검토 단계에서는 방향과 전략이 콘텐츠에 잘 녹아 들어가 있는지를 검토한다. 최종 제출 전에는 고객의 요구한 작성지침에 적합한지와 최종 오타 등을 검토한다.
외국 수주기업의 경우 이런 단계별 검토 팀을 색깔별로 구분하여 활용한다. ‘블루 팀(blue team)’은 전략과 제안 솔루션을 검토하고, ‘핑크 팀(pink team)’은 제안 콘텐츠의 스토리보드나 목업(mock-up)을 중점 검토한다. ‘그린 팀(green team)’은 이길 수 있는 가격 전략을 검토하고, ‘레드 팀(red team)’은 최종 결과물을 검토해 스스로 점수를 매기는 역할을 한다.
검토자의 단계별 검토 결과는 문서로 프로젝트 책임자에게 전달되어야 한다. 종종 검토한다고 10명이 넘는 사람들이 모여 3~4시간씩 회의를 하는 경우가 있다. 경영진에게 열심히 하고 있다는 모습을 보여주기 좋아하는 임원이 선호하는 방식이다. 이런 회의는 아무런 소득도 없이 참여하는 직원의 시간만 소비하고 끝난다. 프로젝트 실무자는 회의 준비하느라 시간 소비하고, 팀장은 자기 목소리만 내는 임원 눈치 보기 급급하다. 전형적인 관료주의며, 대기업 병이라 할 수 있다.
단계별로 지정된 검토자가 자료를 검토하여 그 결과를 문서로 전달하면, 프로젝트 책임자는 검토 내용을 확인하고 꼭 필요한 경우에만 회의를 소집하면 된다. 생색내는 회의에서는 필요 없는 말들을 쏟아 내지만, 문서로 결과를 보내는 경우 검토자는 더욱 신중해진다. 검토 결과가 문서로 남기 때문이다. 그리고 검토 내용에 대한 반영 여부는 프로젝트 책임자에게 주어져야 한다. 최종 프로젝트에 대한 책임은 검토자가 아닌 프로젝트 책임자에게 있기 때문이다.
검토 과정은 실무자에게는 힘들지만, 경쟁에서 이기기 위해서는 꼭 필요한 과정이다. 실무자가 힘들어하는 것은 아무런 소득 없이 시간만 낭비하는 검토다. 생산적인 검토라면 누구라도 반긴다. 기업 관리자는 검토하는 회의가 ‘논쟁하는 회의’, ‘자신의 직급을 보여주기 위한 회의’, ‘자기주장만 하는 사람들로 가득한 회의’가 되지 않도록 검토 프로세스를 운영하는 것이 필요하다.