Death march projectDeath march- the complete s/w developer’s guide to Surviving “ Mission Impossible” ProjectsEdward Yourd...
. medium-sized projects … .1~2년이 걸릴 것으로 에상되는 20~30명으로 구성된 경우.. large-scale projects … 3~5년의 일정과 100~200명 으로 구성된 경우.. Mind-...
Death march project실로 많은 경우 상위 관리자들은 행복스럽게 복잡한 프로젝트들의 예측이나 일정계획 수립process에 경험의 결핍과 순진성을 허용하고 있다. “이일에 얼마나 기간이 소요될까?”라는질문을 ...
1.3.5 해병대 정신 ;   진정한 프로그래머는 잠을 자지 않는다 신설기업은 해병대 신드롬에 물들기 쉽다. 그러나 나는 EDS나 6대 회계법인과 같은 컨설팅 조직에서 자주 그것을 보아왔다. 그것은 창립자의 개인적 성향...
Death march project이고 긍정적인 기회로 인식될 수도 있다. – “만약 우리가 2BYTE의 글자를 갖는 이 새로운 시스템을 만든다면 일본 시장에 진출할 수가 있다”. 유사하게 급격한 기술의 개선에 대한 소...
march project가 생긴다. 특별히 이러한 많은 death march project들이 부담스러운 것은dead line때문이다. 새로운 시스템은 제멋대로 정한 날짜까지(예를 들면 1월1일) 운영될 수있어야 하며 ...
Death march project주제였다. 우리들은 이러한 이유들에 동의하거나 동의하지 않을 수 있고, 진정으로 예기치못한 위기로 인한 프로젝트들에 동정할 수도 있다. 그러나 궁극적으로 개인적인 입장에서 삶의 한 사실...
똑똑하게 보이는 어리석음   일을 하는 Job을 얻기 위하여   단지 프로젝트이니까   친구가 프로젝트에 참여하니까   형제가 프로젝트에 참여하니까   사장의 지시로   다른 삶이 없다.   그렇게 하는 것 보다 더 좋...
Death march project구하고 나는 아직 기업가적 기회에 매력을 느낀다. 나에게 흥분될만한 위험과 보상의 공식을제시하라. 그러면 나는 또 다른 death march project에 참여할 것이다. 말이 난 김...
당신이 에베레스트 형태의 death march project의 흥분상태에 휩쓸리고 있는지 살펴보는 두가지 방법이 있다. 하나는 실패하기로 미리 정해진 프로젝트인지 살피는 것이다. 예를 들면 ,누군가 당신이 화성에 가는 ...
Death march project는 22살의 젊은 프로그래머에게서 더 자주 볼 수 있는 것이다. 경영층에 성공을 약속한 비교적 젊은 낙관적인 Project manager뿐만 아니라 death march project에...
신 부모님과 다른 가족을 뒤에 남긴다는 것이 너무나 고통스럽기 때문에 중년이나 장년의 사람들에게는 역시 공통적인 문제이다. 인력 수요가 증가할 때는 이러한 것들은 문제가 아니다.그러나, 누구나 내가 말하고 있는 것을 정...
Death march project할 만하다. 그러나 이 한가지를 기억하라. 만약 death march project가 성공한다면 , 또 다른death march project가 나타난다. 이 책의 서두에서 언급한 테마...
자로부터 death march project에 참여하지 않을 사람은 바로 회사를 그만두라는 도발적인선언에 의하여 자주 사람들을 분개 시킨다. 그래서 남아있는 사람들은 회사를 구하기 위하여집중할 수 있다. 다시 말해, 이...
Death march project있다. OO programming 과 같은 신기술을 시도하고, 다른 경우에는 요구되어지는documentation과 무거운 절차를 간소화 시킬 수 있다. 역시 중요하게, death mar...
1.4 SUMMARY. 이 장에서의 논의가 비관적이고 냉소적 이라면, death march project가 계속 발생한다는것을 기억하라. 크든 작든 회사는 정치적인 것들로 가득 차고 , 공포 불안 오만 냉혹함과 같은 감...
Death march project2장.     POLITICS정치적으로 사로잡히는 것을 조심해라. 그들은 흥미 있고 영리하지만, 그들은 그들의 본질에서 놓치고 있는 그 무엇인가가 있다; 구멍이 있고, 빈 자리가 있고,...
면 성공의 기회는 거의 zero에 가깝다. 그들 중에 일부는 다른 사람보다 더 시끄럽고, 누군가는 지원가나 친구일 것이다. 그러나 일부는 프로젝트의 반대 목소리를 가지고 다른 이들은프로젝트 관리자의 뒤에서 해칠 기회를 ...
Death march project그런 프로젝트를 시작하지 않는다 – 그러나 여기서 명심해야 할 핵심은 많은 death marchproject는 owner로부터 확실한 명령 없이 시작되는 것은 볼 수 없다는 것이다. 이...
가 아니라는 사실이다.; 프로젝트에 정치적 영향을 미치는 사람이 owner, 한 사람이 아니라는 사실이다. 아래에서 논의 될 다른 players도 명심해야만 한다.2.1.2 Customers 많은 경우에 customer...
Death march projectShareholders를 다룰 수가 있다. – 여기서의 핵심은 Shareholders는 무시되어서도 잊혀져서도 안 된다는 것이다. 그들을 간과하기 힘든 이유는, 그들은 자신의 위치와 목...
들은 종종 의사 결정자의 귀에 부드럽게, 잠재 의식의 톤으로 속삭이는 데 시간을 보   낸다. 그리고 일이 발생되고 있는 상태에서도 당신은 알지 못한 채 단시간 내에 친구   를 적으로 만든다.이 말은 stakehold...
Death march project조직이나 IS/IT부의 평판과 신빙성의 영향을 받기 때문에 project의 모든 성공 사례를 고려한다. 가장 자주, champion은 Java, 객체지향 기술이나 새로운 client-s...
있을 수 있다; 그리고 그들은 schedule, 예산, 관련된 자원의 다른 조합에 영향을 줄 수도있다.그러나 이런 project를 특성화시키는 다른 방법이 있다. 그리고 모든 고려되어야 할 사항에의미 있는 politic...
Death march project의 영웅으로 기술적인 hacker로 똑똑한 천재이며 team 내부에 신적인 존재로 자리매김한다.Team 구성원은 다른 이들에게도 열정적으로 성실하다. (Tom Cruise 영화의 왜곡에...
3 장. 협상만일 당신이 death march 프로젝트의 관리자(PM)라면, 예산, 스케줄, 자원 등을 통해 협상의 결과를 쉽게 예측했을 것이다. : 당신은 실패했다.이것은 어쩌면 당연한 결과이다. 그러한 협상들이 프로...
Death march project3.1. 합리적인 협상 우리는 어떠한 S/W 전문가들과 관리자들의 그룹간에 있어서 감정적 논쟁을 낼 수 있는 중요한 프로젝트를 위해, 요구되는 스케쥴, 예산, 자원들을 정확하게 측정하는...
떤 효과가 있을까? 하루 8 시간안에 보다 많은 산출물을 얻느냐는 것이 기본적인      가정이다. ; 그러나, 대부분 경험이 풍부한 PM 들은 점점 지쳐가면서 생산성이 떨      어지는것들 (일일 functionpo...
Death march project협상에 필요한 몇몇 유용한 질문들“만일 시스템이 9월 1일에 준비가 되어야 할 것이 9월 5일에 준비가 되었다면, 그러나 9월 2일에 파산이 되었다면 ?“여기에는 80/20법칙이 있습니...
일반적으로 non-linear 미분 방정식에 기초하고, 우리들의 대부분은 이미 우리 머리에 있는수학 수준을 향상시키는데 익숙하지 않다. 유사한 예로, 상업적인 측정도구는 상황들을 통해서 얻은 직감을 기초로 얻은 많은 매...
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
죽음의 행진
Upcoming SlideShare
Loading in …5
×

죽음의 행진

1,140 views

Published on

인터넷에서 구하게 된 죽음의 행진 요약본입니다. 죽음의 행진은 제가 좋아하는 프로젝트 관리에 대한 책입니다.

요약본이지만 페이지수는 115페이지나 되네요~!

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,140
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

죽음의 행진

  1. 1. Death march projectDeath march- the complete s/w developer’s guide to Surviving “ Mission Impossible” ProjectsEdward Yourdon1997.1장. Introduction1.1 Death march Project의 정의 : 프로젝트의 평균적인 특성을 50%이상 초과하는 프로젝트. . schedule … .일정이 합리적 예측process으로부터 12개월이 소요된다면 6개월이나 그보 다 짧은 기간에 완료해야하는 경우. 오늘날 세계시장에서의 사업경쟁의 압력 때문에 이 것이 death march project의 가장 일반적인 것이다. . resource … .. 개발인력이 예상되는 것보다 50% 또는 그 이상 줄어든 경우. 이것은 CASE나 새로운 Programming langue에 대한 순진한 믿음으로부터 기인한다. 팀원들에 대한 새로운 기술에 대한 교육을 실시하지도 않았음에도 불구하고 downsizing과 reengineering ,인력감축의 다양한 형태로부터 기인한다. . Budget … … 예산이 50%이상 감축된 경우. 이것은 고정금액 게약 방식에서 경쟁적인 입찰의 결과로 기인한다. 영업부서로부터 PM은 “ 좋은 소식은 우리가 게약을 땄다는것 이고,나쁜소식은 경쟁에 이기기 위하여 당신이 말한 예산의 50%에 수주했다는 것이다.” 라는 말을 듣는 경우이다. 이것은 임금수준이 높은 경력자보다 경험없는 신참들과 프로 젝트를 수행하거나 수행에 필요한 팀원의 수를 줄이거나 야식이나 야근,특근시 그에따른 비용을 사용할수 없게 된다는 것이다. . scope … ..일반적인 환경하에서의 프로젝트보다 기능,구성,성능,기술적 관점이 두배이상 되는 경우. 이때 프로젝트팀은 그들의 시스템이 예전에 비교되는 시스템보다 트렌젝션 의 2배의 양을 처리토록 해야만 될 수도 있다. 납기의 제한에도 불구하고 인간두뇌의 믿 을수 없는 창의력을 요구하게 된다.많은 회사들에서 이러한 제약조건들에 대한 즉흥적인 결정은 프로젝트 팀원들이 주당 2배이상 일 하거나 , 2배이상 힘들게 일하도록 한다.1.2 Death March Projects의 분류. small-scale projects … .. 3~6개월 안에 프로젝트를 완료할 가망성이 없는 것에 대하여 10명이하의 인원으로 팀원이 구성된 경우. -1-
  2. 2. . medium-sized projects … .1~2년이 걸릴 것으로 에상되는 20~30명으로 구성된 경우.. large-scale projects … 3~5년의 일정과 100~200명 으로 구성된 경우.. Mind-boggling projects … ..7~10년의 일정과 1000~2000명으로 구성된 경우(많은 경우 컨설턴트나 협력업체인력 포함).프로젝트의 크기에 더하여 프로젝트에 관여하는 고개의 수와 같은 요소가 프로젝트를 분류하는 요소가 될 수 있다. 특히 정치적으로 적대적인 고객들이 프로젝트에 관여하는 경우프로젝트는 매우 어렵다. 프로젝트팀이 아무리 훌륭해도 성공을 보장할 수 없다.1.3 왜 death march project가 발생하는가?발생이유 . Politics, Politics, Politics . 영업,경영층,PM에 의해 만들어진 순박한 약속. . 젊음의 순박한 낙관주의 : “ 우리는 주말까지는 그것을 할 수 있어 !” . 거대한 기업들, 신설기업의 착수 심리 . 해병대 정신 ; 진정한 프로그래머는 잠을 자지 않는다. . 세계화에 따른 경쟁의 심화 . 신 기술의 출현에 따른 경쟁의 심화 . 예상치 못한 정부의 규제에 기인한 극심한 압력 . 예상치 못하거나 계획되지 않은 위기의 도래 ; 팀원들의 급사, 벤더의 도산.1.3.1 Politics, Politics, Politics 대립하는 2명의 부사장 사이에 프로젝트가 놓이면 프로젝트는 죽음의 행진이 될 가능성이많다. 예산,기간,인력, 범위 등이 50%이상 어려운 경우에 처할 가능성이 많다.만약 프로젝트가 계속되어 진다면 그것은 하나의 사고이거나 반대편에 서기보다는 자발적인희생양으로서 현명한 정치가가 된 당신의 PM이나 그 위의 관리자가 있다는 것이다.1.3.2 영업,경영층,PM에 의해 만들어진 순박한 약속 고객에게 순박한 약속을 하고 그 약속이 영웅적이라고 느끼는 경우에 Death march project가 만들어 진다. .가장 나쁜 경우는 그러한 약속을 한 사람이 그 결과에 대하여 잘 알면서도 그렇게 한 경우이다.1.3.3 젊음의 순박한 낙관주의 : “ 우리는 주말까지는 그것을 할 수 있어 !” 관리자가 death march project에 관련된 바보 같은 많은 의사결정에 편리한 희생양이지만기술자들은 전적으로 전혀 책임을 지지 않는다. -2-
  3. 3. Death march project실로 많은 경우 상위 관리자들은 행복스럽게 복잡한 프로젝트들의 예측이나 일정계획 수립process에 경험의 결핍과 순진성을 허용하고 있다. “이일에 얼마나 기간이 소요될까?”라는질문을 적극적이고 유능한 기술자에게 물어볼 것이다.만약 그 기술자가 젊은 낙관주의와 야심에 가득 차 있다면 “걱정 마세요. 주말까지는 완전히끝내버릴 것입니다.” 라고 말할 것이다.그들은 document 같은 산출물, 에러 처리,사용자의 자료 편집,요구사항 변경, 테스팅 과 같은 귀찮고 어려운 일들을 전혀 고려하지않고 하는 이야기일 경우가 많다.만약 당신이 산전수전 격은 베테랑이라면 , 그리고 어떤 순진하고 젊은 Technical manager가 프로젝트의 자원,일정,예산에 대한 말도 안되는 낙관적인 commitment에기인한 death march project에 로프로 묶이게 된다는 것을 알 수 있다면 당신은 어떻게 할것인가? 최선의 충고는 내 생각으로는 도망가라는 것이다.1.3.4 거대한 기업들, 신설기업의 착수 심리 나는 이러한 경우를 보아왔고,그러한 프로젝트에 참여해 왔으며 여러 경우에서 프로젝트착수의 책임자로 있었다. 이 책을 쓰고 있을 때,회사이름이나 제품이름에 “Java”라는 말이들어가는 신설 회사들이 그들이 하려고 하는 것에 대해 아는 것 보다 많은 venture 자금을갖을 수 있다는 현상이 나타났다. 그러나 일반적으로 신설회사는 직원,자금,관리,등에서 부족하고 성공기회에 대한 턱없는 낙관을 하고있다. 그들은 좀더 조심스러워야 한다. 경험 많은경영자는 예측되지 않은 위험에 대비할 많은 예비비와 심사숙고된 계획없이 새로운 회사를시작하는 꿈을 꾸지는 않는다.그래서 신설회사와 관련된 프로젝트의 대다수가 death march project이다. 프로젝트의 대다수가 실패한다. 대다수의 회사가 프로젝트와 함께 망할 것이다. 인생은 그런 것이다.(C’est lavie) 그것이 첨단기술 자본주의인 것이다.대부분의 사람은 회사 창립의 문화나 환경과 익숙하지 않다. 만약 당신이 쇠퇴해 가는 정부기관에서 뇌사상태의 COBOL zombie들과 지난 20년간 일해왔다거나 reengineering,outsourcing, downsizing으로 신설회사에 일자리를 얻었다면 , 당신은 무었을 해야 하는지생각이 없을 것이다. Death march project는 역시 대기업에서도 발생한다. 그러나 그들은 자주 “night of the living dead”같은 영화의 엑스트라들로 팀을 구성한다. 환경은 신설회사와는매우 다르다. 그것은 밀려드는 공포와 같다. 동시에 신설회사는 자주 내가 언급한 순박한 낙관주의로 고통을 격는다. 많은 신설회사는 그들의 새로운 기술이 빌게이트 보다 부자로 많들어 줄 것이란 확신에 의해서 만들어진다. 다른 것들은 에스키모에게 인터넷이되는 냉장고를팔수 있다고 믿는 마켓팅의 마법사에 의하여 설립된다.낙관주의는 신설 벤처회사에게 중요하며, 다른 사람들이 이전에 가능하다고 생각하지 않은것에 벤처의 성공여부가 달려있을 수 있다. 그러나 도전적이고 낙관적인 신설기업은 수학과물리학의 원칙에 따라야만 한다.만약 당신이 신설회사의 death march project에 참여한다면,성공을 위한 계획인지 아닌지 전체의 모험이 희망적인 꿈에 기초한 것인지 체크하기 바란다. -3-
  4. 4. 1.3.5 해병대 정신 ; 진정한 프로그래머는 잠을 자지 않는다 신설기업은 해병대 신드롬에 물들기 쉽다. 그러나 나는 EDS나 6대 회계법인과 같은 컨설팅 조직에서 자주 그것을 보아왔다. 그것은 창립자의 개인적 성향을 반영할 지도 모른다. 또는 그것은 설립당시의 기업문화로부터 기인한 것일지도 모른다. 예를들면 Microsoft에서 기업문화는 이러한 요소들에 기인해왔다.본질적으로 당신은 상사로부터 “ 모든 프로젝트는 다 이래. 그것은 우리가 여기의 일들을 처리하는 방법이기 때문이지.우리는 성공적으로 해왔고,그것을 자랑스럽게 여긴다.그것을 할 수없다면 너는 우리와 함께할 수 없다.”는 이야기를 듣게될 것이다.그것이 성공적이었다고 해도 , 중요한 것은 그것이 우연한 결과가 아니라 의도적이라는 것이다. 만약 당신이 순교자이거나 혁명가라면, 그러한 기업문화와 싸울 결심을 해도 좋다. 그러나 당신은 성공할 가능성이 아주 작다. 다만 전반적인 death march 문화의 부정적인 결과들이 나타날 것이다. 예를 들면 훌륭한 사원들이 슬금슬금 빠져나가고 회사는 결국 망할 것이다. 때때로 그러한 기업의 행동에 대하여 공식적인 논리적 근거가 있을 수 있다. 예를 들면“ 우리는 험한 시장환경과 싸워야 되, 우리의 경쟁자도 우리만큼은 해, 우리가 이길 수 있는유일한 길은 두배로 열심히 일하는 거야!”. 때때로 death march project는 초심의 젊은 사원들을 제거하기위해서 만들어 지기도 한다.그 결과 death march project로 부터 살아남은 자가 부사장이나 임원의 자리에 도달할 것이다. 이유가 무었이건, 단순히 한 프로젝트만을 위하여 그것에 대하여 불평을 할 점은 많지않다. 그것이 그러한 프로젝트에 투입되는 것을 수용하여야 한다는 것은 아니다.결국, 회사의모든 프로젝트가 death march project이기 때문에 당신이 성공하거나 살아남을 것이라는 것을 의미하는 것은 아니다.1.3.6 세계화에 따른 경쟁의 심화 과거에 death march project를 허용하지 않던 기업들도 90년대에는 세계화된 시장 경쟁의수준이 높아졌기 때문에 그것을 허용 하곤 한다. 여기 두 번째 요소는 인터넷을 포함한 범세계적인 통신수단 과 관세와 쿼터의 제거나 보호하던 시장의 개방에 대한 정부적 의사결정이다. 어떤 회사들에겐 새로운 현상이 아닐 수 있다. 예를 들면 전자,자동차산업에서는 1970년대 이래 극심한 경쟁에 직면해왔다. 그러나 다른 산업에서는 북미시장에 유럽과 아시아의경쟁자가 출현함에 따라 갑작스런 충격이 왔다. 그것은 downsizing에서 reengineering까지급격한 이동의 다양성에 대한 모함을 시작하기로 결정할지도 모른다. 그러나 그것은 조만간그것을 지원할 새롭고 야심찬 시스템을 필요로 하는 새로운 제품이나 서비스를 만들고자 할것이다. 자 death march project가 시작된다. 그러한 프로젝트는 실패의 결과 상위 경영층으로부터 예를 들면 도산이나 해고와 같은 무서운 경고를 동반한다. 이것은 그러한 프로젝트에 참여하는 제일 큰 정의임을 입증할지도 모른다.1.3.7 신 기술의 출현에 따른 경쟁의 심화 시장의 확대로부터 기인한 경쟁은 자주 방어적인 문제로 인식된다. 그러나 그것은 도전적 -4-
  5. 5. Death march project이고 긍정적인 기회로 인식될 수도 있다. – “만약 우리가 2BYTE의 글자를 갖는 이 새로운 시스템을 만든다면 일본 시장에 진출할 수가 있다”. 유사하게 급격한 기술의 개선에 대한 소개는 기존의 기술에 의한 제품들로 이성적으로 행복한 기업에게 방어적인 요인이 될 수 있거나경쟁우위를 위한 새로운 기술을 사용하기로 하는 전향적인 의사결정을 유도할 수도 있다. 이책을 쓸 때 , JAVA나 World Wide Web 과 같은 기술들은 명백히 이러한 현상의 예가 되었다.그러나 우리 산업에 대한 놀라운 것은 매년 새로운 사례들이 나타난다는 것이다. 만약 새로운 기술상황에 대한 기업의 반응이 방어작인 것이라면 Death march Project는 기존 한계를뛰어넘을 수 없는 그 기업의 기존 기술을 사용하는 프로젝트의 하나일 것이다. 그래서 만약회사가 그 기술을 통째로 버리기에는 너무 많이 투자하였다면, 프로그래머가 기존보다 10배나 빠르고 매력적인 방법을 찾도록 요구하며 기존 시스템을 재구축하는 모험을 할 것이다.신기술 출현에 의한 많은 Death march Project 들은 새로운 기술을 처음 사용하게 된다. 당신 회사에서의 처음 Internet/Java , relational database, object-oriented, client-server 프로젝트들을 돌이켜 생각해보라. 그들 중 어떤 것은 새로운 기술의 잠재적 효용성을 탐색하기위한 온당한 실험이었을 것이다. 그러나 그들 중 어떤 것은 같은 기술을 발표하려는 다른 기업에 대한 경쟁적 반응으로 수행되었을지도 모른다. 후자의 경우, 말도 안되는 일정과 예산을부과할 뿐만 아니라 규모가 컷을 것이다.그러나 크기,일정,예산의 명백한 특징을 무시한 그러한 프로젝트들의 진짜 death march 성격은 산업의 강한 적용을 위하여 방금 떠오르는 신시술의 적용을 시도한다는 것이다.그 기술이 기본적으로 사용할만한 것이라 할지라도, 그것은 대형 프로젝트에 적용하기에 적합하지 않은 경우가 많고 그 기술의 약점을 피하고 장점을 어떻게 적용하여야 하는지 아무도모르며 , 공급자도 그것을 적절히 지원할 방법을 모르며, 등등 많은 문제점이 있다. 기존 기술자들에게 이런 것들이 유쾌하지않은 경험으로 인식되는 반면, 그것이 새로운 것이기 때문에 Project manager나 젊은 기술자들은 이것을 좋아한다는 것을 기억하는 것이 중요하다. 그리고 이것은 내가 그들이 일해야 하는 일정,예산의 제약에 대한 순박한 낙관주의로 위에 언급한 것과 같다. 실험적 신 기술을 작업지시의 형태로 떠맡게 하여 모두 야근과 특근을 계속해야 하는 death march project가 되는 것이 두려운가?1.3.8 예상치 못한 정부의 규제에 기인한 극심한 압력 위에 언급한 것처럼, 시장의 세계화는 닫혔던 시장을 개방하는 의사결정이나 수입 쿼터의철패,관세인하 등의 정부의 조치는 death march project 요인들 중의 하나이다.그러나 이것은 한 예에 불과하다. 실로 통신시장,금융시장,항공시장에 대한 규제완화의 정부결정의 결과로 오늘날 많은 death march project가 발생한다.어쨌든, 특별히 과세,증권감독원에의 상세한 회계보고,환경규제 같은 정부의 증가된 규제압력의 예는 많다. 민주주의 하에서, 적적한 법규를 정하기 전에 입법부가 여러 달이나 여러 해동안 논쟁하고 논의하고 떠들기 때문에, 그러한 규제를 사전에 쉽게 알 수가 있다. 그러나,바로 지난달 까지는 자세한 것이 명확하지 않다. 경영자로부터의 전형적인 반응은 그것이 회피할 수 없다는 것이 분명해질 때까지 그 전체를 무시하는 것이다. 그리고 또 다른 death -5-
  6. 6. march project가 생긴다. 특별히 이러한 많은 death march project들이 부담스러운 것은dead line때문이다. 새로운 시스템은 제멋대로 정한 날짜까지(예를 들면 1월1일) 운영될 수있어야 하며 아니면 하루에 백만불의 벌금이 부과된다. 포기하거나 연기를 요청할 수 있으나많은 경우 deadline은 절대적이다.만약 제때에 새로운 시스템이 끝나지 않으면 재앙이 발생할 것이고 도산, 해고 등 그 결과는기업에게 무시무시한 것이다. 이러한 프로젝트에서는 기술이 문제가 되는게 아니라 도전적인일정이 문제가 된다. 물론, 경영자는 때때로 부적절한 예산으로 프로젝트를 엉망으로 만들거나 인력을 부족하게 구성하여 상황을 악화시킨다.1.3.9 예상치 못하거나 계획되지 않은 위기의 도래 당신의 프로그래머 2명이 결혼을 한다거나 평화봉사단에 가거나 오늘까지만 근무한다고말하러 회사에 나왔다거나 network 서비스담당자가 공급회사가 부도가 났다고 말하려고 당신에게 전화를 하고 그래서 당신은 다른 공급자의 network protocol 을 사용하기 위하여 앞으로 한 달 동안 모든 프로그램을 다시 짜야 한다. 법제팀에서 당신에게 아무도 알지 못하는 애매한 세법 몇 조 몇 항의 위반으로 회사가 몇 천억이라는 소송에 부쳐졌다는 이야기를한다.물론 당신은 잘 관리되는 회사에서 2명의 최고 프로그래머의 퇴사는 예상되었고 계획된 것이라고 주장할 수도 있다. 그리고 당신은 하나의 통신 공급자에게 의존할 만큼 그렇게 어리석고 바보 같지 않을 수도 있다. 회사는 그 세법의 상세한 내용을 체크하는 예지력을 가졌고그러한 위기는 관리부재와 계획이 제대로 되지 않은 결과일 수 있다. 그래서 “계획되지 않은 위기”는 반어법적인 표현이다.아마도 그래서, 사업을 수행하는데 발생할지도 모르는 모든 미칠만한 것들을 모두 예상하고준비하는 것은 점점 더 어렵게 되었다. 좋던 싫든, 우리는 혼돈의 시대에 살고 있고 deathmarch project는 이러한 혼돈의 당연한 결과이다.어떤 경우이든 예상치 못한 위기는 death march project를 유발한다. 가장 나쁜 경우는 위기가 이미 발생했고 그 문제를 해결할 새로운 시스템이 설치될 때까지 상황이 계속 악화되기때문에 dealline이 이제이고 이미 늦은 프로젝트가 만들어 지는 경우이다. 다른 경우는 프로젝트의 중요한 사람이 갑자기 떠나버려 한편으론 합리적인 프로젝트가 death march project로 바뀌는 것이다.위에 언급한 “해병대”상황에서는 놀랄 일이 아니고 이전의 모든 프로젝트처럼 특별한 노력을요구할게 될 프로젝트라는 것을 프로젝트의 첫번째 날부터 모두 안다. 신설회사에서는 deathmarch project는 도전적이고 흥분되고 그것이 성공하면 모두를 부자로 만든다는 설레임으로예상되는 경우이다.1.3 왜 사람들은 death march project에 참여하는가? 앞 장에서는 많은 이유들로 회사가 death march project를 만들거나 허용하는 것이 논의의 -6-
  7. 7. Death march project주제였다. 우리들은 이러한 이유들에 동의하거나 동의하지 않을 수 있고, 진정으로 예기치못한 위기로 인한 프로젝트들에 동정할 수도 있다. 그러나 궁극적으로 개인적인 입장에서 삶의 한 사실로서 그것을 수용하여야만 한다.그러나 그것이 우리가 그 프로젝트에 반드시 참여하여야 한다는 것을 의미하지는 않는다. 이책의 대부분은 당신이 어떤 환경에서 참여하지않는 것을 제안할 것이지만 당신이 deathmarch project에 참여할 것이라는 것을 상정한다. 그러나 그러한 의사결정의 제일 좋은 시점은 프로젝트의 시작 단계이다. 당신이 그러한 프로젝트에 배정되었다는 이야기를 들을 때 ,당신은 거절할 것이지 고려하여야 한다. 만약 그러한 거절이 불가능한 회사의 분위기라면 회사를 그만둘 것인지 선택을 해야 한다. 명백히 어떤 개발자들과 대다수의 관리자들은 이것은현실적인 선택이 아니라고 논쟁할 것이다. 나는 이것을 짧고 자세하게 논의할 것이다. 그러나 당장은 death march project에 참여하는데 대한 부정적인 이유들 중의 하나가 있고, 그것은 마음에 들지않을지 모른다.그러나 그것은 다른 대안보다 그렇게 나쁘지 않을지도 모른다.다른 면에서는 ,어떤 개발자들은 그런 프로젝트에 참여한다. 순박한 낙관주의 때문도 아니면서 , 일 이년 휴가를 미루고 휴일 없이 하루에 14시간 일해야 하는 프로젝트에 참여하기위해합리적인 사람이 왜 지원하는가? TABLE 1.2 Death march rojecte에 참여하는 이유 리스크는 높다, 그러나 그만한 보상이 있다. “에베레스트” 신드롬 프로젝트를 수행할 사람들의 열의에 마음이 든다 젊음의 순진한 낙관주의 다른 대안은 해고밖에 없다. 장래의 승진을 위하여 고려되었다. 대안은 파산이나 고사목이 되는 것이다. 그것은 관료주의로부터 탈출하는 기회이다. 복수이것은 완전한 것이 아니다. Kevin Huigens는 그의 프로젝트 팀원들과의 brainstorming을 통하여 death march project에 참여하는 이유를 아래와 같이 도출하였다.모두 그들이 요구되는 사람이라고 느끼기를 원한다. 기회로 인식한다. 돈을 벌 수 있다고 인식한다. 일을 잃고 싶지 않다. 프로젝트를 리드하기 위하여 외부에서 영입 되었다. 허구에 대한 믿음 프로젝트가 실패할 것인지 관심이 없다, 새로운 기술로 하는 일을 얻고 싶다. 새로운 기술의 OJT 영원한 낙관주의 도전 -7-
  8. 8. 똑똑하게 보이는 어리석음 일을 하는 Job을 얻기 위하여 단지 프로젝트이니까 친구가 프로젝트에 참여하니까 형제가 프로젝트에 참여하니까 사장의 지시로 다른 삶이 없다. 그렇게 하는 것 보다 더 좋은 것이 없다. Stock option 급여인상 사랑은 맹목적이다. 경력을 쌓기 위하여 무식 우정1.4.1 리스크는 높다, 그러나 그만한 보상이 있다1.3.4장에서 논의된 신설회사의 시나리오는 이 상황의 좋은 예이다. 만약 그들의 프로젝트의성공은 상장되는 것을 의미한다는 것을 당신이 말한다면 , 그들의 stock option이 그들을 바로 백만장자로 만들 것이고, 실패할 때까지 그들은 행복하게 일할 것이다. 그들은 적어도 지성적으로 모험에 따른 위험이 존재한다는 것을 깨닫고 있으나, 그들의 대다수는 그들이 불사신이며 전지전능하다고 믿고있기 때문에 위험에 많은 주의를 기울이지 않는다. 실로 서부 문화를 고려해보면 젊은 s/w 개발자가 death march project에 자발적으로 참여하는 것이 놀랄일이 아니다. 우리는 주로 쉴줄 모르는 에너지, 터무니 없는 commitment, 긴 시간의 근무와개인적인 희생에 의존한 s/w 기업가와 경영자 뿐만 아니라, 올림픽 우승자, 스포츠 영웅,rock singer, 영화 스타들의 성공에 대하여 수없이 들어왔다. 우리는 성공과 관련된 불법적인 행동들과 어두운 거래 , 표리부동,배반에 대하여 결코 듣지 못 한다. 그리고 드물게 때와 장소의 중요성과 행운에 대하여 듣는다.한가지 더하여, 우리는 death march project 희생자들의 결과에 대하여 충분히 듣지 못한다.개인적인 건강, 정신건강, 가족관계 등 22살짜리 기술자에게는 문제가 안 된다.그들은 컴퓨터 분야에 매력을 느끼는 사회적이지 못하거나 내성적인 사람인가가 문제가 되지 않는다. 한편 당신은 death march project에 자진해서 참여하려는 40대 중반에서 50대의 사람들을 거의 찾을 수 없다는 것이 약간 우려가 된다. 그들은 이러한 프로젝트들이 실패할 수밖에 없는운명이라는 것을 배워왔고 자녀와의 좋은 관계나 결혼을 희생할 만한 가치가 없다는 것을 배워왔다.궁극적으로 이것은 가치관에 따른 개인적 선택의 문제이다. 나는 어느것이 옳고 나쁜지 말할 입장에 있지 않다. 나는 위에 언급한 것으로부터 사람들이 생각하는 것 만큼 부정적이지않음에도 불구하고 나는 강조해야 한다.나는 30년 전보다 훨씬 순박하지 않다고 믿음에도 불 -8-
  9. 9. Death march project구하고 나는 아직 기업가적 기회에 매력을 느낀다. 나에게 흥분될만한 위험과 보상의 공식을제시하라. 그러면 나는 또 다른 death march project에 참여할 것이다. 말이 난 김에 때때로보상은 재정적인 것보다는 심리적인 것이다.1.4.2 “에베레스트” 신드롬 왜 사람들은 고통과 위험에도 불구하고 에베레스트같은 산을 오르는가? 거기 산이 있기 때문이다. 왜 사람들은 삼종경기에서 졸도하도록 달리거나 마라톤을 달리는가?도전 때문이다. 도전이 전에 아무도 성공하지 못한 것이라면 그 도전은 더욱 흥미 있는 것이다. 지구상의 50억 인구 중에 오직 한 사람 만이 할 수 있었고 “나는 달 위를 걸은 최초의사람이다” 라고 말할 수 있다면. 어떤 사람들은 그것을 미친 짓이고 이기적이라고 생각할지도 모른다. 그러나 다른 사람들은 개인적인 스릴과 성공의 대중적인 영광을 위하여 무서운장애물과 가능성에 기꺼이 맞선다. 최근의 컨설턴트 AI Christians 는 아래의 e-mail을 보내왔다.나는 “그곳에 산이 있다”와 같은 “testosterone”이라는 남성호르몬의 일종에 대답하도록 요구 받고있다. 왜라는 질문이 생기는 많은 직업이 있다. 지하 광물 채굴, 카우보이,삼림소방낙하대원,벌목반출,제트기 전투, 잠수함승무원, 고층건물 유리창 청소등 s/w개발보다 모두 심각한 위험을 갖고있다. 그러나 그 모든 직업은 그들의 열정에 기인한 자신감을 갖은 참여자들이 있다.나는 1983년 가을에 최초의 macintosh 프로젝트를 방문한적이 있다. 나는 팀원들의 강열한확신에 감명을 받았다. Stive Jobs의 과대망상과 긴 작업시간을 일하는 이유가 무엇이든지 간에, 그 팀원들은 Macintosh가 personal Computing을 혁신할 것이라고 완전히 확신하고 있었다. 그들은 행운이 따랐고 그들이 옳았다는 것이 밝혀졌다.이런 시각으로부터 ,death march project의 실패는 고상한 실패일수 있다. 실리콘벨리의 셀수 없이 많은 수천만 달러의 벤처자금이 투하된 프로젝트들이 이 범주에 속한다. 1990년대초에 Pen-based computing이 이러한 사례이다 . 그러나 그들은 불행하게도 실패하고 회사가 통째로 파산했지만, 그것으로 이혼하고,위 궤양에 걸리고, 신경쇠약에 걸리고 또는 그 이상이었음에도 불구하고 그 프로젝트에서 일했던 사람들은 아직도 조용한 목소리로 그들의 경험을 말한다. “나는 GO! Corp에서 operating systems 일을 했다.” 산전수전 겪은 베테랑은그의 겁먹은 견습생에게 말할 것이다. “어쨌든 그것은 s/w의 혁명중의 하나였다.” Computer world의 표지를 결코 장식하지 못할지 모르지만, 역시 “회사의 에베레스트가 도전할 만한 가치가 있다고 여겨지기 때문에 기꺼이 참여한 개발자들이 있는 대기업 안 에서 묻혀버린 높은 야망을 가진 셀 수 없이 많은 death march project들이 있다.때때로 이러한 프로젝트들은 혁신적이고 현란하게 개발된 시스템을 시장상황이나 최종사용자나 원하거나 필요로 하지않기 때문에 실패하거나,프로젝트팀이 그들이 개발할 수 있는 것보다 더 많은 것을 약속하거나 그들이 고려할 수 있었던 많은 것을 무시해 버려서 실패한다. -9-
  10. 10. 당신이 에베레스트 형태의 death march project의 흥분상태에 휩쓸리고 있는지 살펴보는 두가지 방법이 있다. 하나는 실패하기로 미리 정해진 프로젝트인지 살피는 것이다. 예를 들면 ,누군가 당신이 화성에 가는 임무를 받을 것이라고 이야기하고 당신이 화성의 표면에 첫 발을딛는 영광을 차지할 것이라고 한다. 물론 당신의 Project manager는 “우리는 여유가 없어서산소통을 갖고 갈 수가 없다. 그래서 당신은 죽을 수 밖에 없다. 그러나 영광과 영웅이 되는것을 생각해봐!” 라고 말할 것이다.두 번째는 회사의 경영자나 창립자가 이야기 하는 도전이 결국 그렇게 대단한 것이 아니라고판명될지도 모른다는 것을 살펴보는 것이다. 만약 그것이 기술적인 문제라면 그것은 방심할수 없는 위험이다. 예를 들면, “우리는 WINDOW 95의 기능을 갖는 OS를 4K의 ROM에 넣는지구상의 최초의 인간이 될 것이다.” 그것이 놀랄만한 기술이 되기를 기원한다. 그러나 그래서?“그래서” 라고 두,세 번 질문하는 것은 좋은 생각이다. 물어볼 때마다 그 대답이 비현실적이고 일관성이 없으면 당신은 빨리 현실 세계로 돌아올 수 있을 것이다.의심 없이 그러한 프로젝트에 그들의 인생의 앞으로 3년을 보낼 “진정해”라고 말하는 몇몇프로그래머들과 지원자들이 있다. 기술적 도전이 충분히 정의로울 수 있다. 만약 그것이 당신의 존재 이유이고 모든 것을 의미한다면 앞으로 나아가 그 프로젝트에 참가하라.에베레스트 프로젝트의 가장 나쁜 형태는 그 도전이 회사의 경영에 터무니 없이 큰 문제로서아무도 잠시동안 그 상황에 대하여 중지하고 생각할 수 없는 경우이다.1.4.3 젊음의 순진한 낙관주의 우리는 신생의 산업에 있다. 대부분의 도전적이고 재미있는 프로젝트들은 20대의 사람들에의하여 수행되고 인도되고 있다. 팀원들의 나이가 25세 이상인 death march project는 별로없다. 그렇기 때문에 그들은 2차대전이나 월남전 당시 공군에 채용된 전투기 조종사나 폭탄투하 승무원을 상기 시킨다. 젊고,이상주의자이고, 그들은 무엇이든 할 수 있다는 절대적 믿음을 가진 .실로, 이것이 전통적인 프로젝트팀이 실패했던 것을 death march 팀이 성공하도록 하는 최고의 확신인 것이다. 우리 산업에서 특징적인 부분은 Lotus123에서 Navigator에 이르기 까지대부분의 성공적인 제품들은 합리적인 팀이 수용하지 않을 조건하에서 소수의 몇몇에 의하여개발되었다. 이러한 프로젝트들이 성공했을 때 그들은 자주 프로젝트팀에 불꽃과 행운을 주었고 실패했을 때 그들은 자주 참여했던 모든 사람에게 가치 있는 교훈을 주었다.(그 회사가아직도 재난을 겪고 있을 수 있음에도 불구하고).젊음의 순박함과 낙관주의는 가족관계의 번거러움으로 부터 자유,단순한 집중,끝없는 에너지로 결합되어 있다. 명백히, 이것들은 젊음의 전유물은 아니다. 그러나 산을 오르기 위한 적절한 열정과 두 아이를 둔 배우자가 있는 35세의 프로그래머 보다는, 일 이년 동안 계속해서주당 100시간을 일하는 death march project의 기술적인 요구에 집중할 수 있고 하고자 하 - 10 -
  11. 11. Death march project는 22살의 젊은 프로그래머에게서 더 자주 볼 수 있는 것이다. 경영층에 성공을 약속한 비교적 젊은 낙관적인 Project manager뿐만 아니라 death march project에 참여한 젊은 프로그래머는 “물론, 나는 이 프로젝트와 성공할 것이고, 완전한 에너지를 같고 많은 장애물을 극복할 것이다”라고 말한다.이것은 초점이 없기 때문에, 나는 이 모든 것에 대하여 가치 있는 판단을 할 수 없다. 위에언급한대로 ,우리는 젊은이를 끌어들이는 산업에 있고, 몇 년 안에 변할 것이라고 생각하지않는다. 젊은이가 한 문제에 일편단심 집중하는 능력과 에너지와 낙관주의를 버릴 것이라고생각하지 않는다. 그들의 순박함 때문에… ..자, 산전수전 다 겪은 베테랑이 이러한 병에 걸린그들의 젊은 동료들을 비난하는 것은 도움이 않된다.1.4.4 다른 대안은 해고밖에 없다 우리는 젊고 낙관적인 사람들이 많이 참여하는 산업에 종사하기 때문에, 지난 30~40년간지속적으로 완만하게(때로는 급격히) 성장하여 왔기 때문에, 나는 death march project에 참여하는데 대한 이러한 설명을 들을 때마다 항상 놀란다.그러나, 우리는 역시 급격한 변호가 베테랑들을 퇴물로 만드는 사업에 종사하고 있다.실로, 지난 10년 동안 우리의 전문가들이 다른 사무직 전문가들 처럼 엄청난 downsizing,reengineering ,outsourcing을 경험해온 커다란 변화가 있었다. S/W 산업에서 고용인력은 완만하게 증가하는지도 모른다. 그러나 우리는 때때로 이것이 단지 C++ 로 프로그래밍하는 일이 COBOL로 하는 일자리가 감소하는 것보다 더욱 증가한다는 것을 잊고있다. 부연하면, 거대한 IS/IT가 reengineering과 downsizing에 특별히 노출되기 쉬운 수천명의 관료들에게 확대되어 왔고, 경영자는 해고해야 될 기술자들의 순서를 준비하지 못했을지 모른다. 그러나그들은 자주 중간 관리자들과 참모들을 해고한다.이러한 모든 것들은 death march project들에서 중요하게 나타난다. 아마도 당신의 프로젝트팀이 필요한 수보다 단지 반 밖에 사람이 없는 이유는 경영자가 전체 S/W 조직을 반으로 줄였기 때문이다. 그리고 당신의 프로젝트가 필요한 기간보다 반 밖에 일정이 할애되지 않는것은 경영자가 명령으로 reengineering을 시도하기 때문이다. 그 명령은 전 조직이 전보다 2배의 생산성을 내고, “더 빨리,더 열심히”라는 단순한 지령으로 변화된다.이책은 reengineering에 대한 책이 아니며 경영자의 reengineering 전략에 대하여 언급하기를 원치도 않는다. 여기의 중요한 ISSUE는 이러한 종류의 환경에서 프로젝트가 만들어 질때 많은 기술자들과 프로젝트 관리자들이 무언의 위협을 느낀다.때때로, 만약 그들이 death march project의 요소들에 동의하지 않는다면, 그들은 일자리를잃을 것이다. 22살의 미혼의 프로그래머에게는 아무 문제가 안되나, 주택을 담보로 채무가있는 35살의 자녀를 둔 가장에게는 보다 심각한 일이다. 그리고, 45살의 단지 COBOL과CICS 밖에 모르는 프로그래머에게는 실로 심각한 문제이다. 우리는 신흥 산업에 종사하고있음에도 불구하고, 그들의 전문성을 굳건히 지키고 있는 55~60세의 프로그래머들이 있는충분히 기간이 경과한 산업에 종사하고 있다.배우자가 같은 도시에 일을 갖고 있거나 ,아이가 아직 그곳의 학교에 다니고 있거나 ,연로하 - 11 -
  12. 12. 신 부모님과 다른 가족을 뒤에 남긴다는 것이 너무나 고통스럽기 때문에 중년이나 장년의 사람들에게는 역시 공통적인 문제이다. 인력 수요가 증가할 때는 이러한 것들은 문제가 아니다.그러나, 누구나 내가 말하고 있는 것을 정확히 안다. 워싱턴의 레드몬드에 사는 사람들은 지금부터 5,10,20년 후에 같은 종류의 갑작스러운 충격과 직면할 자신들을 발견할 것이다.그런 상황이 그들에게 일어날 가능성을 무시하는 기술자를 발견하고 눈이 휘둥그래질 만큼Reengineering/downsizing 현상이 오랫동안 계속되어 왔음에도 불구하고 나는 일반적으로이런 위치에 처한 자신을 발견하는 중년이나 장년의 S/W전문가에게 연민을 느낀다.그러나 이것은 역시 다른 책의 주제이다. 나는 내가 쓴 “Decline and Fall of the AmericanProgrammer”와 “Rise and Resurrection of the American Programmer”라는 책에서 언급한바 있다.그리고, 나는 여기서 그러한death march project 의 실체에 한정할 것이다.만약 당신이 회사로부터 웃기는 일정과 자원과 예산을 배정한 프로젝트에 합류하지 않는다면당신의 자리는 없어질 것이라고 이야기를 듣는다면 어떻게 할 것인가? 명백히 이것은 당신의재정과 건강과 감정과 정신적 상황에 대한 당신의 평가에 달려있다. 그러나, 당신 역시 당신회사내의 상황을 정확하게 평가할 필요가 있다. 어떤 경우에는 진짜 위협은 당신이 참여하지 않는다면 승진,보너스,급여인상이 보류될 것이라는 것이다. 그러나 위협이 해고라 할 지라도, 큰 회사는 그들의 위협을 바른 방법으로 수행할 수 없다. 당신은 해고되기 전에 2~3달의 여유기간을 갖고, 어딘가 일을 찾을 충분한 시간을 갖을 수도 있다. .“즉시 death march project에 싸인하든지 아니면 개인적인 물건들을 챙겨서 즉시 회사를 떠나!” 라고 사장이 말하듯이 만약 그 위협이 더 즉흥적이고 무례합니까?나는 합리적인 사람이 그러한 환경에서 일하려고 선택할 것이라고는 믿을 수 없다. 그러나구조조정의 광기가 사장을 미처 날뛰도록 만들 때 까지는 직장의 환경이 합리적이고 친절했다고 가정하자. 자… 여기 사인을 하든지 그만두든지 해고되든지 당신은 무었을 할 수 있습니까?만약 모든 것이 가능하다면, 내 충고는 점점 더 상황이 나빠지고 있는 것이기 때문에 지금그만두라는 것이다. 당신은 몇 달 동안 저금해둔 돈으로 살아가야만 할 지도 모른다. 그리고새로운 기술을 익힐 때 까지 봉급이 줄어들지 모른다. 그러나 만약 당신이 굴복하여 아무런가능성이 없는 그러한 상황을 지속하는 것 보다는 행복한 사람이 될 수 있는 기회이다.death march project의 중간에 그만두는 것이 오도가도 못하는 당신의 동료들을 도움도 없이남겨두는 것이라고 느낀다면 이것이 당신을 윤리적인 궁지에 빠뜨린다 할지라도, 때때로 당신은 당신의 이력서를 수정하면서 일자리를 찾기 시작하면서 death march project에 지원하면서 이것을 달성할 수 있다.만약 당장 연금에 의존하거나 회사와의 약속에 묶여있거나 시장에서 팔리지 않는 기술을 가졌기 때문에 어쩔 수 없다고 느낀다면 당신은 death march project에 긍정적인 접근을 할지도 모른다. “늙은 개도 짖을 힘은 남아있다는 것을 보여주겠다”든지 , 중년의 베테랑은 “나는경영진에게 내가 아직 젊은 애숭이들 만큼 괜찮다는 것을 보여 주겠다. 그리고 우리는 이프로젝트를 납기 내에 끝낼 수 있다.”라고 말할 것이다. 그 용기와 긍정적 전망은 실로 칭찬 - 12 -
  13. 13. Death march project할 만하다. 그러나 이 한가지를 기억하라. 만약 death march project가 성공한다면 , 또 다른death march project가 나타난다. 이 책의 서두에서 언급한 테마를 기억하라. : death marchproject는 예외적인 것이 아니다. 그것들은 정상적인 것으로 되어왔다.1.4.5 장래의 승진을 위하여 고려한다. Death march project에 참여하도록 초청하는 때에는 장래의 승진과 직위의 상승이 제안을수용하고 프로젝트를 성공하는 것에 달려 있다는 위협을 가지고 사람을 사로잡는 경우가 종종 있다. 이것은 자주 Reengineering 을 시작하는 것과 관련이 있다. 예를 들면 “MegalithBank를 21세기로 리드하는 사람들은 믿을 수 없이 복잡하고 도전적인 Total System 2000reengineering Project를 통하여 우리를 리드하는 사람들일 것이다.” 만약 당신이 이러한 상황에 있다면 Politics가 key factor라는 것을 잊지 말라. Death march project에 일시적으로신망을 받는 사람은 그 프로젝트에 참여할 수도 있고 참여하지 않을 수도 있다. 그리고Death march project를 제안한 관리자는 그 프로젝트 팀원들이 그 process에서 살아 남을지죽을지는 관심이 없고 reengineering “crisis”를 단지 그 자신의 승진 기회로 사용할 지도모른다. 만약 당신이 Machiavelli의 “The Prince”라는 모든 단어를 기억해 왔다면 , 그리고 당신이정치적 게임을 즐긴다면 , 그러한 death march project는 정말로 신바람나게 건전한 것이어야만 한다. 그러나 대부분의 S/W 전문가들은 “the prince”를 대학시절 이래 읽은 적이 없다.덧 붙여서 정지적으로는 애숭이에 불과하다. 그들은 역시 정치적인 모든 개념에 혐오감을 나타내고 정치적인 것에 빠져있는 사람들을 대단히 경멸한다. 만약 그런 상황이라면 왜 누구나Megalith Bank의 Total System 2000 Project에 서명을 해야 하는가? 단 한가지 그럴듯한 이유는 이것은 단 한번의 death march project이고 Magalith Bank에서 장기간의 경력관리에 도움이 된다고 진실로 믿기 때문이다. 그리고 당신이 이것을 믿는다면, 기회는 돼지가 날수 있다고 당신이 믿는 것 만큼 그렇게 좋다. 내가 관찰해온 대부분의 경우에서, 승진에 대한 위협은 먼저 언급한 해병대 문화의 일부이다. 이 점에서 그것이 옳든 그르든 , 그것이 공정하게 지속적이라는 것이다. 만약에 당신의처음 death march project에서 그러한 위협을 받았다면 , 당신은 다음에도 또 그 다음에도또 그 다음에도 그러한 위협을 받을 것이다. 당신이 처음 회사에 입사했을 때 그러한 정책의장기적인 적용에 대하여 심사숙고하기에는 너무나 순진했을지도 모른다. 그러나 늦든 빠르든빠져들 것이다. 이러한 경우의 진짜 두 가지 선택은 수락하든가 그만두든가 하는 것이다.1.4.6 대안은 파산이나 어떤 다른 재난이다. 내가 설명한 것 처럼, 어떤 death march project들은 reengineering, downsizing, 경영진에의하여 결정된 outsourcing등에 의하여 만들어지며 , 국제경쟁, 예상치 못한 정부의 규제,이런 것들에 기인한다. 어떤 경우이든 결과는 같다. 다른 대안이 파산이나 어떤 다른 재난일수 밖에 없다고 믿기 때문에 사원들은 프로젝트에 참가하기로 한다. 그리고 이 상황은 경영 - 13 -
  14. 14. 자로부터 death march project에 참여하지 않을 사람은 바로 회사를 그만두라는 도발적인선언에 의하여 자주 사람들을 분개 시킨다. 그래서 남아있는 사람들은 회사를 구하기 위하여집중할 수 있다. 다시 말해, 이 문제는 옳으냐 그르냐의 문제가 아니라 경영자가 위기를 회피하기 위하여조기에 조치를 취하여야 하는가 하는 것이다. 요점은 위기가 오고 회사가 death marchproject를 시작했다면 참여할지 않 할지 합리적인 결정을 할 필요가 있다. 이 책을 쓸 때 ,Apple Computer 가 생존을 위해 싸우는 것처럼 death march project로 꽉 채워진 회사의 좋은 예이다. 초기의 논의로부터, 당신은 여기에서의 나의 충고를 예측할 수 있다.뒤로 물러서서 이death march project가 단 한번의 예외적인 것인지 지속적인 형태의 시작인지 자신에게 물어보는 것이다. 당신이 전투에서 승리한다고 해도, 당신 회사는 전쟁에서는 패배할지도 모른다. 당신의 death march project에서의 당신의 성공은 아이러니컬하게도 두번째 deathmarch project를 견딜 만큼 회사의 파산을 연기시키는 결과를 가져올지도 모른다. 다시 말해, 이러한 개인적인 의사결정은 충성심이나 동정심이나, 회사나 당신이 싸워보지도 않고 포기하지는 않는다는 것을 세상에 보여주기 위하여 최후의 만세를 외치는 심정으로각색될지도 모른다. 누가 알겠는가? : 19995년 초에 delphi를 출시한 borland 의 경우처럼 ,당신의 death march project가 엄청난 성공을 할지. death march project의 미래를 알 수 있는 수정 구슬을 우리들은 아무도 가지고 있지 않으며 , 정확히 death march 의 성공이나 실패의 결과가 어떠할지 예측할 수 없다. 어떤 회사는 일찍 망하고, 오래 있다 망하고, 근근히살다 망하고, 다른 회사들은 악재가 이어지기 전 까지는 호평을 듣는다. 당신이 당신의 수정구슬에 자문하듯이, 많은 사람들로부터 자문을 받으라. 당신은 deathmarch project의 성공/실패 결과를 솔직하게 논의할 정직하고 객관적인 관리자들을 발견할지도 모른다. 그러나 당신은 그 관리자들도 경력과 승급에 대한 같은 염려를 갖고있고, 자존심과 정치적 본능이 당신이 의사결정을 하는데 필요한 생생한 정보를 나누는데 방해를 할지도 모른다.1.4.7 그것은 관료주의로부터 탈출하는 기회이다. 기술자들과 프로젝트 관리자들은 회사의 관료주의가 생산성을 질식 시키고 불필요한 s/w개발 공정의 지연을 초래한다고 자주 불평한다. 그러나, 큰 조직에서는 더욱 관료주위가 확고하다. 특별히 방법론 경찰이 CMM이나 ISO-9000 공정에 엄격한 집착을 요구하는 회사에서. 유사하게 인사부서는 새로운 사람을 채용하기 전이나 프로젝트에 외부 계약자를 사용하기 전에 반드시 따라야 하는 복잡한 절차를 갖고 있을지도 모른다. Death march project는 자주 관료주의의 어떤 것들을 둘러쌓아 없애버릴 기회를 제공한다.이것은 실망한 s/w 개발자가 그러한 프로젝트에 기꺼이 서명하는 충분한 이유가 된다. 극단적인 경우, 프로젝트팀이 회사 밖의 별도의 분리된 건물로 옮기고, 늘상의 관료주위에 방해를 받지않고 그들의 일을 수행할 수 있다. 그러나 덜 극단적인 상황에서도, deathmarch project에서 자주 자신들의 tool과 Programming 언어를 사용하는 것을 허락받을 수 - 14 -
  15. 15. Death march project있다. OO programming 과 같은 신기술을 시도하고, 다른 경우에는 요구되어지는documentation과 무거운 절차를 간소화 시킬 수 있다. 역시 중요하게, death march project의 관리자는 자주 보통의 경우보다 팀원들을 선발할 때, 많은 자율권을 갖는다. Best case의 경우, 모든 이러한 변화는 death march를 세련된 경험으로 바꾸도록 할 수있다. 만약 death march project가 대단히 성공적이라면 , 그것은 전사적으로 개발 프로젝트에서 사용되는 기술,인력,공정에 대하여 지속적 변화를 만드는 촉매가 될 수 있다. 반대로death march project가 실패하면, 그것은 결국 표준 정책이 그렇게 나쁘지 않다는 것을 확정하는 계기가 된다. 어떤 경우에서든, 이 같은 상황은 그렇지 않으면 문명적이 아닌 것으로 보이는 프로젝트에 참여하는 완벽한 그럴듯한 이유이다. 어떤 회사에서는 , 어떤 s/w 개발자들은 그러한 프로젝트에 항상 싸인을 한다. 그것이 관료주의로 빨려들어 가는 것을 피하는 유일한 길이기때문이다.1.4.8 복수 복수는 daeth march project에 참여하는 합리적인 설명으로는 보이지 않는다. 그러나,그럼에도 불구하고 이것은 실제이다. Death march project의 성공은 무능력한 부사장으로부터 힘의 방향을 바꾸기에 충분할지도 모르고,death march project의 예산,납기의 조건하에서는 당신은 절대로 그것을 해낼수 없다고 말하는 추악한 비평가에게 창피를 줄지도 모른다. 복수심은 아주 강력한 감정이다. 특별히 큰 회사에서 경영진으로 진입한 사람들에게는 명백한 것이다. 다른 사람에 대한 모욕은 영원히 기억되는 법이다. 교활한 정치가는 몇 달이나 몇 년을그들의 적들에게 복수를 하기 위하여 기다릴 것이다. 복수는 매우 강력한 개인적 동기 유발 요인이 될 수 있다. 그러나 모든 프로젝트 팀원들을복수심으로 물들게 하는 것은 흔히 더 어렵다. 그리고 그러한 때에는 프로젝트 자체의 예산과 일정 내에 돌아가는 시스템을 제공한다는 공식적인 괘도를 잃어버리고 결국에는 복수 자체에 집중한다. 만약 복수가 당신에게 동기부여가 된다면, 나에게 말할게 많지 않다. 그것은 또 다른 개인적 판단이다. 그러나 프로젝트관리자의 복수, 팀의 복수 때문에 프로젝트에 참여하였다면 실로 매우 조심하여야 한다. 부사장은 바보야라고 PM이 당신에게 말할지 모른다. “그리고 만약6개월 안에 프로젝트를 끝내면 임원회에서 지독한 창피를 당하고 마침내 사직하고 말거야” .아마 부사장은 진짜 바보일지도 모른다. 그러나 그의 파멸을 위하여 당신의 개인적 삶을 2년동안 희생하기를 원하는가? 결국 다음의 부사장도 지난번 부사장처럼 바로 그렇게 바보일지모른다. 다른 한편, 부사장이 star wars의 영화에 등장한 Darth Vader의 화신으로 모든 사람이 인식하고 있고, PM은 Luke Skywalker와 Yoda 의 결합체로 인식되고 있다면 , death marchproject는 실로 크게 고무될 수 있다. 이러한 경우라면, 프로젝트는 선과 악의 전투로 바뀐다.그리고 불평 없이 사람들을 믿을 수 없는 희생을 수용하게 만드는데 그것으로 충분하다. - 15 -
  16. 16. 1.4 SUMMARY. 이 장에서의 논의가 비관적이고 냉소적 이라면, death march project가 계속 발생한다는것을 기억하라. 크든 작든 회사는 정치적인 것들로 가득 차고 , 공포 불안 오만 냉혹함과 같은 감정들 뿐만 아니라 깜짝 놀랄 낙관주의로부터 고통 받는 기술 개발자와 관리자들로 구성되어있다. OO, Client-server , Internet과 같은 신기술에 의해 제공되는 기회들을 갖는reengineering, downsizing, out-sourcing의 조합은 나에게 몇 년 사이에 death marchproject 들이 자연스런 것이 된 것으로 보인다. 그리고 이것이 이장의 요점이다. 당신은 여기서 제시된 논리적 근거 중 어떤 것에 동의하지 않을지도 모른다. 그러한 프로젝트에 참여하거나 착수하는 이유 중 어떤 것들은 싫어할지도 모른다. 요점은 death march project의 초기에 당신의 동기 부여 요인들을 이해하고 인식하는 것이다. 그래서 당신은 다음 직업을 위하여 그 밖의 다른 곳을 찾거나 팀과 합류하는합리적인 결정을 만들 수 있다. 이러한 프로젝트들의 대다수가 커다란 회사 스트레스와 감정의 기간동안 착수되기 때문에 , 당신이 생각하는 것처럼 합리적인 의사결정은 쉽지가 않다.당신의 관리자나 따르는 동료들의 감정은 움직이기가 너무 쉽다. 그런데, 이것이 내가 death march project를 반대하는 것을 의미하는 것은 아니다. 나는Rick Zahniser 의 그러한 프로젝트들은 실패한다고 하여도 교육적인 경험이 될 수 있다는 견해에 동의한다. 나는 전에부터 말해왔다. 나는 누구나 이러한 프로젝트의 마지막 하나에 있어야 한다. 그러나,당신이 적어도 한번 해야 하는 다른 것들이 있다. . 감옥에서 밤을 보내기 . Get commode-hugging drunk . Raise a boy . Raise a girl . Start your own business . Climb mount Fuji 이 책의 나머지에서는 , 당신은 항상 프로젝트를 수행하는 중에 그만둘 수 있는 Option을갖고 있다고 수시로 일깨움에도 불구하고 , 당신은 death march project에 참여하는 합리적인 의사결정을 했다는 것을 가정할 것이다. 이 시점에서 당신의 최고의 목표는 성공하는 것이거나 프로젝트를 살려내고, 다음 장에서는 어떻게 그것이 될 수 있는지 우리는 알게 될 것이다. - 16 -
  17. 17. Death march project2장. POLITICS정치적으로 사로잡히는 것을 조심해라. 그들은 흥미 있고 영리하지만, 그들은 그들의 본질에서 놓치고 있는 그 무엇인가가 있다; 구멍이 있고, 빈 자리가 있고, 그리고 그들은 정치를 그것을 채우는 데 사용한다. 그것은 그들을 기형인 채로 남겨둔다. Peggy Noonan정치 무대는 어떤 선택도 할 수 없으며, 반드시 열등생이거나 불한당이어야만 한다. Emma Goldman정치에서 당신의 위치를 아는 것은 매우 중요하다. 단지 당신의 자리를 지키는 것이나 당신의 자리에 매달리는 것이 아니다. 왜냐하면, 야망이나 권태는 위 아래로의 이동을 규정할 수도 있지만, 지위에 대한 의식- 자신의 지위에 대한 느낌- 은 당신이 해야만 할 일을 조정하는데 유용하다. William Safire 우리가 그것을 얼마나 부정하던지 간에 모든 소프트웨어 개발 프로젝트에서 정치는 하나의요인이다; death march project의 구별되는 특징은 정치는 어떤 일을 행하는 노력을 압도할만큼 충분히 강하다. 그러므로, 정치와 관련된 process는 다른 장에서 논의하기로 하고, 이장에서는 정치의 존재를 아는 것이 왜 중요하고, 몇 가지 충고를 제공하고자 한다.많은 소프트웨어 개발자는 정치가 존재하는 것에 대해 논쟁을 할 것이며, 그들은 모든 추한혼란을 제거하는 것을 조정하기를 더 좋아한다. 소프트웨어 분야에 관심을 가지는 많은 사람은 사회적으로 서투르고, 정치적으로 속기 쉽다: 우리는 정치적 게임들이 매우 지겨울 뿐 아니라, 우리가 정치의 “게임”을 하려 한다면 우리는 잘 할 수 없을 것이다. 누군가가(전형적으로 프로젝트 관리자) 정치를 조절한다면 매우 좋다. 그러나 모든 사람이 death marchproject에 참여한다는 가정하에, “프로젝트가 너무 중요하기 때문에, 그들은 우리를 일반적으로 혼란스런 정치적 협상에 남겨 두고 떠난다” 그렇게 되면 그 프로젝트는 더 성공의 기회를잃게 된다. 나는 이 장에서 정치의 3가지 양상에 대해 논하겠다.? 프로젝트에 포함된 정치적 “players” 를 확인하는 것 ?? 프로젝트의 기본적인 성질을 결정하는 것 ?? 프로젝트 참가자의 책임의 수준을 확인하는 것 ?2.1 IDENTIFYING THE POLITICAL “PLAYERS” INVOLVED IN THE PROJECT 여기서 기억해야 할 핵심은 death march project에서 핵심 인물이 누구인지를 알지 못한다 - 17 -
  18. 18. 면 성공의 기회는 거의 zero에 가깝다. 그들 중에 일부는 다른 사람보다 더 시끄럽고, 누군가는 지원가나 친구일 것이다. 그러나 일부는 프로젝트의 반대 목소리를 가지고 다른 이들은프로젝트 관리자의 뒤에서 해칠 기회를 기다리고 있을 것이다. : 수많은 관리 위기와 기술적문제에 시달리는 동안 이것은 쉽게 잊혀지지만, 이것은 기본적인 것이다. 나는 프로젝트에서누가 핵심 인물인가에 대해 모든 사람들이 아는 것이 필수적이라고 믿는다 – 비록 프로젝트관리자의 일상 생활이 모두 외부 사람과의 관계일지라도. 드문 경우에, “Skunk works”프로젝트는 일이 진행되는 동안 인류의 나머지로부터 프로젝트 팀의 모두가 격리될 것이다. 진실로,요즘은 “Skunk works” 프로젝트 조차도 완전히 격리될 수 없다. 왜냐하면 모든 사람이 전자메일이나 인터넷으로 다른 사람들과 관계를 맺고 있기 때문이다. 보통의 업무 환경 하에서,모든 사람은 기술적 동료, 프로젝트 밖의 관리자들, 사용자 단체의 사람들과 프로젝트가 진행되는 동안 관계를 맺는다. 이것은 피할 수 없는 일이다. 그러므로, 프로젝트 팀원이 분명히 친한 중간 수준의 관리자에게 전화나 전자 메일 메시지,또는 우연한 “프로젝트는 잘 진행되나? 라는 질문을 받는다면, 이런 메시지를 친구,적으로부터 받았던지 간에 이것에 대해 아는 것은 팀원에게 중요하다. 우연한 질문에 당신이 대답하는 것이 무엇이던 간에, 조직의 다른 부분에게로 전달될 것이고, 이런 정보가 더 커지거나,또는 사장되는 것을 보는 것은 일반적인 일이다. Dale Emery 가 나에게 보낸 전자 메일을 관찰한 것이다.[1]: 일반적으로, 입력된 내용이 고객과 관계가 있다면, 개발자는 그것이 비싸건, 변형되었 던 간에 여하튼 그것을 취해야 한다. 다른 경우에는, 개발자는 고객에 요구에 대해 간단한 가정을 한다.death march project에서 전형적인 “players”는 다음과 같다.: ? Owner ? ? Customer ? ? Shareholder ? ? Stakeholder ? ? Champion ?나는 각각에 대해 앞으로 논하겠다.2.1.1 Owner owner는 전통적으로 프로젝트의 결과나 시스템에 대해 지불하거나, 인정하고, 받아들이는사람이다. 이 사람이 어떤 사람인지를 확인하고, death march project가 진행되는 동안 그를행복하게 하는 것이 중요하다.많은 프로젝트가 owner의 희망도 없는 생각을 가지고 시작하는 것은 놀라운 사실이다: 특히,이런 조직의 야망과 과도한 열정은 이런 프로젝트를 낳는다. 분명히, 잘 관리된 조직은 결코 - 18 -
  19. 19. Death march project그런 프로젝트를 시작하지 않는다 – 그러나 여기서 명심해야 할 핵심은 많은 death marchproject는 owner로부터 확실한 명령 없이 시작되는 것은 볼 수 없다는 것이다. 이유는 간단하다: 그러한 프로젝트들은 특별한 비용과 위험, 납기 등의 제약을 포함하고 있기 때문이다.IS/IT부분은 그러한 프로젝트를 스스로 시작하려 하지 않고, 조직 내에 일반적 관료는 프로젝트가 권위를 가진 누군가의 강한 명령이 없이는 조정되고, 자금이 모아지는 것을 막는다.부각되는 또 다른 핵심은: death march project의 owner는 보통 소프트웨어 프로젝트 관리자보다 더 높은 수준의 관리자인 경우가 많다. 실로, 때때로는 조직의 사장 또는 CEO, 왜냐하면 이 프로젝트는 회사의 존립에 영향을 미치기 때문이다. death march project의 owner가비록 부사장일지라도, 보통 프로젝트에서보다 더 높은 지위와 관료적 제한을 배제해야 한다.한편, 이것은 정치적 잡음이 완전히 사라지는 것을 의미하진 않는다. 실지로, 많은 deathmarch project의 문제점 중 하나는 프로젝트 관리자가 거의 owner와 직접적인 접촉을 할 수없다는 데 있다. 프로젝트에 대한 권한 부여뿐 아니라 현 상태 보고에 대한 요구는 높은 지위의 owner로부터 중간 지위의 관리자 (death march project 관리자)까지 가는 명령의 사슬이다. 그리고 프로젝트 관리자와 real owner사이의 중간 관리자의 모두는 customers,shareholders, stakeholders, champions 이거나 프로젝트의 적들이다.이것을 명심해야 하는 이유는 death march project에 대한 owner의 원래 요구 사항이 프로젝트 관리자가 주문을 받기 전에 이미 쉽게 사장되어 버리기 때문이다. 흔히, death marchproject의 협상이 되지 않는 측면은 납기 부분이다: 새로운 Super-Widget 시스템은 절대적으로 1월 1일까지 마쳐야만 한다. 지구의 종말이 올지라도! 그러나 이와 같은 주문은, 명령의 사슬에 따라 내려가다 보면, 부가적인 제약 사항의 리스트 위에 쌓여 버리게 된다: 프로젝트는 Ada와 RPG의 결합에서 프로그램 되어야만 한다; 팀은 조지, 해리트, 멜빈을 포함해야만 한다.; 프로젝트는 새롭게 창조된 객체 지향 방법론을 사용하여야만 한다; 프로젝트 팀원들은 반드시 주의 마지막 날에 XJ13의 형식으로 17페이지를 작성해야만 한다.이와 같은 상황에서 높은 지위의 프로젝트 owner와 대면 미팅을 하는 것은 때때로 말도 안되는 제약들을 제거하는 결과를 가져오기도 한다. 하나만 제외하고는.- 납기. 그러나 프로젝트 관리자가 말도 안되는 규칙들로부터 제외될 수 있는 허가서를 써 준다면, 요구된 납기 내에 death march project를 마칠 수 있을 것이다. 그리고 만약 높은 지위의 owner가 준비품,도구, 또는 프로젝트 팀에 대한 회식에 대해 예외의 돈이 필요하다고 확신한다면, 프로젝트관리자는 그것을 얻을 수 있을 것이다.분명히, 높은 지위의 owner가 그렇게 협조적이 아니고, 프로젝트 owner이 조직 내에서 모두높은 지위에 있는 것은 아니다. 그러나 프로젝트의 owner에게 그것의 중요성을 확인 시키는동안 death march project의 중요성도 같이 확인시키는 것이 된다. 그리고, 나의 경험 중 대부분은 높은 지위의 프로젝트 owner은 적보다 더 친구가 되기 쉽다. 관료적 제약을 없애 주고, 금지 사항을 끊어 주는 owner의 관심은, 프로젝트 관리자에 대한 축복이다.그러나 명심해야 할 것은 시스템이 설치되었을 때 그것을 사용하는 사람은 프로젝트 owner - 19 -
  20. 20. 가 아니라는 사실이다.; 프로젝트에 정치적 영향을 미치는 사람이 owner, 한 사람이 아니라는 사실이다. 아래에서 논의 될 다른 players도 명심해야만 한다.2.1.2 Customers 많은 경우에 customer은 한 집단의 사람이고, death march project가 끝나면 시스템을 사용한다. 이런 사람들을 조직 내에서는 보통 “User”라고 부르는 것이 일반적이다. customers또한 death march project의 owners일 것이다. 그러나 death march project 팀에 의해 시스템을 개발하고, 작동하며, 상호 작용하는 사무적이고 행정적인 customers는 일반적이다.프로젝트 customer와 관계를 맺는 정치는 대부분의 프로젝트 관리 교과서에서 논의되어서,나는 이 주제를 상세히 다루지는 않겠다; 간단히 말하면, 정치의 모든 부분이 death marchproject에서 더 확장된다. 예를 들어, customer는 일반적으로 시스템에 대한 상세한 요구사항의 자원이다. 왜냐하면, owner는 비즈니스 적용의 실질적 경험이 거의 없고, 멀리서 관조적인 보는 입장이다. 그러나, 시스템의 상세한 요구사항을 도출해내기 위해 customer/user가상호 커뮤니케이션을 해야 함에도 불구하고, 많은 프로젝트에서 owner는 프로젝트 팀이 사용자에게 너무 바빠서 말하지 않거나 그들이 필요로 하는 요구 사항에 대해 모두 말했기 때문에 더 이상 말할 필요가 없다고 말한다. 결국, 보통의 프로젝트에서 customer는 그것을 사용하는 것을 반대함으로써 프로젝트를 방해하거나 그들의 필요 사항을 충족시키지 못했다고불평한다.이것 모두가 death march project에 대한 사실일 뿐 아니라, 부가된 경고이다.: customer는예외의 정치 상황, 제약, death march project와 관련된 압력 등을 알지 못할 수도 있다. 이것은 프로젝트 팀의 누군가가 customer에게 다가가서, -당신이 당신의 요구사항을 지금 상세하게 서술함으로써 당신의 일에 방해가 된다면 나는 정말로 당신에게 감사하겠소. 왜냐하면 만약 프로젝트가 늦어지면, 전체 회사가 파산을 할 것이기 때문이다’ 라고 말한다면 이것은 큰 재난을 창출하는 것이다. 그러나 물론 프로젝트가 성공하면, 당신은 직업을 잃을 것이다. 왜냐하면, 새로운 시스템의 전체적 관점에서 보면 더 적은 노력으로 제 기능을 발휘하고, 이에 따라서 당신을 포함한 약 700명의 사람이 제거될 것이다.2.1.3 Shareholders Shareholders 은 효율적으로 시스템의 “co-owners”이다; 그들이 프로젝트를 시작할, 또는그것의 결과를 받아들일, 또는 예산을 승인할 만한 권위를 가지고 있지 않을지 몰라도, 그것의 결과에 대한 기득권을 가진다. 실지로, 많은 경우에 그들은 예산과, 프로젝트와 연관된 위험과 이익을 분할한다. Shareholders가 정기적으로 모이거나 모이지 않아도, 그들은 프로젝트 팀과 직접적으로 교류하지는 못할 것이다; 그럼에도 불구하고 그들은 Shareholders이다.그러므로 프로젝트 팀과 프로젝트 관리자는 그들이 다루었던 owner와 같은 방법으로 - 20 -
  21. 21. Death march projectShareholders를 다룰 수가 있다. – 여기서의 핵심은 Shareholders는 무시되어서도 잊혀져서도 안 된다는 것이다. 그들을 간과하기 힘든 이유는, 그들은 자신의 위치와 목소리를 흘려보내는 경향이 있기 때문이다.; 또한, 그들은 death march project와 관련된 프리젠테이션이나 미팅의 많은 경우에 참석하기 때문이다. 한편, 프로젝트 관리자의 일부는 이런 개인적인것들을 피하려는 경향이 있고, 프로젝트 관리자는 프로젝트에서 Shareholders를 다루는 데많은 시간을 보낸다. 그러나, Shareholders가 death march project에서 돈을 지불하고, 승인하고, 의사 결정에 참여하는 것과 같이, 그들은 프로젝트를 취소할 결정도 할 수가 있다. 만약 그들이 무시당한다고 느낀다면, 그들은 더욱 이와 같이 할 것이다.컨설턴트 Dave Kleist 는 최근은 전자 메일을 통해서 Shareholders의 흥미있는 유형을 확인했다. [2] 내가 경험한 많은 경우의 death march project에서, 나는 Shareholders의 다양성이 존 재하고, 이것을 확인하는 것은 매우 중요하다: 특히 그들이 프로젝트에서 일할 사람을 보유하고 있다면.실지로, vendor가 포함된다면, Shareholders는 몇 개의 카테고리로 분류되어야 한다. vendor의 시장 대표는 프로젝트가 성공하는 것보다 판매하고 수수료를 버는데 더 관심을 두고 있다.만일 vendor가 프로젝트 팀과 일하는 기술자나 컨설턴트를 취임시킨다면, 그것은 또다른 정치적 대행기관의 출현일 것이다.2.1.4 Stakeholders shareholder와 stakeholder를 구분 짓는 것은 academic하지만, 중요한 것이다.Stakeholder들은 비록 그들이 그것의 행동 또는 progress에서 명백한 의사 결정 역할을 가지지 않는다라고 해도 프로젝트의 결과에서의 “ stake - 이해 관계” 가지는 사람들이다 를고객은, 위에서 논의된 것을 갖는 이들은, 분명한 stakeholder이고 주인이고 다른shareholder가 될 수 있다.다른 stakeholder들은 적기에 새로운 system이 끝나게 되면 그들의 오랜 informationsystem을 버리는 관리 조직의 구성원이 될 수 있다. 또는 그들은 조합, 지원자, 고객, 경쟁자의 구성원이 될 수도 있다. 그들은 IS/IT 조직의 다른 구성원이 될 수도 있다; 만약 deathmarch project가 성공을 한다면, 그것은 method나 tool, 또는 “보통의” project가 수행되는방법의 다른 면에 영향을 줄 수도 있다.Paul Neuhardt는 최근 내게 보낸 e-mail에서 stakeholder의 또 다른 일반적 형태에 대해지적하였다.[3]: 당신은 “내부의 원”을 놓쳤다. You missed "the inner circle." 이들은 아직 직접적인 이해관계는 없지만, 무엇을 해야 하는지에 대한 의견과 그들의 생각을 다른 사람들이 영향을 받도록 한다. 또한 “가장 가까운 조언자”로 알려진 이 - 21 -
  22. 22. 들은 종종 의사 결정자의 귀에 부드럽게, 잠재 의식의 톤으로 속삭이는 데 시간을 보 낸다. 그리고 일이 발생되고 있는 상태에서도 당신은 알지 못한 채 단시간 내에 친구 를 적으로 만든다.이 말은 stakeholder들이 death march project의 “적”으로 들릴 수 있다. 나는 이것을 내포하여 의미하고자 하지는 않는다; stakeholder들은 동맹할 수 있고 다양한 지원자가 될 수있다. 그들은 참견할 때 듣기 말만 하며 Project team 구성원들의 뒤에 가려진 채 피할 수도없게 발생된다; 그리고 그들은. –깨지기 쉽든 그렇지 않든-project team에 만약에 그들이 제공 가치를 느낀다면 모든 종류의 지원을 제공할 수 있다. 게다가, 만약 death march project는 “David와 Goliath” battle에 어떻게든지 해서 포함이 되어 “경험을 하고 있는” 중이라고여긴다. project의 결과 산출물에 아무런 이해관계도 없는 조직 구성원들은 때때로 앞으로 나아가거나 자원 제공을 해 줄 수 있다.이런 종류의 지원의 가능성에도 불구하고, stakeholder는 project의 적이 되고 위험요소가 될수 있는 높은 가능성이 있다. 이유는 간단하다: death march project는 현상에서 severe 변화를 표현하는 것이 좀 더 일반적인 project보다 있을 만하다; 그리고 politics의 기본적인 원칙중의 하나는 개인과 조직의 문화는 변화가 중요하고 필요한 것이라고 이해를 할지라도 자동적으로 상태의 변화를 거부한다는 것이다. 그래서, project team이 분명하게 project의 우호적 인물로 밝혀진 stakeholder를 환영해줄 것을 원하고, schedule과 project 계획에 장애물을던지는 stakeholder들의 가능성을 인지하는 것을 필요로 한다.또 다른 하나를 기억하라: stakeholder의 존재와 신원은 항상 분명하지는 않다, 왜냐하면 그들은 일정 형식의 조직 구성의 일원이 아니기 때문이다. 만약, system이 노동조합이나 주문한-실재 부분의 점원들에 명확한 영향을 가지고 있다면, stakeholder로 그들을 확인하는 것은 어려운 일이 아니다. 그러나, 만약 information system의 VP로 골프를 즐기는 까다로운늙은 project 관리자가 있다면, 그리고 만약에 project 관리자가 “만약 death march project가 성공한다면, 우리 모두는 Smalltalk를 배운다면, 나는 Smalltalk는 Communist plot이라는확신을 가질 것이다” 라고 혼잣말로 중얼거린다면, project에는 중요하고 영향력은 있지만 교활한 silent stakeholder를 얻은 것이다.2.1.5 Champions death march project에 잠재적인 적이 있다. 그들은 또한– 매우 강력하고 협조적이어서champion이라 알려진 친구를 포함해서 -우호적인 관계에 있는 사람일 수도 있다.이 세상에서 최고는 champion이다 그들은 또한 project의 owner이다; champion들은 또한고객, shareholder, stakeholder의 순위에서 나올 수 있다. 그러나, Champion들은 종종project에서 political 역할의 전형적인 틀에서 벗어날 수 있다. Champion은 젊은 project 관리자의 성공에서 나올 수도 있다 그(녀)는 관리인(부하)를 고려한다; .또는, champion은 전 - 22 -
  23. 23. Death march project조직이나 IS/IT부의 평판과 신빙성의 영향을 받기 때문에 project의 모든 성공 사례를 고려한다. 가장 자주, champion은 Java, 객체지향 기술이나 새로운 client-server 개발 tool들을death march project의 project 관리자에게 보여주고 이것을 이용하도록 제안하여 기적을 이루고자 하는 death march project의 관리자와 함께“silver bullet”의 기술을 통해 음모를 꾸밀수 있다.모든 project는 한 명 또는 두 명의 champion을 이용하지만 death march project는 진정으로 그들을 요구한다. 위에 말한 내용의 이유는 명확하다: 이런 project는 project 관리자가모든 결정을 하는 데 있어 예언을 하는 많은 위험과 적들이 있다. 누군가가 관리를 할 때 불평 사항을 대할 때 project의 결과로 다수의 사건들이 생긴다. “Titanic Project의 유능한techno-nerds는 적절한 channel들을 통하지 않고 Visual basic Enterprise의 7개 복사본을주문했다. Project 관리자는 지난 금요일 project 팀을 위해 맥도날드 햄버거와 French 프라이의 구입에 $32.98의 현금을 소비했다는 것을 내 사무실 전체적으로 배어난 냄새로 알 수있었다![4] 우리는 회사 police에 이런 무지한 행동을 그만두게 할 수는 없다!! champion은말로 이러한 상황을 끝낼 수 있다. “나를 믿어라, 이 사람들은 조금 원기가 왕성하지만 그들은 직업을 구할 것이다. 그들을 내버려 둬라.”물론 champion이 조직의 political circle내에서 많은 신뢰성을 갖지 못한다면, 그(녀)는 절대champion이 될 수 없고 일을 하지 못한다. 그러나 때로 champion은 조직 내에서 노련한 사람이 된다는 것을 의미하며, 한 달의 마지막까지 하루 18시간을 근무할 수 있는 deathmarch의 지원자와 성격이 급한 project 관리자보다 나이도 많고 현명하다는 것을 고려해야한다.bottom Line : project champion은 최근의 methodology나 razzle-dazzle project 언어 보다좀 더 중요하다. 관료적인 규칙들이 팀을 무시하는 것을 방어하고,위험한 기술들을 사용한다고 하는 팀의 결정을 지원하는 챔피언이 없는 death march project는 고독한, 비참한 경험이다. 나는 추천하지는 않는다. 만약 당신의 champion이 또한 project의 owner이면, 그리고만약 그것에 대해 걱정하는 다른 shareholder가 없다면, 그리고 당신의 owner/champion이stakeholder를 설득시키고 관련 시키고 하기에 충분한 능력이 있다면, 이런 political issue들의 모든 것을 무시하기 위한 만족이 있어야 한다. 그러나 불행히도, 대부분의 death marchproject는 그리 만족스럽지는 못하다; 대부분의 상황을 책임져야 하는 project 관리자는 항상team의 모든 이들에게 적어도 최소한 political character의 특징들을 인지하기를 요구한다.2.2. DETERMINING THE BASIC NATURE OF THE PROJECT 앞 장에서 나는 death march project의 여러 특징들을 기술했다;그것은 크거나 작을 수 있다; 고객의 동종의 그룹과 조합되지 않는 이종의 그룹들이 연관이 - 23 -
  24. 24. 있을 수 있다; 그리고 그들은 schedule, 예산, 관련된 자원의 다른 조합에 영향을 줄 수도있다.그러나 이런 project를 특성화시키는 다른 방법이 있다. 그리고 모든 고려되어야 할 사항에의미 있는 political한 영향을 미칠 수 있다. 그림 2.1에 표현되었듯이, 2차원 공간에 대응될수 있는 2개의 중요한 요소가 있다: 세로축은 project가 성공할 수 있는 기회를, 가로축은project team 구성원들이 project가 수행되는 동안 느끼는 만족감을 표현한다. team 구성원이 세로축에 “project가 언제 끝나지? 당신은 또다른 death march project를 수행할 것을 고려하고 있나요?” 또는 아주 간단히 “당신은 고통스러운가요?”라는 질문으로 그들의 위치를결정하는 방법이 있다. 이 도표에는 특별한 값이 없다. 그리고 4부분의 경계선도 가변적이다; (내가 질문을 하고 그들에게 도식화해 주기 전에 그들은 그것에 대해 생각하지 않을 것이다.) 그렇지만, 나는 아직까지 death march project에서 그들이 네 영역 중 어디에 속하는 지를 아는 것을 본 적이 없다. 누군가가 도표의 특정 위치에 명백한 목적으로 death marchproject를 시작할 것인지 매우 의심스러운 일이다. 그러나 politic과 project 구성요소(예산,일정 등)의 조합은 project를 하나 또는 다른 방향으로 위치시킬 것이다. high Mission Kamikaze ImpossibleHappy_ness Suicide Ugly low Chance of success high 그림 2.1 THE DEATHMARCH PREJCT STYEL QUADRANT네 영역이 가변적이지만 특징들을 기술할 수 있다. 그리고, 당신은 당신 조직의 문화적 특성을 맞는 것을 변화시키기 쉬울 것이다. 다음은 각 영역의 특징들을 기술해 놓은 것이다”mission impossible Project – 오래된 TV 방영물이나 새로운 Tom Cruise가 나온 영화(1996년제작)에 의해 칭찬 받은 project의 종류이다. 이것은 악인과 배신자가 team을 양도하기 위한음모가 있으며 project 성공의 가능성이 거의 희박하다. 그러나. Project 관리자는 Hollywood - 24 -
  25. 25. Death march project의 영웅으로 기술적인 hacker로 똑똑한 천재이며 team 내부에 신적인 존재로 자리매김한다.Team 구성원은 다른 이들에게도 열정적으로 성실하다. (Tom Cruise 영화의 왜곡에도 불구하고), 각기 개인적으로 “벼랑 끝에 선” 스릴과 도전으로 발전할 것이다. 그리고 오랜 TV 방영물에서 별로 표현되지 않는 실세계의 임무 수행 불가능한 project team은 정형적으로 만약그들이 성공한다면 명성, 영광과 부를 누릴 꿈을 꾼다.Ugly project – project의 team 구성원은 냉혈한의 project 관리자가 project를 성공으로 끝낼때까지 맘껏 이용할 수 있는 희생양이다. 대부분 이런 종류의 project는 1장에서 다루었던“Marin Corps”를 적용한다 – e.g. project 관리자는 그(녀)의 team에 “진정한 programmer는잠을 필요로 하지 않는다!”, “진정한” programmer는 project의 기간동안에는 가족을 돌보는일이나 병원에 계시는 노부모를 돌보는 일을 하지 않는다고 끊임없이 열변을 토할 것이다.이런 project에서 하나나 둘 정도의 project team 구성원들이 과로와 위궤양, 신경쇠약으로시달리거나, 이혼을 경험하는 등의 일을 보는 것은 특별한 일이 아니다. - 25 -
  26. 26. 3 장. 협상만일 당신이 death march 프로젝트의 관리자(PM)라면, 예산, 스케줄, 자원 등을 통해 협상의 결과를 쉽게 예측했을 것이다. : 당신은 실패했다.이것은 어쩌면 당연한 결과이다. 그러한 협상들이 프로젝트의 시작단계에 일어나고 ( 또는그 프로젝트가 정식으로 시작되기도 전에 ) 그러한 때에는 그 프로젝트의 갑과 을의 지적능력도, 감성적 스테미너도, PM 에 의해 제안되어진 달갑지 않은 대안을 수용할 정치적 요구도없기 때문이다. 보다 합리적인 협상들은 때때로 마감 한 달전에 일어나고 그 때에는 그 첫번째 PM 은 일을 그만 두거나 해고되고, 새로운 PM 은(임무를 수용한다는 전제하에) 모든사람들이 최초의 마감일, 예산, 그리고 달성될 수 없는 기능성을 요구하는 현실에 직면하길 요구한다.어떤 누구도 이런 악조건의 업무상태를 기꺼이 수용하지는 않을 것이다. 그래서 이 장에서PM의 교체를 위한 합리적 협상전략에 초점을 맞출 수 있다 하더라도, 본인은 우리중 대부분이 씨름해야할 문제들에 직면할 것이다. 우리는 어떻게 death march프로젝트의 초기에 적당한 일련의 조건을 협상할 수 있을까?이 장에서 드러낼 그런 특별한 것은 없다.비참한 현실은 그러한 process의 끝에 당신은 실패한다는 것이다.그러나, 그것은 당신이 허를 찔릴 수 있는 우회적 정치적 게임이나 당신이 완전히 비현실적인 스케쥴, 예산, staff 의 압박에 당면하고 있을 때, 폭발되어 질 수 있는 대안들을 인지하는데 유용하다. 이 장을 통해서 본인은 당신이 death march 프로젝트나 스케쥴 등에 관한 협상에 관련되어 있는 사람의 하나라고 가정한다. 당신이 만약 전문 staff member 라면, 당신은아마도 간접적으로 관련되었을 것이다.- 예를 들어 PM 에게 조언이나 평가자료 등을 제공하여 그 또는 그녀가 보다 높은 수준으로 그 협상전쟁의 관리를 수행할 수 있도록 하는등....그러나, 최근 Doug Scott [1]의 e-mail 통신에 따르면, 나는 몇몇 프로젝트에서 PM 마저도간접적인 역할을 수행하고 있다는 생각을 했다. 왜냐하면 그 협상들 모두가 차기 상관 관리들에 의해 그/그녀를 대신해서 만들어졌기 때문이다....death match 프로젝트에서 가장 큰 관건의 하나는 내자신의 관리였다. 나는 UK 에 1972년에 와서, 거의 곧 바로 큰 프로젝트로 옮겼다. 나는 그날 ( 난 정치적인 것들에 관하여 많은 것들을 배웠지만, 그것은 다른것이었다.) 이후 내가 프로젝트를 맡으면서 어떤 것도 배웠다고 생각하지 않는다. 당신은 배울 필요가 있다. 당신은 당신 자신만의 관리와 협상 자세를이해할 필요가 있고, 만약 그들이 역할 분담을 좋아한다면, 당신은 그들을 그 프로젝트로부터 떼어놓아야 할 것이다. - 26 -
  27. 27. Death march project3.1. 합리적인 협상 우리는 어떠한 S/W 전문가들과 관리자들의 그룹간에 있어서 감정적 논쟁을 낼 수 있는 중요한 프로젝트를 위해, 요구되는 스케쥴, 예산, 자원들을 정확하게 측정하는 법을 알아야만한다는 것을 제안한다. 몇 년간에 걸친 프로젝트 실적이 그다지 좋지만은 않다. ; 한편, 많은사람들은 그 문제가 이 책에서 다루고 있는 death march 프로젝트와 관련되는 정치적인 게임의 결과였다고 논쟁할 수도 있다. 그러나 대부분의 대규모의 조직들은 S/W 팀이 자신의 스케쥴을 만들고 자신들의 예산을 제안하고, 그것이 그들의 제약들안에서 완벽하게 기능적 시스템을 수행할 것이라는 충만한 자신감을 표현하는 수많은 프로젝트들을 지적할 수 있다. ;그팀은 자승자박으로 언젠가 실패하고 말았을 것이다. 이러한 조직들이 많다는 것은 놀랄일이 아니다, 사용자와 상급 관리는 협상 process 을 포기하는 대신에 종료일과 예산에 “맞추던지 죽던지”라는 지침을 강조하기 시작했다. 이것이 death march 프로젝트 내력이다.그렇다고 해서, 프로젝트를 위한 사전협상에서 사용할 수 있는 “합리적인” 측정을 도출하기위한 모든 노력들을 포기하라는 의미는 아니다. 게다가, P M 이 프로젝트를 포기할 유혹을경계하고 단지 참조로서 초기의 death march 프로젝트를 쉽게 받아들인다는 것은 중요하다.프로젝트팀이 제 2 장에서 “자살-스타일”이라고 불렀던 것을 받아들이는 태도– PM 에 의해표현되고 팀원에 의해 반영되는- 는 일반적이다. “그들이 이미 우리에게 마감일을 말해 주었지만, 우리는 이 프로젝트가 실질적으로 얼마나 걸릴지도 모른다. 그래서 우리는 피로로지칠때까지 하루 24 시간 일주일 내내 일할 것이다. 그들이 아무리 채찍질을 할지라도 우리는 더 이상은 할 수가 없다… ..”나는 이 책에서 기술측정에 대해서 장황하게 언급하진 않을 것이다. ; 만일 PM 이 측정에대한 어떤 skill 도 경험도 없다면, death march 프로젝트에서 교훈을 얻지 못할 것이다. 그러나 이 분야에서 활용할 수 있는 몇몇 명백한 소스들을 지적해 주고자 한다. ? 상업적 측정 도구 – SLIM.ESTIMACS,CHECKPOINT 와 같은 상품은 Quantitative ? Systems Management, Computer Associates, and Software Productivity Research (SPR)에 각각 이용된다. SPR 의 사장은 - metrics 의 권위자인 Capers Jones – 50 개정도의 상업적인 프로젝트 측정도구가 있다고 어림잡는다. 그 도구들 중에 완벽한 것은 없고, 그 모든 도구들은 사용자의 지적능력을 요구한다. (무가치 한 것을 넣으면, 무가치한 것이 나온다.) 그러나, 가장 좋은 예로, 그 도구들은 ± 10%정도의 정확성을 산출할 수 있다. 비록 그 도구들이 단지 ±50%정도의 정확 성이 있다 할지라도, 그것은 PM 이 대처하고 있는 프로젝트 팀원이 수행할 수 있 는 능력의 1000%의 정치적인 요구보다 낫다. ? 시스템 역학 모델 – 많은 시뮬레이션 모델들은 프로젝트의 행동에 영향을 끼치는 ? 여러 가지 요인들 사이에서 비선형 상호 작용들을 탐험하기 위해 개발되었다. 예 를들어, death marth 프로젝트 전략의 한 부분이 PM 의 잔업시행을 강조한다면, 어 - 27 -
  28. 28. 떤 효과가 있을까? 하루 8 시간안에 보다 많은 산출물을 얻느냐는 것이 기본적인 가정이다. ; 그러나, 대부분 경험이 풍부한 PM 들은 점점 지쳐가면서 생산성이 떨 어지는것들 (일일 functionpoints 또는 일일 lines of code 로 측정된)을 또한 지적 할 것이다. 오류비율은 또한 testing 과 debugging 의 효과로 증가할 것이다. 그 리고, 만일 잔업이 너무 오랜 기간 지속된다면, 프로젝트팀은 결국에는 피로로 무 너질것이다. 본인이 이분야에서 본 시뮬레이션 모델중에는 DYNAMO 와 iThink 와 같은 언어로 제공되는 Tarek Abdel-Hamid’s[2] 가 최고였다. ? 많은 기사와 책들이 Project estimating 을 주제로 쓰여졌다. ? Barry Boehm 의 Software Engineering Economics [3]이 좋은 기원이다. ; 1980 년대 초기의 COCOMO-2 모델로 update 된 Boehm 의 COCOMO 모델은 중요하다. 또다른 고전 은 Fred Brooks 의 ‘The Mythical Man-Month[5]이다. 이것은 또한 최근에 update 되었고, 현대 technology 와 S/W 기량에 반영된다. 보다 최근의 S/W estimation 책은 Jim McCathy’s Dyanmics of Systems Development[6]이다. ? estimationprocess 은 연구되고 서류화(documented)되어 왔다. S/W Engineering ? Institute 와 같은 조직에서는 estimation [7,8]의 process 을 개선하기 위한 유용한 가이드라인과 checklist 를 발행해 왔다. 만약 우리가 능숙하지 못하다 할지라도, 이 간행물을 통해서 우리는 더 잘 다룰수 있는 방법을 알수 있다. ? prototyping 과 time-boxing 과 같은 흔한 기술을 통해 실행가능하거나, 실행불가 ? 능한 프로젝트 제약들이 개발중인 시스템 전반에 걸쳐서 있는 정확한 그림 (picture)을 얻을 수 있다. 이것은 가장 간단한 방법이지만, 프로젝트팀원과 주위 의 관리자, 고객층에 현실성을 부여할 수도 있다. 만약 관리에서 12 달내에 백만 라인의 코드를 입력해야하는 3 개의 팀이 필요한 시스템에 요구된다면, 처음 한달 안에 구축될 수 있는 시스템 version 의 골격을 정의하는 것은 가능할 것이다. ; 이 것은 프로젝트 전반에 대한 실현가능성에 대한 생각뿐만 아니라, 최소한 팀의 생 산수준에 대한 거친 눈금(예측)을 제공할 것이다.3.2 수용가능한 대안들에 대한 확인 프로젝트 팀이 death march프로젝트에서 요구된 스케쥴, 예산, 인원의 “합리적인 ”estimation을 준비했다고 가정하자 ; 최종결정을 내리기 전에 주고-받는 식의 협상의몇 가지를 준비했다고 가정하자. 대부분의 일반적인 상황에서 관리는 “수용할 수 없는” 최초의 측정을 분명하게 밝힐 것이고, 보다 긴급한 반대요구를 하게 될 것이다. 그렇다면, PM은 무엇을 해야 할 것인가?John Boddie컨설턴트는 최근 e-mail을 통해 중요한 것은 프로젝트의 “계획”을 보다 가능성있게 하는 모든것에 동의할수 있는 확신이라고 내게 지적해 주었다. - 28 -
  29. 29. Death march project협상에 필요한 몇몇 유용한 질문들“만일 시스템이 9월 1일에 준비가 되어야 할 것이 9월 5일에 준비가 되었다면, 그러나 9월 2일에 파산이 되었다면 ?“여기에는 80/20법칙이 있습니까? 만일 우리가 가치의 중요한 20%만을 deliver하고, 80%를 준다면, 우리는 최초의 roll-out(착수) 20%가 필요한가?“ 모든사람들이 좋은 것과 신속한 것, 값싼것을 원한다. 모든 사람들은 당신이 실질적으로 달성할 수 있는 2/3안다. 당신이 원하는 2가지는 무엇입니까? “만일 그들이 보다 가능성 있는 것에 대해 생각하는 것을 꺼려한다는 전제하에 업무의법칙은 death march가 비합리적으로 본 것을 요구하는 사람을 만드는 것이다. 어떤 문제에 접근할 수 있는 방법이 수용될 수 없다면, 더이상의 협상도 없을 것이다. 모든 관리자들은 “우리의 최상의 것을 줄 것이지만, 어떤 보증도 없을 것이다.”라고 말할 수 있을것이다.만일 상급관리자 또는 고객으로부터 반대 제안이 한개의 “변수들”을 포함한다면, PM은 다른변수의 충격들을 측정할 수 있을 것이다. 예를 들어, 만일 관리자의 프로젝트기간이 12개월걸릴 것이고, 예산 $200,000과 3명의 인원이 필요할 것이라고 최초로 측정을 했다면,“Baloney(어리석은, 빌어먹을..)! 우리는 6개월안에 시스템을 가동시켜야 해.”라는 상급관리의 최초의 반응이 나올 것이다. 이것을 성취하기 위한 확실한 방법은 인원을 더 투입하거나예산을 더 확보하는 것이다. (예 ; 생산성이 높은 인원 고용을 위해pay수준을 높인다는 등의..)그러나 Fred Brooks는 20년 전쯤에 S/W프로젝트에 있어서 시간과 투인인원의 관계는 1차함수 관계가 아니라고 말했다. “man-month”기간 (오늘날의 정치적인 조직에서는 “staff-month”로서 표현될 지도 모를)이 미스테리로 남는다. 게다가 프로젝트에서 모든 주요 변수들간의 관계는 non-linear(비선형)일 것이고, time-sensitive일 것이다. 많은 관리 결정의“feedback효과” 때문에 한 변수의 변화는(staff를 더 추가하는등의) 초과업무시간(생산물과같은) 뿐만 아니라, 결국에는 원래의 변수에도 영향을 줄 것이다. - 예시, staff를 추가로 고용함으로써 사기를 저하시킬 수 있고, 차례로 프로젝트의 대사회전속도를 증가시킬 수도 있어 결국에는 staff의 규모를 감소시킬 것이다. -non-linear과 time-sensitive의 자연적인 상호작용은 위에서 언급한 System Dynamics 모델의 필수 조건이다. ; 그러나 그것은 앞에서 묘사된 다양한 상업적인 측정 도구로 사용되는 이유이기도 하다. Key point가 여기에 있다. : System Dynamics 모델의 배경이 되는 수학은 - 29 -
  30. 30. 일반적으로 non-linear 미분 방정식에 기초하고, 우리들의 대부분은 이미 우리 머리에 있는수학 수준을 향상시키는데 익숙하지 않다. 유사한 예로, 상업적인 측정도구는 상황들을 통해서 얻은 직감을 기초로 얻은 많은 매개 변수들을 포함하는 정교한 계산을 수행하는데, 실수를 저지르기 쉽다.불행히도, 그것은 death march프로젝트 PM들이 그들 자신의 프로젝트에서 발견한 상황이다. 때때로 이것은 협상process의 자연적인 현상 때문이기도 하다. ( 아래에서 언급할“Spanish Inquisition”라고 불리는 특별한 게임 ) ; 그러나 그것은 또한 측정도구의 부족과 많은 조직의 전문가 의견에 의해서도 야기될 수 있다. 다시 말해서, 만일 아직 본격적으로 프로젝트가 착수되지 않았다면, 이것은 우리가 death march프로젝트에서 풀어야 할 문제는 아니다. 만일 조직이 봉투(envelope)의 뒤에 갈겨쓴 숫자들에 의해 프로젝트 측정을 도출하는데 익숙해져 있다면, death march프로젝트 PM은 아마도 $10,000짜리 고도의 측정 도구를사는데 낭비하지 않았을 것이다.그러면, 이와같은 상황에서 관리자는 무엇을 해야 하는가? 극단의 경우, 관리자는 무익한상황을 인지하고, 적절하게 대처해야 할 것이다. ; 본인은 아래 3.5 Section에서 보다 상세하게 언급할 것이다. 그러나 보다 덜 극단적인 상황에서는 아래 두개의 가이드라인이 있다. ? 만약 사용자 또는 상급 관리자가1개의 프로젝트 변수에서 10%의 변화를 포함하는 ? 협상을 요구한다면, 그 다음에 당신은 직접적이고 비례적인 방식으로 다른 변수를 늘리면서 보상할 수 있다. 만일 관리가 스케쥴을 10% 감소시키기를 원한다면, 프로 젝트 팀을 10%로 늘리면 된다. 이것은 전체적으로 정확하지는 않지만, 최초의 좋은 어림 측정일 수도 있고, 협상의 견지에서 당신이 버릴 수 있는 모든 것일 수도 있다. ? 만일 변화가 1차원적으로 10%이상을 포함한다면, 당신은 “inverse square law”를 가 ? 질 것이라고 가정할 것이다. 이러한 위의 시나리오에서 관리는 프로젝트 스케쥴을 12개월에서 6개월로 반으로 삭감하기를 원한다. 관리는 프로젝트팀을 두 배로 하기 보다는 팀을 4배로 늘릴 것이다. - 또는 동시에 두 손으로 code할 수 있는 훌륭한 프로그래머를 고용할 수 있는 4배의 예산 - 앞의 측정 모델이 아니고는 이 자연학 습방법이 어떤 특수한 상황에도 정확할 것인지를 알 수 있는 방법은 없다. 그러나 적 어도 덫에 걸리는 것보다, 시간을 사람으로 교환하는 협상보다 나을 것이다. 불행히 도, ‘inverse square law’는 협상하는 것은 어렵다. and PM들의 터무니없는 요구를 깨 질 수 있는 좋은 기회가 있다. ; 하지만 다행히도, PM들은 linear 교환이 제공되었던 것보다 유리한 위치에 서게 될 것이다.3.3 협상게임 - 30 -

×