| 이만용의 Open Mind] 실패한 프로젝트를 수습하며 |
| 이만용 (리눅스코리아) |
| 2004/09/15 |
|
 이제 가을의 문턱 9월, 한국인들이 본격적으로 부랴부랴 일을 할 시기다. 12월은 연말 결산한다고 보내고, 1분기는 늦어진 결산하고 새로운 계획 세운다고 보내고, 2분기는 조사한다고 보내고, 3분기에는 아직도 아무 것도 결정하지 못했다는 사실에 놀라서 허둥대면서 보냈다가 8, 9월쯤 되면 그 동안 없었던 결단력을 허겁지겁 발휘한다. 올해 안에 꼭 뭔가를 끝내야 한다면서. 이 모습은 대기업, 소기업 그리고 신속한 결단력을 생명력으로 해야 할 벤처기업 할 것 없이 모두 똑같다. 어찌 되었든 3분기와 4분기는 모든 산업 분야가 바쁜 시기이다. 지방 정부에서는 남은 예산을 쓰기 위해 멀쩡한 도로를 뜯어내 행인들을 짜증나게 만들 것이다. IT 분야의 매출 상당량이 이 시기와 거의 일치한다. 퇴근길 필자의 휴대폰 배터리 잔류량 표시가 상반기와 달리 1개이거나 바닥인 것을 봐도 알 수 있다. 오늘은 필자로 하여금 지난 번 앵커데스크 원고까지 빼먹게 만든 '실패한 프로젝트'에서 배운 쓰라린 교훈에 대한 이야기를 해보겠다. 슬슬 일의 가속도가 붙기 시작한 지난 8월 중순, 회사 내에서는 중대한 대책 회의가 열렸다. 9월 초까지 끝내야 할 'D 프로젝트'가 위기에 처해 있었기 때문이다. D 프로젝트 종료 시기가 얼마 남지 않은 상황에서 아예 포기하는 사람들이 하나 둘 나타나기 시작했으며, 일을 제 시간에 끝낼 수 없을 것이라는 불안감이 팽배해졌다. D 프로젝트가 위기에 처할 것이라는 사실을 그 전에 눈치 못 챈 것은 아니다. 프로젝트에 참여하고 있는 사람들이 일하는 모습만 봐도 그 프로젝트가 위기에 처해 있는지 아닌지 감은 잡을 수 있다. 하지만 '내 업무만으로도 바쁘다'는 이유로 항상 지켜보고 있을 뿐이었다. 우선 전체 회의가 빈번하다는 것은 프로젝트 매니저(PM)가 일을 잘못 진행하고 있다는 분명한 증거이다. 개발자에게 있어 가장 중요한 대화는 대회의실에 모두 모여 숙제 검사하듯 진행하는 공식적 대화가 아니라, 2~3명이 잠시 모여 차를 마시면서 나누는 비공식적인 의견 교환이다. 무엇보다 매일매일 일어나는 일이 중요하다. PM이 혼자서 근사한 계획을 세우거나 수정하고 나서 모두에게 공표하는 행위는 PM의 자위행위일 뿐 아무런 도움이 되지 않는다. 인간이란 원래 PM이 생각하는 대로, 공식적으로 주어진 일정표에 따라 동작할 수 있는 기계가 아니다. 그런데 사람은 조금이라도 뭔가를 관리하는 위치에 올라서면 이 사실을 깨끗이 잊어버리는 경향이 있다. 대책 회의 때 실패의 원인을 개발자에게 돌리는 PM이야말로 최악이다. PM은 쉬지 않고 고객과 개발자 사이를 오가면서 '짧은 대화'를 많이 해야 하며, 프로젝트 기간 동안 이 일을 절대 멈춰선 안된다. 우선 D 프로젝트의 PM은 회사에 거의 나타나는 일 없이 외로운 호랑이 스타일로 일했다. 프로젝트란 평원에서 사자들이 협동하여 사냥하는 것과 같다. PM의 독단적인 업무 스타일 하나만 봐도 실패는 예견된 것이었다고 할 수 있다. 필자가 자책하고 후회하는 것은 결정적인 일이 아니고서는 PM에게 간섭하지 않겠다는, 쓸데 없는 배려 또는 나태함 때문에 개입해야 할 시기를 놓쳐 결국 이 지경에 이르렀다는 사실이다. 모든 위기가 위기인 진짜 이유는 잘못을 바로잡을 시간이 부족하기 때문이며, 또한 문제가 꼬여 있어 새로운 시작보다 몇 배 더 많은 정신적 에너지를 쏟아야 하기 때문이다. 실패한 프로젝트는 모든 인간적 문제와 기술적 문제를 동시에 드러내 도대체 어디부터 손을 대야 할 지 알 수 없게 다가온다. 개발자들은 위축된 채 '그 동안 도대체 뭘 했느냐'는 원망성 질문에 변명을 하게 된다. 답변이 아니라 변명이 나온다면 그 일은 그들의 마음 속에서 이미 '자신의 일'이 아닌 것이다. 자신의 일이 아니라고 생각하는 일의 진척 속도는 놀라울 정도로 느리다. 하루면 할 수 있는 일을 1∼2주 동안 해도 제대로 끝낼 수 없는 게 바로 이런 개발이다. 여기에 '개발자가 협조하지 않는다'고 PM까지 변명하면, 프로젝트 상태는 이미 그들의 힘으로 치유할 수 없는 상태라고 봐야 한다. PM이 변명으로 일관한다면 그 역시 '자신의 일'이 아님을 의미한다. 일이 이 지경까지 오면 문제는 심각해진다. PM이 회사에 가장 큰 피해를 끼치는 경우는 상황을 은폐하고 시간을 끄는 것이다. D 프로젝트가 바로 그러했다. 변명하는 자는 물어보기 전에 설명하는 일이 없으며, 결국 은폐하고 시간을 허비해 상황을 최악으로 끌고 간다. 결론은 분명했다. PM은 경질됐고 필자가 결국 PM을 대신 맡았다. 이제 모든 일은 갑자기 '나의 일'이 돼버렸다. 새 업무를 맡기 위해서는 업무 분석부터 시작할 수 밖에. 모든 프로젝트가 그러하듯 고객의 요구사항 문서, 그리고 그 요구사항을 분석한 요구사항 분석서, 분석에 의거하고 개발자와 협의하여 만들어진 구현 계획서부터 읽어나가야 했다. 프로젝트를 해봤고 프로젝트 때문에 고통받아 본 사람은 모두 매 단계마다 문서를 작성하는 일이 얼마나 하기 싫은 일인지 공감할 것이다. 하지만 달리 어찌 하겠는가. 개발을 통해 구현할 수 있는 것은 '글로 설명할 수 있는 것' 뿐이다. 말로는 지금 당장이라도 화성에 로켓을 쏘아 보낼 수 있다. 말로 설명할 수 있어도 막상 글로는 적을 수 없는 것이 있다면 그건 구현 불가능하다. 또한 그 글을 남이 읽어서 이해할 수 없다면 그것 역시 구현이 불가능하다. 그동안 제출했던 문서와 웹 화면 설계를 보면서 필자는 다시 한 번 경악하지 않을 수 없었다. 개발자들은 구현 계획서가 아니라 요구사항 문서를 들고 일하고 있었다. '장애가 발생해도 서비스에는 이상이 없어야 한다'는 요구사항 문구만 가지고 도대체 어떤 일을 할 수 있단 말인가. 개발자에게는 이다, 아니다를 분명히 하는 매우 구체적인 구현 지시서가 있어야 한다. 또한 그러한 구체적인 구현 지시서가 있어야만 개발자에게 변명이 아니라 정확한 답변을 기대할 수 있다. '프로젝트 잘 되가나', '공정률이 얼마나 되나'는 류의 질문만큼 무의미한 질문도 없다. 공정률을 수치화한다는 것 자체가 원래 불가능하며, 설사 90%라고 답한다 할지라도 나머지 10%를 마치는 데 지금까지 걸린 시간보다 더 많은 시간이 필요한 경우가 비일비재하다. 실패하는 프로젝트는 대략 다음과 같은 증상을 드러낸다:
프로젝트가 실패하면 할 수 있는 일은 3가지다.
그러나 어떤 이유에서든 첫번째가 답이 아니라면(경제적 또는 기타 문제에 의해) 하루라도 빨리 고객에게 진실을 일리는 것이 좋다. 필자는 2번과 3번을 모두 선택했다. 일의 양이 줄고 시간이 늘었다고 해서 이 프로젝트가 또 다시 실패하지 말란 법은 없다. 실패하지 않기 위해서는 책 속의 어떠한 방법론보다도 구성원의 정신적인 에너지가 집중적으로 발휘되도록 하는 것이 필요하다. 우선 PM은 어떠한 일이 있어도 프로젝트가 실패하도록 좌시하지 않겠다는 강한 의지를 보여줘야 한다. 이것이 프로젝트의 가장 중요한 기본 조건이다. PM은 개발자에게 구체적인 업무를 지시하고 구체적인 질문을 던지고 구체적인 방향을 제시해야 한다. 개발자는 구체적인 일이 주어졌을 때 그 일을 자신의 일로 생각하기 때문이다(최소한 개발자는 구체적인 일에 대해서는 변명을 할 수 없게 된다). 필자는 책임의식이니 주인의식이니 하는 것에 대해서는 말하고 싶지 않다. 이는 PM이 불어넣어 줄 수 없는, 지극히 개인적인 정신 상태이기 때문이다. 어떤 프로젝트가 성공하기 위해 그런 고차원적 의식이 반드시 필요한 것이라면 이 세상 대부분의 건물은 이미 무너졌을 것이라고 생각한다. 프로젝트의 구성원들이 각자 해야 할 일이 무엇인가 끊임없이 자각하게만 한다면 프로젝트는 실패하지 않는다. 필자와 똑같은 '패전처리 투수' 처지에 놓인 PM들, 그리고 개발자들이 힘낼 수 있기를 바라며, 필자도 다음 앵커데스크까지 이 일을 꼭 마무리하리라 다짐해 본다. @ |
"이제 조립만 하면 돼"
"머리 속에 다 들어 있어."
새로운 요구 사항이 항상 추가 된다.
구현계획서가 없다.
딱 우리 팀 이야기군..
댓글 없음:
댓글 쓰기