HOME > 상세정보

상세정보

PM의 변(辯) : 능력없는 프로젝트 관리자의 변명 (6회 대출)

자료유형
단행본
개인저자
나피엠
서명 / 저자사항
PM의 변(辯) : 능력없는 프로젝트 관리자의 변명 / 저자: 나피엠.
발행사항
서울 :   비팬북스 ,   2010.  
형태사항
289 p. : 삽도 ; 22 cm.
ISBN
9788996204572
일반주기
색인 및 부록수록  
000 00629camccc200229 k 4500
001 000045602165
005 20100805073111
007 ta
008 100713s2010 ulka 001c kor
020 ▼a 9788996204572
035 ▼a (KERIS)BIB000012045384
040 ▼a 244004 ▼c 244004 ▼d 222001 ▼d 211009
082 0 4 ▼a 658.404 ▼2 22
090 ▼a 658.404 ▼b 2010z2
100 1 ▼a 나피엠
245 1 0 ▼a PM의 변(辯) : ▼b 능력없는 프로젝트 관리자의 변명 / ▼d 저자: 나피엠.
260 ▼a 서울 : ▼b 비팬북스 , ▼c 2010.
300 ▼a 289 p. : ▼b 삽도 ; ▼c 22 cm.
500 ▼a 색인 및 부록수록
940 ▼a 피엠의 변
945 ▼a KLPA

소장정보

No. 소장처 청구기호 등록번호 도서상태 반납예정일 예약 서비스
No. 1 소장처 과학도서관/Sci-Info(1층서고)/ 청구기호 658.404 2010z2 등록번호 121196599 (5회 대출) 도서상태 대출가능 반납예정일 예약 서비스 B M
No. 2 소장처 과학도서관/Sci-Info(1층서고)/ 청구기호 658.404 2010z2 등록번호 121196600 (1회 대출) 도서상태 대출가능 반납예정일 예약 서비스 B M

컨텐츠정보

책소개

다양한 프로젝트 현장에서 PM으로 일해 해 온 저자의 경험을 이야기 형식으로 펼쳐낸 책이다. 대부분의 프로젝트는 WBS 단위로 진행되며, 주별로 PM이 해야 할 일과 그 일을 하는 와중에 일어나는 다양한 사건들을 가상의 주인공인 나피엠이 어떻게 해결해 나가는지 이야기하였다. 또한, 사건을 해결해 나가는 과정을 수기 형식으로 이야기하는 가운데 프로젝트 관리에 필요한 요소들을 하나씩 짚어준다.

이 책은 십 수 년 동안 다양한 프로젝트 현장에서 PM으로 일해 해 온 저자의 경험을 이야기 형식으로 펼쳐냈습니다.

대부분의 프로젝트는 WBS 단위로 진행됩니다. 그래서 이 책도 주별로 PM이 해야 할 일과 그 일을 하는 와중에 일어나는 다양한 사건들을 가상의 주인공인 나피엠이 어떻게 해결해 나가는지 이야기합니다.

일반적인 프로젝트 관리 서적은 프로젝트 관리 기법을 이론 중심으로 설명하지만, 이 책은 사건을 해결해 나가는 과정을 수기 형식으로 이야기하는 가운데 프로젝트 관리에 필요한 요소들을 하나씩 짚어나갑니다.

프로젝트의 궁극적인 목적은 그랜드 오픈일에 제대로 오픈하는 것입니다. 이를 위해서는 개발자, 고객, 감리, PL, PM, PMO, 관리자, 경영자가 모두 혼연일체가 되어야 합니다. 따라서 이 책은 PM만의 이야기가 아니라, 이 땅에서 프로젝트에 직간접적으로 참여하는 모든 이들을 위한 이야기입니다.

처음 저자가 제시한 원고의 제목에는 ‘소설’이라는 단어와 ‘대한민국’이라는 단어가 있었다. 또, ‘비겁한’이라는 단어도 있었다. 저자는 별로 비겁해 보이지 않는데 ‘비겁한’이라는 단어를 넣고 싶어 한 것을 보면 그는 ‘겸손’한 듯하다. 그리고 ‘대한민국’이라는 단어에서는 그가 이 나라를 사랑한다는 생각도 살짝 든다. 또한 ‘소설’이라는 단어를 넣고 싶어 한 것을 보면 한 때 소설가가 꿈이었을지도 모르겠다. 아니면 소설을 쓰고 읽듯이 프로젝트를 재미있게 하고 싶은 소망을 가지고 있는지도 모르겠다. (사실, 이 책은 소설에 가깝다.)

저자의 그러한 소망이 이루어지는 데 이 책이 작은 힘이 되었으면 한다. 또한 낮과 밤을 밝히는 개발자들과 그러한 개발자들과 함께 하는 PM들의 열정이 보태진다면 이것이 꼭 소망으로만 머물러 있지 않을 것이다. 저자의 말로 서평을 마무리한다.

[ 이 책의 기타 특징들 ]
- 월별/주별, 어떤 공정으로 프로젝트가 진행되는지 알 수 있습니다.
- 분석부터 이행까지 프로젝트 진행 도중에 발생하는 다양한 이슈를 알고 해결의 단초를 제시받을 수 있습니다.
- 소프트웨어 업계가 안고 있는 문제점과 해결책을 제시합니다.
- 방법론에 대해 자연스럽게 이해할 수 있습니다.
- 프로젝트 관리 이론과 기법을 체득하게 됩니다.
- 소프트웨어 공학의 다양한 이론을 이야기로 읽을 수 있습니다.
- 대규모 프로젝트에 참여해 보지 않았어도 프로젝트에 여러 번 참여한 사람처럼 될 수 있습니다.
- 필자가 제안하는 신선한 방법론의 아이디어를 엿볼 수 있다.
- 마지막으로, 재미있어서 금방 읽을 수 있습니다.

[이 책의 대상 독자]
1. 프로젝트의 고객과 원청 수주사의 담당자
2. PM과 PMO
3. PL
4. 개발자와 코더와 제품 디자이너
5. 의사결정자(경영자)
6. IT 관리자
7. 감리 담당자
8. 프로젝트 영업 담당자
9. 소프트웨어 공학과 프로젝트 관리를 배우는 모든 이들
10. 프로젝트의 흐름을 알아야 하는 모든 이들


정보제공 : Aladin

저자소개

나피엠(지은이)

18년 넘게 현장에서 프로젝트 관리자로 일하면서, 공공, 금융, 일반 기업 등에서 중대형 프로젝트만 약 20여 개 수행하였다. 저자는 프로젝트 관리, 방법론, 프로세스 개선 방법을 현장에 적용하고 효과를 내는 일에 특히 많은 관심을 가지고 있으며, 프로젝트를 사랑하는 평범한 프로젝트 관리자다. 저서로는 <프로젝트 관리자를 위한 PMBOK 활용(비팬북스)>, <PM의 변(비팬북스)>이 있다.

정보제공 : Aladin

목차

목차
들어가기 전에 = 2
목차 = 4
등장 회사와 인물 소개 = 13
M-1, W1 사전 준비: RFP 검토 및 계획 수립 = 18
 나피엠, 신규 프로젝트 PM 선정 = 18
 영업 히스토리=영업 회의록 = 19
 6억 5천과 5억 5천 = 19
 본, MM, 최소 금액 계산: 복병 '등'과 '각종' = 20
M-1, W2 사전 준비: 제안서 작성 = 24
 제안 룸 = 24
 보안 프로그램 설치 = 25
 제안 요약서와 제안서 = 25
 제안서 작성 기간: 1주일, 길다! = 26
 제안서 분량 목표: 40→37(20→25→32→36→37) = 26
 제안 요약서 분량 목표: 2 = 29
 보안 프로그램 삭제 포기. 노트북 포맷 = 30
M-1, W3 사전 준비: 제안서 PT와 프로젝트 팀 구성 = 31
 제안서 PT 시작 = 31
 RFP의 목적, 목표, 결과 = 32
 고객이 원하는 특장점은? = 32
 제안서 PT 룸의 풍경 = 33
 제안서 PT 결과: 기술<가격 = 34
 프로젝트 팀 구성: PL과 개발자 확보하기 = 35
M-1, W4 사전 준비: 본사 착수 보고 = 37
 본사 착수 보고 준비 = 37
 프로젝트 비용, DC 된다! = 38
 10% 이익 내기, 궁리 끝에... = 39
 본사 보고용 프로젝트 관리 계획서 결제 받기 = 42
M+1, W5 준비: 개발자 환경 준비와 개발 환경 설정 = 46
 착수 보고용 프로젝트 관리 계획서 작성 = 46
 방법론과 산출물 양식 = 47
 프로젝트 룸과 환경 구축 = 48
 나피엠의 소고: 방법론 = 48
 사무실 환경 설정 시 확인 사항 = 50
 착수 보고 준비 = 51
 착수 보고 = 52
 착수 보고 회식 = 53
 업무 별 주간 보고와 수행 팀 주간 보고 = 54
M+1, W6 분석: 요구 분석 - 요구 분석 준비, 고객 1차 면담 = 56
 박피엘 투입 = 56
 고객 패키지 교육 = 56
 요구 분석을 위한 고객 면담 = 58
 나피엠의 소고: 고객 면담 = 59
 고객 면담에는 인내와 설득이 필요 = 61
M+1, W7 분석: 요구 분석 - 고객 1차 면담, 고객 2차 면담, 업무 흐름 정의 = 64
 '등' 지뢰 터짐 = 64
 추가 개발 비용 계산 = 65
 사용하지 않을 기능의 시스템화가 능사? = 67
 2차 면담 완료 = 69
 사기업 고객과 공기업 고객 = 69
 프로젝트는 정치 = 71
M+1, W8 분석: 요구 분석 - 고객 1차 면담, 고객 2차 면담, 요구 사항 정의 = 72
 3차 면담 종료, 추가 개발 건 협상 난항 = 72
 추가 개발 건 확정: 5억 프로젝트에서 순이익 39백 만원으로 감소 = 73
 워크샵 예정 = 75
 워크샵에서 고객 사인 받기 = 75
 고객 사인 받기 일부 실패 = 79
M+2, W9 분석: 요구 분석 - 인터페이스 계획, 데이터 이행 계획/설계: 화면 설계 = 82
 최피엘 투입 = 82
 별다른 이유 없이 사인해 주지 않는 고객: 사인할 핑계 만들어 주기 = 82
 고객은 검토 중 = 84
 지연된 화면 설계 따라잡기. 방법은? 휴무 근무 = 84
M+2, W10 설계: 화면 설계 = 87
 초보 최피엘, 강한 피엘 만들기 = 87
 최피엘 구하기: rolling wave 방식 = 91
M+2, W11 설계: 화면 설계, 화면 설계 리뷰 = 92
 개발자 1명 투입, 1명 지연 = 92
 개발자 투입 지연 대비 위험 관리 = 93
 프로젝트 시작 2개월; 가격 협상 지연 = 93
 내려갑니다: 6.5억→5.5억→5억→4억9천. '올라갑니다'는? = 94
 가격 협상 타결 기념(?) 회식 = 94
 프로젝트 가격은 떨어지고, 레퍼런스는 쌓이고 = 95
 회식 후유증, 강개발 지각 = 95
 화가 나도 우리가 잘못했으면 어쩔 수 없다 = 97
 패키지인데 투입 인력에 따라 결정되는 계약금 금액 = 98
 개발자는 피엠이 혼난다는 것을 아는가? = 99
M+2, W12 설계: 화면 설계 리뷰, 상세 설계, 인터페이스 설계, 데이터 이행 설계 = 100
 소환당한 부사장님 = 100
 고객이 잘못 했다고 하면 잘못 한 것이다 = 101
 상습 지연, 공정 준수율 84% = 101
 은개발 투입 = 102
 개발 부서를 조직별이 아니라 업무별로 = 102
 공정 준수율 71.68%: 휴일 반납, 야근 = 104
M+3, W13 설계: 상세 설계, 인터페이스 설계, 데이터 이행 설계, 테스트 계획 = 108
 원피엠 하차 = 108
 총괄 이사가 원피엠 대행: 회의 시간 1/3로 줄어듦 = 110
 중간 보고 연기 = 111
 총괄 이사의 Force = 112
 중간 보고 주체가 수행 팀에서 고객으로 변경 = 112
 중간 보고까지는 무조건 100% = 113
M+3, W14 설계: 상세 설계 리뷰 = 115
 새로 온 허피엠 = 115
 중간 보고를 위한 철야 행진 = 115
 감리 준비 = 116
 나피엠은 파워포인트 디자이너 = 117
 공정 준수율 98%. 100%를 향해서 야근, 철야, 휴일 근무 = 118
 결과에 대한 팀원 격려와 보상 약속 = 119
M+3, W15 설계: 상세 설계 리뷰 = 121
 감리 착수 보고 = 121
 나피엠의 소고: 프로젝트 품질과 소프트웨어 품질 = 121
 감리: 5일? 3일? = 123
 감리: 부적정과 미흡 없애기 = 124
 일방적인 감리 = 126
 ISP의 유용성 = 127
 감리 결과 보고: 미흡 1개 = 128
 중간 보고 회의: 내부 PT의 중요성 = 128
 중간 보고 회의 종료: 본격적인 전쟁 전야 = 129
M+3, W16 설계: 상세 설계 리뷰/개발: 프로그램 개발 = 131
 개발 전 설계 승인 받기: 하루에 2번씩 찾아가기 = 131
 모든 팀원 투입 완료 - 개발 시작 = 132
 공정 준수율 114%; 감리 결과 조치 계획서 작성 = 134
M+3, W17 개발: 프로그램 개발, 단위 테스트 = 135
 단위 테스트 동시 진행 = 135
 장개발 개발 속도 지연, 이유는? = 136
 월간 보고서 작성: 고객은 말로, 나피엠은 손으로 = 137
 고객들과의 화기애애한 회식 = 138
 공식 휴가 줄이기, 비공식 휴가 보장 = 139
M+4, W18 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완 = 142
 장개발 개발 속도 계속 지연 - 1주일 기다리기 = 142
 고객사의 강제 구매 = 143
 개발 지연, 지친 개발자들, 추가 투입? = 145
 배코더 투입 - 사용자 화면 나오기 시작 = 146
M+4, W19 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 147
 단위 테스트 중, 소프트웨어 품질에 대한 논쟁 = 147
 나피엠의 소고: 소프트웨어 품질 = 147
 인터페이스 문제 해결 = 149
 장개발 속도 지연 원인은? = 149
 장개발 속도 지연 해결책은? = 151
 개발자 1명 추가 제안, 본사와 격돌 = 152
 본사와 고객사 사이에서 샌드위치된 나피엠 = 154
M+4, W20 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 156
 개발자 1명 추가 투입 결정 - 순이익 하락 = 156
 개발자 1명 추가 투입에 팀원들의 사기 올라감 = 157
 이슈 해결 방안 제시, 여세 몰아 고객에게 단위 테스트 부탁 = 158
M+4, W21 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 160
 신규 투입 인력 면접 및 확정 = 160
 나피엠의 소고: 프로그래머 요건과 테스트 방법 = 160
 개발 속도 개선: 패키지의 위력 = 164
 보고용 표에 문제 = 164
 단위 테스트 결과 좋지 않음 = 165
 일요일에 쉴 수 있다는 것은? = 166
M+5, W22 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 170
 본사 창사 기념일; 미안한 2일짜리 여름 휴가 = 170
 추가 개발자 투입 - 사기 오름 = 171
 보고용 표에 또 오류 = 171
 고객, 다른 부서로 발령 = 173
M+5, W23 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 175
 개발자들 안정 - 개발 속도 향상 = 175
 설계부터 통합 테스트 시작 전까지 프로젝트 관리자는? = 177
M+5, W24 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 178
 나피엠의 실수: 일정에 추석 휴무 잡지 않음 = 178
 프로젝트 시작 후 5개월 만에 작업 진행 관리 변경, 부끄러운 일 = 180
 버퍼로 잡은 일정이 없었다면 = 181
M+5, W25 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 183
 장기 휴가 후 사라지는 개발자 = 183
M+6, W26 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 = 188
 장기 휴가 후유증 회복 = 188
 이고객 PT 능력 향상 = 189
 나피엠의 소고: 요건 변경이 정당화될 수 있는 경우는? = 189
 기분이 좋아지면 개발자들은 마구 개발한다 = 191
 월화수목금금금 = 192
 나피엠의 소고: 소프트웨어 업계에 대한 이야기 = 193
 소프트웨어 공학의 '공학'은? = 194
M+6, W27 개발: 단위 테스트, 단위 테스트 보완 = 196
 프로그램 완료 = 196
 공정 준수율 103%, 3일 특별 휴가 = 197
M+6, W28 개발: 단위 테스트 보완/테스트: 2차 데이터 이행 = 200
 휴가는 역시 좋다 = 200
 후반전 시작: 기와 정치의 전쟁 = 200
 신규 기능 추가 건, 협상과 불발 = 201
 다른 업무 개발 지연 예상; 자체 통합 테스트 준비 = 203
M+6, W29 테스트: 2차 데이터 이행, 인터페이스 연동 테스트 = 205
 고객사의 창사 기념일 = 205
 문서 현행화 = 205
 80% 고지에서 늘어지는 팀원들 = 206
M+6, W30 테스트: 2차 데이터 이행[지연], 인터페이스 연동 테스트[지연] = 208
 다른 업무 지연 - 통합 테스트 일정 연기 = 208
 그랜드 오픈 연기로 비용 상승 = 208
 오픈일 지연: 책임지는 사람은 없고, 손해만... = 210
 야단맞는 개발 지연 업무 담당 고객, 그래도 재떨이는 없다 = 212
 단위 테스트 승인 = 213
M+7, W31 테스트: 통합 테스트[지연], 통합 테스트 결과 보완[지연] = 216
 고객 일부 교체 - 사인 주체 변경 = 216
 신고객은 힘이 넘친다. 나피엠은? = 218
M+7, W32 테스트: 인터페이스 연동 테스트, 통합 테스트 = 220
 시작하지도 못한 통합 테스트; 자체 시스템 테스트 진행 = 220
 내부 시스템 테스트와 동료 테스트 진행 = 220
 신고객 공부시키기 = 221
 나피엠의 소고: 고객과 대기업과 중소기업의 상생 방안 = 222
 인터페이스 테스트와 통합 테스트 시작 = 224
 신고객의 통합 테스트는 언제? = 225
 버퍼로 잡은 일정 모두 사라짐; WBS 일정 변경 = 226
M+7, W33 테스트: 인터페이스 연동 테스트, 통합 테스트 = 228
 통합 테스트 고객 비협조 - 일일 리포팅으로 대처 = 228
 마지막 기 싸움. 승패는? = 228
 미안한 일이 아니지만 미안해야 하는 나피엠 = 230
 통합 테스트 30% 진행, 100%이어야 하는데... 마지막 방법을? = 231
M+7, W34 테스트: 통합 테스트, 통합 테스트 결과 보완 = 232
 통합 테스트 계속 정체 - 신고객 비협조 = 232
 마지막 기 싸움의 승자와 패자는? 통합 테스트 다시 시작 = 233
 철수를 위한 최소요건: 공정 준수율 100% = 233
M+8, W35 테스트: 통합 테스트 결과 보완, 시스템 테스트, 시스템 테스트 결과 보완 = 238
 테스트 진척율이 꼴찌! 이유는? = 238
M+8, W36 테스트: 시스템 테스트 결과 보완, 추진단 테스트 = 240
 테스트 순항 - 진짜 공정 준수율 100% = 240
 변경 건 무조건 개발 요청, 마지막 이슈인가? = 241
 테스트 워크샵 출발 = 242
 나피엠의 소고: 워크샵 = 242
 테스트 워크샵 시작 = 243
 신고객 사용자 교육; 추가 요구 사항과 요건 변경 = 244
 신고객과 잠깐 화해 = 245
M+8, W37 테스트: 추진단 테스트, 추진단 테스트 보완 = 246
 마지막 감리: 미흡을 보통으로 = 246
 마지막 마무리를 향해서 = 246
M+8, W38 테스트: 추진단 테스트 보완, 인수 인계 테스트 = 248
 추가 변경 건 자동 해결 = 248
 나피엠의 소고: 소프트웨어 기업과 노조 = 248
 대부분의 업무 완료 = 249
M+8, W39 테스트: 인수 인계 테스트/이행: 운영 환경 설정, 3차 데이터 이행 = 251
 인수 인계 테스트 종료, 인수 인계 사인 = 251
 모든 업무의 개발 종료(서류상) = 251
 오픈 준비: 24시간 대기 = 252
M+9, W40 이행: 그랜드 오픈, 안정화 = 256
 오픈; 오류 수정 = 256
 그룹웨어 공정 준수율 100%, 관리 프로세스의 우는 얼굴 하나 = 257
 완료 보고 전 인원 철수 동의 받기 = 257
 본사의 종료 품질 관리 생략 = 259
M+9, W41 이행: 안정화 = 260
 인력 철수 계획 승인 = 260
 나피엠의 철수 시점은? = 260
 최종 계산: 순이익 2천만원, 미친 짓이다 = 261
M+9, W42 이행: 안정화 = 262
 에러 2개는 무료 백신 프로그램 때문 = 262
M+9, W43 이행: 안정화 = 263
 잔류 인원 확정 = 263
 프로젝트의 마지막 회식 = 264
M+10∼M+12 마무리: 종료 보고와 검수 사인 = 268
 2월 중순: 모든 업무의 개발 및 테스트 완료 = 268
 종료 보고: 문서상으로 완벽한 보고 = 268
 검수 사인: 잔금에 대한 세금 계산서 발행, 지급은? = 269
 본사 종료 보고: 최종 순이익은 1,800만원. 2.7%. 10%는? = 269
 비겁한 변명: 결어 = 270
에필로그 = 273
 에필로그: 또 다른 변명의 시작, 그리고 밝은 미래를 꿈꾸며 = 274
부록 1. DOPA 방법론 = 278
부록 2. 프로젝트 챠터 샘플 = 281
찾아보기 = 285

관련분야 신착자료

김홍탁 (2026)