영원한 전쟁! Death March Project

Edward Yourdon / @parkh37t

'주변을 당신이 찾을 수 있는 최고의 사람들로 가득 채워라, 그리고 권한을 위양하고 간섭하지 마라!'  -로널드 레이건(레이건 시대 비판)

'중요한 것은 성취 하였다는 그 자체가 아니다. 실패하고 낙담하고 미심쩍어했던 일들을 늘 돌아볼 수 있어야 한다. 우리는 과거의 어려웠던 일, 잘못된 시작으로 고통스럽게 더듬거리며 나아갔던 일을 잊는 경향이 있다. 무조건 돌진한 결과 과거의 성공을 이루어냈으며, 현재의 어려움은 일이 망해가고 있는 신호라고 생각한다.' - 에릭 호퍼(Eric Hoffer,)

이 책에서의 'Death March Project'의 의미는 '죽음의 프로젝트' '파멸 프로젝트' '이슈 프로젝트' 등을 후보로 놓고 고민을 하다가 일반적으로 사용하는 용어인 '문제 프로젝트'로 번역 했다.

'문제 프로젝트는 예외적인 것이 아니라 보편적이라는 것이다.'
'품질 -> 사용자의 입장에서 품질이라는 것은 정해진 날짜에 시스템을 쓸 수 있는 것과도 같다.'
'발견을 방해하는 가장 큰 요인은 무지가 아니고, 지식에 대한 환상이다.'
'많은 문제 프로젝트의 실패는 숨겨지며, 교훈이 축적되어 다른 프로젝트에 적용될 수 있는 기회는 경영층의 잦은 교체로 원천적으로 차단 된다.'

Project Manager 라면 우리는 항상 다음과 같은 현실적인 질문을 던져야 한다.

- 문제 프로젝트를 피할 수 없다면, 어떻게 살아 남아야 할까?
- 문제 프로젝트의 성공 가능성을 높이려면 무엇을 해야 할까?
- 타협이 필요하다면 언제 해야 할까?
- 만약 뜻대로 되지 않으면 언제 문제 프로젝트를 그만두고 사표 쓸 준비를 해야 할까?

이 책의 저자인 '이드워드 요든'은 다음과 같은 글귀를 기억하기를 충고 한다.

'노력도 해보고 실패도 해봤지 별 것 아냐 다시 하면 되!'
'다음엔 더 멋진 '실패를 보여주자고!' - 사무엘 베케트

[1] 도입
- 문제 프로젝트란 무엇인가?

(1) 일정 - 합리적으로 산정한 기간보다 일정이 반 이상 줄어든 프로젝트 - 예전 교원 프로젝트의 예
(2) 인력 - 프로젝트에 할당된 인원이, 규모와 범위가 비슷한 다른 프로젝트에 비해 절반 이하인 프로젝트
(3) 예산 - 예산이나 관련 자원을 반 이상 줄인 프로젝트
(4)기능 및 성능 - 비슷한 일정이나 예산의 다른 프로젝트보다 기능, 특성, 성능을 두배 이상 구현해야 하는 프로젝트

- 문제 프로젝트의 유형 분류 : 기준은 규모 이다.

(1) 소형 프로젝트 - 3 ~ 6개월 안에 오나료할 가능성이 거의 없는 프로젝트를 10명이 되지 않는 인원이 수행하는 프로젝트
(2) 중형 프로젝트 - 20 ~ 30명 정도의 인원으로 1 ~ 2년 정도 걸릴 것이라 예상 되는 프로젝트
(3) 대형 프로젝트 - 100 ~ 300명 정도의 인원으로 3 ~ 5년 정도 걸릴 것이라 예상 되는 프로젝트
(4) 초대형 프로젝트 - 1000 ~ 2000명 이상의 인원으로(컨설턴트와 외주 계약자도 포함) 7 ~ 10년 동안 계속 추진할 예정인 프로젝트
--> 여기서 규모가 작을수록 문제 프로젝트가 성공할 가능성은 높다고 저자는 말한다.
이 대목에서 스스로의 경험을 비추어 생각을 해 볼 필요가 있음

- 문제 프로젝트가 왜 발생하는가?

(1) 이해당사자들 간의 정치,정치,정치
(2) 영업, 경영자, 경험 없는 프로젝트 관리자가 남발하는 순진하고 무리한 약속
(3) 젊음의 순진한 낙관주의 : 우리는 이번 주말까지 끝낼 수 있어!
(4) 벤처 기업 정신
(5) 해병대 정신 : 진정한 프로그래머는 잠을 자지 않는다.
(6) 세계화에 따른 경쟁의 심화
(7) 새로운 기술의 출현에 따른 경쟁의 심화
(8) 예상치 못한 정부의 규제로 인한 위기
(9) 예상치 못하거나 계획에 없었던 위기 : 유능한 프로그래머의 갑작스러운 이직, 하드웨어/소프트웨어 벤더의 도산 등

- 왜? 문제 프로젝트에 참가 하는가?

(1) 위험이 크지만 그만큼 보상받을 수 있다.
(2) 에베레스트 산 증후군(정상 정복의 도전 의식)
(3) 다른 여러 사람과 어울려 떠들썩하게 일하는 즐거움
(4) 젊음의 특성인 순진함과 낙관주의
(5) 대안이 퇴직밖에 없다.
(6) 승진하기 위해 필요한 절차다
(7) 프로젝트를 성공하지 못하면 회사가 파산한다.
(8) 조직의 관료주의적인 업무처리 과정에서 벗어날 호기이다.--> 스컹크 프로젝트
(9) 복수하기 위해서???

[2] 정치

관리자는 정치를 해야 한다. 아니 할 줄 알아야 한다. 이 책에서는 네 가지 양상을 말해 주고 있다.

(1) 프로젝트와 관련된 '정치가' 식별하기 --> 대표적인 협상의 내용은 납기, 예산, 사람이다.즉, 프로젝트에 참여하는 모든 사람들이, 핵심 인물이 누구인지를 정확하게 파악하지 못하면 그 문제 프로젝트는 성공하기 힘들다.

(2) 프로젝트의 기본 특징 결정
가미가제 프로텍트 | 미션 임파서블 프로젝트
자살 프로젝트 | 착취 프로젝트
--> 직접 책을 읽어 보세오! ^^

(3) 프로젝트 참여자들의 헌신(Commitment) 수준 식별하기
Im Commitment --> 나 존나게 내 몸 바쳐서 일하고 있어!

(4) 정치적인 문제를 일으키는 주요 논쟁거리 분석
대표적으로 요구사항명세서(또는 정의서)의 핵심은 사용자의 요구사항 가운데 미리 정해진 일정과 예산 안에서 어떤 것이 실제로 구현 될 수 있는지를 결정하는 것이다.

[3] 협상

'자유인만이 협상한다. 죄수는 협상 자체를 할 수 없다. - 넬슨 만델라,,,1985년 그의 석방을 위한 조건을 거부하며<희망을 넘어서,Higher than Hope>

- 문제 프로젝트에서는 프로젝트 관리자가 협상을 포기하고 프로젝트의 제약조건을 단순한 명령으로 받아들이려는 충동을 느끼기 쉽다는 점에 특별히 유의한다. 즉, 위에서 까라면 깐다? 젝일,,,프로젝트 관리자는 정치적 협상을 항상 해야 한다는 뜻 같은데,,,

- 협상 게임
'과거 전통적인 프로젝트에서 가장 확실한 안전핀은 "잔업" 이였다고 한다.
또한 경영층과 고객은 잔업이 필요할 것이라는 점을 잘 알고 최초 일정을 수립할 때 이미 그것을 반영할 정도로 영악하다.
순진한 프로젝트 관리자는 자신이 과거에 수행한 프로젝트가 성공한 이유는 무리한 일정을 달성하기 위해 팀원들이 자발절-헌신적으로 잔업을 했기 때문이라는 사실을 모른다.

- 협상에 실패했을 때 해야 하는 일
--> 냉철함, 그 무엇보다 차가운 냉정함만이 필요할 뿐이다.

- 존 보디의 '위태로운 상황-Crunch Mode'에서 다음과 같이 지적을 하고 있다.

'팀원을 생각하는 프로젝트 리더는 팀원들에게 프로젝트와 관련된 내용에 대하여 거짓을 이야기 하지 않는다. 그런 사람은 프로젝트가 필요로 하는 투입공수와 성공의 가능성에 대하여 정직하게 이야기 한다. 프로그래머들은 바보가 아니다. 경험 많은 사람은 "언제가 과연 어려운 시점"인지 할 수 있는 감각이 발달 되어 있다. 그런 사람들은 절대로 그 게임에 뛰어 들지 않는다. 프로젝트가 어려워질 때 자신들이 책임을 져야 하는 위치라는 것을 알고 있기 때문이다.'
--> 팀원들이 정치적인 전투에서 무고한 희생양이 되지 않도록 하여야 한다.

'문제가 있다고 판단한 계획을 수행하겠다는 지휘자는 잘못 되었다. 그건 계획이 변경되어야 한다고 논리적으로 주장하여야 하며 부대원들을 파멸시키는 수단이 되기 보다는 사퇴를 고려하여야 한다. -나폴레옹 "전쟁 금언과 사상"

[4] 문제 프로젝트의 사람들

- 프로젝트가 성공적으로 완료 되었을 때 멋지게 상을 주되, 프로젝트를 수행하는 동안은 터무니 없이 과한 상을 주지 않는 것이 좋다.

- 프로젝트 관리자는 팀에 잘 어울리지 않거나 적합하지 않다고 생각하는 사람은 강력하게 거절할 수 있는 용기를 가져야 하며, 그럴 권리가 있다는 것을 알고 있어야 한다.

- 일반적으로 문제 프로젝트 중간에 팀원을 프로젝트에서 떠나게 하거나 신규로 투입하는 일은, 피할 수 있다면 피하는 것이 바람직하다.

- 충성, 자발적 헌신(Commitment), 동기부여와 보상 즉, 팀원이 충성심을 느끼고 헌신하려는 자세는 프로젝트 관리자의 동기부여 능력에 많이 달려 있다.

'개발자는 스스로 동기부여할 수 없으며 프로젝트 관리자가 동기부여를 해주어야 한다는 생각만큼 작업자의 의욕을 꺽는 일은 없다. 프로젝트 관리자는 사람들이 얼마나 일을 열심히 하는지 일일이 평가할 필요가 거의 없다. 왜냐하면, 그들은 대부분 자신의 일을 좋아하기 때문이다.

- 의사소통의 중요성은 아무리 말해도 모자르지 않다. 특히 프로젝트 관리자가 비밀을 가지지 않는 것이, 즉 모든 팀원이 프로젝트에 대해 아는 것이 가장 이상적인 상황이라고 생각한다.

- 프로젝트 팀원들이 자신들이 원하기만 하면 프로젝트의 진행상황에 대한 정확한 정보를 알 수 있다고 믿는다면, 그들은 프로젝트 에너지의 99포센트를 정치가 아닌 기술적인 일에 행복하게 집중 할 것이다.

[5] 문제 프로젝트의 프로세스

- 문제 프로젝트를 포함 모든 프로젝트에서 가장 중요한 것은 '우선순위 즉, ICS4의 priority 라는 개념보다는 Trage이다.

<참고>Trage

 치료의 필요성이나 치료 효과를 고려하여 상황에 따라 부상당한 사람을 구분하는 과정, 트리아지는 의료 자원이 한정 되어 있는 전쟁이나 재난 상황, 병원 응급실 등에서 사용 된다. 참고로, 가장 성공적이고 많이 쓰이는 협상 전략은 고객 요구사항에 우선순위를 적용하는 것이다. 물론 가끔 그 대상이 고객이 아닌 주관사로 탈바꿈 되어 있는 경우가 있다. 참 난감하다. ㅋㅋ

- '필수'에 먼저 집중하고, 시간이 남았다면 '해야 되는' 요구사항을 하고, 만약 기적이 일어난다면 '가능한' 요구사항을 구현하는, 분명한 프로젝트 전략이 서게 된다.

- 문제 프로젝트에서 또 하나의 중요한 점은 그 세계(고객 또는 주관사)의 모국어를 프로젝트 관리자 또는 전체 팀이 배워서라도 사용해야 한다는 것이다. 그들의 언어로 접해야 한다.

- 문제 프로젝트의 프로세스에서 SEI(대표적으로 CMM), ISO-9000같은 공식 프로세스 또는 방법론(삼성의 이노베이터 같은 CBD) 보다는 비공식 적인 프로세스가 더 필요하다.

- 사고를 피하기 위한 목록

(1) 유사한 프로젝트 통계치 대비, 프로젝트 기간 단축을 10퍼센트 이상 예상 하지 말아라.
(2) 일정 단축을 핑계로 신기술을 정당화 하지 말아라.
(3) 특정 고객용 솔루션 개발을 프로젝트에 강요하지 말아라.
(4) 만병 통치약 식의 접근 방식에 넘어가지 말아라. --> 아주 훌룡한 말솜씨 ^^;
(5) 외부 통제에 있는 요소를 크리티컬 경로에서 제외 시킬 수 있는 기회를 놓치지 말아라.
(6) 감사원 또는 심사원들이 준비도 없이 참가한 공식 감사에서 프로젝트의 상태를 정확히 파악하려고 애쓰지 마라.
(7) 납기를 10퍼센트 단축하려면 기능을 10퍼센트를 줄여야 한다는 사실을 기억해라.

[6] 프로세스 역학

- 도입에서도 말했듯이 많은 문제 프로젝트에서 가장 심각한 문제는 기술적인 문제가 아니라 정치, 사회, 문화, 사람 등과 관련된 문제가 대부분이다.
- 지연되는 프로젝트에 인력을 추가할 수록 프로젝트 일정은 더 지연된다. --> 생각해 볼만한 대목이다. 그리고 아래의 대목은 직접 책에서 확인 하시길,,,,

[7] 애로사슬 일정 수립과 제약이론
[8] 시간관리
[9] 프로젝트 진척통제
[10] 문제 프로젝트의 도구와 기술