저자들은 다양한 분야에서 소프트웨어 개발 프로젝트를 오랫동안 경험한 베테랑들이다. 6명이서 경력 합계가 150년이라고 한다. 그런 이들이 프로젝트에서 경험해 봄직한 86개 패턴들을 정리해 놓았다. 풍성한 사례와 직관적인 설명덕분에 이해하기 쉬웠다. 실패를 예방하고 바람직한 상황을 조성하기 위한 저자들의 노하우도 담겨 있었다. 프로젝트 관리자라면 꼭 한번 읽어보기를 권한다.

아래는 주요 패턴별로 기억해 놓고 싶은 문구를 기록해 놓았다.

패턴 1. 아드레날린 중독증
"모든 사안이 늘 긴급하지는 않다. 긴급함을 선별과 절제로 대체해야 한다."

패턴 2. 발바닥에 땀나도록 뛰어라
"시간의 촉박함을 본능적으로 아는 팀에서 나타나는 양상이다. 지연이야말로 진짜 위험으로 여긴다."

패턴 7. 내일
"마감일이 다가오면 모든 프로젝트 참가자가 제발 일주일만 더 있으면 좋겠다고 바란다. 훌륭한 프로젝트 관리자는 프로젝트 초반 시간을 프로젝트 후반 시간보다 더 귀중하게 여긴다"

패턴 9. 무드링 관리
"진행 중인 업무의 본질에 적합한 출시물 상태를 살펴 프로젝트 상태를 평가한다."
"예상치 못한 사고, 문제, 변경 계획에 초점을 맞춘다. 필요한 조치와 결정을 제시한다."
"보고하는 내용이 개별적이며, 지속적이지 않고, 정량적이다."
"객관적인 정보와 주관적인 판단을 균형 있게 제공한다."

패턴 13. 후보 선수 없음
"프로젝트에서는 시간이 돈보다 귀한 자원이다. 프로젝트 후반에 가면 시간을 돈으로 살 기회는 없다"

패턴 20. 한 놈만 팬다.
"자신에게 책임이 주어지면 사람들은 의욕이 높아진다. 그리고 모두가 자신이 언제 무엇을 해야 할지 안다. 좀더 중요하게는 동료가 언제 무엇을 하는지도 안다."

패턴 22. 소비에트 스타일
"고객이 요구하는 기능을 모두 넣어 출시했지만 고객이 싫어하는 바람에 제품이 곧바로 사장된다."
"프로젝트 초반부터 프로토타입을 활용하여 피드백을 얻으라. 비기능적인 품질을 높여 사용자가 좋아할만한 제품을 만들어라."

패턴 35. 테스트 전에 하는 테스트
"테스트는 테스트 이상이다"

패턴 45. 뉴스세탁
"조직이 나쁜 소식을 신속하고 정확하게 보고하는 능력을 높이려면 어떻게 해야 할까? 하나는 대처 방안을 모색하는 태도고 다른 하나는 원인을 파악하는 태고다."

패턴 52. 기능 수프
"기능 스프를 피하려면 규율과 통제가 필수적이다. 정작 스프에 빠지는 사람은 단편적인 기능을 요청한 사람이 아니라, 개발자 바로 자신이라는 사실을 명심하자."

기능 스프를 피하는 조직의 공통점
1. 프로젝트 목표와 비목표를 최대한 초반에 분명하게 정의한다.
2. 프로젝트 범위를 선언하고 항상 최신으로 유지한다. 입력 자료와 출력 자료를 명확하게 명시한다.
3. 명시된 목표와 무관하고 프로젝트 범위를 벗어나는 요구사항은 단호히 거부한다.
4. 새 요구사한은 변경 제어 절차를 따른다. 변경 제어 절차는 관련자가 승인했으며, 추적이 가능하고, 프로젝트 목표에 비춰 요구사항을 평가한다.

패턴 56. 전념
"두 가지를 한꺼번에 하면 IQ가 절반으로 떨어진다."

패턴 59. 매번 정시에 출시한다.
"개발 주기를 이끌어가려면 지속적으로 우선순위를 재조정하고 자원을 재할당해야 한다."

1. 사람 : 프로젝트에 누구를 할당할까?
2. 기술 : 팀이 어떤 프로세스, 방법론, 도구를 사용할까?
3. 범위 : 어떤 기능을 만들까? 어떤 플랫폼을 지원할까?
4. 일정 : 언제 출시할까?
5. 출시 품질 기준 : 출시하려면 제품이 어느 정도 완성도, 정확도, 견고함을 갖춰야 할까?

패턴 61. 고아 산출물
"때때로 팀은 아무도 관심 없는 산출물을 만드느라 시간을 낭비한다. 이때는 이 산출물의 후원자는 누구인가?라는 질문을 던질 필요가 있다."

패턴 65. 공동 교육
"고객은 자신의 지식을 제작자에게 제대로 전달하지 못한다."
- 고객은 자신의 업무에 너무도 익숙하야 뻔한 사실을 언급하지 않는다.
- 고객들은 의사소통 기술이 부족하다.
- 고객들은 자신의 필요한 내용을 잘 모른다.