디자이너, 개발자 그리고 그들의 PM - 성공적인 프로젝트를 위하여

흔히 웹프로젝트를 진행할때 디자이너, 개발자(또는 프로그래머) 그리고 그들을 관리하고 대변해주는 PM 이 있습니다. 성공적인 프로젝트를 위해서는 각기 상대 직책에 대해 알 필요가 있습니다.

 

앞으로 이 세계에 뛰어드실 예비 IT인이나혹시 지금 개발자, 디자이너, PM때문에 힘들어하시는분에게 도움이 되었으면 하는 바램에서 키보드를 두드려봅니다.

 

To. Designer

디자이너는 IT직종중에서 가장 창조적인 역할을 하는 직책입니다. 때문에 그만큼 고민을하고 몸의 컨디션이나 마음가짐에 따라서 결과물의 질이 크게 좌우되곤 하죠. 대부분 디자이너분들은 매우 예민합니다. (역설로 들리시겠지만 남자디자이너가 더 예민한경우가 많습니다.) 때문에 그 예민함과 자신이 내놓은 결과물에 흠집을 내는일을 "극도"로 꺼려하지요. 하지만 디자이너는 프로젝트에 동참한 이상 디자이너가 해야할일은 물론 훌륭한 디자인을 창조해내는것도 중요하지만 그외의 임무도 띄고 있습니다.

1. 궂은일도 기꺼이 감수하라.
"를"->"을" 로 바꾸는 일, 1px 차이로 어긋나는 이미지, 모니터마다 다르게 보이는 색상들... 디자이너를 짜증나게 하는 일들입니다. 하지만 이것을 알아두십시요. 자신이 이세상에 나오게한 모든 이미지를 비롯한 아이콘이나 텍스트들은 자신이 끝까지 책임지십시오. 프로젝트에 "사소한 일"은 없습니다. 끝까지 자신이 만들어낸 이미지는 자신의 얼굴이고 자신의 능력입니다. 어떤 훌륭한 디자이너도 붓칠한번에 몇백만원을 벌지 않고 선한번 긋는다고 박수쳐주지 않습니다. 다 사소한 작업들이 쌓이고 쌓여서 훌륭한 결과물을 만들어내느것입니다.

2. HTML을 익혀라.
자신은 디자이너라고 html 안하려는 디자이너분들. 결국 자신의 몸값을 낮추는 결과입니다. 프로그래머가 더 잘안다고 html 안한다고 하시는 분들은 속으로는 "나같이 세련된 디자이너가 html 따위를 만질순 없지" 라는 생각을 한다면 그것은 자만이요 오만한 행동입니다. 조연없이는 영화도 드라마도 찍을수 없습니다. 스스로 조연이 되기를 자청하십시오. 그러면 훗날 빈틈없는 디자이너가 될 수 있습니다.

3. 타인의 의견에 충분히 귀 기울여라.
디자이너들뿐만이 아니라 IT직종에 있는 분들이 대부분 자존심이 강하고 유아독존하려는 경향이 있습니다. 하지만 엄연히 사회입니다. 프로젝트의 성공은 자신의 최고실력을 발휘하는것이 아닌 "우리의 최고실력을 발휘하는것입니다." 다수의 의견을 따르고 거기에 소수의 의견까지 기억하십시요. 평범한 디자이너는 없습니다. 자신의 고집만을 부린다면 "오만한 그림쟁이"일 뿐이며, 다른이의 의견을 취합할줄 안다면 "능력있는 디자이너"가 될것입니다.

4. 자신의 의견에 충분한 근거를 제시하라.
디자인이라는 일 자체가 굉장히 추상적이며 상대적인 분야입니다. 내가 볼땐 아무리 이쁘고 요즘 트렌드에 맞게 디자인을 했어도 그것을 접하지 않은 사람들에게는 "못보던것"일뿐입니다. 그들에게 자신의 결과물에 대한 설득을 시키려면 "말"보다 "근거"를 제시하는 방법을 터득하십시요. 훌륭한 사이트의 스크린샷을 뽑아서 비교한다던가 해상도를 통계한 수치를 제공한다던가 그에 대한 타당한 근거를 제시하여 설득시키십시요. 데이타와 문서의 힘은 당신을 보다 Professional 하게 만들어줄것입니다.

 

To. Developer

IT분야에 개발자는 종류가 참 많습니다. 자바개발자, 웹프로그래머, 플래시 개발자, 모바일 개발자, 서버관리자, Data아키텍쳐 참 많습니다. 하지만 프로그램 방법론이 크게 객체지향과 절차지향으로 나눌수 있듯이 개발자가 맡게되는 업무는 공통점이 많을것입니다. 다른 디자이너나 PM이 꼬치꼬치 따지거나 당연한것들을 이것저것 요구하거나 물어볼대 짜증이 쓰나미처럼 밀려오죠. 하지만 우물안에만 있어서는 결코 하늘을 날지 못합니다.

1. 충분히 설명하고 또 설명하라.
프로그램은 해당 직종이 아닌 사람이 봤을땐 외계어입니다. 한국인이 아랍어 봤을때 실타래풀어놓은것 처럼 보이듯이 디자이너가 개발자의 전문용어나 구조적인 용어들은 당췌 딴나라 얘기일것입니다. 그들에게 최대한 쉽고 전문용어를 풀어서 설명해주십시요. 그리고 가장 중요한것은 "무슨뜻인지 이해가시죠?" 라고 확인하십시오. 모른다면 더 쉽게 풀어서 설명하십시오. 그렇지 않다면 당신은 똥고집쟁이 프로그래머 될것이지만 그들에게 충분히 설명하고 원활한 해결방법을 설득시켰다면 당신은 "뛰어난 개발자" 가 될것입니다.

2. 상대의 비합리적인 요구에는 반드시 대안을 제시하라.
무조건 안된다고 하는 개발자보다 무식해보이는 행동은 없습니다. 왜 안되는지에 대한 설명을 하고 그에 대한 대안을 제시해야합니다. 그래도 상대가 계속 주장을 관철시킨다면 설명이 부족한것입니다. 상대가 내입장에서 생각할 수 있을정도의 충분한 설명이 필요합니다. 개발자가 소요하는 시간은 미팅과 회의 > 고민하는 시간 > 파일명 생각하는시간 > 주석다는 시간 > 소스짜는 시간 순일수록 훌륭한 개발자라고 하더군요. 설득과 설명을 멀리하지 마십시오. 그래야 당신도 상대도 수월하게 일을 할 수 있습니다.

3. 기획을 하는것에 대해서 두려워하지 말아라.
스스로를 수동적인 기계로 만들지 마십시오. 능동적으로 책임감을 가지고 예상하지 못한 문제점에 대해서 스스로 기획하고 상부로 건의하십시오. 이는 당신의 몸값을 올려줄 뿐만 아니라 기획자나 PM으로 가는 방법을 제시해줄 것입니다.

 

To. Project Manager

보통 PM은 개발자나 디자이너보다 상사일 경우가 많습니다. 하지만 PM은 그들위에 있는 존재가 아닙니다.
과장되게 말하면 PM은 그들의 "시다바리"입니다. 디자이너에게는 훌륭한 디자인을 뽑아낼수 있도록 모든 컨텐츠를 제공해주고 개발자에게는 최적화된 모듈이 나올수 있도록 모든 정보를 수집하여 문서화해서 넘겨주어야 합니다. 거기다가 PM은 항상 예상가능한 문제점에 대해서 대비해야합니다. 기간이 길어질 것에 대한 대비라던지 비용이 추가될 것에 대한 대비를 해야합니다. 디자이너와 개발자분들은 어떻게 생각하실지 모르겠지만 프로젝트가 성공하기 위해서는 무엇보다 PM의 역할이 가장 중요합니다.

1. 자신을 그들보다 낮춰라.
절대 명령하지 마십시오. 어떻게 결정된 사안이든지 그들의 의견을 묻고 "나의 의견"이 아닌 "우리의 의견"으로 인식시켜야 합니다. 그것은 그들 스스로에게 책임감을 심어주는 중요한 계기가 됩니다. 돈보다 중요한것은 열정입니다. 열정을 갖기 위해서는 스스로에게 목표에 대한 중요성을 일깨워줘야 하는데 "명령"을 해서는 그들의 마음을 움직일수 없습니다. 스스로를 결과물을 만들어내는 기계로 인식해버리고 재료를 넣으면 결과물만 만들어내는 녹즙기로 되버립니다. 이는 일을 지루하게 느끼게 하고 해야할 의무감마저 잃어버리게 만듭니다. 그러다보면 슬슬 딴청을 피게되고 요리조리 안할생각만 하게 됩니다.

그들보다 몸을 낮추십시오.
아무리 좋은 기획과 대안을 가지고 있어도 디자이너와 개발자가 그것을 창조해 내지 않는다면 무슨 소용이 있겠습니까?
그들에게 권유하십시오.
"우리 같이 ㅇㅇㅇ합시다."
"이 의견의 이런 부분이 저는 참 마음에 드는데 ㅇㅇㅇ디자이너분 생각은 어떠세요?"
"개발자님 혹시 ㅇㅇㅇ게 더 간단하지 않을까요? 어떻게 생각하세요?"
라고 권유를 한다면 그들은 한층 기쁜 마음을 가지고 업무에 임하게 될것입니다.

2. 프로젝트는 가만히 두면 실패하게 되어 있다
이 말은 무엇보다 중요합니다. 아무리 플랜이 잘 짜여져 있고 일정과 기간이 풍족하더라도 프로젝트는 가만히 놔두면 실패하게 되어 있습니다. 아무리 완벽한 기획도 실무에 들어가면 반드시 예상하지 못한 부분들이 드러납니다. 이부분을 얼마나 잘 준비하여 대처하느냐에 따라서 그 리스크는 0에 가까워질수 있습니다.

항상 움직이십시오. 아무리 잘 다듬어진 기획서라도 계속 중간 중간 검토하고 예상되는 모든 리스크에 대해서 대비하십시오. PM은 기획자와 같이 반발씩 앞서나가면서 시작하지만 PM은 프로젝트가 끝난 후에도 가장 오랫동안 해야할일이 많습니다. 사용하는데 발생한 문제점은 없는지 잘 사용하고 있다면 어떤 부분이 가장 편한지 끊임없이 조사하고 관리해야합니다.

3. "Yes-man"이 되어선 안된다.
절대로 그들의 모든 의견에 "Yes"부터 나가면 안됩니다. 반드시 그들의 의견은 문서화하여 두번 세번 검토해야합니다. 그보다 더 나은 대안은 없는건지 이 의견에 대한 하자는 없는건지 충분히 심사숙고하여 검토한 후 결정해야합니다. 해는 동쪽에서 떠야한다고 주장을 하더라도 사람의 방향에 따라서 그들의 입장에서는 서쪽이 될수도 북쪽이 될수도 있고 동서남북을 모르는 사람일 수도 있는것입니다. 충분히 고려하고 또 고려해서 스스로가 질릴때까지 검토할 수록 좋은 대안이 나올 수 있는것입니다.

4. 클라이언트에게 개발자와 디자이너를 내세우지 마라.
자신이 잘 알지 못한다고 개발자나 디자이너를 연결한다거나 자신을 거치지 않고 그들에게 부담을 주어서는 안됩니다. 그들의 자문이 필요하다면 직접 그 내용을 받아 문서화한뒤 해당 개발자나 디자이너에게 문의하십시오. 말로 하는것과 문서로 하는것에는 그 의무감이 다릅니다. 말로하는것은 잊어버릴수도 있고 와전될수도 있으며 문서로하는것은 그 흔적이 남고 무엇보다 누구에게나 동일한 내용을 보여준다는 것입니다. 이해는 각기 다를 수 있겠지만 적어도 내용은 동일한것입니다.

개발자나 디자이너에게 있어서는 클라이언트를 대변하지만 클라이언트 앞에서는 자신이 개발자와 디자이너를 대변해야합니다. 그들의 변명도 자신의 이름으로 해야하며 클라이언트의 어이없는 요구도 스스로 막아내야합니다. 그것이 바로 Manager 인것입니다.



우리나라 IT시장이 분명히 인프라에 비해 성숙하지 못한게 사실입니다. 욕심이 많은 한국인으로써 경쟁하기를 좋아하기 때문인것 같습니다. 서로가 서로에 대해서 충분히 알만큼의 기간이 없었던것 같습니다. 조금씩 서로 이해해가면서 발전해나갔어야 하는데 너무 빨리 성장해버린 지금 IT에 대한 환상과 허상이 저급 인프라를 양성해내는것인지도 모르겠습니다. 어떤 직업이나 직책이든지 "이해"와 "타협"만큼 좋은 해결방법은 없는것 같습니다.

이상 여기까지가 우야꼬님께서 올리신 글입니다.
다 맞는 얘기고 공감하는 부분이지만, 말처럼 쉽게 되는 법은 없는 듯 합니다.
하지만, 모든 것에 좋은 출발은 소통이 아닌가 생각합니다.

 

소통(疏通)이란?

막힘 없이 잘 통하는 것이다. 즉 뜻이 서로 통하여 오해가 없는 것이다.

라는 뜻이 있습니다. 
그야말로 하나의 프로젝트를 성공으로 끝맞추기 위해서는 소통이 우선시 되어야 할 것 같습니다.
아무리 평소에 좋은 사이라도 프로젝트만 들어가면 소통이 원활하게 되지 않는 경우가 있더군요.

말이 오해에 오해를 부풀리는 경우가 발생하게 될 때도 있습니다.
아뭇튼, 조직에 맞는 소통하는 방법을 생각해 볼 필요가 있을 듯 합니다.