• 매니지잇!
  • 최신기법으로 배우는 프로젝트 관리

  • 요한나 로스먼 지음
  • 신승환 옮김

  • IT Leaders 시리즈 _ 010
  • ISBN: 9788992939263
  • 22,000원 | 2010년 03월 10일 발행 | 416쪽



현대적인 프로젝트 관리에 적용할 수 있는 현실적인 가이드

여러분이 맡은 프로젝트는 절대로 실패해서는 안 된다. 아울러 PM으로서, 팀원으로서 엄청난 스트레스에 시달리지만, 그렇다고 자신만이 서로 옳다고 주장하는 방법론, 프로세스, 생애주기만을 선택해서, 절.대.성.공.해야 하는 프로젝트를 관리하고 싶지 않다.

백인백색이란 말처럼, 프로젝트마다 저마다의 사연이 있다. 따라서 프로젝트를 성공으로 이끄는 프로젝트 관리 방법을 적용하려면 프로젝트의 맥락(고객, 팀, 회사)을 파악하는 데서 시작해야 한다.

이 책은, 바로 프로젝트의 맥락을 파악하고, 프로젝트에 맥락에 가장 적당한 방법론을 선택하는 방법, 그리고 그 방법론을 프로젝트에 효과적으로 적용해서 프로젝트 성공을 거머쥘 수 있는 비법을 알려줄 것이다.

 

추천의 글

이 책을 읽으면서, 내가 겪었던 비슷한 경험이 생각났다. 그리고 이렇게 혼잣말을 했다. “이렇게 했다면 어땠을까?” 책을 읽으면서 이런 혼잣말을 계속했다. 이 책은 내가 읽었던 최고의 IT 서적 가운데 하나며, 저자의 성품도 엿볼 수 있다. 여러분은 이 책을 읽으면서, 저자의 숨결을 느낄 것이다.

-- 에릭 피터슨, Emprove 선임 컨설턴트

20년 동안 프로젝트 관리를 하면서, 프로젝트 관리자들이 명심해야 하는 비법들이 있었다. 저자는 관리 비법 가운데 많은 것을 이 책에 실었다. 회의관리를 다루는 장만으로도 이 책은 충분한 가치가 있다. 이 책을 읽고, 이 책에서 설명하는 원칙들을 실천하라. 그렇게 한다면, 팀원들은 당신이 정말로 스마트하다고 생각할 것이다.

-- 드웨인 필립스, 시스템 선임 엔지니어

프로젝트마다 독특하다. 이 이야기는, 프로젝트를 관리하려면 하나 이상의 방법이 필요하다는 것을 설명해준다. 저자는 자신의 사고과정을 친절히 보여주면서, 프로젝트의 맥락을 평가하고, 생애주기를 선택하고, 프로젝트의 기준을 명확하게 수립하는 방법을 설명한다. 저자의 도움말 덕분에, 여러분은 프로젝트를 성공하게 하는 선택을 할 것이다.

-- 에스더 더비, esther derby associates 대표

수많은 기법, 실천방법, 듣고 싶지 않은 충고들이 프로젝트 관리란 이렇게 저렇게 하라고 여러분을 괴롭힌다. 그리고 이것들은 이렇게 말한다. “잘 들어봐! 내 말이 맞거든!”

물론, 그런 이야기 중에 맞는 것도 있다. 즉 조건만 맞는다면 말이다. 하지만 프로젝트마다 특징이 다르기 때문에, 여러분이 놓인 맥락(프로젝트, 팀, 회사)을 반드시 평가하고 나서 어떤 방법이 효과가 있고 어떤 방법이 소용 없는지 실용적인 선택을 해야 한다.

이 책은 소프트웨어 프로젝트란 무엇이며, 프로젝트에서 발생하는 위험과, 프로젝트를 시작하면서 동반하는 위험을 관리하는 통찰력을 제공해준다. 프로젝트 헌장 작성에서 출시까지, 각 장마다 여러분이 소프트웨어 개발 프로젝트에서 접할 수 있는 방법을 알려준다. 이런 방법들을 평가하고, 느끼고, 음미하고 즐기길 바란다.

모든 프로젝트에 적용되는 방법은 존재하지 않는다. 다만, 여러분과 팀이 목표를 달성하게 도와주는 생애주기에 적절한 실천방법들만이 있을 뿐이다.

  • 생애주기를 계획하고 사용하는 방법
  • 일정 게임을 피하는 방법
  • 위대한 팀을 구성하고 유지하는 방법
  • 회의를 관리하는 방법
  • 다수의 프로젝트, 프로그램을 관리하는 방법

이 책은 프로젝트를 계획하고 운영할 때 뛰어난 결정을 내리도록 프로젝트 위험을 기반으로 한 가이드를 제공한다. 여기에서 설명하는 내용은 프로젝트 관리자, 팀원, 프로젝트가 성공하도록 계획하고 조정하는 소프트웨어 관리자에게 분명히 큰 도움이 될 것이다.

요한나 로스먼(Johanna Rothman)

요한나 로스먼은 하이테크 제품 개발 관리에 대해서 컨설팅, 강연, 집필을 하고 있다. 실용적인 프로젝트 관리 분야에서 로스먼의 풍부한 경험 덕분에 고객들은 프로젝트를 성공적으로 마쳤으며 수십억을 절약할 수 있었다. 로스먼은 150개가 넘는 기사와 논문을 작성했고, 블로그 두 곳을 운영하고 있으며, Better Software, Computerworld.com, StickMinds.com에 글을 쓴다. 로스먼은 ‘Hiring the Best Knowledge Workers, Techies & Nerds’를 집필했고, 공동으로 ‘실천가를 위한 실용주의 프로젝트 관리(원제: Behind Closed Doors)’와 ‘Corrective Action for the Software Industry’을 집필하였다.

신승환

신승환은 소프트웨어 개발, 프로젝트 관리, 프로세스 컨설팅 등의 업무를 십 년간 수행했으며, 현재는 차량용 임베디드 소프트웨어를 만들고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)에 꾸준히 남기려고 노력한다. 지은 책으로는 ‘겸손한 개발자가 만든 거만한 소프트웨어’와 ‘도와주세요! 팀장이 됐어요’가 있으며, 다수의 IT서적을 번역하였다.

 

옮긴이 글

프로젝트 관리란 무엇일까요?

이 질문에 대한 제 대답은, 프로젝트 관리자(Project Manager, PM)로서 프로젝트를 하나씩 끝날 때마다 조금씩 바뀌는 듯합니다. 제일 처음 프로젝트를 맡았을 때, 프로젝트를 끝내는 데 초점을 맞췄죠. 그렇기 때문에, 프로젝트 내에서 개발할 기능을 개발하는 게 중요했으므로 ‘기능 개발관리’=’프로젝트 관리’라고 생각했습니다.

시간이 흘러 회사에서 PMBOK 형태의 프로젝트 관리 체계를 강조했을 때, 정해진 절차에 따라서 계획을 세우고 관리하는 게 매우 중요해졌습니다. 따라서 기능 개발보다 프로젝트 계획을 준수하려고 노력했습니다.

프로젝트라는 게 변화무쌍한 유기체 비슷하고, 장기 계획의 정확성이 낮다는 것을 깨달았을 때, 변화를 관리하는 게 중요하고 그래서 애자일 실천방법을 프로젝트에 적용하는 것에 중점을 두었죠.

그리고 최근에 드는 생각은, 특히 SI 프로젝트라면, 다양한 이해당사자(stakeholder)들의 힘 벡터가 평형을 이루는 지점에 시스템이 완성된다는 것입니다. 즉 프로젝트의 자금을 대는 스폰서의 벡터가 크다면, 시스템은 최종 사용자 쓰기 어려운 거만한 소프트웨어가 되거나. 프로젝트 팀원들의 벡터가 지나치게 큰 경우, 그들만의 잔치로 끝나는 경우가 있죠.

결국 이해당사자들의 요구사항을 잘 파악하는 것에 덧붙여서 프로젝트의 주변환경을 정확하게 파악하는 것이 프로젝트 성공에 핵심이죠. 즉 프로젝트를 성공으로 이끌려면 흔히들 말하는 프로젝트의 맥락(context)를 파악하는 작업이 무척 중요하다는 게 요즘 드는 생각입니다.

이 책은 다른 프로젝트 관리 서적에서 소홀히 다루었던 프로젝트의 맥락을 파악하는 데서 프로젝트를 시작하라고 충고하죠. 그리고 프로젝트의 맥락을 충분하게 살피고, 프로젝트를 성공으로 이끄는 관리방법을 선택해서 적용하는 방법을 알려줍니다.

아울러, 정형화된 프로젝트 관리방법을 적용하면서 염증을 느끼신 분들이나, 애자일 실천방법을 알지만 현실에 적용하면서 적당한 지침이 없어서 곤란했던 분들에게, 실용적인 프로젝트 관리 지침으로서 이 책이 유용할 것입니다.

아무쪼록 이 책에 있는 지식들이, 함정과 암초가 똬리를 트고 있는 험난한 프로젝트 던전에서, 독자 여러분들을 가슴뭉클한 엔딩으로 안내해주길 바라겠습니다. 감사합니다.

  • 01장 프로젝트 시작하기
    • 1.1 프로젝트, 프로젝트 관리자란 무엇인가
    • 1.2 견인인자, 제한인자, 변동인자 관리하기
    • 1.3 고객이나 후원자와 함께 프로젝트 제한인자에 대해 이야기하기
    • 1.4 프로젝트에 있는 견인인자 결정하기
    • 1.5 프로젝트에서 원하는 게 많은 후원자 관리하기
    • 1.6 프로젝트 헌장을 작성해서 의사결정 내용 공유하기
    • 1.7 프로젝트에서 품질이 뜻하는 바를 파악하라
  •  
  • 02장 프로젝트 계획하기
    • 2.1 시작하기
    • 2.2 시작하기에 적당한 정도로만 계획하기
    • 2.3 프로젝트 계획 양식 만들기
    • 2.4 출시 기준 정의하기
    • 2.5 출시 기준 사용하기
    •  
  • 03장 생애주기를 사용해서 프로젝트 설계하기
    • 3.1 프로젝트 생애주기 이해하기
    • 3.2 생애주기 개요
    • 3.3 프로젝트에서 피드백 받아보기
    • 3.4 대규모 프로젝트에서는 다양한 방식으로 생애주기를 조합할 수 있다.
    • 3.5 아키텍처 위험 관리하기
    • 3.6 폭포수 생애주기를 유용하게 하는 방법
    • 3.7 내가 가장 좋아하는 생애주기
    •  
  • 04장 프로젝트 일정잡기
    • 4.1 프로젝트 일정을 수립하는 실용적인 접근방법
    • 4.2 일정잡기 방법 선택하기
    • 4.3 사무용품을 활용해서 일정잡기 시작하기
    •  
  • 05장 작업량 예측하기
    • 5.1 프로젝트를 예측하는 실용적인 접근방법
    • 5.2 마일스톤은 프로젝트 범위를 정의한다
    • 5.3 얼마나 적게 일할 수 있을까?
    • 5.4 멀티태스킹 상황에서 예측하기
    • 5.5 고의적으로 멀티태스킹을 하도록 일정 수립하기
    • 5.6 ‘연동 계획하기’ 사용하기
    • 5.7 반복주기 기간을 정하기
    • 5.8 가능하다면 인치페블을 사용해서 예측하기
    •  
  • 06장 일정 게임을 파악하고 막아내기
    • 6.1 일정을 다시 작성하게!
    • 6.2 희망만이 살길이다!
    • 6.3 현실부정의 관리자
    • 6.4 눈 가리고 아웅
    • 6.5 운 좋은 완료일
    • 6.6 불붙은 엉덩이
    • 6.7 쪼개진 과녁
    • 6.8 일정은 판결문이다
    • 6.9 거기로 갈까? 아니면 저기?
    • 6.1 일정 관리도구는 항상 옳다. 혹은 꿈 같은 일정
    • 6.11 구현하거나 죽거나
    • 6.12 ‘아니요’는 죽어도 안되죠.
    • 6.13 치킨 게임
    • 6.14 90퍼센트 완료
    • 6.15 내일은 더 괜찮아질 거야
    • 6.16 일정에 최면이 걸리다
    •  
  • 07장 탁월한 팀 만들기
    • 7.1 팀원 고용하기
    • 7.2 팀원들이 단합하도록 돕기
    • 7.3 회사 지원 얻어내기
    • 7.4 필요한 팀의 규모를 파악하라
    • 7.5 인원을 추가할 시점을 파악하라
    • 7.6 위대한 프로젝트 관리자로 거듭나기
    • 7.7 떠나야 할 때를 알아라
    •  
  • 08장 프로젝트 조정하기
    • 8.1 프로젝트 리듬을 사용해서 프로젝트를 조정하라
    • 8.2 임시 회고 사용하기
    • 8.3 요구사항에 우선순위 부여하기
    • 8.4 요구사항 작업에 타임박스를 적용하라
    • 8.5 반복주기에 4주나 4주 이하의 타임박스 적용하기
    • 8.6 연동 계획하기와 연동 일정잡기 사용하기
    • 8.7 교차 기능 프로젝트 팀 만들기
    • 8.8 프로젝트의 위험을 근거로 생애 주기를 선택하라
    • 8.9 적당한 근무시간을 지켜라
    • 8.1 인치페블을 사용하라
    • 8.11 작업 훼방 관리하기
    • 8.12 프로젝트 초기에 발생하는 결함 관리하기
    •  
  • 09장 프로젝트 리듬 유지하기
    • 9.1 프로젝트에 지속적인 통합 적용/변형하기
    • 9.2 빌드 작업에 자동화된 스모크 테스트 만들기
    • 9.3 아키텍처 수준이 아니라 기능 단위로 구현하라
    • 9.4 제품을 철저히 검토하자
    • 9.5 리팩터링을 계획하라
    • 9.6 유스 케이스, 사용자 스토리, 페르소나, 시나리오를 활용해서 요구사항을 정의하라
    • 9.7 요구사항에서 GUI 설계를 분리하라
    • 9.8 가능한 오랫동안 엉성한 프로토타이핑을 사용하라
    •  
  • 10장 회의 관리하기
    • 10.1 이런 회의라면 취소하라
    • 10.2 이런 회의를 실행하라
    • 10.3 프로젝트 킥오프 회의
    • 10.4 출시 계획하기 회의
    • 10.5 진행 상황 보고 회의
    • 10.6 경영층에게 진행 상황 보고하기
    • 10.7 프로젝트 팀 회의
    • 10.8 반복주기 검토 회의
    • 10.9 회의에서 문제점 해결하기
    • 10.1 전화회의 관리하기
    •  
  • 11장 프로젝트 대시보드를 만들고 사용하기
    • 11.1 측정은 위험할 수 있다
    • 11.2 프로젝트 완료를 향한 진척도 측정하기
    • 11.3 후원자를 위한 프로젝트 대시보드 꾸미기
    • 11.4 프로젝트 날씨 보고서를 사용하라
    •  
  • 12장 멀티사이트 프로젝트 관리하기
    • 12.1 질문을 하면 손실이 발생한다고요?
    • 12.2 프로젝트에 존재하는 문화적 차이를 찾아내라
    • 12.3 팀 사이에서 신뢰 구축하기
    • 12.4 팀 단위로 서로 보완하는 실천방법을 사용하세요.
    • 12.5 잠재적인 다문화 문제를 찾아라
    • 12.6 아웃소싱할 때 피해야 할 실수
    •  
  • 13장 프로젝트에 테스트 통합하기
    • 13.1 팀원들이 기술 빚을 줄이려는 마음으로 시작하게 하라
    • 13.2 간단한 테스트를 사용해서 위험을 줄여라
    • 13.3 TDD는 프로젝트에 테스트를 도입하는 가장 쉬운 방법이다
    • 13.4 다양한 종류의 테스트 기술을 사용하라
    • 13.5 팀원마다 테스트 역할을 정의하자
    • 13.6 적당한 개발자와 테스트 비율은?
    • 13.7 개발과 테스트를 동시에 진행하라
    • 13.8 프로젝트에 적합한 테스트 전략을 정의하라
    • 13.9 시스템 테스트 전략 템플릿
    • 13.1 QA와 테스트의 차이
    •  
  • 14장 프로그램 관리하기
    • 14.1 프로젝트가 프로그램일 때
    • 14.2 서로 관련된 여러 프로젝트를 하나의 출시로 구성하기
    • 14.3 프로그램을 진행하면서 관련된 프로젝트들 정리하기
    • 14.4 프로젝트 관리자 관리하기
    • 14.5 프로그램 대시보드 만들기
    •  
  • 15장 프로젝트 완료하기
    • 15.1 출시를 앞당겨 달라는 요청을 관리하라
    • 15.2 베타 출시 관리하기
    • 15.3 출시일을 준수하지 못한다는 것을 알았을 때
    • 15.4 프로젝트 완료하기
    • 15.5 프로젝트 취소하기
    •  
  • 16장 프로젝트 포트폴리오 관리하기
    • 16.1 전체 프로젝트를 담은 포트폴리오를 만들어라
    • 16.2 프로젝트를 평가하라
    • 16.3 당장에 자금을 지원할 프로젝트를 결정하라
    • 16.4 포트폴리오에 순서를 매겨라
    • 16.5 프로젝트 더 일찍 시작하라
    • 16.6 제품 백로그를 사용해서 새로운 기능에 대한 요구를 관리하라
    • 16.7 포트폴리오 관리 문제점 해결하기
    •  
  • 부록 A 연속적인 생애주기: 폭포수 방법 또는 단계-게이트 방법
    • A.1 연속적인 생애주기: 폭포수 방법 또는 단계-게이트 방법
    • A.2 반복적인 생애주기: 나선형, 점진적인 프로토타이핑, 유니파이드 프로세스
    • A.3 점진적인 생애주기: 단계별 인도, 디자인-스케줄
    • A.4 애자일 생애주기
    •  
  • 부록 B 용어 정리
  • 부록 C 참고 자료
  • 11쪽 맨 아래 줄

    9쪽 1.4절에 있는 ---> 10쪽에 있는

  • 13쪽 맨 위 제목과 내용에서

    맥락에 독립적인 질문 ---> 맥락에 자유로운 질문(context-free question)

  • 13쪽 3번째 줄

    암묵적으로 내리는 ---> 암묵적으로 판단하는

  • 49쪽 그림 3.6 두 번째 화살표 설명에서

    타임박스가 끝날 때마 ---> 타임박스가 끝날 때마다

  • 51쪽 두 번째 단락 첫째 줄

    펌웨어를 맥락에 의존하는 ---> 펌웨어를 상황에 따라

  • 74쪽 첫째 줄

    않 다 ---> 않다

관련 글


엮인 글

엮인 글 주소: http://wikibook.co.kr/manage-it/trackback/