프레더릭 브룩스의 '맨먼스 미신'의 초판에 언급된 격언 -이라 불러도 충분할 말- 들.
소프트웨어 개발자가 아닌 탓에 읽기가 결코 쉽지 않은 책이었다. 그런데도 이 책 다음에 '애자일 회고'라는 책을 읽고 있다. 이 책들은 기본적으로 개발자를 위한 책이지만, 그렇다고 개발자에 한정되는 것은 결코 아니다.
1975년에 브룩스가 제시한 것들의 대부분은 30년이 넘게 지난 지금도 여전히 유효하다. 소프트웨어 프로젝트에 있어서, 아니 모든 일에 있어서 역시 으뜸이 될만큼 중요한 것은 커뮤니케이션이다. 이것만은 아무리 강조해도 지나치지 않다. 누구나 커뮤니케이션의 중요성을 알고 있다는 것은 역설적으로 '아무나' 성공적인 커뮤니케이션을 하는 것은 아니라는 반증이다.
류한석 소프트뱅크 소장이 '좋은 관리를 받아보지 못한 사람이 좋은 관리자가 될 수 있을까'하는 질문을 던진 적이 있다. 이 질문은 나에게도 유효하다.
관련글: 10명의 일을 20명이 하면 시간이 절반으로 줄까?
날짜에 쫓겨 프로그래밍 프로젝트가 실패하는 경우가 다른 모든 실패 원인을 다 합친 경우보다 많다.
프로그래머들은 순수한 사고물을 구축하기 때문에 구현하는 데 어려움이 거의 없을 것이라고 기대한다. 하지만 우리의 아이디어 자체는 오류가 많으며, 그래서 버그가 생긴다.
저자는 어림잡아 전체 일정의 1/3을 설계에, 1/6을 코드작업에, 1/4를 컴포넌트 테스트에, 1/4를 시스템 테스트에 각각 할당한다.
브룩스의 법칙: 일정이 늦어진 소프트웨어 프로젝트에 인력을 추가하면 일정이 오히려 더 늦어진다.
소프트웨어 프로젝트에 사람을 추가하면 필요한 총 노동력이 다음과 같은 세 가지 측면에서 증가한다. 작업과 혼란이 계속 반복되고, 새로운 사람을 훈련시켜야 하며, 상호 의사소통이 늘어난다.
적은 수로 구성된 똑똑한 팀이 최고다 - 가능한 머리수가 적을수록.
리더를 포함해서 두 사람으로 된 팀이 두뇌를 최고로 활용하는 경우가 많다.
적은 수로 구성된 똑똑한 팀은 초대형 시스템 작업을 하기에는 오히려 너무 느리다.
대부분 초대형 시스템 개발 경험에 비추어볼 때, 인원수만 늘리는 난폭한 접근법은 비용이 많이 들며, 비효율적이며, 개념적 무결성을 갖추지 못한 시스템을 낳는다.
개념적 무결성을 얻으려면, 한 사람의 두뇌에 의해서 또는 의견이 잘 맞는 소수그룹에 의해 설계가 진행되어야 한다.
바벨탑 프로젝트는 커뮤니케이션의 부재 그리고 그로 인한 조직의 부재 탓에 실패했다.
"일정 참사, 기능적 부적합성, 시스템 버그, 이 모든 것은 오른손이 하는 일을 왼손이 모르기 때문에 발생한다." 각 팀은 단지 추측만 하다가 흩어진다.
프로젝트 관리자의 기본 임무는 모든 사람이 같은 방향으로 가도록 유지하는 것이다.
프로젝트 관리자의 주된 일상 업무는 결정 내리기가 아니라 커뮤니케이션이다. 계획과 결정사항들은 문서를 통해 팀 전체에 전달된다.
유지 관리 비용은 사용자 수에 크게 좌우된다. 사용자가 많을수록 버그도 많이 발견한다.
큰 참사보다 매일 조금씩 일정이 지체되는 것은 인식하기도, 예방하기도 그리고 만회하기도 훨씬 어렵다.
소프트웨어 공학의 진흙 구덩이는 앞으로도 오랫동안 헤쳐 나오기 힘들 것이다.
프로그래머들은 순수한 사고물을 구축하기 때문에 구현하는 데 어려움이 거의 없을 것이라고 기대한다. 하지만 우리의 아이디어 자체는 오류가 많으며, 그래서 버그가 생긴다.
저자는 어림잡아 전체 일정의 1/3을 설계에, 1/6을 코드작업에, 1/4를 컴포넌트 테스트에, 1/4를 시스템 테스트에 각각 할당한다.
브룩스의 법칙: 일정이 늦어진 소프트웨어 프로젝트에 인력을 추가하면 일정이 오히려 더 늦어진다.
소프트웨어 프로젝트에 사람을 추가하면 필요한 총 노동력이 다음과 같은 세 가지 측면에서 증가한다. 작업과 혼란이 계속 반복되고, 새로운 사람을 훈련시켜야 하며, 상호 의사소통이 늘어난다.
적은 수로 구성된 똑똑한 팀이 최고다 - 가능한 머리수가 적을수록.
리더를 포함해서 두 사람으로 된 팀이 두뇌를 최고로 활용하는 경우가 많다.
적은 수로 구성된 똑똑한 팀은 초대형 시스템 작업을 하기에는 오히려 너무 느리다.
대부분 초대형 시스템 개발 경험에 비추어볼 때, 인원수만 늘리는 난폭한 접근법은 비용이 많이 들며, 비효율적이며, 개념적 무결성을 갖추지 못한 시스템을 낳는다.
개념적 무결성을 얻으려면, 한 사람의 두뇌에 의해서 또는 의견이 잘 맞는 소수그룹에 의해 설계가 진행되어야 한다.
바벨탑 프로젝트는 커뮤니케이션의 부재 그리고 그로 인한 조직의 부재 탓에 실패했다.
"일정 참사, 기능적 부적합성, 시스템 버그, 이 모든 것은 오른손이 하는 일을 왼손이 모르기 때문에 발생한다." 각 팀은 단지 추측만 하다가 흩어진다.
프로젝트 관리자의 기본 임무는 모든 사람이 같은 방향으로 가도록 유지하는 것이다.
프로젝트 관리자의 주된 일상 업무는 결정 내리기가 아니라 커뮤니케이션이다. 계획과 결정사항들은 문서를 통해 팀 전체에 전달된다.
유지 관리 비용은 사용자 수에 크게 좌우된다. 사용자가 많을수록 버그도 많이 발견한다.
큰 참사보다 매일 조금씩 일정이 지체되는 것은 인식하기도, 예방하기도 그리고 만회하기도 훨씬 어렵다.
소프트웨어 공학의 진흙 구덩이는 앞으로도 오랫동안 헤쳐 나오기 힘들 것이다.
소프트웨어 개발자가 아닌 탓에 읽기가 결코 쉽지 않은 책이었다. 그런데도 이 책 다음에 '애자일 회고'라는 책을 읽고 있다. 이 책들은 기본적으로 개발자를 위한 책이지만, 그렇다고 개발자에 한정되는 것은 결코 아니다.
1975년에 브룩스가 제시한 것들의 대부분은 30년이 넘게 지난 지금도 여전히 유효하다. 소프트웨어 프로젝트에 있어서, 아니 모든 일에 있어서 역시 으뜸이 될만큼 중요한 것은 커뮤니케이션이다. 이것만은 아무리 강조해도 지나치지 않다. 누구나 커뮤니케이션의 중요성을 알고 있다는 것은 역설적으로 '아무나' 성공적인 커뮤니케이션을 하는 것은 아니라는 반증이다.
류한석 소프트뱅크 소장이 '좋은 관리를 받아보지 못한 사람이 좋은 관리자가 될 수 있을까'하는 질문을 던진 적이 있다. 이 질문은 나에게도 유효하다.
관련글: 10명의 일을 20명이 하면 시간이 절반으로 줄까?
