출간된 지 무려 20년이 지난 책이고 해서, 줄곧 내 돈 주고 사 보기는 위험천만하다 생각하고 있었다. 아무리 뛰어난 통찰력을 자랑한다 해도, IT 관련 책을 20년 후에 읽는다는 건 아무래도 좀..
결국은 (빌려서) 읽어본 감상은 그럭저럭 나쁘지 않은 편이다. 역시 끝까지 집중하며 읽기는 버거웠지만, 몇 가지 꼭지는 놀라울 정도로 (20년 후의) 현실과 부합한다. 20년간 여전히 제자리 걸음인 부분도 분명히 있다는 거.
특히, ‘진흙 구덩이’, ‘맨먼스 미신’, ‘수술 팀’ 이 세 꼭지는 업계에 있는 사람이라면, 누구나 고개를 끄덕일 거라고 본다.
소프트웨어 프로젝트가 실패하는 가장 흔한 이유는 일정을 맞추지 못하는 데 있다. … 왜 이럴까?
첫째, ‘모든 것이 일정대로 제대로 진행될 것’이라는, 전혀 현실적이지 못한 전제가 알게 모르게 프로젝트 진행과정에 개입된다.
둘째, 인력(man)과 작업기간(month)이 상호 교환 가능한 관계라는, 정확하지 않은 가정을 바탕에 깔고 있는 것이다.
다섯째, 일정이 공전되고 있다는 것을 깨달을 때, 뻔한(그리고 전통적인) 대응방법은 그저 인력을 더 많이 투입하는 것이다. 이는 마치 불에 기름을 붓듯이 상황을 더욱 그것도 아주 심하게 악화시킬 뿐이다.
1/3 : 계획
1/6 : 코딩작업
1/4 : 컴포넌트 테스트와 초기 시스템 테스트
1/4 시스템 테스트, 모든 컴포넌트 입수.
그의 팀이 일하는 시간의 50%만 실제 프로그래밍 작업과 디버깅 작업시간으로 쓰였다는 사실을 발견할 수 있었다. … 나머지 시간은 머신이 작동을 멈춘 시간, 우선순위가 더 높지만 작업과는 관계없는 회의들, 회의, 문서 작업, 회사 일, 병, 개인 시간 등에 쓰였다.
위의 인용은 내 경험상 매우 – 거의 100%에 가깝게 - 현실적이다.
p.s. 일상(?)에서 흔히 쓰이는 Man-month라는 단어가 실제로 영어권에 존재하는 단어인지를 안 것도 이 책 덕분이다. 그 전까지는 콩글리시거나 적어도 일본식 조어라고 생각 – 아니 확신 - 했었다.