CHAOS 리포트
1994년 미국의 Standish group에서는 프로젝트의 성공과 실패에 대한 리포트(The CHAOS 리포트)를 발표했다. 이 리포트는 그동안 잘 알려지지 않았던 프로젝트의 성공과 실패에 대한 진솔한 내용을 담고 있어서 많은 이들의 주목을 받았다. 이후 이 리포트는 소프트웨어 공학에서 자주 인용되고 있다. Standish group에서는 1994년부터 정기적으로 프로젝트 관리에 대한 리포트 통계를 제공하고 있다. Standish group 홈페이지 (www.standishgroup.com)를 참고하면 Sample Research라고 하면서 공개하는 몇 개의 리포트가 있다. 주로 과거 자료를 공개하고 있는데, 1994년 CHAOS 리포트부터 2001년도 CHAOS 리포트까지 공개돼 있다. 거의 10년이 넘은 리포트이지만 현재까지도 가치가 있는 리포트이기에 여기에 몇 가지 내용을 소개하고 필자의 의견을 덧붙이려 한다.
실패를 반복하는 소프트웨어 프로젝트
네기 멜론 대학 컴퓨터공학과 교수였으며, IBM 연구원으로 근무하였고, 현재는 구글 연구소 부사장으로 근무하는 알프레드 스펙터(Alfred Spector)가 1986년에 다리 건축과 소프트웨어 개발을 비교했다.
“다리 건축은 계획된 기간에 끝나고, 계획된 예산으로 마무리 되며, 무너지지 않고 성공적으로 완료가 된다. 하지만 소프트웨어 개발은 계획된 기간에 끝나지도 않으며, 계획된 예산에 마무리 되지도 못한다. 또한 성공적으로 완료되지 못하고 실패한다.” 건축과 소프트웨어에 궁극적으로 무슨 차이가 있기 때문에 이러한 일이 발생하는 것일까?
한 마디로 요약하면 디자인의 상세화로 발생하는 차이다. 건축은 눈에 보이기 때문에 미리 상세하게 디자인하고 나중에 수정하는 부분도 적다. 발주자 측에서도 고치는 것이 어렵다는 것을 알기 때문이다. 하지만 소프트웨어에서는 급변하는 비즈니스 환경 때문에 미리 정의된 설계가 통하지 않는다(알프레드는 급변하는 비즈니스 환경을 이유로 들었지만, 필자는 그것 보다는 소프트웨어라는 것이 눈에 보이는 사물을 설계하는 것이 아닌, 눈에 보이지 않는 프로세스를 설계하는 것이기 때문이라고 말하고 싶다). 자주 변경되는 설계가 필요하고 그렇기 때문에 소프트웨어 프로젝트는 자주 실패할 수밖에 없다.
“또 다른 차이점은 만약 다리가 무너지면 조사하고, 왜 다리가 무너졌는지 그 이유를 찾아내서 재발을 방지하려고 노력하지만 소프트웨어 프로젝트의 실패는 감추어지고, 무시되며, 합리화 된다는 점이다. 그래서 우리는 실패하더라도, 그 원인에 대해 찾고 배우지 않기 때문에 또 다시 실패하게 된다.” 이 부분이 필자가 가장 감동 받은 문구이다. 같은 실수를 두 번 반복하는 것이 소프트웨어 프로젝트의 현실이기 때문이다.
왜 소프트웨어 프로젝트에 대한 실패는 감추어지는 것일까? 우리나라나 미국도 마찬가지지만 누구나 프로젝트가 성공하기를 바란다. 소프트웨어의 실패라는 것이 명확한 기준이 없기 때문에 누구나 자신의 참여한 프로젝트가 실패한 프로젝트라고 말하기를 싫어한다. 남에게 얘기할 때에는 다들 성공한 프로젝트라고 얘기를 한다. 그런데 해당 프로젝트를 마치고 2~3년이 지나면 은근슬쩍 ‘차세대’, ‘신시스템’, ‘2.0’, ‘통합’ 이러한 문구가 붙는 프로젝트가 생긴다. 기존 소프트웨어가 현재 비즈니스의 요구사항을 다 수용하지 못했기 때문에 새로운 프로젝트가 생기는 것일 수도 있는데, 내부적으로는 기존 프로젝트가 완수하지 못했던 기능의 일부가 포함되는 경우가 종종 있다. 그래서 프로젝트의 실패는 외부로 들어나지 않으며, 아무도 모르는 사이에 차세대 프로젝트 사이에 숨어 들어간다.
그러다 보니 프로젝트 실패에 대한 정확한 원인 조사와 재발 방지를 위한 노력이 이루어지기 어렵다. 우리나라에서도 예전 한국소프트웨어진흥원에서 이러한 조사를 시행하려 했지만 관련 기관의 협조가 어려운 관계로 CHAOS 리포트 만큼의 자세한 조사를 시행할 수 없었다. 대규모 예산 집행이 되는 소프트웨어 프로젝트에서 실패에 대한 언급은 누구나 부담스러운 내용인 것이다. 한국에서 이런 조사 결과가 없어 미국에서 조사한 내용을 토대로 우리나라 환경을 유추해 보는 것도 좋은 방법이라 생각되어 CHAOS 리포트를 소개해 보려고 한다.
프로젝트 성공률 16%?
1994년에 발표된 CHAOS 리포트의 가장 충격적인 내용은 소프트웨어 프로젝트의 성공률이 고작 16% 밖에 안 된다는 것이다. 프로젝트의 31%는 완료되기 전에 취소되었으며, 100개의 프로젝트 중에 94개는 재시작 (중복 포함) 프로젝트였다. 평균적으로 180% 비용을 초과하였으며, 164% 기간을 초과하였고, 61% 정도의 기능만 구현하고 프로젝트가 마무리 되었다. 매우 충격적인 사실이 아닐 수 없다. 그래도 희망적인 것은 2000년도 조사한 결과에는 프로젝트 성공률이 28%까지 높아졌다. 2004년도에는 평균적으로 56% 비용을 초과하였으며, 기간은 84% 초과하여 점점 나아지는 모습을 보이고 있다.
그럼 왜 이러한 결과가 나온 것일까? CHAOS 리포트에서는 프로젝트 성공을 위한 방법으로 CHAOS Ten이라는 10가지 법칙을 발표하고 있다. 1994년부터 해 오고 있는데, 발표할 때 마다 내용이 약간씩 변경된다. 필자는 이 법칙을 그대로 인용하기 보다는 한국적인 상황과 필자의 경험에 비추어 2005년도의 내용을 수정하여 10가지 법칙을 소개하려고 한다. 원문의 10가지 법칙 내용은 Standish group 홈페이지에서 샘플 리포트로 누구나 확인할 수 있다.
법칙 2: 사용자의 참여
소프트웨어 개발 프로젝트를 하는데 있어 두 번째로 중요한 것은 사용자의 참여이다. 소프트웨어라는 것이 궁극적으로 사용자가 하는 일의 프로세스를 자동화해 주는 부분이기 때문에 사용자의 참여 없이는 제대로 된 결과물이 나올 수 없다. 한 가상의 예를 들어 보자.
기업의 CRM 시스템을 만드는 프로젝트였는데, 발주자 측에서는 만들어 달라고 업체에게 의뢰한 다음에 알아서 만들어 오라고 하였다. 자신들은 바쁘기 때문에, 시스템 개발에 참여할 시간이 없었다. 프로젝트 팀에서는 업무 설계를 해야 하기 때문에 현업 담당자에게 참여를 부탁했지만 현업의 입장에서는 가기도 귀찮고 업무도 바빴다. 그렇다고 프로젝트 팀에 가서 인터뷰하고 있으면 팀장 눈치도 보였다. 일은 안하고 계속 자리를 비운다고 팀장이 눈치를 주는 것이다. 그래서 현업들은 프로젝트에 적극적으로 참여하지 않았다. 프로젝트 개발팀에서는 현업이 와서 업무 설계를 도와주고 원하는 것을 말해줘야 하는데 현업의 참여가 없었다. 그래서 일단 프로젝트 개발을 완료하고 오픈을 하였다. 그런데 그때부터 현업들의 원성이 잦아지기 시작했다. 몹쓸 소프트웨어를 개발했다면서 못 써먹겠다고 난리다. 자신들이 데이터를 입력해야 하는데 일단 입력하기도 귀찮고, 데이터 입력한다고 누가 알아주는 것도 아니고, 팀장은 확인도 안하고, 그러다 보니 현업들은 데이터 입력을 안 해준다. 게다가 자신들이 원하는 기능이 없다고 불편하다면서 모든 책임을 프로젝트 팀에 떠 넘겼다. 결국 이 프로젝트는 2~3개월 후에는 아무도 사용을 안 하는 무용지물이 되었다.
SI 소프트웨어 프로젝트는 현업의 업무 프로세스를 자동화해 주는 부분이기 때문에 현업의 적극적인 참여가 필수이다. 현업들이 참여하지 않고, 알아서 만들어 달라고 하는 경우에는 실패할 확률이 매우 높아지는 이유다.
예전에 필자가 참여한 ERP 구축 프로젝트는 이와는 반대였다. 임원진이 적극적으로 관심을 가지고 있던 이 프로젝트의 성공을 위해 현업 각 부서에서 일 잘한다고 소문난 사람들로 별도의 프로젝트 팀을 구축했다. 이들은 이 프로젝트팀에 전담을 하면서 오직 프로젝트의 구축에만 힘을 쏟았다. 만약 실패하면 돌아갈 부서가 없기 때문에 모두 제대로 된 기능 구현에 전념하였다. 그러다 보니 현업의 적극적인 참여가 이루어졌고 현업의 요구사항이 바로 반영될 수 있었다. 결국 프로젝트를 성공하기 위한 첫 번째 열쇠는 프로젝트 팀이 아닌 발주자 자신이 가지고 있는 것이다.
법칙 1: 임원진의 지원
법칙 2에서 왜 현업 사용자들은 비협조적이 되었을까? 그것은 바로 임원진의 적극적인 지원이 없었기 때문이다. 별도의 프로젝트 팀이 없이 현재 하는 업무를 병행하면서 프로젝트에 참여하는 것은 매우 제한적일 수밖에 없다. 프로젝트 팀에 가서 인터뷰하고 업무 설계를 해 주러 자리를 비우면 일단 팀원은 팀장의 눈치를 봐야 한다. 또한 현재 자신의 업무가 다른 업무와 병행을 할 만큼 여유있는 업무가 아닐 경우가 많기 때문에 다른 업무할 시간이 상대적으로 부족하다. 또한 프로젝트를 완료한다고 하여도, 팀장이나 임원진이 데이터에 대해 관심이 없다면 어떤 현업도 데이터를 입력하지 않을 것이다. 입력하는 것 자체가 귀찮기 때문이고, 입력을 해서 통제받기 싫어하기 때문이다. 임원진이 적극적으로 별도의 프로젝트 팀을 조성해 주고 프로젝트 진행사항을 체크하며, 완료된 결과물에 대해 관심을 가져준다면 프로젝트의 성공률은 높아지게 된다. 그래서 법칙 1과 2의 순서를 바꾸어 소개하였다. 이때 프로젝트 팀에서도 임원진이 중간에 확인해 볼 수 있는 결과물을 보여주어야만 한다. 산출물을 보여주면서 “이 정도 개발 중입니다”라고 얘기해 봐야 눈에 보이는 것이 없기 때문에 임원진으로서는 잘 진행이 되고 있는지 판단하기 어렵다. 그보다는 마일스톤을 짧게 잡아서 중간에 시연 가능한 결과물을 보여주는 것이 더 효과적이다.
법칙 3: 분명한 목표
프로젝트에 성공하기 위해서는 프로젝트에 대한 분명한 목표가 있어야 한다. 해당 프로젝트를 통해서 무엇을 할 것인지에 대한 분명한 목표가 수립되어 있어야 한다는 의미다. 그렇지 않을 경우 많은 이해관계자들의 다양한 요구사항에 프로젝트가 흔들릴 수 있다. 초기에 이 프로젝트를 통해서 무엇을 할 것인가에 대한 분명하게 정의해 놓아야만 나중에 여러 이해관계자들의 요구사항에 흔들리지 않을 수 있다.
한 예를 들어 보자. 프로젝트 초기에 CRM 시스템을 만들기로 하였는데, 수행을 하다 보니 전자결재 시스템이 필요하게 되었다. 그렇다고 프로젝트 목표를 수정하여 전자결재 시스템을 새로 구축해서는 안 된다. 프로젝트의 목표는 CRM 시스템 구축이지 전자결재 시스템 구축이 아니기 때문이다. 전자결재를 대체할 수 있는 다른 방법을 찾거나 전자결재 시스템은 별도로 도입해야 한다.
법칙 4: 최적화된 범위와 요구사항
2002년도 Standish 리포트에 따르면 프로젝트를 수행하고 난 후에 자주 사용하는 기능은 전체의 20% 정도 밖에 안 된다. 거의 사용되지 않거나 전혀 사용되지 않는 비율은 64%나 됐다. 그만큼 소프트웨어 개발의 낭비가 심하다는 얘기다. 프로젝트 범위를 정하는데 있어 많은 이해관계자들의 요구사항을 다 들어주다 보면 이런 낭비가 발생한다. 일 년에 한 번 하는 작업을 위해서 소프트웨어 개발을 할 필요성이 있는지는 한 번 고민해 봐야 한다. 프로젝트 팀에서는 이러한 요구사항의 우선 순위화를 통해서 요구사항을 걸러내고 최적화해야만 한다.
법칙 5: 능력있는 프로젝트 관리자
프로젝트를 수행하는 데 있어 프로젝트 관리자는 매우 중요한 역할을 한다. 프로젝트 관리자가 프로젝트를 수행하는 전반적인 관리를 하기 때문이다. 프로젝트 관리자는 프로젝트를 수행하는 모든 이해관계자와의 의사소통을 위한 중심에 서 있는 인물이다. 모든 이해관계자들과 빈번한 의사소통을 통해서 프로젝트 수행에 대한 문제점을 발견하고 해결하고 이슈화하는 책임을 지는 사람이다.
PM(Project Manager)은 프로젝트 관리에 대한 지식도 중요하지만 가장 중요한 필수 능력은 의사소통 능력이다. PM의 역할이라는 것이 기본적으로 사람을 관리하여 프로젝트를 성공적으로 이끌어 가는 것이기 때문에 사람 관리를 위해서는 필수적으로 원활한 의사소통 능력은 필수이다. 이러한 능력은 지식으로 배우기 어려우며, 다양한 오랜 경험이 필요한 직무이기도 하다. 한 가지 재미있는 사실은 standish group에서 회원들을 상대로 PM이라면 PMP 자격증이 필요하냐고 설문조사를 하였더니 84%가 “No”라고 대답하였다. 그만큼 PM에게는 지식보다는 경험이 더 중요하다는 것이다.
법칙 6: 반복적인 애자일 프로세스
Standish group에서 개발 방법론 중에 애자일 방법론을 프로젝트의 성공적인 요소로 지목한 것은 상당히 고무적인 내용이다. 심지어 프로젝트 성공을 위한 은빛 탄환(silver bullet)을 지목하라면 바로 이 애자일 프로세스라고 말하고 있다. 2005년도 얘기니까 지금은 또 달라졌을 수도 있겠지만, 아무튼 애자일 방법론을 거론한 것 자체에 의미가 있다고 볼 수 있다. 애자일 방법론에서는 짧은 마일스톤을 통해서 조기에 확인할 수 있는 결과물을 만들어 가면서 지속적으로 확인할 수 있다. 따라서 프로젝트 실패에 대한 느낌을 초기에 확인할 수 있고 지속적으로 수정하고 개선해 나갈 수 있다는 장점이 있다.
법칙 7: 재무관리
프로젝트 비용에 대한 정확한 비용 측정이 필요하다. 어떤 요구사항을 구현하는 데 얼마의 비용이 필요하다는 내용이 있어야 한다. 인원에 대한 인건비도 정확한 계산을 통해서 프로젝트의 손익을 계산할 수 있어야 한다.
법칙 8: 능력 있는 자원
프로젝트를 수행하는 핵심 자원은 바로 사람이다. 따라서 능력있는 개발자와 이해관계자들이 참여하면 프로젝트의 성공률이 높아지는 것은 당연한 것이다.
법칙 9: 형식적인 방법론
프로젝트를 수행하는데 있어 관리 방법론도 중요하다. 프로젝트에 대한 진척사항, 비용계산에 대한 방법이 미리 정해진 대로 이루어져야 한다. 특히 이러한 관리 방법론을 관리하는 데 있어 PMO(Project Management Office)의 역할이 중요하다. 프로젝트의 진행사항을 보고 받고 지원해 주는 역할을 하기 때문이다.
법칙 10: 표준화 된 도구와 인프라스트럭처
프로젝트를 수행하는데 있어 핵심 자원은 사람이다. 사람이 일을 하는데 있어 도움을 받을 수 있는 각종 도구가 있다면 보다 능률적으로 일할 수 있다. 프로젝트 관리 도구들에는 많은 것들이 있는데 위키피디아에 보면 아래와 같은 정의가 있다.
Project management software is a term covering many types of software, including scheduling, cost control and budget management, resource allocation, collaboration software, communication, quality management and documentation or administration systems, which are used to deal with the complexity of large projects.
프로젝트 관리 소프트웨어는 일정관리, 비용/예산 관리, 자원 할당, 협업, 커뮤니케이션, 품질관리, 문서관리 등을 위한 소프트웨어이다.
이러한 도구들은 많은 종류가 있는데 크게 라이선스에 따라 두 가지로 나눌 수 있다. 무료 제품과 상용제품. 각각 장단점이 있는데 무료제품의 경우 각각 개별 제품으로 되어 있어 통합해서 사용하는 데 어려움이 있을 수 있다. 대신 오픈 소스 기반이므로 사용자가 무료로 수정해서 사용할 수 있는 장점이 있다. 상용제품의 경우 비용이 들긴 하지만 하나로 통합된 관리 환경을 제공해 주므로 편리하게 사용할 수 있다.
필자의 경우에는 Visual C#을 자주 사용하기 때문에, Visual Studio Team System의 기능을 필요에 따라 사용하고 있다. <표 1>에서는 누구나 사용할 수 있는 오픈소스 기반의 도구 몇 가지를 나열해 보았다. 전체 리스트는 위키피디아에서 확인할 수 있다(http://en.wikipedia.org/wiki/List_of_project_manage ment_software).
프로젝트 성공의 핵심 3대 요소
CHAOS 리포트에서는 프로젝트 성공의 핵심 3대 요소를 임원진의 지원, 사용자의 참여, 분명한 목표라고 정의하고 있다. 3대 요소가 결국은 프로젝트 개발 조직이 아닌 발주 조직에 해당하는 내용이다. 발주자가 그만큼 프로젝트에 관심을 가지고 지원을 해야만 프로젝트가 성공할 수 있다는 것이다. 단지 발주를 해 줬으니 알아서 개발하라면서 방관자적인 자세를 취한다면 발주자 스스로 프로젝트의 실패를 자초하는 것이다.
참고자료
1. 소프트웨어 공학의 사실과 오해, 로버트 L. 글래스, 2003
2. 조엘 온 소프트웨어, 조엘 스폴스키, 2004
3. Professional 소프트웨어 개발, 스티브 맥코넬, 2004
4. 똑똑하고 100배 일 잘하는 개발자 모시기, 조엘 스폴스키, 2007
5. 스크럼-팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들, 2002
6. 피플웨어, 톰 디마르코, 2003
최근에 이런 글이 부쩍 공간되는 이유는 왜 일까?
(0) 
(0)Posted by 좐군
