[공지사항] 블로그 DNA 변경: 블로그는 계속된다.

원래 이 블로그는 The Art of Project Management : 마음을 움직이는 프로젝트 관리 책을 번역하면서 아쉬웠던 뒷 이야기를 정리하기 위한 목적으로 출발했습니다. 하지만 1장부터 16장까지 한번씩 빠진 이야기를 쓰고 나서 이 블로그를 얌전히 닫아버리려니 그동안 열렬한 성원을 보내주신 독자 여러분의 성원이 눈에 밟혔습니다. 그래서 역자 일동(저와 해님)은 이 블로그의 취지를 계속해서 살려서, 앞으로 프로젝트 관리나 소프트웨어 공학에 대한 책을 번역할 경우 뒷 이야기를 꾸준히 올려드리기로 결정했습니다.

이런 노력의 일환으로 이번에 새로 번역한 로버트 L. 글래스의 소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁에 대한 뒷 이야기를 계속해서 올려드리기로 했습니다. 이런 정책 변화에 따른 문의 사항은 댓글로 피드백 부탁드리겠습니다. 새로운 시즌은 1월 7일부터 시작입니다. 기존에 연재했던 '마음을 움직이는 프로젝트 관리'와는 느낌이 다른 즐겁고 재미있는 글을 기대하십시오!

'소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 공동 역자 박재호 이해영 올림

여러분의 프로젝트가 성공할 확률은 얼마입니까(2)?

이번에는 주위 동료나 팀원들에게 개별적으로 물어보십시오.

우리 프로젝트가 성공할 확률은 얼마라고 생각합니까?

다른 사람이 내놓은 값을 알면 무의식적으로 비슷한 확률을 내놓게 되므로 개별적으로 묻는 편이 좋겠습니다. 또한 팀장이나 상사 입장이라면 팀원들이 솔직히 대답하도록 신경써야겠죠. 팀장이 듣고싶어 하는 답을 내놓을지도 모르니까요.

이렇게 얻은 확률은 프로젝트 현재 상태를 이해하는 데 유용한 정보가 됩니다. 예를 들어, 무언가 프로젝트를 방해하는 요인이 있다면, 팀원들 모두가 성공 확률이 낮다고 보겠죠. 팀원들이 '프로젝트 성공 확률을 낮춘다'고 느끼는 요인을 그대로 방치하고는 프로젝트를 성공시키기 어렵습니다.

팀원들이 내놓은 확률 편차가 아주 크다면 이 또한 문제입니다. 모두가 같은 수준으로 프로젝트를 이해하는지, 팀원들의 능력에 맞게 업무를 적절히 분배했는지 다시 확인해야 합니다.

전반적으로 확률이 높다면 좋은 소식입니다. 모두가 프로젝트 성공에 긍정적이라는 뜻이죠. 하지만 단순히 낙천적인 희망은 아닌지, 한번 더 짚어보시기 바랍니다. 아무리 조심해도 지나치지 않으니까요.

스티브 맥코넬은 'Rapid Development: 프로젝트 쾌속 개발 전략' 8장 '예측'에서 다음과 같은 두 가지 사항을 언급합니다. 앞서 언급한 방법과 한번 비교해보시기 바랍니다.

• 개발자가 도출한 예측값을 사용해라. 업무를 직접 수행할 개발자가 아닌 사람들이 도출한 예측값은 담당 개발자가 도출한 값보다 부정확하다. 예측자겸 개발자가 예측과 업무를 모두 맡으면, 자신이 도출한 예측값을 달성함으로써 예측 능력과 업무 능력을 함께 증명하는 긍정적인 효과가 있다. 별도 예측자는 예측자겸 개발자보다 예측값을 과소평가할 가능성이 크다.
• 검토 회의를 통해 예측하라. 팀원 각자가 프로젝트를 예측한 후, 예측값을 비교하는 검토 회의를 하라. 예측값이 차이가 나는 경우, 충분히 토론하여 원인을 파악하라. 예측값 범위에 모두 합의할 때까지 함께 작업하라.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 이해영-박재호 올림.

여러분의 프로젝트가 성공할 확률은 얼마입니까?

딱 1분만 눈을 감고 생각해봅시다.

지금 내가 참여 중인 프로젝트가 성공할 확률은 얼마인가?

몇 퍼센트라고 생각하셨습니까? 80%? 90%? 아마 50% 미만으로 잡으신 분들은 별로 없으리라 생각합니다.

그런데 Standish Group이 내놓은 2004년 CHAOS 보고서에 따르면, IT 프로젝트의 성공률은 대략 30%에 불과하다고 합니다. 놀라셨습니까? 10개 중 7개는 실패한다는 말입니다.

정확하게 말하자면,

• 예산과 일정에 맞게 계획한 기능을 모두 끝낸 프로젝트, 즉 성공적으로 완료한 프로젝트: 34%
• 끝내기는 했지만 예산을 초과하고 일정이 지연되고 애초에 계획했던 기능을 모두 구현하지 못한 프로젝트, 즉 난관을 겪으면서 완료한 프로젝트: 51%
• 끝내기 전에 취소되었거나 끝을 보지 못한 프로젝트, 즉 실패한 프로젝트: 15%

그렇다면 왜 IT 프로젝트 성공률이 이렇듯 저조할까요? 와트 험프리 Watts S. Humphrey는 IT 프로젝트가 실패하는 대표적인 이유로 비현실적인 일정, 인력 부족, 개발 도중 요구사항 변경, 품질 관리 부재, 낙관적인 희망을 듭니다.

하지만 이렇게 유명한 사람을 인용하지 않아도 이유를 충분히 이해하실 겁니다. 자신이 떠올린 확률와 평균을 비교해본다면요. 우리 프로젝트는 실패하는 70%에 들지 않으리라는 생각, 그 근거 없는 믿음 자체가 가장 큰 원인이 아닐까요.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 공동 역자 이해영 올림.