The Mythical Man-Month

소프트웨어 프로젝트들은 항상 늦어진다.

 

첫 번째 이유는 사람은 낙관적이기 때문이다. 그래서 일정을 설정하는데 오류를 범한다. 이러한 낙관론은 테스팅 단계에서 가장 크게 실패한다. 따라서 소프트웨어 일정을 잡을 때는

1/3: 디자인

1/6:코딩

1/2:테스팅

이런 식으로 코딩하는 시간은 1/6만 할애한다.

 

다음 이유는 프로젝트 매니저가 일정을 설정할 때 사람 명수에 따라 프로젝트 진행속도가 올라간다는 잘못된 가정을 하기 때문이다. 사람이 추가되면 사람을 교육하는데 드는 시간이 선형적으로 증가한다. 거기에 커뮤니케이션 비용은 지수적으로 증가하여 결국 사람을 추가하다 보면 프로젝트가 더 늦어지게 된다.

 

프로젝트가 늦어진 걸 아는 타이밍은 항상 데드라인이 얼마 남지 않은 마지막 기간이다. 이때 어떻게 대쳐 해야 할까. 요리사가 오믈렛이 2분 안에 된다고 했다. 하지만 시간이 부족하다면 손님에게는 두 가지 선택지가 있다. 기다리거나 덜 읽은 오믈렛을 먹거나. 프로그램의 고객에게도 마찬가지이다. 보통 프로젝트의 일정을 책임지는 사람들은 프로그래밍을 모른다. 이들의 요구에 맞추게 된다면 결국 오믈렛을 센 불에 익혀야 하고 한쪽은 타고 한쪽은 덜 익은 상태의 최악의 오믈렛을 서빙해야 하게 된다.

 

Regenerative Schedule Disaster

보통의 경우 프로젝트가 늦어졌을 때 다음과 같은 선택지들이 있다.

1. 마감 기한을 늘리지 않고 남은 기한을 고려해서 인원을 늘린다

2. 마감 기한을 늘리지 않고 앞에 있었던 딜레이가 남은 일에도 적용된다 가정하고 그를 고려하여 더 인원을 늘린다.

3. 기한을 늘린다. 충분히 기한을 늘려서 더 늦어지는 일이 없게 한다.

4. 프로젝트 범위를 조정한다.

앞의 두 경우는 반드시 실패한다. 새로 들어온 사람들은 교육을 받아야 하고 교육을 하는 사람의 man-month가 낭비된다. 그리고 다시 일을 쪼개야 하기 때문에 여기서 또 낭비가 발생한다. 그래서 결국에는 또 딜레이가 발생한다.

 

Brooks's Law

Adding manpower to a late software project makes it later

 

프로젝트가 늦어져서 사람을 늘릴때는 해당 사람이 얼마나 숙련되어 있는지 그리고 일을 얼마나 더 쪼갤 수 있는지를 고려해야 한다. 이를 고려하면 더 적은 사람을 추가하고 기한을 늘리는 식으로 스케줄을 다시 잡을 수 있을 것이다. 절대로 더 많은 사람과 더 적은 기한으로 마감기한을 설정할 수 없다.