기획자나 PM이 알아야 할 기술 지식들-문제제기

 

기획자나 PM이 알아야 할 기술 지식들(I) – 문제제기

 

비기술 계열 프로젝트 매니저의 호소

 

지금은 어느 정도 줄어들었지만, 외부 프로젝트로 해당 회사의 담당자를 만나면 흔히 겪는 현상이 있다. 발주회사 측에서 게이트웨이, 혹은 프로젝트 매니저 역할을 하시는 분들이 애로를 토로한다. 스스로의 분야가 기술 계열이 아닌데 솔루션 구입이나 구축 프로젝트를 진행하게 됐다는 불평아닌 불평이 섞인 말을 접하곤 했다.

 

이런 일은 Web Agency 성격의 회사에 근무하시거나 소프트웨어개발 회사에서 영업을 담당하시는 분들이라면 자주 겪는 일일 것이다. 특별히 기술 계열의 프로젝트가 아니라도, 광고나 마케팅 대행 등, 타 회사의 일을 대신 수행하는 에이전트 서비스 업종의 종사자 분들도 두 번에 한 번 꼴은 다 겪어 보셨으리라 짐작된다.

 

“이건 내일이 아닌데 왜 회사에서는 나에게 이런 일을 시킬까요”, 또는 “제가 이쪽으로는 문외한이니 잘 부탁 드립니다” 등, 그 반응도 참으로 다양하다. 그런데 솔직히 이런 말을 전하는 프로젝트 카운터파트는 만나기도 제일 꺼려질 뿐더러, 프로젝트 수행 기간은 그야말로 눈물의 세월이기 십상이다.

 

이야기를 쉽게 풀기 위해, 프로젝트의 성격이 전산 관련, 혹은 웹 관련인 경우에 한정 지어보자.

 

가장 훌륭한 프로젝트관리자는 누구일까?

 

결론부터 얘기하자면, 필자의 주관적인 의견으로 특정한 목적의 프로젝트를 가장 잘 수행할 수 있는 사람은 개발자(프로그래머, 엔지니어)가 아니라 그 업무를 가장 잘 알고 오랫동안 해당 현업에 종사한 사람이다. 이 말을 약간 달리 표현하면, 가장 좋은 솔루션은 정형화된 것을 구매하는 것이 아니라 직접 만드는 것이라는 얘기일 수도 있다.

 

물론 특정 분야 한 가지에만 매진해 온 스페셜리스트가, 다양한 프로젝트를 수행해 온 제너럴리스트보다 좀 더 빠르고 정확한 결과를 도출해낸다는 것에는 이의없다. 하지만 필자의 견해로는, 그래도 가장 훌륭하게 해당 프로젝트를 수행할 수 있는 사람은 개발자가 아니라 그 업무를 가장 잘 이해하고 있는 사람인 것이다.

 

예를 들어, 세무나 회계와 관련된 전산 프로젝트에서 가장 훌륭한 결과를 만들어낼 수 있는 사람은 재무 관련 현업에서 오랜 기간 종사해온 사람이고, 보험 관련 프로젝트는 보험 관련 업무에 경험이 많은 사람이 맞춤이다.

 

또 쇼핑몰을 예를 들자면, 범용적인 쇼핑몰 솔루션을 개발해온 회사가 발주된 쇼핑몰 설계의 주도자여서는 안되고, 쇼핑몰을 운영하려는 업체에서 오랫동안 근무하고 그 회사의 영업 관행이나 내규를 잘 아는 경력 사원이 가장 훌륭한 설계의 컨셉과 세부 구조도를 제공할 수 있다는 얘기이다.

 

즉, 표면적인 프로세스만 알고 있는 것이 아니라 각 업무, 업무의 이면에 숨겨져 있는 의미까지도 잘 아는 사람이 해당 프로젝트에서 핵심 역할을 맡는 것이 당연하다는 말이다.

 

솔루션은 솔루션, 웹사이트에의 궁합은 또다른 문제이다

 

여기서 잠시, 이런 의문이 들 수 있겠다. 왜 프로그래머나 엔지니어가 아닌 현업 담당자가 솔루션을 가장 잘 설계할 수 있단 말인가. 그럼 전문 솔루션 업체들이 만든 솔루션들은 제대로 된 솔루션이 아니란 말인가.

 

이에 대한 설명을 위해, 최근 컨텐츠 업종 뿐만 아니라 금융과 상거래 등 엔터프라이즈 레벨까지 그 영역을 넓혀가고 있는 CMS(Content Management System)를 한 예로 살펴보자.

 

대다수 CMS 솔루션의 공통점은 관리의 용이성과 운영상의 효율성, 그리고 성능상의 이점이다. 기능적 영역을 좀더 세부적으로 살펴보자면, 입력되는 각종 데이터의 저장과, 저장된 데이터로부터 만들어지는 Context 템플릿, 그리고 템플릿을 이용한 각종 HTML 컨텐츠의 제작 기능이 있다. 여기에, 자체 FTP 모듈을 이용한 실시간 배포 및 업데이트와, 이러한 일련의 일들을 기록하고 추적하는 Work Flow 관리 기능 등이 있다. 그밖에도 개발 회사별로 장점이라 내세우는 다양한 기능들이 있을 것이다.

 

문제는 솔루션의 성격이 정해지고 나서부터 본 게임이 시작된다는 데에 있다.

 

프로젝트의 성격상 CMS를 써야 한다고 결론을 내린다. 솔루션 도입을 위해 다양한 회사들의 자료 검토와 영업상의 미팅, 그리고 견적을 받고 일차 선정, 또 최종 선정을 위하여 BMT를 실시하는 등 다양한 과정을 거친다.

 

문제는 그런 공정하고도 객관적인 과정을 거쳐서 선정된 솔루션이라고 하더라도 해당 프로젝트의 목적을 100% 충족 시키기가 힘들다는 것이다. 솔루션 개발 회사는 당연히, 다양한 업종에서 사용될 것과 솔루션을 사용하게 되는 미래의 현업 담당자들의 편의성을 고려해서 최대한 많은 기능을 구현했을 터이다. 그러나 본 회사의 해당 업무를 단 1년도 겪지 않은 상황에서 미션을 100% 만족시키는 솔루션이란 있을 수 없다.

 

완품 솔루션의 납품 결정 과정에서부터 고난은 시작된다

 

CMS 얘기를 했으니 CMS를 가장 많이 사용되는 신문사를 실례로 들어보자.

 

각종 DATA를 조합, 가공하여 하나의 정보로 만들어 사용자들에게 제공하는 것은 대부분의 신문사가 가지고 있는 업무의 큰 틀이다. 하지만 이 큰 틀을 세부적으로 파고 들어가다 보면 각 신문사마다 저마다의 업무 프로세스가 있을 것이다. 기사 마감 시간도 저마다 다 틀릴 것 이고 각 기사의 종류 마다 채워야 하는 양도 틀린다. 또, 동일한 성격의 정보라도 그 중요도는 해당 신문사의 논조별로 틀려지기 일쑤다.

 

즉, 아무리 기능이 많고 뛰어난 성능을 보이는 솔루션이라고 할지라도 특정 신문사의 업무에 가장 잘 부합이 되는 CMS를 만들기 위해서는 결국 해당 신문사 고유의 업무 특성에 맞게 뜯어 고치거나 기능을 새로이 추가하는 상황은 불가피하다는 말이다. 이런 상황이라면 제 아무리 뛰어난 능력의 개발자라 할 지라도 기능의 설계나 디자인에 대한 컨셉에 있어서는 그 신문사에 1년 근무한 신참 기자보다도 못할 수 밖에 없는 것이다.

 

하지만 어떠한 종류의 솔루션이건 간에, 클라이언트 쪽의 비기술 계통인 담당자는 자기의 골치 아픈 문제를 한번에 해결해 줄 솔루션을 찾을 것이다. 또, 해당 솔루션 영역의 회사 영업 담당자는 당연히 자사의 솔루션이 상대의 문제를 한번에 해결해 줄 수 있다고 사전 영업 단계에서 계속적으로 유혹을 할 것이다.

 

저마다 기능면에서 최고를 주장하고 온갖 화려한 기술 용어가 눈앞에서 휙휙 날아다니며 TCO 뿐만 아니라 ROI 측면에서도 자사의 솔루션은 최고라고 얘기한다. 업종을 불문하고 영업사원 최고의 무기가 마구 사용되는 시기가 바로 이 때일 것이다.

 

“저희 회사 제품이 최고 입니다”, “타사 대비 50%의 비용 및 시간의 절감 효과가 있습니다”, “네, 가능합니다. 문제 없습니다”, “도입전과 비교하였을 때 최소 o o %의 업무 능률이 향상 됩니다”, 등등. 한편 생각해보면, 레퍼런스 사이트와 매출 외형에 목말라 하는 IT 기업 영업맨들에게 어쩌면 이런 과정은 참으로 서글프다 아니할 수 없다.

 

그렇다면 비기술 계통 PM이 알아야 할 개발적인 지식들은?

 

이런 열악한(?) 상황을 직면하고, 기술적인 지식이 전혀없는 프로젝트 담당자가 취해야 할 태도는 과연 무엇일까. 또 사전에 가지고 있어야 할, 혹은 기습득하고 있어야 할 지식은 무엇일까. 프로그래밍이나 시스템 엔지니어링 상의 용어나 기초적인 지식도 없이 어떻게 현업 담당자가 가장 뛰어난 솔루션 설계자가 될 수 있다는 말인가. 여기까지 글을 읽으신 분들은 당연히 이런 의문점들을 가지시리라 본다.

 

그렇다면 과연 이러한 상황은 IT 업계에 종사하는 동안은 피할 수 없는 것일까? 도저히 사람의 힘으로는 해결을 할 수 없는 것일까? 다음 번엔 왜 현업 당사자가 가장 훌륭한 솔루션 개발자여야 하는가에 대한 좀 더 실질적인 이야기를 풀어나가도록 하자

 

 

 

기획자나 PM이 알아야 할 기술 지식들(II) - 커뮤니케이션 불통

 

두 번째로 칼럼을 풀어나가기에 앞서 여러분들께 먼저 몇 가지를 밝혀 두고자 한다.

 

이 글을 쓰는 사람은 엔지니어 및 개발자 출신이며, 이 칼럼을 쓰는 목적은 문과와 이과의 벽을 조금이라도 허물자는 의도에서이다. 즉, 비기술계열의 기획자나 PM들이 이들 기술자들과 교감을 이뤄내 프로젝트를 원활하게 진행할 수 있도록 하기 위함이다.

 

지난 주 칼럼에 관하여 한 회원 분께서, 프로젝트 진행에서 업무 사항 분석 시 가장 큰 문제점이 고객 자신 스스로 자신의 요구사항에 관하여 명확하게 모른다는 점임을 지적해 주셨다. 이 말씀에 아마도 PM 역할을 해보신 많은 분들, 특히 개발자나 엔지니어 출신으로 PM 생활을 해보신 분들은 대부분 공감하시리라 본다.

 

그렇다. 프로젝트 진행 시에 가장 핵심적으로 떠오르는 문제는, 개발을 요구하는 주체가 구현하고자 하는 기능이나 프로젝트의 목적에 관하여 무엇을 생각하고 있는지를 구현 주체(개발자나 엔지니어, 또는 디자이너)에게 어떻게 이해시키느냐일 것이다.

 

아니 좀 더 정확히 얘기하자면, 구현 주체와 의사소통에 들어가기 전에 해당 프로젝트에 대해 기획자 스스로의 머리 속에 어떤 방식으로 정의(Definition)를 하고 있느냐일 것이다. 그것도 기술자들을 이해시킬 만한 아주 “비추상”적인, “구체”적인 언어로.

 

커뮤니케이션 불통은 프로젝트 협업자들간의 문제만이 아니다.

 

언어나 용어의 문제는 프로젝트 진행상에 항상 최고의 장벽으로 작용한다. 이들 기획자나 PM들이 전문 개발자나 엔지니어가 아닌데 어떻게 자신의 머리 속에 있는 내용을 지칭하는 용어나 언어가, 협업 카운터파트인 기술자들의 언어와 매우 다르다. 그런데도 그들이 이해할 수 있는 언어로 구체적인 산출물로 만드는 것은 정말 불가능한 걸까?

 

실례로 비기술 기획자나 PM들은 기술적 언어들인 3Tier가 뭔지, MiddleWare가 무슨 역할을 하는지, Transaction 정합성 추구가 무슨 의미인지 알 수가 없다. 즉 양측이 서로 같은 한국말을 하고 있지만, 마치 다른 나라 말을 듣는 것 같아서 심한 경우엔 구성원 간에 괴리감마저 발생하는 일은 둘째치고, 서로 이국적인 언어를 구사하는 통에, 원활한 프로젝트 진행의 핵심 요건인 커뮤니케이션 자체가 이뤄지지 않는 것이다.

 

그럼 우선, 언어가 다른 이들이 의사불통 속에 진행한 프로젝트가 어떤 프로세스와 결과를 만들어내는지 보자.

 

글을 쓰는 사람을 비롯하여 여러분들은 알게 모르게 IT 기반하의 시스템을 개발하여 사용해 왔다. 재밌다고 해야할까, 침통해 해야 할까, 그런 시스템을 개발했던 프로젝트의 최종 결과가 초기의 목적했던 바와 상이한 경우가 발생되는 일이 허다하다.

 

또한 여러분들이 공감(?)하시고 계실 터, 현재 개발되어 있는 많은 시스템들이 100%, 사용자의 요구를 완벽하게 충족시키지 못하고 있을 것이다. 사용할수록 품질에는 만족을 못하게 되고 성능과 효과는 기대치에 미치지 못하며 총소유비용은 날이갈수록 늘어만 간다.

 

바벨탑, 동상이몽, 산으로 가는 배 - 모두 의사불통의 결과다

 

이러한 현상이 자주 발생하는 주된 원인은 프로젝트 진행 초기에 목적 및 그 목적을 달성하기 위한 세부 미션들이 잘 정의하지도 않았을 뿐만 아니라, 최종 의사 결정권자들이 바라는 것을 어떻게 해서든 단기간 내에 프로젝트 내에 달성하고 관철시키려 하는 것이 최우선 목적이다시피 해왔기 때문이다. 즉 “선 납품 후 보완”하는 사고방식 내지는 관례.

 

어떠한 종류의 Solution이든 간에 기업에서 IT를 도입하는 이유를 생각해보라. 업무 진행에 있어서 좀 더 효율적이고 저 비용으로 경영활동을 지원하고자 함인데, 그 저비용 고효율을 목적으로 진행한 프로젝트가 종국에 더 불편하고 비용만 많이 드는 경우가 빈발하는 것이다.

 

즉 업무에 맞춰 솔루션을 구축하는 것이 아니라 솔루션에 맞게 업무 체계를 바꿨기 때문이다. 그것도 구성원들(실관리자들 또는 소비자들)의 온갖 불평과 원망을 들어가면서 말이다. 물론 나중에 가서는 BPR이라는 그럴 듯한 이름으로 덮어 버리기도 하겠지만.

 

이 모든 것이 초기부터 시스템 개발의 명확한 목적 및 세부 목표, 그 시스템 프로세스 상의 세목에 대한 합치된 의견 교환이 선결돼있지 못했기 때문이다. 첫단추가 잘못된 것은 그 이후로도 반복된 잘못을 낳아, 공기만 맞추려는 건설업자의 행동과 유사한 줄달음질 속에 목적과 결과의 간극은 멀어지게 된다.

 

이해와 배려를 기반으로 하는 부지런한 커뮤니케이션은 기초 중의 기초인 의지

 

성공적인 프로젝트 진행을 위하여 사람들마다 내세우는 중요도가 저마다 다 틀린데, 그 중에서도 커뮤니케이션과 일정관리가 가장 중요하다고 말하는 사람들을 많이 보아왔다. 물론 그 말에 반대를 하는 것은 아니다. 이들의 말을 인체의 관점으로 풀면 혈액의 순환과 신경계통에 비유를 할 수 있을 것같다.

 

그렇게 프로젝트의 참여자들 간의 커뮤니케이션이 중요하다고 하지만, 비기술 계열의 프로젝트 책임자 입장에서는 어떻게 해야 할지 그저 막막하기만 하다. 자기가 가진 지식을 동원하여 어떻게 목적하는 바를 구현 주체에게 이해시킬까 하는 생각 자체가 두려움이다. 심한 경우엔 나는 영어로 얘기하고 상대는 중국말을 하는 듯한 느낌의 상황도 벌어진다.

 

이런 상황으로부터의 뒷걸음질은 하등의 도움이 안된다. 비기술 계열 PM들에게 권고컨대, 여러분은 그런 상황을 두려워하거나 회피하지 말았으면 한다. IT 프로젝트든 비IT 프로젝트 든 간에 그러한 상황은 피할 수 없음을 우리 스스로 너무도 잘 안다.

 

여기서 삐뚤어나가, 문과가 우월하다느니 기술자없이 무엇을 할 수 있냐느니, 구성원 간의 이런 불필요하고 소모적인 논쟁도 피하자. 관건은 상호간의 의견을 얼마나 받아들이고 이해하려 하는가하는 의지, 즉 커뮤니케이션이라는 행위를 실제로 이행하는 것이라고 본다.

 

여기까지 쫓아오신 여러분께 또하나의 딴죽을 걸자. 자 이제, 이 커뮤니케이션의 의지만 있으면 만사형통일까? 구체적으로 들어가서, 그 커뮤니케이션 행위 이전에 선행되어야 하는 것은 없나? 이에 대해 검토해보자.

 

커뮤니케이션 의지 발휘의 전단계 : 철저한 정보 스캔의 중요성

 

정확한 이름은 기억이 나질 않지만 어떤 정보학자가 말하기를, 본인이 필요로 하는 정보의 80%는 그 사람 주변에 몰려 있고 단지 그것을 보고 있지 못하고 있을 뿐이라고 한다. 그리고 그 이유를 기술의 발달로 인한 정보의 홍수 때문이라고 전한다.

 

그 수많은 정보 속에 기술 상대자와 원활한 의사교환을 할 재료들이 있다. 이를 기반으로 상대와의 이해를 도모하려는 의지를 가지고, 이 재료들을 우선적으로 주의 깊게 모아나가는 과정을 보도록 하자.

 

흔히들 IT를 기업 활동에 적용을 시키면서, 프로세스나 로직은 굉장히 중요시하면서도 데이터는 등한시하는 경우를 많이 봐왔다. 대기업들이 앞다투어 추진하고 있는 ISP(Information Strategy Planning : 경영전략수립)와 BPR(Business Process Re-engineering : 경영과정재설계)을 기반으로 하는 대형 SI 프로젝트에도 프로그램 통합 또는 시스템 연동에만 집중하고 있지, 데이터에 대해서는 별로 중요하게 생각하지 않는 것같다.

 

프로세스를 정립하고 최적화하는 방법을 생각하기 전에, 우선 데이터(혹은 단편적인 팩트)를 먼저 중요시 하는 작업이 선행되어야 한다. 그리고 그 수집된 데이터들을 가지고 어떠한 형식이든 좋으니 지도를 한번 만들어 보시기를 바란다. 프로세스 순서도 또는 로직 차트를 만들듯이.

 

그리고 여기서 말하는 지도는, 흔히들 얘기하는 DBMS 상의 데이터 모델링이나 ERD(Entity Relationship Diagram : 객체관계도)를 얘기하는 것이 아니다. 차라리 사이트 맵을 연상하시는 것이 더 낫겠다. 데이터 A,B는 기획팀, 데이터 C,D는 홍보팀 이런 식으로 말이다.

 

구체적인 실체를 대상으로 한 사고 구조도의 구축 필요성

 

이 지도 상에 수집된 데이터를 기반으로 한 데이터들 간의 어떤 체계가 수립이 되면, 그 다음 단계로 그것을 다시 프로젝트의 각각의 미션들에 하나씩 Mapping 시켜보도록 하자. 이러한 과정을 거치고 나면 프로젝트의 목적이 보다 더 구체적이고 명확해져 있을 것이다.

 

즉 자기(또는 프로젝트의 주제 또는 목적)를 중심으로 범위를 점점 넓혀 나가면서 정보를 스캔(수집)해 나가다 보면 좀 더 프로젝트의 모습과 나가야 할 방향이 명확해 질 것이다.

 

그리고 이러한 과정을 거치고 난 그 다음에, 구현 주체와 커뮤니케이션을 시도해도 해야 할 것이다. 물론 거기에는 앞서 말한대로 상대의 입장과 상황을 이해하는 배려심이라는 것이 선행이 되어 있어야 할 것이겠고.

 

여기서 지적하는 바는, 대다수의 프로젝트 진행이 입담좋은 유기적, 원활한 의사소통, 커뮤니케이션의 중요성을 당위적으로 외치고 있지, 선행되어야 할 이러한 조사의 중요성은 등한시하고 있는 것 같다는 점이다.

 

정보 계층도를 예로 들자면, 단편적인 Data가 모여서 Information이 되고 이러한 Information을 좀더 가공 하거나, 혹은 또 다른 Information과 합하여 만들어지는 것이 Intelligence이며 그 Intelligence를 실행 또는 활용하는 것이 결국 우리가 흔히 말하는 CRM이다.

 

즉 기업 행위를 위한 모종의 Intelligence를 달성하는 것이 우리가 진행하려는 프로젝트의 목적이라면, 결국 그 출발도 하나의 데이터(단편적인 사실)에서 시작해야 순조롭고 달성도도 높다.

 

언어는 달라도 생각의 대상이 같으면 그만큼 의사소통은 가까워진다

 

기술적인 지식을 가지고 있든 없든, 프로젝트의 성공적인 완성을 위해서 원활한 커뮤니케이션은 당연히 중요하다. 또 그 커뮤니케이션의 가장 중요한 목적은 기획자와 개발자의 생각을 100%에 가깝게, 최대한 동기화 시키는 것이다.

 

그렇다면 그 동기화율을 높이기 위해서는 비기술적 언어라도 좋다. 사고의 구조도만이라도 유사해지게끔 하려는 노력이 필요하다. 개선돼야 할 업무의 개체를 작은 것에서부터 면밀히 쌓아놓고 이를 프로젝트에 맵핑시키는 행위는 당연히 선행돼야 한다. 그 과정이 기술자들의 IT 기술 언어와 가까워지는 초석이다.

 

물론 이 모든 것들 중에 가장 중요한 것. 그것은 상대에 대한 이해와 배려이다. 인간은 어찌됐든 감정의 동물이다

 

 

기획자나 PM이 알아야 할 기술 지식들(III) - 방법론들

 

지금까지는 짧게나마(?) 여러분들과 같이 공감대를 형성하면서 현 상황을 진단해 보는 시간을 가졌으니, 금주부터는 보다 더 실질적인 내용들을 공유하는 시간을 가져볼까 한다.

 

전 칼럼의 마지막과 TalkBack의 답글에서 금주에 다룰 주제를 기획자 등이 지녀야 할 시스템적 사고라고 밝혔다. 그런데, 먼저 양해를 구해야겠다. 본격적으로 이 주제를 다루기에 앞서, 먼저 다양한 프로젝트 진행(혹은 컨설팅, 혹은 시스템 개발)상의 방법론들을 살펴야할 필요성을 느꼈다.

 

다양한 프로젝트 진행 방법론에서 공통적인 처음 단계가 ‘진단’ 또는 ‘분석’ 단계이고, 이 단계에서 시스템적 사고가 가장 많이 필요하게 되기 때문이다. 또한 어떤 방법론을 적용하건 간에 전체 절차를 여러분들의 머리 속에 먼저 그려두는 것은, 전반적인 프로젝트 진행 도중에 여러 가지 면에서 도움이 될 것이라는 판단 때문이다.

 

현재 IT 분야에서는 다양한 프로젝트 진행 방법론이 존재하고 있고 각각의 방법론들마다 상이한 절차와 수행 방식 등이 존재 하지만, 이들은 모두, 조직(또는 업무)의 변화와 정보공학 방법론(Information Engineering Methodology)이 수반된다는 공통점이 있다.

 

조직의 변화는 현재의 경영활동을 보다 더 효율적으로 수반하고자 하는 경영진의 의지가 반영되는 것이고, 정보공학 방법론은 IT 시스템의 계획뿐만 아니라 개발 전체에 대한 방법론을 포함하기 때문이다.

 

본 칼럼에서 소개하고자 하는 방법론은 지금까지 필자가 현업에서 직,간접적으로 접해온 것을 소개하는 것이다. 그리고 세부적인 소프트웨어 개발 방법론은 제외하고 프로젝트 진행이란, 약간은 넓은 범위의 방법론만을 살펴보려 한다.

 

이 방법론들 중 현재 IT 관련 산업에 종사하시는 기획자들의 현 실정에 어떠한 것이 맞는 것인가, 그리고 가장 적합한 프로젝트 수행 방법은 무엇인가를 여러분과 같이 고민했으면 한다. 오늘 제시하는 것 이외에 다른 프로젝트 진행 방법론을 아시는 회원은 주저하지 말고 글에 대한 반론이나 방법론을 소개해 주시기 바란다.

 

더불어, 비기술 계열의 회원들을 고려하여 MIS, SIS, 그리고 정보공학 등의 개념을 여기서 설명할 수도 있겠으나 그러기에는 지면도 부족할 뿐더러 여러분이 원하는 실질적인 내용과는 다소 거리가 있다. 관심이 있으신 분들은 관련 원서나 대학교재 등을 참고하시길 권하고 싶다.

 

그럼, 오늘의 주제인 프로젝트 진행 방법론들에 대한 간단한 리뷰로 바로 들어 가도록 하겠다

 

콜프/프로만 방법론 (Kolb/Frohman Model, 1970)

 

이 모델에서는 경영 활동을 성공적으로 혁신하기 위하여 그 혁신의 과정을 일곱 단계로 나누고 있다. 이 모델은 그  혁신의 과정 중에, 각각의 단계별로 프로젝트를 진행하는 담당자와 실제 사용자 사이의 적절한 관계 형성을 중시한다. 좀더 구체적이고 실질적으로 표현하자면, 이는 시스템 설계자(또는 분석가 또는 개발자)와 사용자의 공감대 형성이라고 할 수 있다.

 

각 과정은 아래와 같다.

 

1. 조사(Scouting): 프로젝트 진행 주체와 사용자가 상호간의 요구 사항과 업무 결과를 평가하여 착수 시점을 결정하는 단계
2. 착수(Entry): 문제, 목표, 목적 등에 대한 각각의 정의를 하고 상호간의 의견 일치점을 도출하고 프로젝트 진행 자체에 대한 필요성을 보다 더 확실히 하는 단계
3. 진단(Diagnosis): 착수 단계에서 정의한 문제, 목표, 목적을 정의하기 위한 자료 수집 및 현재 이용 가능한 자원을 평가하는 단계
4. 계획(Planning): 구체적인 미션을 정의하고 미션을 달성하기 위한 솔루션과, 이 솔루션이 조직(현업 부서의 실 사용자)에 미치는 영향을 평가한 뒤 실질적인 액션 플랜을 수립하는 단계
5. 행동(Action): 계획 단계에서 수립한 솔루션을 개발하는 단계
6. 평가(Evaluation): 행동 단계에서 개발한 결과들을 평가, 즉 목적이 얼마나 달성되었는지를 평가하고 향후 계속적으로 발전시켜 나갈 것인지 중지시킬 것인지를 결정하는 단계
7. 종료(Termination): 새로이 개발된 솔루션을 확인하고 개발된 솔루션의 소유권(또는 사용권)을 실제 사용자에게 완전히 이양하는 단계

 

만약 이 글을 읽는 회원이 웹에이전시에 근무하시는 기획자라고 가정을 한다면,

 

1번이 아마도 사전 영업 내지는 클라이언트와의 첫 대면 단계일 것이고, 2번은 프로젝트 참여 여부를 결정하는 단계, 혹은, 참여를 결정했다면 제안 또는 제안 내용에 대한 설득의 단계일 것이다. 3번은 솔루션(또는 사이트)을 개발하기 위한 데이터를 수집하며 기본적인 업무 구조(조직)를 형성하는 단계이다.

 

4번은 개발 계획 및 솔루션을 설계하는 단계라고 할 수 있을 것이다. 이 단계에서는, 5번의 행동 단계에서 어떤 식으로 행동할 것인가에 대한 좀 더 구체적인 소프트웨어 개발 방법론이 채택된다. 즉 개발자나 엔지니어들이 얘기하는 CBD(Component Based Development, 콤포넌트 기반 개발 방법론) 또는 OOP(Object Oriented Programming, 객체 지향 프로그래밍), Method/1 같은 용어들이 이 단계에서 본격적으로 거론이 된다.

 

5번은 실질적인 Implementation(개발) 단계이고, 6번 단계에서는 일차적으로 완성된 솔루션(또는 사이트)에 대한 테스트 및 디버깅이 이루어지고 실 사용자와의 커뮤니케이션을 거친 뒤 부분적인 Customizing이 적용된 후 최종 납품(7번)이 이루어지게 된다.

 

국제노동기구 방법론 (ILO Model, 1996)

 

국제노동기구(ILO)의 주관으로 정리된 이론들을 정리한 것이며, 흔히 ‘밀란 모델(Milan Model)’이라고 칭하는 방법론이다. 국내에 있는 여러 컨설팅 회사에서 이 방법들을 적용 또는 변형하여 많이 사용하고 있고, 몇몇 SI 회사에서는 이 방법론을 기본으로 채택하고 있다.

 

이 방법론은 경영 분야의 업무 혁신에 초점을 두고 있고, 각 단계가 끝날 때마다 사용자(또는 클라이언트)의 피드백 및 승인을 획득하도록 돼있다. 필자의 개인적인 생각으로는 ‘갑(클라이언트)-을(구축자 혹은 개발회사)’ 관계에 있어서 다소 ‘을’의 입장이 많이 들어간 방법론 이라 할 수 있다.

 

이 방법론이 적용된 단계는 크게 5가지로 나뉘어 진다.

 

1. 착수(Entry): 프로젝트 진행 주체와 실 사용자의 대면 및 예비 진단이 이루어 지는 단계로서 사용자와의 인터뷰, 예비 문제 진단, 프로젝트 수행 계획 수립 및 제안 등이 수행되는 단계이다. (더불어 갑과 을의 관계라면 계약 체결도 이 단계에 포함된다.)
2. 진단(Diagnosis): 사용자(또는 의뢰인)이 직면한 문제점에 대한 원인 규명과 이를 해결하기 위해서 구축해야 할 솔루션에 필요한 보다 더 깊이 있는 자료 수집이 이루어 지는 단계이다.
3. 계획(Planning): 진단 단계에서 파악한 문제점과 솔루션을 개발하기 위한 실행 계획을 수립한다. 해결 대안 개발, 대안에 대한 평가 및 실행 계획 수립 등의 세부 단계가 있으며 이 단계에서 대부분의 문서화 작업이 이루어 지게 된다.
4. 구현(Implementation): 수립된 계획에 따라 변화를 유도(또는 솔루션을 개발)하는 단계이다. 또한 이 단계에서 솔루션에 대한 평가, 테스트 및 조율(Customizing)도 같이 실행된다.
5. 종료 (Termination): 프로젝트 완료 결과에 대한 의사결정권자(또는 경영진)의 승인을 획득하는 단계이다. 수행 결과에 대한 최종 평가 및 보고서 작성, 경영층의 승인 획득, 유지 보수 계획 수립 등이 이 단계에서 이루어 진다

 

지금까지 프로젝트 전체를 진행하는 방법론 두 가지를 살펴보았다. 기타 여러 방법론이 존재할 것이고 In-House 스타일의 방법론을 적용시키는 경우도 있을 것이다. 아이비즈넷의 경우, 위 두 가지 방법론을 상황에 맞게 적절히 섞어서 쓰고 있다. 여러분들의 피드백과 함께 계속적으로 풀어나가게 될 내용도, 위 두 방법론의 각 단계를 현업에서 어떤 식으로 처리해나갈 것인가에 대한 이야기가 될 것이다.

 

이어, 다음에 소개하는 두 방법론은 프로젝트 진행 방법론 중에서도 실행 및 개발의 비중은 약하지만 전략 수립에 좀더 중점을 두고 있는 방법론들이다. 흔히 얘기되는 ISP(Information Strategy Planning, 경영전략수립 또는 정보전략계획수립)의 방법론이라고 생각하시면 된다.

 

이 프로젝트의 산출물(정확히는 컨설팅 결과 보고서)를 기반으로 하여, 좀 더 세부적으로 BPR(Business Process Re-engineering, 경영과정재설계)을 진행하거나 ERP(Enterprise Resource Planning, 전사적자원관리, 대표적으로 SAP를 생각하시면 된다) 같은 솔루션을 도입(또는 개발)하게 된다고 생각하시면 된다.

 

그리고 꼭 이 방법론을 전략 수립에만 활용한다고 생각하진 말기 바란다. 방법론을 적용시키는 주체가 동 방법론을 어떤 관점에서 보느냐에 따라 충분히 위 두 방법론을 대체할 수 있다.

 

한국능률협회컨설팅 방법론

 

현재 한국능률협회에서 다양한 분야별 주제로 제공하는 컨설팅 서비스에서 기본적으로 적용하는 방법론이다. 사실 필자 자신도 아래에 소개하는 방법론을 가지고 프로젝트에 참여한 적은 없고, 2000년 경에 프로젝트 진행을 하면서 알게된 지인께서 공부 삼아 보라고 주신 문서를 여러분과 공유하는 것이며, 필자 나름대로 정리한 것을 소개하는 정도로 그치겠다.

 

이 방법론이 타 방법론과 차별화 되는 특징은 주어진 데이터를 근거로 해서 시뮬레이션을 해보는 과정이 있으며, 프로젝트 진행에 있어서 업무 성과, 자원(인적, 물적), 조직 운영 방법, 업무 프로세스, 갈등 구조라는 5개의 항목을 주로 다루게 된다. (혹시 이 글을 보시는 분들 중 해당기관에 근무하시는 분께서 계시다면 필히 톡백을 달아주시기를 부탁 드린다. 2000년 말의 자료라서 지금과는 조금의 차이가 있으리라 짐작이 된다.)

 

1. 팀 형성과 프로젝트 계획 수립

: TFT 형성, 프로젝트 계획 수립, TFT 구성원의 평가 및 훈련 등의 일들이 이루어 지는 단계

2. 현황 분석

: 업무성과, 자원 평가, 조직 운영 및 업무 프로세스 상의 문제점 및 프로젝트에 필요한 각종 데이터를 수집하는 단계

3. 가설 설정 및 가설 검증

: 2번째 단계에서 수집된 데이터를 근거로 다양한 케이스를 만든 후 발생하는 문제점의 원인을 분석하고 검증하는 단계. 즉 현재의 시스템을 가지고 정형화된 업무 외에 다른 업무 사례를 적용을 시켜 그 결과를 보고 어떠한 문제점이 발생하는가를 시뮬레이션해보는 단계

4. 해결방안 수립

: 5개 항목의 제약 조건하에서 도출될 수 있는 해결 방안을 도출및 검증한 뒤 채택.

5. 실행계획 수립

: 4번 단계에서 채택된 해결방안을 실제적으로 적용하기 위한 계획을 수립하는 단계

6. 실행: 필요한 솔루션의 개발, 모니터링, 평가, 피드백 및 수정

 

IBM의 BSP (Business System Planning)

 

이어 제시하는 IBM의 BSP 방법론은 흔히들 얘기하는 Top-Down 분석과 Bottom-Up 개발을 결합시킨 방법론이다. 이 방법론은 IBM에서 상향식 계획과 하향식 계획을 적절히 조율하여 만든 전략 수립 방법이다.

 

그 두드러지는 특징은 현업 사용자들의 적극적인 참여를 요구하는 것이다. 단점은 계획 과정을 너무 중요시 하다 보니 프로젝트를 진행해 나갈수록 정확도가 떨어지고 흔히들 하는 말로 “생각하다가 세월 다 보내”는 경우가 자주 발생한다. ISP 수립에 참여해 보지 않으신 분들은 용어 등이 다소 생소할 수 있으나, 차분히 읽어 나가시면서 본인이 현재 처해있는 상황은 어디일까를 생각해 보시기 바란다.

 

크게 6개의 단계로 나누어진다.

 

1. 준비: 최고 경영진의 지원 획득, 자원 확인, 단계별 실행 계획서 작성, 프로젝트 구성원의 교육 등이 이루어 지는 단계

2. 경영전략 모델 수립: 조직의 장기, 단기 목표 설정, 목표 수립에 있어서의 장애 요인 설정, 목표에 대한 우선 순위 설정 등이 이루어 지는 단계. 이 단계에서 여러분들이 자주 접하는 SWOT 분석, 포터의 5F (Five-Force) 모델, 가치 사슬 같은 용어가 적용된다.

3. 기업 모델 구축: 길거리에서 흔히 접하는 모델 하우스를 제작하는 단계라고 생각하시면 된다. 현업 부서의 실무자의 인터뷰나 리서치가 이 단계에서 다양한 형태로 실행되며, 이를 근거로 하여 조직의 여러 가지 실체들을 객관화 내지는 단순화시켜 TFT 내에서 표준화된 용어로 혹은 기호로 만드는 단계이다. 사업 기능 모델링, 데이터의 그루핑 및 모델링, 기업 목표와 조직 목표의 연계성 검증, 사업 기능과 조직 구조와의 연계성 검증 등이 이 단계에서 이루어 진다. 또한 이 단계에서부터 테크니컬 베이스의 인력이 본격적으로 투입이 된다.

4. 현 시스템 분석: 말 그대로 현재의 시스템을 분석하고 평가하는 단계이다. 단 평가를 하는데 있어서 3번째 단계에서 도출된 여러 가지 항목들을 적용시켜서 평가를 해보고 미래의 시스템을 구축하는 데 있어서의 근거 자료를 산출해 낸다.

5. 전략적 기술 모델 구축: 4번째 단계와 비교를 하자면 향후 어디로 갈 것인가를 결정하는 단계라고 할 수 있다. 방식의 차이를 비교를 하자면 3번째 기업 모델과 비교를 할 수 있는데, 기업 모델 구축이 개개의 나무를 그려 나가면서 숲을 그리는 과정이면 5번째는 숲을 먼저 그린 뒤 나무를 그리는 방식이다. 시스템의 필요 성능, 사이징(sizing, 예를 들면 동시 사용자 몇 명을 처리하기 위해서 어떤 성능의 서버가 몇대가 필요하다 따위의), 분산 처리 유무, 현 운영 환경과 향후 운영 전략 설계, 하드웨어와 소프트웨어의 대체안 검증 등, 아마도 테크니컬 베이스의 인력이 가장 많이 투입되며 비기술인력과 기술인력의 커뮤니케이션이 가장 많이 이루어지는 단계일 것이다.

 

6. 종합계획 수립: 프로젝트의 성공을 위한 CSF(Critical Success Factor, 절대성공요인)를 도출하고 이를 근거로 최고경영층의 승인을 획득하고 실질적인 구현을 위한 문서를 산출하는 단계이다. 타 방법론의 계획 단계와 대동소이하다고 생각하면 된다.

 

지금까지 크게 4가지의 프로젝트 진행 방법론들을 살펴 보았다. 용어나 단계별 행위, 산출물등의 차이가 있지만, 공통적인 것은 자료 수집과 계획 수립에 많은 시간과 중요도를 할애 한다는 것이다.

 

이 글을 보시는 분들 중 많은 분들은 이미 알고 계시는 분도 계실 것이고 본인이 처한 현실과 괴리감이 있다고 생각하는 분들도 계시리라 짐작한다. 이견이 있으시거나 더 나은 지식을 보유하고 계시는 분들은 언제든지 의견을 개진해주시기 바란다.

 

굳이 지면을 낭비해 가며 모델 중심으로 장황하게 프로젝트 진행 중에 적용 가능한 방법론들을 설명한 이유는, 앞으로 풀어나가게 될 이야기의 근거가 되기도 하려니와, 어떠한 방법론 또는 상황에 접하게 되더라도 프로젝트를 총괄하는 입장에 있는 사람이 위 사항을 머리 속에 그리고 접하는 것과 그러지 않는 것에는 현격한 차이가 있기 때문이다.