1

2006년 졸트상에 빛나는 역작이다. 번역도 잘되어 있다. 그리고 해당 주제에 대한 목록이 잘 정리되어 있어서 5년차 이상 개발자들은 읽어보면 좋은 내용이 많다. 특히 자신의 PM에 대한 관점이 조금은 달라보일지도 모른다. 만약, 달라보이지 않는다면 사직서를 준비하는게 좋을지도 모르겠지만…

1. 이렇듯 과거에 대한 연구를 통해 얻은 핵심 교훈은 다음 셋으로 요약할 수 있습니다. 1) 프로젝트 관리와 소프트웨어 개발은 신성한 예술이 아니다. […] 과거에서 배운 지식을 최대한 활용하고자 한다면, 기존 방식과 비교한 창조적인 고유성과 모방을 통한 파생성을 모두 고려하는 열린 자세가 필요합니다. 2) 시각을 단순화할수록 집중력과 성취도가 높아진다. […] 3) 단순함이 쉬움을 뜻하지 않는다.

2. 그렇다면 다른 사람의 실패에서 최대한 많은 교훈을 얻어내는 방법 밖에 없습니다. 다시말해 다른 이의 경험을 지렛대로 삼아야 합니다.

3. 많은 분야에서 유사한 프로세스를 발견할 수 있습니다. 모두가 계획, 실행, 다듬기에 시간을 할애합니다.

4. 이 직책을 맡은 사람은 명세서 작성, 마케팅 계획서 검토, 프로젝트 일정 수립, 팀 관리, 전략적 계획 수립, 버그/결함 선별, 팀 동기 고취를 비롯하여 아무도 하지 않는 다양한 임무를 기꺼이 수행해야 합니다. 마이크로소프트 사에서는 이런 새로운 직책을 프로그램 관리자라고 불렀습니다.

5. “스콧, 이런 자료도 좋네만 자네 프로젝트는 자네 팀이네. 체크리스트가 아니라 팀을 관리하게. 체크리스트가 팀 관리에 도움이 된다면 더할 나위 없겠지. 그런데 지금 자네 방식을 보아하니 조만간 팀이 체크리스트 관리를 도와야 할 듯 싶네.”

6. “스콧, 뭐해요?”라고 물으면, 저는 웃으며 대답합니다. “좋은 일이 일어나게 하는 중입니다.”

7. 아주 단순한 일정 수립 모델을 소개합니다. 우선, 전체 프로젝트 기간을 설계, 구현, 테스트라는 세 부분으로 나눕니다. […] 프로젝트 업무는 해야 할 일을 파악하거나, 계획한 일을 실제로 수행하거나, 해놓은 일을 검증/분석/개선하는 작업 중 하나에 속합니다.

8. 즉, 일정 예측이 시간이 지날수록 정확도가 증가한다는 사실을 프로젝트 관리자가 이해해야 합니다. 일정은 프로젝트를 진행해가면서 주의를 기울이고 조정해야 합니다.

9. 프로그래머가 에측값을 내놓기 망설일 때 제가 던지는 질문이 있습니다. “제가 어떤 질문에 대답해주면 예측하기가 좀더 편해지겠습니까?” 이렇게 물어서 프로그래머가 좀더 구체적인 생각을 하도록 유도합니다.

10. 요구사항을 작성하지 않는다면, 설계를 맡은 사람이 위험 부담을 짊어져야 합니다.

11. 그래서 설계와 요구사항 사이에는 피드백 순환이 있어야 합니다.

12. 창의적인 문제 해결과 과련하여 고려해야 할 질문 유형은 크게 세가지이며, 여기에는 주의를 집중시키는 질문, 창의적인 질문, 반문적인 질문(나쁨)이 있습니다.

13. 우수한 명세서는 단순합니다.

14. 다른 관리자를 교육하다 보니, 사람들은 자신이 겪지 못한 문제를 완전히 납득하기 어려워한다는 사실을 깨닫게 되었습니다. […] 무슨 이유에선지 자신에게는 해당하지 않는다고 믿더군요. 좀더 엄밀하게는, 자신이 겪었던 문제는 너무나 독특해서 불가피하게 다른 누구도 겪어보지 못했다고 믿습니다.