M-1, W1 사전 준비: RFP 검토 및 계획 수립 나피엠, 신규 프로젝트 PM 선정 영업 히스토리 = 영업 회의록 6억 5천과 5억 5천 본, MM, 최소 금액 계산: 복병 '등'과 '각종'
M-1, W2 사전 준비: 제안서 작성 제안 룸 보안 프로그램 설치 제안 요약서와 제안서 제안서 작성 기간: 1주일, 길다! 제안서 분량 목표: 40->37(20->25->32->36->37) 제안 요약서 분량 목표: 2 보안 프로그램 삭제 포기. 노트북 포맷
M-1, W3 사전 준비: 제안서 PT와 프로젝트 팀 구성 제안서 PT 시작 RFP의 목적, 목표, 결과 고객이 원하는 특장점은? 제안서 PT 룸의 풍경 제안서 PT 결과: 기술 < 가격 프로젝트 팀 구성: PL과 개발자 확보하기
M-1, W4 사전 준비: 본사 착수 보고 본사 착수 보고 준비 프로젝트 비용, DC 된다! 10% 이익 내기, 궁리 끝에 … 본사 보고용 프로젝트 관리 계획서 결제 받기
M+1, W5 준비: 개발자 환경 준비와 개발 환경 설정 착수 보고용 프로젝트 관리 계획서 작성 방법론과 산출물 양식 프로젝트 룸과 환경 구축 나피엠의 소고: 방법론 사무실 환경 설정 시 확인 사항 착수 보고 준비 착수 보고 착수 보고 회식 업무 별 주간 보고와 수행 팀 주간 보고
M+1, W6 분석: 요구 분석 - 요구 분석 준비, 고객 1차 면담 박피엘 투입 고객 패키지 교육 요구 분석을 위한 고객 면담 나피엠의 소고: 고객 면담 고객 면담에는 인내와 설득이 필요
M+1, W7 분석: 요구 분석 - 고객 1차 면담, 고객 2차 면담, 업무 흐름 정의 '등' 지뢰 터짐 추가 개발 비용 계산 사용하지 않을 기능의 시스템화가 능사? 2차 면담 완료 사기업 고객과 공기업 고객 프로젝트는 정치
M+1, W8 분석: 요구 분석 - 고객 1차 면담, 고객 2차 면담, 요구 사항 정의 3차 면담 종료, 추가 개발 건 협상 난항 추가 개발 건 확정: 5억 프로젝트에서 순이익 39백 만원으로 감소 워크샵 예정 워크샵에서 고객 사인 받기 고객 사인 받기 일부 실패
M+2, W9 분석: 요구 분석 - 인터페이스 계획, 데이터 이행 계획 / 설계: 화면 설계 최피엘 투입 별다른 이유 없이 사인해 주지 않는 고객: 사인할 핑계 만들어 주기 고객은 검토 중 지연된 화면 설계 따라잡기. 방법은? 휴무 근무
M+2, W10 설계: 화면 설계 초보 최피엘, 강한 피엘 만들기 최피엘 구하기: rolling wave 방식
M+2, W11 설계: 화면 설계, 화면 설계 리뷰 개발자 1명 투입, 1명 지연 개발자 투입 지연 대비 위험 관리 프로젝트 시작 2개월; 가격 협상 지연 내려갑니다: 6.5억->5.5억->5억->4억9천. '올라갑니다'는? 가격 협상 타결 기념(?) 회식 프로젝트 가격은 떨어지고, 레퍼런스는 쌓이고 회식 후유증, 강개발 지각 화가 나도 우리가 잘못했으면 어쩔 수 없다 패키지인데 투입 인력에 따라 결정되는 계약금 금액 개발자는 피엠이 혼난다는 것을 아는가?
M+2, W12 설계: 화면 설계 리뷰, 상세 설계, 인터페이스 설계, 데이터 이행 설계 소환당한 부사장님 고객이 잘못 했다고 하면 잘못 한 것이다 상습 지연, 공정 준수율 84% 은개발 투입 개발 부서를 조직별이 아니라 업무별로 공정 준수율 71.68%: 휴일 반납, 야근
M+3, W13 설계: 상세 설계, 인터페이스 설계, 데이터 이행 설계, 테스트 계획 원피엠 하차 총괄 이사가 원피엠 대행: 회의 시간 1/3로 줄어듦 중간 보고 연기 총괄 이사의 Force 중간 보고 주체가 수행 팀에서 고객으로 변경 중간 보고까지는 무조건 100%
M+3, W14 설계: 상세 설계 리뷰 새로 온 허피엠 중간 보고를 위한 철야 행진 감리 준비 나피엠은 파워포인트 디자이너 공정 준수율 98%. 100%를 향해서 야근, 철야, 휴일 근무 결과에 대한 팀원 격려와 보상 약속
M+3, W15 설계: 상세 설계 리뷰 감리 착수 보고 나피엠의 소고: 프로젝트 품질과 소프트웨어 품질 감리: 5일? 3일? 감리: 부적정과 미흡 없애기 일방적인 감리 ISP의 유용성 감리 결과 보고: 미흡 1개 중간 보고 회의: 내부 PT의 중요성 중간 보고 회의 종료: 본격적인 전쟁 전야
M+3, W16 설계: 상세 설계 리뷰 / 개발: 프로그램 개발 개발 전 설계 승인 받기: 하루에 2번씩 찾아가기 모든 팀원 투입 완료-개발 시작 공정 준수율 114%; 감리 결과 조치 계획서 작성
M+3, W17 개발: 프로그램 개발, 단위 테스트 단위 테스트 동시 진행 장개발 개발 속도 지연, 이유는? 월간 보고서 작성: 고객은 말로, 나피엠은 손으로 고객들과의 화기애애한 회식 공식 휴가 줄이기, 비공식 휴가 보장
M+4, W18 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완 장개발 개발 속도 계속 지연-1주일 기다리기 고객사의 강제 구매 개발 지연, 지친 개발자들, 추가 투입? 배코더 투입-사용자 화면 나오기 시작
M+4, W19 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 단위 테스트 중, 소프트웨어 품질에 대한 논쟁 나피엠의 소고: 소프트웨어 품질 인터페이스 문제 해결 장개발 속도 지연 원인은? 장개발 속도 지연 해결책은? 개발자 1명 추가 제안, 본사와 격돌 본사와 고객사 사이에서 샌드위치된 나피엠
M+4, W20 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 개발자 1명 추가 투입 결정-순이익 하락 개발자 1명 추가 투입에 팀원들의 사기 올라감 이슈 해결 방안 제시, 여세 몰아 고객에게 단위 테스트 부탁
M+4, W21 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 신규 투입 인력 면접 및 확정 나피엠의 소고: 프로그래머 요건과 테스트 방법 개발 속도 개선: 패키지의 위력 보고용 표에 문제 단위 테스트 결과 좋지 않음 일요일에 쉴 수 있다는 것은?
M+5, W22 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 본사 창사 기념일; 미안한 2일짜리 여름 휴가 추가 개발자 투입-사기 오름 보고용 표에 또 오류 고객, 다른 부서로 발령
M+5, W23 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 개발자들 안정-개발 속도 향상 설계부터 통합 테스트 시작 전까지 프로젝트 관리자는?
M+5, W24 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 나피엠의 실수: 일정에 추석 휴무 잡지 않음 프로젝트 시작 후 5개월 만에 작업 진행 관리 변경, 부끄러운 일 버퍼로 잡은 일정이 없었다면
M+5, W25 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 장기 휴일 후 사라지는 개발자
M+6, W26 개발: 프로그램 개발, 단위 테스트, 단위 테스트 보완, 인터페이스 개발 장기 휴가 후유증 회복 이고객 PT 능력 향상 나피엠의 소고: 요건 변경이 정당화될 수 있는 경우는? 기분이 좋아지면 개발자들은 마구 개발한다 월화수목금금금 나피엠의 소고: 소프트웨어 업계에 대한 이야기 소프트웨어 공학의 '공학'은?
M+6, W27 개발: 단위 테스트, 단위 테스트 보완 프로그램 완료 공정 준수율 103%, 3일 특별 휴가
M+6, W28 개발: 단위 테스트 보완 / 테스트: 2차 데이터 이행 휴가는 역시 좋다 후반전 시작: 기와 정치의 전쟁 신규 기능 추가 건, 협상과 불발 다른 업무 개발 지연 예상; 자체 통합 테스트 준비
M+6, W29 테스트: 2차 데이터 이행, 인터페이스 연동 테스트 고객사의 창사 기념일 문서 현행화 80% 고지에서 늘어지는 팀원들
M+6, W30 테스트: 2차 데이터 이행[지연], 인터페이스 연동 테스트[지연] 다른 업무 지연-통합 테스트 일정 연기 그랜드 오픈 연기로 비용 상승 오픈일 지연: 책임지는 사람은 없고, 손해만... 야단맞는 개발 지연 회사, 그래도 재떨이는 없다 단위 테스트 승인
M+7, W31 테스트: 통합 테스트[지연], 통합 테스트 결과 보완[지연] 고객 일부 교체-사인 주체 변경 신고객은 힘이 넘친다. 나피엠은?
M+7, W32 테스트: 인터페이스 연동 테스트, 통합 테스트 시작하지도 못한 통합 테스트; 자체 시스템 테스트 진행 내부 시스템 테스트와 동료 테스트 진행 신고객 공부시키기 나피엠의 소고: 고객과 대기업과 중소기업의 상생 방안 인터페이스 테스트와 통합 테스트 시작 신고객의 통합 테스트는 언제? 버퍼로 잡은 일정 모두 사라짐; WBS 일정 변경
M+7, W33 테스트: 인터페이스 연동 테스트, 통합 테스트 통합 테스트 고객 비협조-일일 리포팅으로 대처 마지막 기 싸움. 승패는? 미안한 일이 아니지만 미안해야 하는 나피엠 통합 테스트 30% 진행, 100%이어야 하는데… 마지막 방법을?
M+7, W34 테스트: 통합 테스트, 통합 테스트 결과 보완 통합 테스트 계속 정체-신고객 비협조 마지막 기 싸움의 승자와 패자는? 통합 테스트 다시 시작 철수를 위한 최소요건: 공정 준수율 100%
M+8, W35 테스트: 통합 테스트 결과 보완, 시스템 테스트, 시스템 테스트 결과 보완 테스트 진척율이 꼴찌! 이유는?
M+8, W36 테스트: 시스템 테스트 결과 보완, 추진단 테스트 테스트 순항 - 진짜 공정 준수율 100% 변경 건 무조건 개발 요청, 마지막 이슈인가? 테스트 워크샵 출발 나피엠의 소고: 워크샵 테스트 워크샵 시작 신고객 사용자 교육; 추가 요구 사항과 요건 변경 신고객과 잠깐 화해
M+8, W37 테스트: 추진단 테스트, 추진단 테스트 보완 마지막 감리: 미흡을 보통으로 마지막 마무리를 향해서
M+8, W38 테스트: 추진단 테스트 보완, 인수 인계 테스트 추가 변경 건 자동 해결 나피엠의 소고: 소프트웨어 기업과 노조 대부분의 업무 완료
M+8, W39 테스트: 인수 인계 테스트/이행: 운영 환경 설정, 3차 데이터 이행 인수 인계 테스트 종료, 인수 인계 사인 모든 업무의 개발 종료(서류상) 오픈 준비: 24시간 대기
M+9, W40 이행: 그랜드 오픈, 안정화 오픈; 오류 수정 그룹웨어 공정 준수율 100%, 관리 프로세스의 우는 얼굴 하나 완료 보고 전 인원 철수 동의 받기 본사의 종료 품질 관리 생략
M+9, W41 이행: 안정화 인력 철수 계획 승인 나피엠의 철수 시점은? 최종 계산: 순이익 2천만원, 미친 짓이다
M+9, W42 이행: 안정화 에러 2개는 무료 백신 프로그램 때문
M+9, W43 이행: 안정화 잔류 인원 확정 프로젝트의 마지막 회식
M+10~M+12 마무리: 종료 보고와 검수 사인 2월 중순: 모든 업무의 개발 및 테스트 완료 종료 보고: 문서상으로 완벽한 보고 검수 사인: 잔금에 대한 세금 계산서 발행, 지급은? 본사 종료 보고: 최종 순이익은 1,800만원. 2.7%. 10%는? 비겁한 변명: 결어
에필로그: 또 다른 변명의 시작, 그리고 밝은 미래를 꿈꾸며
부록 1. DOPA 방법론 부록 2. 프로젝트 챠터 샘플
찾아보기
이 책은 십 수 년 동안 다양한 프로젝트 현장에서 PM으로 일해 해 온 저자의 경험을 이야기 형식으로 펼쳐냈습니다.
대부분의 프로젝트는 WBS 단위로 진행됩니다. 그래서 이 책도 주별로 PM이 해야 할 일과 그 일을 하는 와중에 일어나는 다양한 사건들을 가상의 주인공인 나피엠이 어떻게 해결해 나가는지 이야기합니다.
일반적인 프로젝트 관리 서적은 프로젝트 관리 기법을 이론 중심으로 설명하지만, 이 책은 사건을 해결해 나가는 과정을 수기 형식으로 이야기하는 가운데 프로젝트 관리에 필요한 요소들을 하나씩 짚어나갑니다.
프로젝트의 궁극적인 목적은 그랜드 오픈일에 제대로 오픈하는 것입니다. 이를 위해서는 개발자, 고객, 감리, PL, PM, PMO, 관리자, 경영자가 모두 혼연일체가 되어야 합니다. 따라서 이 책은 PM만의 이야기가 아니라, 이 땅에서 프로젝트에 직간접적으로 참여하는 모든 이들을 위한 이야기입니다.
[ 이 책의 기타 특징들 ] - 월별/주별, 어떤 공정으로 프로젝트가 진행되는지 알 수 있습니다. - 분석부터 이행까지 프로젝트 진행 도중에 발생하는 다양한 이슈를 알고 해결의 단초를 제시받을 수 있습니다. - 소프트웨어 업계가 안고 있는 문제점과 해결책을 제시합니다. - 방법론에 대해 자연스럽게 이해할 수 있습니다. - 프로젝트 관리 이론과 기법을 체득하게 됩니다. - 소프트웨어 공학의 다양한 이론을 이야기로 읽을 수 있습니다. - 대규모 프로젝트에 참여해 보지 않았어도 프로젝트에 여러 번 참여한 사람처럼 될 수 있습니다. - 필자가 제안하는 신선한 방법론의 아이디어를 엿볼 수 있다. - 마지막으로, 재미있어서 금방 읽을 수 있습니다.
처음 저자가 제시한 원고의 제목에는 '소설'이라는 단어와 '대한민국'이라는 단어가 있었다. 또, '비겁한'이라는 단어도 있었다. 저자는 별로 비겁해 보이지 않는데 '비겁한'이라는 단어를 넣고 싶어 한 것을 보면 그는 '겸손'한 듯하다. 그리고 '대한민국'이라는 단어에서는 그가 이 나라를 사랑한다는 생각도 살짝 든다. 또한 '소설'이라는 단어를 넣고 싶어 한 것을 보면 한 때 소설가가 꿈이었을지도 모르겠다. 아니면 소설을 쓰고 읽듯이 프로젝트를 재미있게 하고 싶은 소망을 가지고 있는지도 모르겠다. (사실, 이 책은 소설에 가깝다.)
저자의 그러한 소망이 이루어지는 데 이 책이 작은 힘이 되었으면 한다. 또한 낮과 밤을 밝히는 개발자들과 그러한 개발자들과 함께 하는 PM들의 열정이 보태진다면 이것이 꼭 소망으로만 머물러 있지 않을 것이다. 저자의 말로 서평을 마무리한다.
'외부의 조건이 바뀌기를 기다리면 도태된다. 이는 자연에서도 나타나지 않는가? 외부의 조건이 그렇다면 내가 바뀌어야 살아남는다. 언제까지 외부의 환경이 변하기를 기다릴 것인가? 젊은 개발자들이 점차 줄어들고, 개발자들의 나이가 점차 높아지는 것은 기업들이 외부의 환경이 변하기를 기다리면서 내부적인 변화를 하지 않고 있어 나타나는 현상으로서 이러한 기업은 언젠가 도태될 것이다.' (/ p.193)
'젊고 능력 있는 재원들이 소프트웨어 공학과 컴퓨터 공학 분야에서 서로 일하려 하는 우리나라의 미래를 꿈꾸며….' (/ p.276)
총 
바보 빅터
