[4장 보충] 장기전은 장기전처럼 치루어야 합니다.

"The Art of Project Management: 마음을 여는 프로젝트 관리" 4장은 이렇게 시작합니다.

팀을 이끄는 과정에서 어려운 점 하나를 꼽으라면, 오랜 기간 동안 모두를 같은 목표에 집중하게 만드는 일이라 하겠습니다.

프로젝트 기간이 길어지고 요구사항이 뒤집히다 보면, 애초에 목표했던 바가 무엇이었는지 가물가물해집니다. 목표가 흐지부지하게 되면, 논쟁이 벌어졌을 때 뚜렷한 결정 기준이 없습니다. 결국 감정 싸움이나 기 싸움으로 번져서 목소리가 큰 사람이 이깁니다. 또한 목표를 달성했는지 여부를 판단하기도 애매한 탓에 프로젝트 끝이 어디인지 알 수가 없습니다. 프로젝트가 끝난다 해도 구렁이 담넘어 가듯 사라지는 경우가 많아서 팀이 성취감을 얻기가 어렵습니다. 오랜 프로젝트 끝에 성취감도 없이 심신이 모두 지친 팀이 다음 프로젝트에 얼마나 열정적으로 뛰어들까요?

그래서 프로젝트 기간이 길수록 좀더 공을 들여 비전문을 작성해야 합니다. 점령해야 할 고지를 명확히 정의하고, 작전 계획을 꼼꼼히 세우고, 자원을 충분히 확보하고, 초과 근무를 없애서 팀원들의 집중력과 체력을 유지해야 합니다.

장기전은 장기전처럼 치루어야 합니다. 마라톤을 100미터 달리기처럼 내달려서는 안됩니다.

The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 이해영 올림

[4장 보충] 반드시 멋진 문서가 아니어도 좋습니다.

"The Art of Project Management: 마음을 여는 프로젝트 관리" 4장에서 저자인 스콧은 비전문을 작성하여 전체적인 프로젝트 목표와 방향을 기록하고 항상 참조하라고 제안합니다.

그런데 막상 비전 '문서'라고 하면 거부감이 들지도 모르겠습니다. 누군가 '작성'하고 '관리'해야 하니까요. 사실 문서 작업은 귀찮습니다. 하지만 '문서'라는 말 때문에 정말 중요한 개념을 놓쳐서는 안됩니다. 비전문을 작성하는 목적, 즉 비전문에서 얻으려는 효과입니다: 전체 프로젝트 목표는 (어떤 방식으로든) 기록하고 팀원 전부가 이해해야 한다!

개인적으로는 반드시 문서 형태가 아니라도 상관 없다고 생각합니다. 화이트보드에다 크게 써두어도 좋고, A4 한 장에 요약해서 팀원들에게 나누어 주어도 괜찮다고 생각합니다. 프로젝트 관리자 자리 앞에 커다랗게 붙여 두거나, 짤막하게 정의한 프로젝트 목표를 프로젝트 관련 메일 뒤에 서명으로 첨부해도 좋겠습니다. 방법은 많습니다. 팀 전체가 프로젝트를 진행하면서 목표를 잊어버리지 않는다는 목적만 달성하면 됩니다.

물론, 스콧이 제안한 바처럼 우수한 비전문을 만들고 항상 점검할 수 있다면 좋겠죠. 하지만 현실적으로 비전문조차 사치라고 여길, 힘든 개발 환경이 많습니다. '멋진 이야기지만 지금 상황에서는 무리야'라고 느끼신다면, 포스트잇으로라도 시작해보면 어떨까요? 프로젝트 목표를 정리할 입장이 아니라면, 이 프로젝트에서 나의 목표는 어떻습니까?

The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 이해영 올림

[독자 소감] [5장을 읽고나서] 회의에서 다른 사람과 충돌을 피하는 방법

Sukwoo님께서 보내주신 회의에서 다른 사람과 충돌을 피하는 방법입니다.

균형 감각을 유지하면서 회의를 하기는 무척 어렵습니다. 저는 말이 헛돌아서 사이클을 두 번 돌고 나면 칠판을 절반으로 나눈 다음에 양쪽 의견을 그냥 받아서 써버립니다. 너무나도 신기하게 칠판에 쓰는 순간 사이클은 끝납니다. 칠판에 있는 이야기를 말로 중언부언할 필요가 없기 때문입니다. ;) 이렇게 하고 나서 아랫부분에 각 진영의 장단점을 적어가면서 대화 분위기를 객관적으로 흘러가도록 조성하면 일이 쉽게 풀리지 않겠습니까?

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림

[공지사항] APM 정오표

사람이 하는 일이다 보니 번역 과정에서 실수가 생기고 말았습니다. APM 정오표를 정리해보았으니 확인해서 잘못된 부분을 수정해서 읽어주시면 감사하겠습니다. 황금같은 시간 쪼개서 1차 오류 보고를 해주신 고양이님께 감사드립니다. (추가) 역시 2차 오류 보고를 해주신 고양이님께 다시 한번 감사 드립니다. (다시 추가) 3차 오류 보고를 해주신 고양이님께 역시 감사 드립니다. (또 다시 추가) 4차 오류 보고를 해주신 고양이님께 정말 감사드립니다. 드디어 책 전체적를 한번 다 훑어보았네요. 5차 오류 보고를 해주신 kks님께도 감사 드립니다. 6차 오류 보고를 해주신 주민석 님께도 감사드립니다.

• 전체: 슈퍼맨이 아니라 수퍼맨이 올바른 표현입니다. 편집 과정에서 찾지 못했네요.
• 66페이지: 좌측 주석 영역 '실적'에서 "Pro gram"이 아니라 "Program"입니다.
• 66페이지: 좌측 주석 영역 'PERT'에서 공식이 잘못되었습니다. (최상의 예측 + 4 * 가장 그럴싸한 예측 + 최악의 예측) / 6이 되어야 합니다.
• 77페이지: 좌측 주석 영역 'mpg'에서 "연비를 단위"입니다가 아니라" 연비를 나타내는 단위입니다"입니다.
• 157페이지: 좌측 주석 영역 '시간 변환 장치'에서 "백 투더퓨처"가 아니라 "백 투 더 퓨처"입니다.
• 157페이지: 좌측 주석 영역 '상식이 통하는 웹 사이트'가 절판되었다고 적어놓았는데, 2판이 대웅출판사에서 새로 출간되었습니다. 확인해주신 김태연님께 감사드립니다.
• 192페이지: 가장 마지막 줄에 "팀이 (그리고 작성자)가"가 아니라 "팀이 (그리고 작성자가)"입니다.

추가된 내용입니다.

• 238페이지: 마지막에서 위로 두번째 문단에서 "어떤 점을 우려했습니까?"가 아니라 "어떤 점을 우려했었습니까?"입니다.
• 242페이지: 좌측 주석 The Mythical Man-Month에서 "바벨탑 그림(Turmbau zu Babel),"이 아니라 "바벨탑 그림(Turmbau zu Babel)과"입니다.
• 247페이지: 좌측 주석 새티어 모델에서 "Effective ness"가 아니라 "Effectiveness"입니다.
• 248페이지: 좌측주석에서 "사실에 만장일치로 동의할 필요는 없습니다."가 아니라 "사안에 만장일치까지 필요하지는 않습니다."입니다.
• 264페이지: 셋째 문단에서 "짜증 위험 계수"가 아니라 "짜증 유발 지수"입니다.
• 265페이지: 첫째 문단에서 "만족하는 방식으로"가 아니라 "만족시키는 방식으로"입니다.
• 270페이지: 마지막 문단에서 "AT는 프로세스 없이 작업하는 사긴보다 작으므로 차이는 음수가 되어야 합니다."가 아니라 ""AT는 프로세스 없이 작업하는 시간보다 작으므로 AT와 프로세스 없이 작업한 시간 사이에 차이를 구하면 음수가 나와야 합니다."입니다.
• 274페이지: 마지막 문단에서 "하지만 남을 칭찬하는"이 아니라 "물론 남을 칭찬하는"입니다.
• 286페이지: 중간 문단에서 "회의를 마칠 때는 다음으로 회의에 참석했던 사람들이 각자 맡아서 진행할 후속 단계가 가장 중요합니다."가 아니라 "회의를 마칠 때는 다음에 전개될 업무 정의가 가장 중요합니다."
• 286페이지: 마지막 문단에서 "회의 목표가 회의 유형과"가 아니라 "회의 목표와 회의 유형이"입니다.
• 292페이지: 첫 문단에서 "장해물"이 아니라 "장애물"입니다.
• 292페이지: 좌측 주석에서 "타성"이 아니라 "탄력"입니다.

3차로 추가된 내용입니다.

• 297페이지: 마지막 문단에서 "PM이나 팀 사기는"이 아니라 "PM이나 팀 사기가"입니다.
• 303페이지: 좌측 주석에서 "Advan tage"가 아니라 "Advantage"입니다.
• 305페이지: 좌측 주석에서 "비즈니스가 정말로 더 나은"이 아니라 "비즈니스를 통해 정말로 더 나은"입니다.
• 311페이지: 첫 문단에서 "개인의 업무와 업무와 맺은"이 아니라 "개인의 업무는 물론이고 이 업무와 맺은"입니다.
• 315페이지: 좌측 주석에서 "Learing"이 아니라 "Learning"입니다. 두 군데 나옵니다.
• 316페이지: "나는 혼자 일한다"에서 "영웅이 되기"가 아니라 "영웅이 되기를"입니다.
• 330페이지: "선수에게 건네는..." 문단과 "(저는 고등학교와 ..." 문단이 하나로 결합됩니다.
• 331페이지: "ex officio"가 이탤릭체가 되어야 합니다.

4차로 추가된 내용입니다.

• 340페이지: 2문단에서 "제가 방어적으로 돌변한다거나..."가 아니라 "제가 방어적으로 돌변한다거나 질책을 당하리라는 두려움 없이 다른 사람들이 편안하게 제 행동을 비판해도 좋다는 신뢰감이 도는 분위기를 꾸준하게 조성해야 했습니다."입니다.
• 342페이지: 좌측 주석에서 "실제로 가장 좋은..."이 아니라 "앞으로 유사한 작은 문제점에 대해 승인 받을 필요가 없음을 알려주는 대응책이 실제로는 가장 바람직합니다."입니다.
• 342페이지: 끝에서 2문단 "관리자는 복구를 도울..."에서 "과정을 이끌어야 하기 때문에"가 아니라 "과정을 이끌어 나가기 때문에"입니다.
• 342페이지: 마지막 문단 "즉, 사람들이"에서 "사람들이"가 아니라 "누군가"입니다.
• 343페이지: "절대로 앉은 자리에서 질책하지 마십시오"에 따라 나오는 문단이 두 개("특히 위기 상황에서..."와 "내 사무실에 불이 났어!")있는데, 한 문단으로 합쳐져야 합니다.
• 343페이지: 마지막에서 위로 여섯째 줄 "물론, 다른 사람의"에서 "물론,"이 아니라 "당연히" 입니다.
• 344페이지: 마지막에서 위로 둘째 줄 "이런 영향력의 중심을"에서 "영향력의"가 아니라 "영향력을 이끌어내도록"입니다.
• 350페이지: 위에서 둘째줄 "일을 잘하는 능력이 타고난 반면"에서 "능력이"가 아니라 "능력을"입니다.
• 350페이지: 위에서 네째줄 "다시 말해 어떻게 이른 능력을"이 아니라 "다시 말해 어떻게 다른 관리자가 이런 능력을"입니다.
• 350페이지: 위에서 다섯째줄 "계발할 수 있도록 만드는지"가 아니라 "계발하도록 도와주는지"입니다.
• 351페이지: 위에서 첫 문단 마지막 부분 "하루 동안 내 자신의 일정을 담은 목록"이 아니라 "내 자신의 하루 일정을 담은 목록"입니다.
• 368페이지: 위에서 첫줄 "분쟁이나 협상에서라도 자신이 옳다고"가 아니라 "분쟁이나 협상 상황조차에서도 자신이 옳다고"입니다.
• 378페이지: 좌측 CMM 설명 주석 부분에서 "카네기 멜론 대학교의 소프트웨어 공학 연구소에서 개발한 소프트웨어 개발 과정을 위해 만든"이 아니라 ""카네기 멜론 대학교의 소프트웨어 공학 연구소에서 소프트웨어 개발 과정을 위해 만든"입니다.
• 380페이지: 위에서 1문단 "자신의 행동이 가져올 결과에 적절지 못한"에서 "적절지"가 아니라 "적절하지"입니다.
• 389페이지: 좌측 험프리 설명 주석 부분에서 "소프트웨어 프로세스 공정 프로그램"이 아니라 "소프트웨어 공정 프로그램을"입니다.
• 389페이지: 마지막에서 위로 2문단 "(물론 속력이 두 배 더 빠르고 형식적인 절차를 반으로 줄인) " 위치를 "적용해서" 뒤가 아니라 "동일한 기술을 적용해서" 앞에 놓습니다.
• 395페이지: 좌측 아이젠하워 주석에서 "총 사령관"이 아니라 "총사령관"입니다.
• 401페이지: 마지막에서 위로 2문단 "(그림 14-8에서 변경 범위라고 부르는)" 위치를 "남은 B 지점까지의 거리보다"를 기준으로 앞이 아니라 뒤에 놓습니다. 즉 "불명확한 변경까지의 거리가" 앞에 놓습니다.
• 402페이지: 위에서 3문단 "미 항공 우주국과 마이크로소프트는 이를 설계 변경 통제"에서 "설계 변경 통제"가 아니라 "설계 변경 요청"입니다.
• 403페이지: 위에서 2문단 "겉잡을 수 없이 울고 있겠죠?"가 아니라 "펑펑 울고 있겠죠?"입니다.
• [5차 추가] 409페이지: 그림 15-1에서 실선과 점선 설명이 바뀌었습니다. 점선이 계획이고, 실선이 실제입니다.
• 428페이지: 좌측 역자주에서 "2004년도에 출간된"이 아니라 "2004년도에 개정판으로 출간된" 입니다. 그리고 "한글판으로 익스트림 프로그래밍 2판(인사이트)가 한글판으로 출간되었습니다."를 추가합니다.
• 448페이지: 좌측 주석 "지각력 왜곡"에서 "Distor tion"이 아니라 "Distortion"입니다.
• 449페이지: 2문단 "저는 프로젝트와 프로젝트 참여자라는 대의에"가 아니라 "저는 프로젝트와 프로젝트 참여자에게 큰 이익을 주지 못하는"입니다.
• 449페이지: 끝 문단 "프로젝트 밖에도 삶이 있습니다."가 아니라 "사람들에게는 프로젝트 밖에도 삶이 있습니다."입니다.
• 473페이지: 부어스틴 대니얼 J. 책 소개에서 "The Discoverers" 폰트 크기가 안 맞습니다. 아래 나오는 "The Creators"와 "The Seekers"와 맞춰야 합니다.
• 479페이지: 색인 DCR이 두 번 나옵니다. 하나는 제거해야 합니다.
• 484페이지: 색인 "반란 도모"가 두 번 나옵니다. 하나는 제거해야 합니다.
• 487페이지: 색인 "신념 부족"이 두 번 나옵니다. 하나는 제거해야 합니다.
• 490페이지: 색인 "인신 공격"이 두 번 나옵니다. 하나는 제거해야 합니다.
• 491페이지: 색인 "정상 상태 점검"을 제거해야 합니다. "정상 상태를 점검하기"로 충분합니다.

혹시 다른 애독자 여러분께서도 APM을 읽는 도중에 오탈자를 찾으시면 저에게 편지를 보내주시면 검토 후에 올려드리겠습니다. 미리 감사 말씀 드립니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림

[3장 보충] 영업/마케팅과 친해져야 하는 이유

일반적으로 (프로젝트 관리자를 포함한) 공학도와 영업/마케팅 부서 사람들 사이에는 묘한 냉기류가 흐르기 마련입니다. 공학도 입장에서 보면 매일 말도 안되는 요구사항만 들고 오는 영업/마케팅 친구들은 다른 화성인처럼 보이고, 반대로 영업/마케팅 사람들은 고객이 목을 매달고 요청하는 기능은 구현할 생각이 전혀 없는 공학도 친구들이 금성인처럼 보일 겁니다.

양 쪽 진영 사이에 오해가 조금씩 쌓이기 시작하면 눈덩이처럼 불어나서 나중에는 "콩으로 메주를 쑨다고 해도 안믿는" 상황에 이르게 됩니다. 이럴 때는 진짜 고객이 요청하는 기능도 개발자들이 구현을 거부하고, 개발자들 구현 과정에서 어려운 기술적인 문제점을 제기해도 영업/마케팅에서 받아들이지 않아서 프로젝트가 엉망 진창이 되어버리는 최악의 상황으로 치닫게 됩니다.

이런 상황을 어떻게 극복해야 할까요? 가장 좋은 방법으로 각자 생각하는 이익을 제시해서 공통되는 교집합을 찾아서 이를 출발점으로 삼아 점점 범위를 넓혀나가면 됩니다. 자기 입장이나 위치만 강조해서는 아무런 일도 되지 않기 때문에 양보하고 타협하고 수용하는 자세가 필요합니다.

그런데, 제가 관찰한 결과에 따르면 개인적으로 친분이 있을 경우에 특히 각자 관점에서 통일된 부분을 찾아내기가 쉬워집니다. 따라서 프로젝트 관리자나 프로젝트에서 중요한 업무를 맡고 있는 핵심 개발자라면 스스럼 없이 영업/마케팅 담당을 찾아가서 이런저런 상황도 듣고 조언도 구하고 기술적인 문제점도 살짝 살짝 풀어놓을 수 있는 자연스러운 분위기를 조성해야 합니다. 저녁에 맥주라도 한 잔 같이 하면서 각자 맡은 일은 다르지만 프로젝트를 성공시켜야 한다는 공통된 목표로 함께 가겠다고 허심탄회하게 말씀하십시오. 똑같은 용어를 완전히 다르게 해석하고 있을지도 모르니 대화를 통해 생각하는 방향을 정렬시키십시오. 완전히 다른 용어를 똑같이 의미로 해석하고 있을지도 있으니 각자 사용하는 용어를 통일하도록 노력하십시오. 이런 노력도 해보지 않고 막무가내로 상대편을 감정적으로 비난하고 있지는 않습니까? 손바닥도 마주쳐야 소리가 나는 법이랍니다.

하지만 이렇게 양쪽 이익과 입장에서 공통 분모를 찾고 나면 갑자기 프로젝트 진행 과정이 아주 매끄러워지면서 사람 사이에 받는 스트레스가 줄어들므로 출근길이 즐거워질겁니다. 이런 사소하다면 사소하다고 볼 수 있는 변화를 통해 여러분들도 프로젝트를 즐겁고 기분좋게 진행하면 좋겠습니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림

[독자 소감] The Art of Project Management

KAISTIZEN님께서 벌써 책을 다 읽으시고 블로그에 서평을 올려주셨습니다. 좋은 글 감사드립니다.

다른 독자 분들께서도 블로그에 글을 올린 다음에 URL을 저에게 알려주시거나 감상문을 편지로 써서 보내주시면 지속적으로 이 블로그에 올려드리겠습니다. 다양한 분야에서 일하는 개발자들이 프로젝트를 진행하면서 겪은 고민을 함께 읽어보고 생각하고 해결해나가는 작은 출발점이 되었으면 좋겠습니다.

박재호 올림

[독자 소감] 프로젝트 일정이라...

수동 트랙백입니다. nemonandes님의 프로젝트가 일정에 맞게 잘 끝나기를 두 손 모아 기원합니다. :-)

프로젝트 일정이라...

참고로, Blogger는 트랙백을 지원하지 않습니다. Haloscan과 같은 무료 서비스도 있습니다만, 조만간 사용을 고려해 보겠습니다.

이해영 올림

[독자 소감] 1장을 읽고 나서...

'이 글이 1장과 관련이 없어보이기는 하나 1장을 읽고나니 갑자기 예전 일이 생각이 나서 몇자 끄적여 봤습니다'라고 독자분께서 글을 보내오셨습니다. 대화체라서 실감나고 재밌습니다.

PM과의 의견 충돌로 프로젝트가 지연될 경우 여러분은 어떻게 하시나요?

재밌게도, 1장을 읽으면서 저 역시 제 첫 번째 Technical Leader였던 분을 떠올렸습니다. 인도인이셨는데, 정말 본받을 만한 멋진 팀장이셨습니다. 그 분이라면, 위 독자님이 말씀하신 상황을 어떻게 헤쳐나갔을까...궁금하네요. 시간이 나면, 저도 그 분에 대한 글을 올리겠습니다. :-)

The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 이해영 올림

[2장 보충] 일정은 어디까지나 확률입니다.

'한 달 정도 걸립니다'라고 예측해서 올리면 위에서 '반 달 만에 끝내' 소리가 나옵니다. 이런 상황에서 올바른 예측과 합리적인 일정 수립이 무슨 의미가 있습니까?

현장에서 뛰고 있는 동료 개발자들에게서 이런 이야기를 들을 때면 안타까움을 느낍니다. 그리고 이런 상황에 처하게 되는 원인이 어디에 있을까를 고민하게 됩니다.

저는 근본적으로 '일정'이라는 개념 자체에 대한 시각 차이라고 생각합니다. 한 달짜리 업무를 반 달만에 끝낼 수 있다고 믿는 태도는 일정이 지니는 '강제 기능 forcing function'만을 맹신하기 때문입니다. 일정이 지니는 다른 목적과 기능은 상대적으로 중요하지 않다고 여겼기 때문입니다.

상부 관리층과 팀 개개인이 일정을 바라보는 시각과 일정에서 기대하는 바가 다르다면 프로젝트는 필연적으로 삐걱이게 됩니다. 가장 기본적인 출발점이 다른 셈이니까요.

설계나 기능에 대한 시각 차이는 프로젝트를 진행하면서 조율할 기회가 생깁니다. 하지만 오히려 기본 개념은 거론조차 하지 않고 그냥 넘어가는 경우가 많습니다. 게다가 나중에 문제를 일으키는 원인이 되어도 이를 깨닫기 어렵습니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 2장은 일정에 관한 진실을 조목조목 잘 설명하고 있습니다. 제목과 내용을 요약해서 간단한 세미나 자료로 만들어도 손색이 없을 정도입니다.

'반 달 만에 끝내'라는 소리에 억울하고 답답해 하는 대신, 모두가 같은 시각으로 일정을 바라볼 수 있도록 세미나를 한 번 열어보면 어떨까요? 일정을 왜 세우는지, 어째서 완벽한 일정이란 존재하지 않는지, 일정이 왜 실패하는지, 실패를 줄이려면 어떻게 해야 하는지 등과 같은 주제를 다같이 토론하는 기회가 되기를 바랍니다.

The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 이해영 올림

[1장 보충] 실패에서 배우기

무릎을 바닥에 찧지 않고서는 걷지 못하며, 자전거나 스키를 잘 타기 위해서는 여러 번 넘어져야 합니다. 마찬가지로 프로젝트를 성공으로 이끌기 위해서는 여러 번 실패를 해봐야 합니다. 많은 사람들이 프로젝트를 바로 성공으로 이끄는 기발한 방법론이나 강력한 도구를 찾아 왔지만 여전히 성공하지 못하는 이유는 '실패'라는 필연적인 과정을 회피하고 싶었기 때문입니다.

'To Engineer is human'에서 헨리 페트로스키가 강조하듯이 실패는 공학도에게 있어 필수불가결한 요소입니다. 만일 실패를 허용하지 않는다면 어떤 새로운 프로젝트도 시작해서는 안됩니다. 모든 새로운 프로젝트에는 위험이 도사리고 있고, 위험을 100% 효과적으로 통제하는 방법은 존재하지 않기 때문에 실패할 확률은 언제 어디서나 존재합니다.

하지만 실패의 댓가는 너무나도 혹독합니다. 특히 요즘과 같은 급변하는 사회에서는 단 한번의 실패가 팀은 물론이고 회사까지 침몰시킬지도 모릅니다. 패배해도 다음에 또 기회를 부여받았던 로마 제국의 장군과는 달리 요즘 프로젝트 관리자는 한번만 잘못하면 다시 회복하기 어려운 상황에 놓입니다. 그 만큼 살기가 팍팍해졌다고나 할까요?

현실적으로 실패가 불가능하다면 간접적으로 실패해보는 방법밖에 없습니다. 어떻게 _간접적_으로 실패를 경험할 수 있을까요? 가장 손쉬운 방법으로 자기 자신은 물론이고 다른 사람의 과거 실패를 면밀하게 분석해서 교훈을 얻습니다. 하지만 한국에서는 이런 호사를 누리기가 곤란합니다. "2차 프로젝트는 있어도 실패한 프로젝트는 없다"라는 화기애애한 분위기에서 '실패'라는 용어를 꺼내면 관련자 모두가 다치기에 좋은게 좋은거라는 식으로 실패를 덮어버리므로 실패에 대한 이력이 남지 않습니다. 일례로 이번에 360억원이 허공으로 사라져버린 의약품유통종합정보시스템의 경우만 해도 몇 달만 지나면 모든 사람들의 뇌리에서 잊혀질 겁니다.

상황이 상황인만큼 간접 경험을 얻기 위해 도대체 어디에 하소연해야 할까요? 현명한 독자 여러분께서는 "The Art of Project Management: 마음을 움직이는 프로젝트 관리"를 읽으면서 강건너 불구경하는 방관자 입장에서 벗어나 스콧 버쿤이 이야기하는 프로젝트와 관련한 다양한 실패와 실수를 능동적으로 새겨들으시리라 믿습니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림