본문 바로가기
DB/SQL

[펌] 오종혁의 웹PM 강좌 - 프로젝트 매니지먼트(PM)란 무엇인가?

by 사우람 2010. 7. 12.

http://www.devbank.co.kr/

 

안녕하세요. 데브뱅크 운영자 오종혁입니다.

오늘은 프로젝트 관리기법에 대해 알아보기 전에 프로젝트란 무엇이며, 무엇을 프로젝트라고 하는 지에 대해 말씀을 드리려구요..

백과사전에 찾아보니 "프로젝트란 각 부문 ·사업부 ·섹션 간에 기술상 ·관리상 복잡하며 교차적 관계에 있는 개별계획으로 프로젝트 매니저에 의한 조정과 관리가 필요한 것을 말한다." 라고 되어있네요.. 맞는 이야기긴 하지만, 정말 어렵네요.

제가 생각하는 프로젝트란?

1. 비연속적인 (즉 시작과 끝이 있는) 일
2. 독립적인 예산을 가지고 있는 일
3. 서로다른 기술, 및 문화를 가진 사람들이 모여서 하나의 목적을 가지고 하는 일

등으로 정의하고 있습니다.

사실, 우리는 프로젝트라는 단어를 많이 사용하고, 여기저기서 아주 많이 듣고 있습니다. 하지만, 프로젝트가 정확하게 뭔가 하고 물어보면 많이 당황하게 되죠. 그냥 일이라고 이야기 하기도 하고, 작업이라고 이야기 하기도 하죠. 하지만, 우리가 직장에서 인사, 회계, 총무, 업무 그리고, 기타 일반적으로 하는 일들을 프로젝트라고 말하지는 않습니다. 그건 위의 정의에 위반되기 때문이죠.

프로젝트만이 프로젝트 매니지먼트(프로젝트 관리)를 했을 때 효과를 볼 수 있는 것입니다. 프로젝트는 역사적으로는 1960년대에 미군에서 잠수함을 축조할때 처음 도입한 방법이라고 하더군요. 그리 오래되지는 않았죠? 그 때 기존의 하던 방법보다, 프로젝트 관리기법을 도입했을 때, 프로젝트의 기간단축, 예산단축에 많은 효과를 보게 되었고, 그 뒤에 선진국들의 지속적인 학문적 연구를 통해 대형 공사나 단위가 크고 많은 사람들이 투입되는 프로젝트에는 어디에나 PM이란 사람이 따라다니게 되었습니다.

웹사이트 개발도 규모가 작기는 하지만 프로젝트라고 볼 수 있으며, 몇몇 프로젝트 매니지먼트를 하시던 분들이 프로젝트 관리기법중 일부를 웹사이트 개발에 도입하게 되고, 효과를 보고, 그러다보니 웹PM이란 단어가 등장하고 지금은 여러사람들이 웹PM을 해보려 노력하고 있는 상황입니다.

웹사이트를 제작하는 프로젝트의 경우는 사실, 다른 거대 프로젝트(건설, 토목, 조선등)들에 비해 매우 간단할 수가 있습니다. 왜냐하면, 투입되는 기술의 형태가 크게 디자인, 프로그램, 기획정도이며, 인력과 시간이외의 다른 자원이 그리 많이 필요하지 않기 때문이죠.

예를 들어 하나의 화학공장을 건설하는 프로젝트라고 한다면, 토목, 건축, 화공, 기계, 배관, 계장, 전기 등의 다양한 기술진들이 서로 모르는 분야와 통합적으로 하나의 생산품을 설계해 내야 하며, 다양한 재료의 구매와 시공 그리고, 감리에 이르기 까지 수많은 분야의 인력이 투입되게 됩니다. 사실, 이렇게 서로다른 분야가 복잡하게 얽혀 있을 수록 프로젝트 관리가 더욱 필요하게 되고, 효과도 그많큼 커지는 것이기는 합니다.

어쨌든 웹사이트제작에서도 프로그램과 디자인이라는 서로의 전혀 다른 기술분야의 인력이 조화있게 업무를 연계해 나가야 하는 것이라는 점에서는 프로젝트관리가 어느정도 효과를 볼 수 있는 분야라는 판단이 드네요.

 

* 웹사이트 제작 프로젝트 관리의 목적


그럼 웹사이트 제작 프로젝트 관리의 목적은 무엇일까요? 웹사이트를 제작하는 데 있어 프로젝트 관리를 사용하는 이유는

1. 최소의 자원(인력과 시간)을 투입하여 적정한 시기에 웹사이트를 오픈하는 것
2. 주어진 예산 안에서 사이트가 완성되고, 웹에이전시라면 적정한 이익을 남기는 것
3. 사이트의 목적에 부합하는 최고의 퀄리티가 확보된 사이트를 만드는 것

이라고 볼 수 있습니다.
즉 같은 사이트를 만든다고 해도, 가장 효율적으로 적은 시간에 적은 인력을 가지고 가장 좋은 상품을 만들어 내는 것이지요. 그럼 이제 부터 이것을 조금이나마 가능케 하는 방법들을 하나씩 말씀드리겠습니다.

1. 인력관리

웹사이트 제작은 컴퓨터, 인터넷라인, 서버등 웹사이트를 제작하는 업체라면 기본적으로 갖추고 있는 고정장비를 제외하면, 프로젝트마다 따로 준비할 구매없이 인력과 시간의 투자만이 필요한 노동집약적 프로젝트 입니다. 실제로 웹사이트 제작의 90%이상 예산이 인건비 이기도 하구요..

그만큼 웹사이트 제작 프로젝트에 인력관리가 중요하겠지요.
사실, 그동안 인력에 대한 관리는 여러 기업과 회사들에서 여러모로 연구가 되고, 시행착오를 겪어온 부분이기도 합니다.

인사고과등의 평가제를 시행하여 보기도 하고, 상벌제를 두기도하고, 업무실적에 따른 인센티브를 주기도 하고, 직원들에 대한 복지를 늘리기도 하고 등등의 여러가지 방법들을 동원하여 직원들이 열심히 일을 하게하고, 수익의 원천이 되도록 노력해왔습니다. 하지만, 저의 개인적인 경험으로는 여러가지 합리적인 제도를 도입하고, 제도적으로 일을 하게 하는 것도 중요하지만, 우리나라의 일하는 문화에서는 이보다는 인간적인 관계가 더 중요하더군요. 해외에서 연구된 인력관리의 방법들이 성공할 확율이 그리 높지는 않다는 것을 보면, 인력의 관리는 그 사회의 문화에 더 기인하는 것 같습니다.

특히 개발기간이 정해져 있는 프로젝트 작업의 경우는 더욱 인력에 대한 관리가 중요합니다. 웹사이트 개발은 90%이상이 노동력으로 인해 진행되는 작업이고, 중간에 프로젝트에 투입된 인력에 변동이 발생한다면, 그 프로젝트에 치명적인 위험요소가 될 가능성이 매우 높습니다.

만일 프로그래머 1명, 디자이너 1명, 기획자 1명이 하나의 사이트를 의뢰받아 만들고 있다고 생각해 보세요. 이런 경우 한명이라도 인력에 차질이 생기게 되면, (.. 회사를 그만둔다거나, 사고가 생겼다거나, 몸이 아프다거나 여타의 이유로 인해서) 촉박하게 돌아가는 프로젝트에서 한명이 빠지면, 프로젝트의 기간을 맞추기가 정말 어려워지죠.. 또한, 프로젝트 관리자로서 인력이 중간에 빠져나가는 부분을 막기란 불가능 할 수도 있습니다. 여러가지 계약이 있다해도 말이지요..

인력 리스크가 나타나는 시기나 가능성에 대해 프로젝트 관리자가 어느정도 예상할 수 있다면, 갑자기 닥치는 것보다는 훨씬 리스크를 줄여갈 수 있는 여지가 많아지게 됩니다. 이를 위해서 프로젝트 관리자는 프로젝트에 투입된 인력이 그리 많지 않다면, 핵심적인 인력에 대해 좀 더 친숙하게 다가가고 그사람이 프로젝트에 대해 개인적으로 생각하는 부분이나, 개인 사생활에도 조금은 관심을 가질 필요가 있습니다. 갑작스런 사고가 아니라면 조금은 미리 닥쳐올 인력로스에 대해 미리 짐작할 수 있게 되니까요..

그리고, 평소에 웹사이트 제작 기술에 대한 많은 인력들과 유대관계를 맺어 둘 필요도 있습니다. 갑작스런 프로젝트 인력의 공백을 매꿔줄 사람들을 많이 알고 있다면, 그만큼 프로젝트가 실패할 확율을 줄일 수 있게 되는 것입니다.

합리적이고 체계적인 것을 좋아하는 제가 인력에 대한 부분 만큼은 매우 뜬구름 잡는 이야기들을 하고 있는 듯 하네요. 이 것은 실제로 프로젝트를 꾸려가다보니, 사람과 사람의 관계에 대한 문제로 접근하여, 위험성을 파악하고, 이 위험성을 극복하는 대처를 해야한다는 것을 몸으로 느끼게 되었기 때문입니다.

더 이야기 한다면 잔소리가 될것같아 인력공백의 위험성에 대한 이야기는 이쯤에서 마치고요. 또하나 덧붙여 말씀드린다면, 각 인력들과의 커뮤니케이션 통로를 좀 넓혀야 한다는 이야기를 하고 싶네요. 특히 프로그래머, 디자이너의 경우 서로 많이 다른 문화적 환경에 살고 있는 사람입니다. 생각하는 방식도 많이 다르고 일을 추진하는 방법도 다르고, 의사전달을 하는 방법도 조금을 다르기 때문에 많은 트러블들을 만들지요. 기획자, 프로그래머, 디자이너가 서로 정확하게 의사를 전달하고 받아들일 수 있도록 중간에서 많은 노력을 해야 합니다.

사실, 프로젝트 매니저가 일을 시키는 입장이고, 개발자는 그 일을 하는 사람입장입니다. 그래서 프로젝트 관리자로서는 일방적으로 일을 시키고, 그 일을 시간내에 끝을 내야 하는 것이라고 생각하기 쉽지만, 어떤 방식이 실제 프로젝트를 성공적으로 이끄는 데 중요한 것인지를 한번 정도 더 생각을 해 보시는 것이 좋습니다. 서로가 참신한 아이디어와 의견을 충분히 교환할 수 있게 하고, 그에 대한 결정을 프로젝트 매니저가 모두가 납득할 수 있는 이유로 인해 신속하게 결정하고 일을 진행할 수 있는 팀웍을 만들어가는 것이 가장 훌륭하겠지요. (너무 어려운 이야기 입니다.) 팀웍이 맞는 다면 팀원들 또한 일이 즐겁고 인력에 대한 리스크도 가장 줄일 수 있는 길이 될 것입니다.

<@NHN@LINEBREAKER@NHN@>

2. 문서관리

 

문서관리에 대해 이야기 해 보도록 하죠..

사실, 많은 회사에서 대부분의 사람들이 문서관리를 매우 등한시 하고, 귀찮아하고, 잘 안하고 있습니다. 아마, 이글을 읽으시는 분들중에도 프로젝트를 진행하면서 체계적으로 문서를 관리하시는 분은 많지 않으리란 생각이 드네요..

그러다가, 우린 어떤 문제에 닥쳤을때 특히, 거래처(클라이언트등)와 이견이 생겼을 때 또 이것이 크게 문제시 될때 부랴 부랴 문서들을 찾고, 보관해 두지 못했음을 한탄하기도 하고, 회사의 윗분들에게 꾸지람을 듣기도 하죠.. 하지만, 그것도 잠시, 일이 바쁘고, 귀찮다는 핑계로 어느정도 시간이 지나면, 문서정리란 흐지부지 되게 마련이죠..

하지만, 프로젝트를 진행해 가면서 관련된 문서를 정리해 두는 것은

1. 프로젝트의 원활한 진행과 추후 문제가 되는 부분에 대한 대비..
2. 회사의 업무 노하우의 축적
3. 체계적인 의사결정 수단

등을 위해 중요한 일입니다.

최근 많은 회사들이 ISO 인증을 받고 있죠.. 이 인증을 받은 회사들은 ISO 규정에 따라 문서를 정리하도록 되어있습니다. 그리고, 형식적이나마 하고들 있죠.. 그도 아닌 중소 회사들은 전혀 체계가 잡히지 않은 문서관리를 하고 있기도 합니다.

그럼, 웹사이트를 제작하는 프로젝트에서는 어떤 문서들을 정리하고, 저장해 두어야 할까요?

1) 계약관련문서


프로젝트에는 대부분 계약서가 있죠. 특히 의뢰를 받은 경우는 당연하겠지요. 계약서는 가장 중요한 문서중에 하나입니다. 클라이언트와의 논쟁이 발생하면, 분쟁해결의 근간이 되는 문서입니다. 이 문서는 대부분 보관을 하시겠지요.. 또하나 덧붙인다면, 견적 및 제안서등을 보관해 두는 것이 좋습니다. 사이트를 제작하다보면, 계약이전에 상담 또는 영업시, 아님 견적서에 들어간 내용들에 대한 언급이 많이 발생하게 되죠..

2) 기획관련문서


사이트를 기획하면서 발생되는 문서들, 사이트 구조도, 사이트 맵, 스토리보드, 플로우챠트등이 보관되어야 합니다. 이는 추후 사이트의 업데이트에도 중요한 문서가 되며, 회사의 노하우를 축적한다는 의미도 있습니다. 그리고, 프로젝트가 끝나고 기획문서를 포함하여 제출해야 하는 경우도 있죠..
이런 기획문서들이 클라이언트(의뢰자)의 승인을 받은 경우라면 계약서에 버금가는 중요한 문서가 되기도 합니다. 사실, 웹사이트라고 하는 것이 계약단계에 사이트의 하나하나 모든 것을 지정할 수가 없기 때문에 개발이 진행되면서 차차 승인을 받아가게 되는 데, 이때 승인 받은 기획문서들은 추후 사이트의 오픈시 의뢰자와의 마찰을 줄일수 있는 문서가 되기도 합니다.

3) 의사전달문서


웹사이트라고 하는 것이 대략의 안을 가지고 시작하는 경우가 많고, 상품자체가 차차 완성되어 가다 보니 의뢰자와 중간중간에 많은 이야기가 오고가게 되고, 그에 따라 계약시와 비교하여 많은 부분 변경이 이루어지게 됩니다. 이런 사이트를 계약서에만 의존하여 분쟁을 해결하기가 정말 힘든 경우가 많지요.. 팩스와 메일을 프린트하여 보관하고, 전화로 통하를 한경우는 통화내역을 요약하여 정리해 두고, 만나서 회의를 한경우는 회의록을 만들어 두는 것이 좋습니다. 경우에 따라서는 회의록이나 유선통화내역정리 문서들을 의뢰자에게 보내어 승인을 받아두기도 하죠...

이런 문서들은 프로젝트의 리스크를 많이 줄이는 데 기인하게 됩니다. 조금은 귀찮고 힘들지만, 나중에 크게 문제가 될 부분을 줄여나간다는 측면에서 반드시 필요한 작업이라는 것을 기억해 두시기 바랍니다.

그리고, 모든 문서는 추후에 찾기 쉽도록 문서넘버를 정리하고, 철하여 두는 것이 좋습니다.
정말 귀찮고 힘든일이지만, 이런 일들이 몸에 베고 근간이 되어야 훌륭한 프로젝트 관리자가 될 수 있답니다..

 

3. 리스크관리

 

사이트를 의뢰받아 만들다 보면, 정말 여러가지 이유로 인해 문제들이 발생하고 또, 이런 문제들 때문에 사이트 제작 기간이 늘어나거나, 일이 중복되거나, 처음보다 더 많은 인력이 투입되거나 심지어 사이트 제작을 포기해야하는 상황들이 발생하곤 합니다.

이럴때 많은 사람들이 "그건 어쩔 수 없는 일이었어" 라든가 "운이 나빴지" 라든가 혹은 사이트 의뢰자의 잘못이라면 그곳을 욕을 하기도 합니다.

하지만, 적어도 프로젝트 관리를 하는 사람이라면, 그런 일들을 최소화하도록 노력하고, 불가항력적인 일이 일어난다고 해도, 그일에 대해 피해를 최소화 할수 있는 방안들을 마련해 두어야 합니다.

사이트를 여러번 만들다 보면, 정말 재수없어서 발생한 일이라고 생각했던 일들이 이따금 일어난다는 사실을 알게 됩니다. 예를 들어, 의뢰자가 도산을 한다거나, 제작하던 컴퓨터의 하드디스크가 박살난다거나, 뭐 사무실에 홍수가 난다거나 등등.. 그럼 과연 이런일들을 막을 수 있단 말인가요? 어떻게 보면, 불가항력처럼 보이는 일들이죠.. 작게는 디자이너나 프로그래머가 갑자기 아프다거나, 상을 당했다거나, 사고를 당할 수도 있죠.

경험이 조금 많은 사람이라면, 어떤 요인들이 사이트 제작에 위험요소로 작용하는 지를 알고 이 요소들에 대한 리스트를 작성할 수 있을 것입니다.

예를 들어볼까요?

1. 인력에 대한 리스크
2. 고객에 대한 리스크
3. 예산에 대한 리스크
4. 재난에 대한 리스크
5. 기타 리스크

이처럼 리스크 군을 나눈 후에 그안에 세부적으로 위험요소가 될 수 있는 사고들을 적어넣습니다. 그리고, 그 일들이 일어나기를 막을 수 있는 방법들과, 그 일이 일어났을 때 대처해야할 방법들을 적어 놓습니다. 그리고, 생각지 못했던 위험사고들이 생겨날때마다 업데이트하여, 사이트 제작에 방해되는 요소들을 미리 준비해 두는 것입니다.

예를 들어 사무실이 홍수가 잘나는 지역에 있다고 가정해 보고, 만일 어느여름 비가 무지 많이 와서 사무실이 홍수가 나 컴퓨터가 모두 물에 잠긴 상황을 리스크로 잡아 두었다면, 아마 그 프로젝트 관리자는 작업파일을 사무실 컴퓨터에만 백업해놓지 않고, IDC 센터나 백업 서비스를 이용한다거나, 집의 컴퓨터에 수시로 백업을 받겠지요.. 그러면, 이 리스크에 대해 안전해 지는 것입니다. 사실, 홍수가 나서 사무실 작업이 모두 날라갔다고 한다면, 그 모든 일을 처음부터 다시해야 하는 것을 당연하겠지요. 너무 황당한 예였나요? 하지만, 황당한 일이 일어나지 말란 법도 없지요..

또하나 예를 들어볼까요? 아주 어려운 프로세스인 작업이고, 자신의 회사에 아주 실력이 좋은 프로그래머가 있어 프로젝트를 수행한다면, 당연히 그 프로그래머의 인력공백은 엄청난 프로젝트 리스크가 될 수 있습니다. 물론 그 프로그래머 자신도 이 프로젝트가 끝날때 까지 열심히 일을 할 것으로 마음먹고 있다고 해도, 그 사람이 사고를 당하거나, 아님, 갑자기 다른회사에서 엄청난 제안을 해서 마음이 바뀔 수도 있구요.. 갑자기 아플수도 있지요.. 그럼 이런 경우도 리스크 체크리스트에 있다면, PM은 어느정도 그사람에 대한 관심을 가지게 되고, 막을 수 있는 일이라면 막고, 만일 그렇지 않다하더라도 아무 생각이 없이 있을 때보다 인력공백이 생길 시기를 조금은 빨리 알게될 가능성이 높아집니다. 그렇다면 대처할 시간이 조금 더 생기게 되는 것이요.. 아니면, 대체인력에 대한 대안을 미리 만들어 놓을 수도 있겠지요.

바로 리스크 관리란,, 모든 위험요소를 막겠다는 것이 아니라 최대한 위험을 줄이고, 또 위험이 일어날 일에 대해 미리 생각해 두고, 또 위험이 일어날 것을 조금이라도 미리 알수 있게 하고자 하는 것입니다.