태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


2013.02.08 00:26

Project Climbing : PM이 되고자 할 때 알아야 하는 9가지

많은 디자인 회사가 도제식으로 운영됩니다. UX 회사라고 해서 별반 다르지 않죠. 저 역시 과거를 돌이켜보면 어떤 프로젝트를 누구와 함께 했는냐에 따라 학습의 범위와 개인적인 성장의 속도가 달라졌습니다. 흔히 말하는 사수와 부사수의 관계안에서 선임 디자이너가 후임(신입) 디자이너에게 디자인적인 스킬과 노하우를 전파하고, 프로젝트 매니저(PM) 역시 도제식으로 PM의 역할과 권한, 책임, 노하우 등이 공유되는 것이 현실이죠.


대다수의 경험과 노하우가 도제식으로 전수되다 보니, 어떤 마스터(사수)를 만나느냐, 어떤 프로젝트를 만나는지, 그 때의 상태가 어떠냐에 따라 전수받는 내용과 질, 양이 달라지는 문제가 발생합니다. 작년에 선임 진급자를 대상으로 짧게나마 PM 교육을 진행한 적이 있었는데, 주위 여건상 끝마치지 못한 아쉬운 마음에서 'Project Climbing_PM이 되고자 할때 알아야 하는 9가지'란 주제로 저의 경험과 노하우를 정리해 보았습니다.


1. 등반을 함께 할 사람들의 역할과 관계를 파악하라_프로젝트 골과 이해 관계자 파악하기
새로운 프로젝트를 시작한다는 것은 새로운 사람을 만나는 것을 의미합니다. 어떠한 사람들과 함께 하느냐가 프로젝트의 성패를 좌우하죠. 보통 UX분야에서 만나는 이해 관계자들은 상품기획, UX / UI 디자이너, GUI 디자이너, 개발부서, 마케팅부서 등 입니다. 프로젝트 시작과 함께 각 이해 관계자들이 각자의 입장을 이야기해 준다면 좋겠지만, 이런 경우는 매우 드뭅니다. 이런 이해 관계자들의 입장과 골을 파악하는 것이 PM이 파악해야 하는 첫번째 임무입니다. 많은 이해 관계자들 중 일부는 프로젝트를 진행하는데 든든한 후원자일수도 있고, 혹은 장애물일수도 있기 때문이죠. 특히 이해 관계자들이 많은 경우 모든 이해 관계자들이 동일한 권한을 가지고 있지 않습니다. 키맨(key-person)을 파악하고 그들의 의중을 빠르게 파악해야 프로젝트를 진행하는 초기비용을 절약할 수 있습니다. 파악이 늦어지면 늦어질수록 많은 비용이 추가될 수 있습니다.


또한 프로젝트를 시작할때 모든 이해 관계자들이 동일한 출발선에 있다는 것을 의미하지도 않습니다. 어떤 프로젝트는 모든 이해 관계자들이 동일하게 공평한 상태에서 출발하기도 하지만, 먼저 출발한 불공평한(?) 이해 관계자들이 있기도 합니다. 대개 이런 이해 관계자들은 자신이 더 많은 지식과 정보, 노하우를 가지고 있다고 믿고 있고, 실제로 그러기도 합니다. 먼저 출발한 이들의 노력과 성과를 빠르게 흡수하고 프로젝트 진행에 도움을 받을 수 있는 부분을 파악하는 것도 PM의 중요한 임무입니다.


어떠한 목표를 달성하기 위해 여러 명의 이해 관계자가 프로젝트에 참여한다는 것은 목표 지점에 도달하기 위한 일종의 등반이자 탐험대와 유사합니다. 그 중엔 함께 정상에 오를 사람도 있겠지만, 등반에는 참여하지 않고 보급을 책임져 줄 사람과, 등반을 위한 장비와 재정적인 지원을 해주는 스폰서 등 눈에 띄지는 않지만 등반의 성공에 많은 기여를 하는 관계자들도 있을 수 있습니다. 마찬가지로 프로젝트에서도 눈에 보이는 이해 관계자뿐만 아니라, 눈에 보이지 않는 모든 이해 관계자까지 파악해야 합니다. 



이해 관계자의 역할과 관계를 파악하기 위해, 필자 역시 매번 프로젝트 시작과 함께 Stakeholder Map을 그려 함께 일하는 팀원들과 프로젝트에 관련된 사람들을 정의하곤 합니다. 사람들의 관계속에서 역할이 정해지고, 함께 의논하고 의지해 나갈 관계를 만들어야 하니까요. 







2. 자신만의 축척으로 그려진 지도를 만들어라_프로젝트 일정 머리 속에 입력하기
프로젝트 시작과 함께 논의하는 것은 일정에 관한 것입니다. 일정은 시간이고, 시간은 곧 비용을 의미하기 때문에, 일정에 대한 감을 가진다는 것은 PM에게 무엇보다 중요합니다. ‘이 정도 시간이면 이 정도의 일을 할 수 있을 것이다’라는 계산이 이루어져야 하는 것이죠. 그 계산을 하는데는 함께 일하는 팀원들의 업무 능력도 파악해야 하고 월간, 주간, 일간 별로 해야할 일과 진행 과정을 머리속에서 그려보고, 압축하고, 분절시킬 수 있어야 합니다.


필자 역시 이런 일정 관리에 대한 감을 익히기 위해 다양한 일정 관리용 문서를 사용했습니다. 월간 일정을 확대해서 주간 일정으로, 주간 일정을 확대해서 일일 일정으로 혹은 그 반대로 큰 일정과 작은 일정을 자유롭게 오갈 수 있어야 합니다. 이를 위해 다양한 일정 관리 파일을 활용하면서 각자의 스타일과 경험에 따라 발전시키면 매우 소중한 자산이 될 수 있습니다. 



다양한 일정 관리 파일을 사용한다는 것은 축척이 다른 지도를 가지고 있는 것과 유사합니다. 주위 상황과 앞에 닥친 목표물에 따라 어떨 때는 전체를 조망해야 하고, 어떨 때는 자세한 지형을 살펴보기 위함이죠. 다양한 축척에 따라 묘사된 디테일한 정보가 의사 결정 및 일정 협의를 하는데 생기는 차이를 줄여줄 수 있습니다.



또한 무리한 일정을 요구받았을 경우를 대비하여 상대방을 이해시킬 수 있는 설득 자료를 준비하고 있으면 좋습니다. 예를 들어 결과물을 만들어 내는데 필요한 적정 시간보다 턱없이 부족한 시간동안 작업하길 원하는 경우, 줄어든 시간만큼 고민의 깊이는 줄어들고 성과물도 평범해질수 밖에 없음을 설명해 주고, 우수한 결과물을 얻기 위해선 어떤 과정을 거쳐야 하고 소요되는 적정 필요 시간도 알려줄 수 있어야 하니까요.


3. 자신만의 등반가방을 만들어라_프로젝트에서 진행할 프로세스와 방법론에 대해 알아야 한다
일정과 함께 논의하는 것은 프로세스입니다. 일정이 가로 항목이라면 프로세스는 세로 항목이죠. 즉 일정 관리를 제대로 하려면 프로세스에 대한 경험과 지식을 갖추어야 합니다. 어떤 과정으로 프로젝트를 진행할 것인가는 UX분야에서 매우 민감한 사항입니다. 어떤 방법론을 사용하느냐에 따라 양질의 결과물이 얻어지기도 하고, 새로운 관점을 얻기도 하기 때문이죠. PM은 프로젝트 결과물을 디자인하는 것과 프로젝트 진행 과정을 디자인하는 것 모두 할 수 있어야 합니다. 두가지 모두에 집중할 수 없다면 프로젝트 진행 과정에 더 많은 비중을 두어야 합니다. 





모든 프로세스가 계획한 대로 진행되지 않을 수 있습니다. 아니 계획한 대로만 진행되는 것이 오히려 매우 드문 경우입니다. 프로젝트를 진행하다 보면 그때 그때 상황에 따라 프로세스를 수정하거나 새로운 것을 추가하거나 삭제해야 하는 경우가 발생하는 것이 자연스러운 과정입니다. 이런 상황에 처했을때 제한된 비용과 일정안에서 꼭 필요한 프로세스와 방법론을 선택하고 재설계 할 수 있어야 합니다. 이를 위해서 PM은 프로세스와 다양한 방법론으로 꾸려진 등반 가방을 만들어 놓아야 합니다. 등반 가방이 있어야 지형에 적합한 장비와 응급 상황에 필요한 비상도구를 꺼내서 사용할 수 있습니다. 등반을 하기 위해선 지도와 장비 모두가 필요합니다. 길을 잃지 않기 위해선 지도가 필요하고, 정상에 접근하기 위해선 다양한 장비가 필요하듯이 말입니다.




4. 팀원들과 로프를 연결하라_함께 일하는 팀원들을 항상 생각하라. 혼자서 일할 수 없다
프로젝트 결과물을 설계하는 것과 프로젝트 진행 과정을 설계하는 것 중, 후자에 더 많은 비중을 두라고 하는 것은 바로 팀원이 있기 때문입니다. 대다수의 UX 프로젝트는 팀원들간의 콜라보레이션이 매우 중요합니다.
팀원으로서 하던 일이 익숙하고 능숙하겠지만, PM으로서 해야 하는 일과는 다릅니다. 팀원들간의 콜라보레이션이 원활할 수 있도록 도와주고, 그들의 잠재된 능력이 표출되도록 하는 것이 PM이 해야 할 일이니까요.
 
팀원들과의 협업과 관계를 유지하는 몇 가지 원칙을 말하자면...

▷ 팀원들은 항상 자신이 하는 일이 어떤 가치가 있는지 알고 싶어 합니다. 지속적이고 반복적인 설명을 통해 자신이 무슨 일을 하고 있고, 성장할 수 있는 기회에 있다는 생각이 들게 해야 합니다.

▷ 각 팀원들이 해당 프로젝트에서 얻을 수 있는 개인적인 목표를 설정하게 하는 것도 지속적인 동기 부여를 유지하는데 효율적인 방법입니다.
▷ 각 팀원들의 상태와 성장 속도는 모두 다릅니다. 각 팀원들의 현재 상태를 파악하고, 그에 따른 맞춤형 관리를 해 주어야  빠르게 성장할 수 있습니다. 예를 들면 신입 사원에겐 용어정의부터 차근차근 설명한다면, 2년차에겐 믿고 맡기고 함께 논의하는 것이 더 도움이 될 수 있습니다.
▷ 솔직하게 말하는 것이 좋습니다. 어쩔 수 없이 하는 거짓말이나 숨김도 같이 일하는 팀원들과의 장벽만을 만들뿐입니다.
▷ 팀원 개개인이 스스로 조절할 수 있는 짧은 일정을 제공하는 것이 좋습니다. 모든 사회인들은 회사 생활과 사적인 개인 생활의 균형이 어루어져야 합니다. 모든 일정을 직접 관리하려 들지 말고 개인별로 일정과 업무의 양을 조절하면서 오늘은 야근을 해서라도 일을 끝내고 내일은 친구들과 만날 수 있게 해 주어야 합니다. 원하는 시간에 친구도 만나고 술도 먹고 영화도 볼 수 있어야, 내일의 업무도 빠르게 진행됩니다.
▷ 공식적인 업무 시간이 아닌 경우에는 회의 시간을 절대 잡지 마십시오. 모든 회의는 업무 시간내에서 시작하고 끝내는 것을 원칙으로 해야 합니다.  
▷ 프로젝트 운영을 효율성을 추구할 것인지, 새로운 가치를 만들것인지, 교육이 목적인지 프로젝트 시작시에 팀원들에게 말해주는 것이 좋습니다. 미리 알려주어야 팀원들도 대비할 수 있습니다.
▷ 모든 팀원을 만족시키는 완벽한 PM이 되기는 매우 어렵습니다. 완벽한 PM이 될 수 없다면 일정한 원칙과 기준을 가져야 합니다. 그래야 함께 일하는 팀원들이 이해할 수 있고, 적응할 수 있으니까요. 제일 안 좋은 PM이 원칙과 기준없이 이랬다 저랬다 즉흥적인 판단과 지시만을 하는 경우입니다.



등반시 위험한 지역을 지나갈 때 모든 등반 팀원을 하나의 로프로 연결하듯이, 프로젝트에서도 보이지 않는 끈으로 모든 팀원들이 연결되어 있습니다.  그 끈을 통해 팀원들간 영향을 주고 받으며 프로젝트가 진행된다는 것을 잊으면 안됩니다.




5. 언어를 배워라_상황에 따른 언어사용 능력이 필요하다
프로젝트를 진행하다 보면 여러 이해 관계자를 만나게 됩니다. 각 이해 관계자들은 고유의 영역이 있고 각자의 베이스가 다르기 때문에 사용하는 언어와 가치판단을 하는 기준이 다릅니다. 언어가 다르고 가치 판단 기준이 다르다는 것은 프로젝트를 원할히 진행하는데 걸림돌이 되기도 합니다. 자신에게 익숙한 언어만으로는 다른 베이스의 이해 관계자를 설득하지 못하기 때문이죠.
상대방의 입장을 이해하기 위해서는, 상대방의 언어를 이해하는 것이 그 시작이 될 수 있습니다. 상황에 따라 다른 베이스의 이해 관계자를 설득할 수 있는 언어와 관점을 가지는 것은 그래서 중요합니다.


다학제적인 특성을 지니고 있는 UX 분야에서 언어를 이해한다는 것은 커뮤니케이션 비용의 절감과 새로운 정보를 얻을 수 있는 루트이기도 합니다. 등반을 하다보면, 먼저 등반을 마치고 내려오는 사람들에게 매우 중요한 정보를 얻는 경우가 있습니다. 정상의 날씨가 안좋아지고 있다거나, 이 경로로 올라가면 어느 정도의 시간이 걸린다는 내용 말입니다. 이런 정보는 등반 계획을 그대로 실행할지, 수정할지를 판단하는 매우 중요한 판단 근거가 되는데, 이 때 언어를 몰라 그 정보를 알아듣지 못하면 등반의 성패를 좌지우지 할 수 있습니다.



또한 각자가 가지고 있는 언어를 고집해야 할 때와 다른 언어를 사용할 때를 선별하는 것 역시 중요합니다. 나의 언어로 나의 전문성을 보여줄 때와 상대방의 언어를 들어주고 상대방의 언어로 응답해 주어야 할 때를 알아야 하는 것이죠. 특히 UX분야에서는 경영, 디자인, 개발 관련된 언어를 이해하고 말할 수 있는 능력이 점점 중요해지고 있습니다.


6. 베이스 캠프를 만들어라_프로젝트 크기나 일정에 따라 Milestone이 필요하다.
일반적으로 프로젝트를 시작하면 ‘업무 감정’과 ‘업무 강도’는 아래와 같은 모습을 띄게 됩니다.
프로젝트 초기에는 새로운 업무에 대한 호기심과 열정으로 긍정적인 감정이 생기지만, 프로젝트가 진행됨에 따라 업무량과 강도는 점점 높아지고, 호기심과 열정이라는 긍정적인 감정은 줄어들어 부정적인 감정이 늘어갑니다. 프로젝트 중반이 넘어가면서 다시 업무량이 줄어들고, 자신들이 창조해 낸 산출물에 대해 보람과 성취감을 느끼며 다시 긍정적인 감정이 발생하게 되는 것이죠.



3개월 미만의 단기 프로젝트일 경우 ‘업무 감정’과 ‘업무 강도’ 그래프가 비교적 단순하겠지만, 3개월 이상의 장기 프로젝트의 경우는 업무 감정이 저점을 찍는 시기가 몇 개월 지속될 수 있기 때문에 관리가 필요합니다. 아래 그래프처럼 프로젝트 일정에 따라 마일스톤을 설정하고, 업무에 대한 감정 그래프를 짧게 분절시켜야 함께 일하는 팀원들의 감정이 부정적으로 흐르는 것을 보다 완화시킬수 있습니다. 업무 강도 그래프 역시 마일스톤을 설정하여 짧게 분절시켜 팀원들에게 인지시키면, 장기 프로젝트를 관리하기에 보다 수월해 집니다.


이런 마일스톤을 설정하는 것은 등반시 베이스캠프의 역할과 비슷합니다. 베이스캠프에 도착함으로써 작은 성취감을 느낄 수도 있고, 프로젝트 진행과정에 대한 이해 역시 높일 수 있습니다. 또한 감정적인 안락함을 느끼게도 도와줄 수 있는 것이죠.
프로세스에 따라 베이스캠프를 만들 시점을 파악하고, 그 시점을 기준으로 긍정적인 감정과 분위기를 생성하도록 유도해 내는 것 역시 PM의 중요 임무임을 잊지 말아야 합니다.





7. 현지 적응 시간이 필요하다_새로운 인력이 투입되는 시기도 때가 있다.
프로젝트를 진행하다보면, 새로운 인력이 추가로 필요한 경우가 종종 있습니다. 새로운 인력이 필요한 경우는 업무 범위의 변경과 역할 변경을 의미하기도 하지만, 대게의 경우는 초기에 예측한 업무량에 대한 판단착오인 경우가 많습니다. 긍정적인 상황이 아닌 경우가 대부분이죠. 그렇다고 무작정 새로운 인력을 투입하는 것이 그 상황을 타개하는 정답은 아닙니다. 


대다수의 프로젝트는 사고의 확장과 수렴과정을 거치게 되는데요. 더블 다이아몬드를 예로 들어 설명하자면, 대게 사고의 확장 단계보다 수렴 과정이 업무량이 많아 지는 단계입니다. 산출물을 만들어 내는 시기이기 때문이죠. 그래서 수렴 과정에 새로운 인력에 대한 필요성을 많이 느끼게 됩니다.



하지만 수렴 과정에 새로운 인력이 투입된다고 해서 업무를 진행하는데 큰 도움을 받을 수는 없습니다. 수렴 과정은 문제를 정의하거나 해결 방법을 선택하는 과정인데 새롭게 투입된 인원은 전후 히스토리와 프로젝트에 대한 이해도가 부족하기 때문에 가치 판단을 하기 어렵기 때문이죠. 새롭게 투입된 인원 역시 자신의 역할을 찾지 못해 난처한 상황에 놓이기도 합니다.


새로운 프로젝트에 참여하게 되면 업무를 파악하는 시기가 필요한데, 수렴 단계보다는 확장 단계가 업무 중요도에 있어 부담이 적습니다. 편하게 동료들과 이야기하고 생각을 확장시킬 수 있기 때문에 적절한 적응 시간이 될 수 있습니다. 처음부터 투입된 팀원들과의 정보의 균형을 맞추고, 자신이 해야 할 일에 대한 오너쉽을 가질 수 있는 시간이기도 하죠. 반면 수렴 과정에 투입되면, 가치 판단과 선택에 대한 확신이 없기 때문에 이미 투입되어 있던 팀원들을 서포트 해준다는 마음을 갖게 될 확률이 그만큼 커지게 됩니다.
리소스가 부족한지, 적절한지는 사고의 확장 단계에서 사전에 체크하고 조치를 취해야 프로젝트와 새로 투입된 인원 모두에게 도움이 될 수 있습니다.


등반에 비유하자면, 현지 적응 시기 없이 바로 등반을 하는 것과 같습니다. 고도, 기온, 날씨 등 현지 적응이 되야 제대로 능력을 발휘하고 함께 등반하는 팀원들에게 도움이 될 수 있습니다. 현지 적응 없이 등반에 참여하면, 짐스러운 존재가 될 뿐입니다.




8. 올라온 코스 되돌아 보기_전반적인 프로젝트 히스토리를 돌이켜보고 회고하라
개인적으로 등산코스를 정할 때, 계곡을 따라 올라가서 능선으로 내려오는 것을 좋아하는데, 내려오면서 왔던 길을 살펴보거나 주위 경관을 볼 수 있기 때문입니다. 프로젝트를 마무리할 때도 올라왔던 길을 살펴보는 것은 다음 등반과 탐험을 위해 꼭 필요한 마무리 과정입니다. 


pxd에서는 하나의 프로젝트가 마무리 될 시점에 'Retrospective'라는 프로젝트 회고 시간을 가집니다.
프로젝트 회고(Retrospective)를 하는 방법을 말하자면...

▷ 해당 프로젝트에 처음부터 끝까지 참여한 인원이 프로젝트 목적이나, 히스토리, 투입 시간, 투입 인원 등 대략적인 프로젝트 정보들을 모아서, 팀원들과 간단히 공유합니다.
▷ 포스트잇에 프로젝트에서 진행했던 중요 사건을 시간순으로 기록하고, 벽에 붙입니다.
▷ 중요 사건들을 보면서 각 사건별로 좋았던 점, 안 좋았던 점을 개인별로 포스트잇에 적어 붙입니다.
▷ 좋았던 점, 안 좋았던 점을 적을때 논리적인 이유가 있을 필요는 없습니다. 예를 들어 특별한 이유는 모르겠지만, 개인의 감정이 좋지 않았던 시점이 있었어도 기록하면 됩니다. 
▷ 각각의 좋았던 점과 안 좋았던 점을 팀원들간 공유하면서, 개선점을 함께 논의합니다.
▷ 프로젝트 초기에 설정한 개인 목표의 달성 여부를 공유합니다. 달성했다면 어떤 부분이 좋았는지, 미달성했다면 달성하지 못한 이유를 이야기하는 것이 좋습니다.
▷ 마지막으로 함께 한 팀원들의 장점을 적고, 서로 공유합니다.





프로젝트 회고를 하는 방법은 다양할 수 있습니다. 각 회사나 조직의 문화에 맞게 변형해서 사용하면 되는데 중요한 점은, 업무시간에 프로젝트 회고를 공식적으로 하는 것입니다. 업무 시간에 함으로써 회사 차원에서 이런 부분까지 신경써 준다는 인상을 받게 되고, 프로젝트에 대한 좋은 경험을 간직하게 되기 때문입니다. 물론 프로젝트를 하면서 팀원들간 쌓였던 감정적인 부분이나 오해들도 풀게 되는 시간이 되고요.


9. 단지 선두에 있는 사람일 뿐이다_PM이 없는 프로젝트가 최고의 프로젝트이다. 
위에 언급한 8가지를 읽으신 분이라면, PM이란 엄청난 권한과 책임을 가진 것으로 착각할 수 있습니다. 하지만 개인적으로 가장 기억에 많이 남는 프로젝트를 꼽으라면, PM이 없었던 프로젝트라고 생각합니다. 즉 리더역할이나 관리자 역할을 하는 PM이 아니라, 팀원들의 잠재력을 표출하는데 도움을 주는 조력자(Facilitator) 같은 PM을 뜻합니다. 팀원들과 PM간 수평적인 관계속에서 팀원들이 자기 역할과 책임을 다하고, PM은 보이지 않는 조정만 하는 것이죠.



등반팀의 리더도 항상 앞서서 등반을 하지는 않습니다. 단지 선두에 많이 서 있는 사람일 뿐이죠. 등반 코스에 따라 서로의 체력을 안배하고, 의지하기 위함이죠. 때론 팀원들이 경험을 쌓게 하고 성장시키기 위함이기도 하고요. 인위적이고 강제적인 책임과 권한보다는 자연스러운 믿음과 의지가 바탕이 될 수 있게 팀원 모두가 PM이 될 수 있다는 사고를 가지는 것이 중요합니다.


마무리하면서...
제가 블로그를 통해 ‘Project Climbing_PM이 되고자 할때 알아야 하는 9가지’란 주제를 다룬 이유는, 처음 PM이 되었을때의 답답함 때문이기도 합니다. 어느 누구도 명확히 가르쳐주지 않았고, 관련된 책도 없었기 때문이죠. 여타 다른 산업의 경우 중간 관리자나 상급 관리자를 위한 교육 등이 잘 정립되어 있고, 제공하는 교육기관도 많이 있으나, 디자인 분야에서는 관리자를 위한 교육 프로그램이 부족한 것이 현실입니다. 
위에 이야기한 내용이 개인적인 경험에 근거했고 UX디자인 분야라는 한정된 분야에만 해당될 수 있으나, PM이 되어야 하는 상황에 처한 분들에게 작은 도움이라도 되었으면 합니다.
산에서 내려오면, 기분좋게 웃으며 마무리 인증사진을 찍듯이, 프로젝트 종료 때도 웃으며 인증사진을 찍을 수 있게 되길 바랍니다. 





[참고##프로젝트 방법##]





팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 1 Comment 10
  1. 신승렬 2013.02.08 10:43 address edit & del reply

    좋은글 잘 보았습니다.
    pxd글은 모두 좋지만 특히나 뼈가되고 살이되는 글이네요..

    스크랩하고 별찍고. 즐찾해놓았습니다..
    감사합니다

    • Aiden Park 2013.02.13 17:05 address edit & del

      감사합니다. ^^

  2. 박차욱 2013.02.12 23:54 address edit & del reply

    도움이 많이 되었습니다. ux 관련 업종은 아니지만 프로젝트 단위로 움직이는 회사에서 일하는 저로써는 도움이 많이 되네요^^

    • Aiden Park 2013.02.13 17:04 address edit & del

      도움이 되셨다니... 저 역시 감사합니다. ^^

  3. doogeon 2013.02.25 20:56 address edit & del reply

    정말 좋은 글이네요
    내용도 내용이지만 그걸 전달하는 글솜씨도 대단하신 것 같습니다.
    덕분에 프로젝트 매니징에 대해 많이 배우고 갑니다^^

    • Aiden Park 2013.02.26 13:17 address edit & del

      감사합니다.

  4. yooorim 2013.03.01 12:29 address edit & del reply

    일하던 회사에 PM의 역할을 하는 '관리'부서가 있었어요. PM들만 따로 모아둔 부서였는데, 그 부서 사람들을 '관리자'라고 불렀구요. 관리부서 이외의 팀원들은 대부분 작가나 디자이너여서, 정말 민감한 감수성과 다양한 개성을 지닌 사람들이 모인 회사였답니다.

    재밌는 건, 관리부서의 분들은 그 업계에 종사한 지 길어야 1-2년 되는 분들인데 비해 팀원들 중 대부분은 2-3년, 팀장급들은 10년이 넘는 경력을 가진 분들이었다는 점이에요. 그런 상황에서 관리자들이 할 수 있는 일들이 그렇게 많지는 않았었죠. 저는 우연히 그 프로젝트와 관련 없는 다른 업무를 진행하고 있어서 그 재미있는(?) 상황을 관찰할 수 있었구요.

    그런데, 회사가 커지면서 점점 업무시간에 감당하지 못할 정도로 업무량이 많아지고, 본인들의 능력을 뛰어넘는 일이 자꾸만 팀원들에게 쏟아지니까 프로젝트 진행이 더뎌지면서 관리자들에게도 위에서 많이 압박이 들어왔나봐요. 관리자들은 경력이 적어서인지, 빨리 프로젝트를 성공적으로 끝내서 자신들의 능력을 증명하고 싶어했구요. 그 때 관리자들이 선택한 방법은 '출퇴근 관리'였답니다. 정말 관리자답죠?^^;

    출퇴근이 지켜지지 않을 시 시말서를 쓰고, 회사의 업무시간이 끝나면 회사 문을 걸어 잠글테니, 이를 지키지 않으면 회사가 맘대로 퇴사시킬 수 있다는 내용의 계약서를 써서 돌렸답니다. 애초에 회사가 사원의 출퇴근 시간을 존중하지 않는데 출퇴근 관리라니.. 작업 속도의 절대적인 시간이 있고, 작가들은 관리자들보다 그 속도를 잘 아는데도 불가능한 시간 내에 프로젝트는가 끝나기를 요청하면서요. 게다가 쉴 새 없이 하루에도 몇 시간동안 진행량을 체크하기까지 하니까, 많은 팀원들이 그 일을 계기로 결국 대거 퇴사해버리셨어요.

    그 즈음에, 관리자들에게 불만을 가진 어떤 팀장이 '내가 다른 회사에서 이 정도로 일하면 더 많은 연봉과 복지 혜택을 받고도 더 좋은 직급을 보장받을 수 있다. 적당한 선에서 업무를 강요했으면 한다'고 하자, 한 관리자분이 이렇게 말했다고 해요. '회사 입장에서 좋은 계약을 한거죠. (그러니까 군말없이 일 하세요.)' 그런데 그 분이 회사랑 정식 계약을 한 게 아니고 사장님이 사정해서 잠깐 계셨던 분이라 결국 콧방귀를 뀌며 퇴사하셨죠.

    대체인력은 구해야 하고, 팀워크는 계속 깨지고, 프로젝트가 지연되니까 전화통은 불이 나고.. 이런 상황에서, 프로젝트 진행이 얼마나 성공적이었는지는 말 안해도 아시겠죠? PM은 컨트롤링하는 사람이 아니라 매니징하는 사람이라는 걸 절실히 체감했답니다. 변화하는 상황에 맞춰서요. 그래서인지, 이 글을 읽으면서 중간 중간 힘차게 고개를 끄덕거렸답니다. 흐흐. 좋은 글 잘 읽었습니다.^^

    • ashley 2013.03.18 21:22 address edit & del

      본문도 진국, 댓글도 진국이네요. 정말 정독했어요.ㅎㅎ
      "PM은 컨트롤링하는 사람이 아니라 매니징하는 사람이다" 굉장히 콕 박힙니다. 좋은 글 감사합니다.

    • 이용훈 2015.10.26 19:46 address edit & del

      좋은글 감사합니다. 이런 케이스가 전형적인 리더(leader)와 리더(reader)의 차이인것 같아요. 제가 최근에 디자인해준 곳도 크랄이언트 말을 들어보니 결국 pm분이 매니징을 못하고 있더군요. 그 부분을 말씀 드렸으나 닥치고 디자인이나 보내라더군요. 안타까웠습니다^^

  5. 이용훈 2015.10.26 19:42 address edit & del reply

    항상 좋은글 감사합니다. 한가지 궁금한게 있습니다. 내용중 UX/UI디자이너와. GUI디자이너를 구분해서 적어주셨는데요. 일에 대한 구분이 있는건가요? Ux와 ui를 함께 다루는 사람과 ui 영역만 다루는 사람을 구분짓는 건가요? 궁금해서 여쭤봅니다^^

Ad Test...