매번 프로젝트를 하다보면 새로운 도전과 문제의 연속을 겪게 되고 이 과정에서 종종 생각나는 속담들이 있다. 선조들의 지혜가 어떻게 프로젝트 관리에 적용되는지 생각해보았다.
배보다 배꼽이 더 크다
프로젝트의 과업 범위를 잘못 파악하고 있다보면 배보다 배꼽이 더 큰 경우가 생긴다. 원래는 작은 일이라고 생각했던 것이지만 기술적 난이도, 요구 사항, 소요 시간 등을 미리 파악하지 못해 결국 다른 모든 일보다 중요하고 큰 일이 돼 버리곤 한다.
내가 지원한 어떤 프로젝트는 외부의 다른 시스템으로부터 데이터를 연계 받아야 하는 경우가 있었다. API 문서가 명확히 있었고 이미 기본적인 연계는 하고 있던 상황이었으며 다른 기관에서도 연계를 많이 하는 것이라 다른 요구 사항에 비해 상대적으로 중요도가 덜 하다고 봤다.
하지만 막상 프로젝트가 진행되는 동안에는 대상 시스템이 UNIX라 개발자를 쉽게 할당할 수가 없었으며 데이터 양이 많아 연계 자체가 시간이 걸리기 때문에 전체가 잘 되는 것인지 테스트하는 것도 쉽지 않았다. 또한 한 번에 연계가 이루어지는 게 아니고 상대방과 맞춰야 할 부분이 있는데 맞출 사항을 정의했더라도 상대방 시스템에서 그걸 반영하는 데 시간이 걸리거나 특정 요일에만 반영할 수 있다는 등의 이유로 계속 시간이 지체됐다. 또한 일단 연계는 됐더라도 그 후에 데이터의 종류 조정이나 연계 주기, 후처리 작업 등이 계속 시간이 걸렸다. 결국 내가 지원을 하게 됐고 상당히 오랜 시간을 거쳐 마무리하게 됐다.
돌 다리도 두들겨 보고 건너라
정말 중요한 속담이다. 나로서는 당연하다고 생각한 어떤 것이 기대와 전혀 다르게 진행되는경우가 왕왕 있다. 예를 들어 "화요일까지 자료를 만들어 주세요"라고 한다고 하자. 그럼 화요일 오전에 볼 수 있게 주겠다는 것인가, 화요일 업무 시간 종료 때까지 주겠다는 것인가? 받는 사람 입장에서는 화요일 오전까지로 생각하고 있다가 막상 화요일 오전이 되니 주는 사람은 오후 늦게나 준다고 해서 당황하게 되는 그런 경우다.
잘못될 만한 것들은 잘못된다는 머피의 법칙도 있듯이 꼼꼼하게 따지지 않으면 놓치거나 예상과 다르게 진행되는 일들이 꼭 생긴다. 또한 프로젝트에서 의사 소통이 차지하는 비중이 대단히 큰데 의사 소통에 조금 소홀하거나 놓치는 게 생기면 이런 문제가 생긴다.
백지장도 맞들면 낫다
일이 많다보면 사소한 일도 점차 버겁게 된다. 어떤 기능을 잘 개발하고 있는지 점검해 봐야 하고 협력업체 연락도 해야 하고 고객과 회의에 참석도 해야 하고 오전에 얘기해둔 문서 작업도 체크해야 하고…
팀원 각자의 역할을 정해 분담하는 일의 분업화, 전문화가 중요하고 권한을 위임하는 것도 중요하지만 한 가지 일을 한 사람만 맡아 하면 그 사람은 계속 피로함을 느낄 수 밖에 없고 결국 능률이 떨어지게 된다. 민첩(agile) 방법론에서처럼 매일 각 팀원이 어떤 일을 하는지 서로서로 파악하고 필요하다면 도움을 주는 것이 그런 면에서 아주 유익한 방법이라고 생각된다.
가능하면 어떤 종류의 일은 잘 하는 사람이 맡아 하는 것이 좋다. 하지만 이렇게만 가면 그 사람 외에는 대안이 없게 된다. On the job training 개념에서도 이때 필요한 것이 "짝 프로그래밍"이다. 짝 프로그래밍은 교육, 훈련 차원에서 뿐 아니라 프로젝트에 실제적인 도움이 될 수 있음을 난 찐하게 경험한 바 있다.
가랑비에 옷 젖는 줄 모른다
프로젝트는 시간과의 싸움인데 사소한 시간 낭비가 누적되면 큰 결과를 가져올 수 있음을 유의해야 한다. 예를 들어 4인 1조의 한 팀이 4주일간 일할 수 있는 시간은 약 20일 x 4인 x 8시간 = 640시간이다. 그런데 다음과 같은 낭비 요소가 있다고 해보자.
웹사이트 개발 중 메뉴를 구현하지 않아 주소를 일일이 입력해서 들어가는 시간
5초 x 1일 30회 x 20일 x 4명 = 200분
개인 컴퓨터가 느려서 이클립스 등 작업시 낭비되는 기회 비용 시간
1분 x 1일 3회 x 20일 x 4명 = 240분
이클립스 단축키, 리팩터링 기능 등을 몰라 낭비되는 기회 비용 시간
30초 x 1일 5회 x 20일 x 4명 = 200분
원활하지 않은 의사소통으로 인한 업무 미스, 재회의 등 낭비 시간
1시간 x 2회 x 4주 = 480분
몇 가지 예를 들었지만 이것만 해도 낭비 시간의 합은 총 1120분, 18시간 이상에 이른다. 640시간 중 18시간의 낭비는 적지 않다. 특히 강조하고 싶은 것은 의사 소통 미흡이다. 누군가 회의에 지각을 한다든가, 누군가 제시간에 이메일 답을 안한다든가, 누군가 업무 내용을 잘못 알고 있다든가 한다면 팀 전체에 영향이 있을 수 밖에 없으므로 전반적인 시간 낭비가 발생하게 된다.
또한 교육도 중요한 것임을 알 수 있다. 개발팀원의 효과적인 업무를 위해 프로젝트에 필요한 기술과 방법 등을 미리 교육한다면 프로젝트 전체적으로 큰 성과가 있을 것이다.
급할수록 돌아가라
가랑비에 옷 젖는 걸 방지하기 위해서는 급할수록 돌아갈 필요가 있다. 가능하면 모든 일을 제대로 하라는 것이다. 바늘 허리에 실 매어 못쓴다는 것과 비슷하다.
프로젝트 중에 급하다보면 임시 방편으로 일을 처리하는 경우가 흔하다. 고객이 어떤 집계표를 뽑아달라고 하면 1회성으로 생각하고 대충 만들어서 던져준다. 그러나 모든 일이 한번으로 끝나는 경우가 별로 없다. 예상치 못한 문제가 있어서 다시 뽑을 수도 있고 시간이 지나 또 필요해질 수도 있다. 어떻게 집계표를 뽑는지 과정을 문서화하고 그때 사용된 프로그램이나 SQL을 잘 보관했다면 다음에 같은 작업할 때 금세 끝낼 수 있다. 내가 못할 경우 다른 사람이 대신 작업하기도 좋다.
원리 원칙과 절차는 괜히 생기는 것이 아니다. 또한 우리가 프로젝트에서 수행하는 사소한 행동도 공식화하고 절차를 수립한다면 나중에 고객이나 감리 앞에 당당해질 수 있게 된다. (개인적으로 문서 작업을 선호한다는 것은 아니다. 문서 양식이 중요한 게 아니고 일을 임시방편적으로 하기보다는 어떤 방법으로든 처리 방안을 계획하고 실제 과정을 기록하는 게 좋다는 것이다.)
밤새도록 울다가 누구 초상이냐고 묻는다
대부분의 팀원들은 과업 목표를 생각하기 보다는 자신에게 주어진 일에 대해서만 신경쓰기 마련이다. 그래서 관리자들은 그런 팀원들을 자기 일 밖에 모르는 편협한 팀원이라고 비난하곤 한다.
그러나 이것은 관리자도 마찬가지다. 정말 프로젝트의 목표, 고객이 최종적으로 원하는 게 뭔지 진지하게 생각해봤는가? 아니, 그 전에 누가 진짜 중요한 고객인지부터 잘 알고 일을 하는가? 대부분 내가 주로 만나는 현업 담당자가 가장 중요한 고객이라고 생각하는 경우가 많은데 정말 그럴까?
우리 프로젝트는 3개월에 걸쳐 기능을 협의하고 개발하고 종료 1개월 정도를 남기고 있었다. 이제 고객에게 결과물을 보여주기 시작하는 단계에 들어섰는데 이때 담당자의 상사인 팀장이 여태까지 프로젝트에 관여하지 않다가 한마디씩 던지기 시작했다. 급기야는 재기획하라는 얘기까지 나왔다. 기능에서 어떤 부분이 상당히 약하니 다른 모든 기능들도 그 부분을 중심으로 재편하라는 날벼락 같은 얘기였다.
정말 황당하지만 어떡하는가. 팀장은 지금까지 개발한 결과물이 정작 중요한 기능은 들어있지 않다고 하는데… 결국 힘들지만 우리는 상당 부분을 돌아돌아 갈 수 밖에 없었고 기간도 원래보다 1개월 정도 지체될 수 밖에 없었다.
이런 일이 드문 일이 아니다. 고객과의 의사소통이 미흡하다보면, 고객의 조직 구조, 고객의 비전을 잘못 알고 있다면 종종 발생하는 일이다. 담당자의 말만을 듣기보다는 반드시 어느 선까지 이 프로젝트에 관여하는지, 어느 선까지 과업 내용에 대해 밤 놔라 대추 놔라 할 것인지, 정말 목표하는 시스템이 어떤 것인지 사업 시작부터 진지하게 확인 또 확인해야 한다.
맺음말
이 외에도 생각해볼 속담이 많이 있을 것 같다. 결국 프로젝트라는 것은 인생사의 축소판이라고도 볼 수 있기 때문일 것이다. 어렵게 PMP 같은 것을 들먹이지 않더라도 우리가 하는 대부분의 일은 진지하게 열과 성을 다한다면 성공적으로 마칠 수 있을 것이다.