프로젝트 M을 논하다 – 3. 프로젝트 M, 왜 힘들었나?
목차
3. 프로젝트 M, 왜 힘들었나?
프로젝트 M, 왜 힘들었나?
30여년간 프로젝트 관리자로서 생활한 PM에게 물었다.
"신참 PM에게 해 주고 싶은 얘기가 있다면 무엇입니까?"
"Good Luck"
- 티모시 리스터, 피플웨어 중에서
SI 프로젝트가 갖는 일반적 문제점
우리나라 환경에서의 SI 프로젝트가 갖는 문제점을 나열하자면 여러 가지가 있겠으나 고객과 SI업체, 개발자(프리랜서)의 측면에서 본다면 다음과 같은 것을 꼽을 수 있을 것이다.
고객측면
- 고객 스스로가 무엇을 원하는 지 모른다.
- SI업체가 오면 무엇이든지 다 해 줄 수 있는 것으로 생각한다.
개발업체측면
- 고객의 요구사항이 명확치 않으므로 고객의 업무량을 파악하기가 어렵다.
- 프로젝트 팀의 상당수가 프리랜서임에 따라 프로젝트의 팀원의 능력을 파악하지 못한다. 즉 단위시간당 얼마의 프로그램을 개발할 수 있는지 모른다.
개발자(프리랜서)
- 프로젝트의 난이도 또는 근무여건을 파악할 수가 없는 상태에서 계약이 이뤄짐에 따라 생각보다 근무여건이 열악한 경우 프로젝트에 대한 동기는 급격히 떨어진다.
- 프로젝트에 대한 Loyalty가 떨어진다.
결국 프로젝트의 규모를 모르고, 프로젝트팀이 어느 정도의 생산성을 갖는지 조차 파악을 하지 못한 체 프로젝트가 시작됨으로 인해, SI 프로젝트가 제대로 끝났다 함은 예술의 경지에 이르게 되는 것이다
Scope 산정
최초 제안 당시에는 기존에 파워빌더로 개발되었던 이들 시스템을 상당 부분 재활용할 수 있을 것으로 생각되었다. 거기에 맞춰 인력 산정이 이뤄졌으며 우리에게는 직접 밝히지 않았으나 각 개발업체별로 인력에 대해서 버퍼를 가지고 갔다고 느꼈다.
본사 회계부분의 경우 제안 당시, 회계 프로그램이 아주 많이 되어봐야 400본 정도로 예상하였다. 그러나 실제로는 600여 본이 나왔으며 Scope 산정에 결정적인 실수가 있었다. – 고객사에서 생각했던 회계시스템은 재무관리 종합선물 셋트였다고 한다 - Scope산정의 실수는 계열사 부문에서도 있었는데, 계열사 시스템을 운영하던 S사는 기존의 시스템을 업그레이드 하여 진행할 생각이었다. 계열사 담당자와의 끈끈한 친분관계도 있고 시스템을 누구보다 잘 알므로 각 계열사의 내용을 취합하여 공통분모를 찾아내고자 하였으나, 계열사 담당 직원들이 본사 회계시스템을 보면서, 본사 회계시스템 기준으로 만들기를 원하는 바람에 – 본사 회계부는 20여명에 가까운 반면, 계열사의 회계업무는 1명 내지 2명이 담당한다 - 나중에는 전부 재개발하는 형국이 되었다.
프로젝트의 Scope을 정확히 산정한다는 것은 정말 어렵다. 미국의 경우에도 프로젝트의 요구사항 분석 시에 Scope에 대한 오차율이 +400% ~ -50%라는 통계가 있다. 미국은 우리보다 훨신 RFP가 자세하다. "전표입력"이란 4글자의 RFP 내용을 가지고 개발자 1명이 4개월 이상을 개발해야 하는 우리나라와는 차이가 있는 것으로 안다.
과다한 개발산출물
개발 산출물이 과다하다는 얘기는 어느 프로젝트의 개발자의 입에서 나오는 불평이지만, 이번 프로젝트는 굉장히 과했다. 프로젝트가 시작되었던 2006년 3월부터 산출물을 만들기 위해서 밤늦게 까지 개발자들이 정신없이 일을 해야 했다. 파워포인트로 산출물을 만드느라 정작 기존 프로그램의 소스 분석을 위한 시간을 갖지 못했다. 개발자들은 무엇에 쓰이는 지도 모르는 산출물을 끊임없이 만들어야 했으며, ERD를 제외하면 거의 다시 볼 일이 없었음은 개발자들을 더욱 맥 빠지게 하는 일이었다.
프로젝트에 투입되어 굉장히 당황했던 일중의 하나는 고객측에서 원하지도 않는 산출물을 QA의 강력한 의지에 의해 진행되고 있음이었다. QA의 얘기도 일리는 있다.
"최종 결과가 나오려면 이러저러한 산출물을 만들어야 한다. 이러한 절차를 밟지 않으면 중간에 누락되는 부분이 발생하고 검증이 이뤄지지 않는다."
개발에 참여했던 대부분의 사람들과 얘기를 해 보면 이러한 얘기에 공감한다. 그러나 그러한 작업을 위해서는 그만한 시간이 필요하며, 정말 개발을 필요한 산출물인가에 대해서 검증이 되었느냐 하는가 이다. 정말 필요한 산출물이라면 개발 도중 개발자들이 한번도 다시 보지 않았을까? 모든 산출물들이 그나마 유용했던 산출물이었던 ERD를 만들기 위한 것이었을까? – 사실 본사부문의 경우는 기존의 DB Scheme를 그대로 유지했기 때문에 DB Scheme의 변경이 거의 없었다.
산출물 작성에 치중하는 통에 정작 개발자들이 프로그램 소스를 분석하고 고민할 시간을 갖지 못했다.
PM 또는 프로젝트를 이끄는 사람은 개발자들에게 최대한 유효한 시간을 많이 만들어 줘야 한다. 불필요한 작업을 제거해서 개발자들이 실제로 프로그램 개발에 많이 집중토록 해야 했음에도 그러한 것을 조율치 못했다.
산출물에 대한 Tailoring이 잘못된 전형적인 케이스다.
고객사 정보팀의 담당자와 차를 마시면서 이런 저런 얘기를 나눴다. "개발 산출물이 너무 많아서 일이 진척이 잘 안 되었어요" 고객사 정보팀 담당자, "제가 생각하기에 너무 많은 것 같더라구요. 저희는 그냥 ERD랑 프로그램 명세서랑, 도움말 파일만 있으면 되요. 왜 그렇게 많이 만들어요?" |
인력선정
개발 프로젝트는 인력으로 하는 노동 집약적인 사업이다. 따라서 인력이 품질을 좌우하게 되는 데 본 프로젝트는 인력선정에도 다소 문제가 있었다.
개발 인력 중 한 사람은, 개발에 늦게 참여한 탓도 있었겠으나 공통모듈에 대한 이해도가 낮았으며 공통모듈을 사용하여 개발하기 보다는 공통모듈을 임의로 수정하여 개별 프로그램에 적용하는 바람에 추후 필요에 의해 공통모듈을 수정하였으나 반영이 되지 않는 문제를 야기시켰다. 더욱 큰 문제는 본인이 어떤 모듈에 공통모듈을 썼는 지, 혹은 수정한 모듈을 썼는지 조차 파악을 하지 못한다는 점이었다.
또 다른 개발자는 UI상에 버튼을 만들어 두고 버튼에 대한 로직을 처리하지 않은 체 완료보고를 하였다. 시스템의 1차 오픈이 실패한 후, 이 개발자의 프로그램에서 버그가 발견되어 추적하던 중 다음과 같은 프로그램 소스를 보고서 우리는 모두 경악할 수 밖에 없었다.
If x = 12 and y > 11 then
// 프로그램 짜야함
Endif
이러한 것은 개발사의 PM 또는 우리가 프로그램의 완료여부를 샘플링해서 관리했어야 했다. 그러나 개발사의 PM이 인력부족을 이유로 본인이 직접 개발을 함에 따라 본인의 업무량에 치여 미처 관리할 시간을 갖지 못했다.
샘플링해서 테스트를 하지 못했던 것이 본 프로젝트를 관리하는 우리회사 입장에서 최대의 실수다. 개발자들의 리포트가, 개발PM으로부터 보고되는 자료가 신뢰할 수 없을 수도 있음을 간파했어야 했다. 테스트 환경이 뒤늦게 구축되고, 20여년 이상 개발하셨던 개발PM을 배제한 체 직접 테스트를 하기는 어려웠던 부분이 있었으나 프로젝트의 실체를 파악한다는 점에서는 반드시 필요했다.
|
프로젝트 인력을 선정할 때 원가를 줄이기 위해서 외부인력을 Outsourcing 함에 따라 개발자의 성향을 제대로 파악하지 못하고 시작하는 위험을 갖게 된다. 인력에 대한 객관적인 정보없이 Sourcing업체에서 보내주는 이력서와 간단한 인터뷰 "우리는 회계시스템을 개발할 건데 회계시스템을 개발해 봤나요?" "네" "그럼 내일부터 출근하세요" 간혹 운이 좋으면, 개발인력에 대해 몇 단계를 걸쳐서 Reputation을 듣거나, 아주 운이 좋으면 지난 번 프로젝트에서 함께 일했던 사람과 다시 일을 할 수 있는 행운이 주어진다. |
개발자의 책임감 상실
개발의 파트리더였던 모 부장님의 말씀으로는 프로젝트가 망가진 데는 개발자의 책임감 상실을 주 원인으로 들었다. 프로젝트가 막바지에 이르러 다들 바쁘다고 얘기는 했지만 은근히 여유를 부리는 사람들이 생겨났다. 우선, 프로젝트의 오픈이 나의 일이 아니라는 생각이 팽배했고 – 개발자들이 이 시점에 이르러서는 다들 지치기도 하였다. – 그 바쁜 와중 – 바쁜 것은 프로젝트를 리딩하는 쪽에서만 그러했던 거 같다 – 에서도 개인적으로 해야 할 일은 다 하는 것처럼 보였다. 프로젝트의 키맨 역할을 하는 사람은 나이든 부장들이 맘이 다급해 휴일에 출근하는 상황에서도 출근치 않은 날이 많았다. 간혹 일요일에 출근해서 일을 해 주면 굉장히 고맙게 느껴야 하는 상황이었다. 이는 정직원이든 Outsourcing해서 구한 개발인력이던 마찬가지였다. 이러한 개발자의 자질문제는 프리랜서로부터 일하시던 분으로부터도 들을 수 있었다.
개발자의 책임감 상실은 인력에 대해서 Outsourcing하면서 피할 수 없는 것이라 본다. 어차피 계약관계로 이뤄지며, 프로젝트가 성공적으로 오픈하던, 혹은 실패하던 프리랜서 개발자 입장에서 손실을 보거나 이익을 보는 게 없다. 프로젝트가 1달 연장되면, 개발자들이 1달 더 일할 수 있는 상황이 된다. 결국 이러한 개발자들의 프로젝트 충실도 문제는 PM이 안고 가야 하는 숙제가 되어 버린다.
관리 부재
개발팀 내에서 관리가 전혀 이뤄지지 못했다. 일이 많으니 프로젝트의 개발을 관리 해야 하는 개발PM이 프로그램에 손을 대기 시작했고, 본인이 서버 관리다, 개발이다, 보고서 작성을 진행하게 되니 개발자들에 대해서 관리를 할 수 없었고, 따라서 프로젝트의 상황이 어떻게 진행되고 있는지에 대해서 정확히 파악을 할 수 없었으며, 프로젝트에 대한 장악력이 떨어졌다. 결국 프로젝트가 어느 시점에서 엉망이 되었는지를 파악조차 할 수 없었고 마치 개구리를 냄비에 넣고 서서히 온도를 높이면 개구리는 죽어가는 지도 모르는 체 죽게 된다는 "개구리 삶기" 처럼 되어 버렸다. 프로젝트에 책임을 지니는 PM과 부장급 인력들만 밤늦게까지 – 새벽 2시에 나가는 경우도 허다 했다 – 일을 해야 했다.
업무 분장
업무의 유사성을 기준으로 업무가 분장되었어야 했다. 이는 업무의 유사성은 설계시 명확하게 파악이 되었어야 했는데 업무 분석이 정상적으로 되지 않음으로 인해 개발자가 유사한 업무를 하지 않고 서로 다른 업무를 진행함에 따라 Loss가 많이 발생했다. 또한 업무의 볼륨을 제대로 파악되지 않은 상태에서 업무분장이 이뤄짐에 따라 일부 개발자들에게 과중한 업무분장 되어 버렸다.
전술한 바와 같이 프로젝트는 본사와 계열사가 동일 아키텍처를 사용하는 방식으로 진행되었으나, 서로 다른 Framework-즉 공통 라이브러리-을 사용하면서 서로간에 라이브러리의 공유 등을 하지 못했다. 각기 다른 회사에서 자사의 공통 라이브러리를 보호하고자 한 관계로, Framework을 서로 공유치 못했고, 이로 인해 중복되어 일을 처리하는 게 많았다. 또한 한쪽에서 유사한 장애가 나면, 얼마 있다가 다른 쪽에서 유사한 장애가 발생하는 등의 문제도 있었다.
요구사항 분석
요구사항 분석시에는 누가 그러한 요청을 했는 지에 대해서 정확히 기록을 했어야 했는 데 이를 누락한 경우가 많았으며, 요청사항을 개진한 사람에 대한 R&R을 명확하게 하지 못했다. 즉, 한 부서에서는 A라고 요구하면 추후에 다른 부서에서 B라고 요구하면서 최초 A요구사항을 요청한 사람과 B요구사항을 요청한 사람간에 의견조율이 있어야 했는 데, 서로 결론을 내주지 못하면서 시간만 흐르는 경우가 발생했다.
요구사항 수렴회의에서 요구사항에 대해서 명확하게 결론을 내지 못하고 다음에 결론을 내자는 식으로 미루는 바람에 사용자 입장에선 본인의 의견이 수렴이 된것으로 생각했고, 그러한 많은 의견들이 조율없이 프로그램에 반영되기에는 문제점이 많았다.
SOW에 부합되지 않는 부분은 과감히 짤라야 했는 데 그러한 것을 고객과의 관계로 인해 짜르지 못한 것이 많았다.
|
J과장과의 대화 - 07.02.12 새벽, 프로젝트 오픈 당일날 새벽 프로젝트 초기에 기존 프로그램에 대한 분석을 했어야 했는 데 산출물 작업이 워낙 많아 수박 겉햝기 식의 문석작성 밖에 할 수 없었다. 개발 초기에 3주 정도를 공통모듈-흔히 Framework이라 부르는-을 파악하는 데 시간을 허비했다. 공통모듈에 대한 간단한 매뉴얼만 주고 소스를 주지 않으니까 의미 파악하기가 너무 힘들었다. - 공통모듈은 N사에서 자체로 개발한 공통모듈이었으므로 소스를 내놓치 않으려고 했다. - 처음에야 그 의미를 물어보면서라도 할 수 있었는 데 나중에 투입된 L과장은 다들 바쁜 통에 물어 보지도 못하고 그냥 혼자 개발하게 되었으며 그 부분을 아무도 care하지 못했다. 공통모듈이 계속해서 변경되었는 데 그것이 잘 통보되지 않았으며 그걸 일일이 파악하는 것이 어려웠다. 일정에 쫓겨 프로그램 개발자가 단위테스트를 할 시간도 없었다. 그냥 UI만 갖춰지고 로직만 들어가면 테스트도 없이 프로그램이 완료되었다고 보고 하는 수 밖에 없었다. 프로젝트의 지연문제로 인해 06/09 ~ 06/10 에 추가 투입되었던 개발자로 인해 오히려 나중에는 시간을 더 소비하는 요소가 되었다. 투입기간이 짧았던 탓에 업무 자체를 맡기기도 어려웠으며, 그 사람한테 작업을 주려면 오히려 시간이 필요했으며, 기존에 있는 프로그램을 신 시스템으로 소스 이관정도 작업을 줄 수 밖에 없었다. 개발이 완료되고 테스트를 하려고 하니 수많은 부분에서 오류가 나왔으며 본인이 분석하며 이관한 게 아닌 관계로 처음부터 분석을 해야 오류를 잡을 수 있었다. |
목차
3. 프로젝트 M, 왜 힘들었나?