월요일, 8월 31, 2009

[독서광] 기업을 죽이고 살리는 리더 간의 갈등 관리



한 동안 경제/경영서 리뷰 블로그(?)라는 명성에 걸맞지 않게 엉뚱한 IT 서적만 잔뜩 선전해서 뿔이 난 독자들이 계실테다. 반성 좀 하고, 금주부터는 가을을 맞이하여 다시 경제/경영서 리뷰를 개시할테니 기대하시라. 그러면 1번 타자 나가신다.



다양한 기질을 타고 나고 다양한 환경에서 자라는 사람들 사이에 함께 뭔가를 하면서 갈등이 없다면 그게 더 이상할 노릇이다. 작년 여름에 소개한 Love: 사랑에 대해 알아야 할 모든 것에서 소개했겠지만, 사람들은 서로에게 상처주는 측면에 빠져서 사랑을 시작한 다음 이를 극복함으로써 스스로를 치유한다. 그렇다면 기업을 이끌어나가는 리더 사이에서 일어나는 여러 가지 복잡한 갈등과 불협화음을 어떻게 치유해야 하나?



리더 간의 갈등 관리은 1부에서 애플의 스티브 잡스와 존 스컬리의 사랑(?)이야기부터 시작한다. 두 거물이 어떻게 서로에게 콩깍지가 씌였고 어떻게 서로를 증오하게 되었고 어떻게 갈라서게 되었는지 차근차근 사례를 들어가며 분석을 시작한다. 그리고 나서 1부와 2부에서는 가상적인 사례를 잡아 관계를 분석하고, 관계 복원에 필요한 열쇠를 찾고, (서로에게 악영향을 주는) 상호 작용 패턴을 해체하고, 사로를 바라보는 프레임을 (긍정적으로) 재구성하고, 진실이라고 알고(아니 착각하고) 있는 가짜 사실을 바꾸는 방법을 설명한다. 마지막 3부는 실질적으로 관계 변화를 이끌어내기 위해 변화를 위한 노력 집중, 올바른 변화 전력, 동기 부여를 소개하며 마무리한다. 이 책의 사실상 하이라트인 4부는 링컨의 예를 들어 감수성이 관계 변화에 어떤 놀라운 영향을 미치는지 설명한다. 감수성은 B급 프로그래머 창의력 세미나에 참석하신 분들께는 이미 이야기했지만 모순되는 상황을 다루는 강력한 무기이므로 감수성의 중요성은 아무리 강조해도 지나치지 않다.



이 책은 부록도 재미있다. 특히 부록 B는 반성의 사다리라는 제목으로 상황을 해석할 때 자신의 마음을 들여다보는 창으로 사용할 수 있는 강력한 방법을 소개한다. 이 내용이 아주 낯익어서 곰곰히 생각해보니 비폭력 대화에서 사용하는 생각을 배재하고 먼저 객관적인 관찰에 집중하라는 충고와 상당히 유사하다는 사실을 깨달았다. 부록 B 본문 중 가장 감명 깊게 읽은 부분을 소개한다.



저명한 물리학자 리처드 파인만의 아버지는 깃털을 바삐 쪼고 있는 새를 가리키며 파인만에게 이렇게 말했다. "저 새의 이름을 전 세계 모든 언어로 안다고 해도 그 새 자체를 아는 것은 아니란다. 너는 단지 전 세계 다양한 사람들이 저 새를 어떤 이름으로 부르는지만을 알게 된 것뿐이란다. 저 새를 보고 그 새가 무엇을 하는지 보는 게 더 중요하단다."

파인만은 나중에 이것을 이런 교훈으로 표현했다. "나는 아주 어릴 적부터 사물의 이름을 아는 것과 그 존재 자체를 아는 것은 전혀 다른 문제라는 사실을 배웠습니다."


"객관적으로 파악한 상황에서 숨겨진 욕구를 발견한다"는 비폭력대화 기본 원칙을 다시 한번 깨닫게 만드는 정말 훌륭한 통찰력이다. 여러 가지 심리학적이고 사회학적인 배경이 들어가 있기에 내용이 다소 어려움에도 불구하고 직장 생활에서 갈등을 경험한 분이라면(안 그런 사람 있나? 낄낄) 꼭 한번 읽어보기 바란다. 강력 추천한다!



EOB

목요일, 8월 27, 2009

[일상다반사] 재난 복구 예판 이벤트 당첨자

지난번 [일상다반사] SOS! 죽어가는 프로젝트 재난 복구 대작전 예약 판매 개시 이벤트에 참여하신 여섯 분을 대상으로 이벤트 추첨을 해보았다. 원래 다섯 분만 모시기로 했는데, 에이콘 출판사 이벤트 결과 글인 '리더 간의 갈등 관리'와 '프로젝트 생명연장'의 해법을 읽다보니 좋은 생각이 떠올랐다. 다섯 분께는 '하드 코드'를 나머지 한 분께는 『기업을 죽이고 살리는 리더 간의 갈등 관리』를 선물로 드리기로 했다. '리더 간의 갈등 관리'는 조금 어렵긴 하지만 상당히 좋은 내용을 담고 있는 책이다(독후감 곧 올릴테니 기다리시라.). 책을 협찬해주신 에이콘 출판사에게 감사를!



자, 그러면 추첨 결과를 공표한다. 그림 세 개를 차례로 보시기 바란다.









당첨된 여섯 분께서는 저에게 email로 책 받으실 주소, 전화번호, 성함을 보내주시면 감사하겠다. 앞으로도 많은 성원 부탁드리겠다.



하지만 책 행진은 여기서 끝나지 않는다. 거의 2년 반을 끌어온 리눅스 관리 서적 중의 최강자인 Linux Administration Handbook (2nd Edition) 한국어판이 조만간 나올 예정이므로, 시스템 관리에 떡실신한 개발자 분들은 조금만 더 참고 기다리시랏!



EOB

월요일, 8월 24, 2009

[B급 프로그래머] 리눅스 커널 개발 관련 통계...

특정 소프트웨어를 개발하기 위해 누가 얼마나 오래동안 얼마나 많은 코드를 작성하는지 궁금한 경우가 있다. 예를 들어, 마이크로소프트 윈도우 개발에 몇 명이 투입되어 어느 정도 규모의 코드를 작성할까? 유감스럽게도 상업적인 소프트웨어를 개발하는 대다수 회사들은 이런 극비 정보를 꽁꽁 감춘다. 이런 정보 자체가 상대편 회사에게 프로젝트 일정을 예측하도록 도와주는 중요한 힌트가 되기 때문이다. 하지만 오픈 소스라면 상황이 달라진다. 통계자료를 제대로 만들어서 배포하면 오픈 소스 공동체에 도움을 주기 때문이다.



이번에 리눅스 파운데이션에서 발표한 Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It: An August 2009 Update은 리눅스 커널 개발 과정에서 나타나는 여러 가지 흥미로운 통계자료를 담고 있다.



바쁜 여러분을 위해 몇 가지 흥미로운 사실을 정리해보았다.




  • 마이너 버전 사이 배포 간격: 2.6.x와 2.6.x+1 사이 간격은 평균적으로 3달 정도로 보여진다. 3달은 반복 주기로서 너무 짧지도 너무 길지도 않는 시간으로, 마이크로소프트 사도 오피스 개발에 대략 3달 주기로 반복을 진행했다고 알고 있다(부탁: 마이크로소프트 사 개발팀에 속한 애독자의 내부 제보가 필요하다).
  • 시간당 코드 변경 내역: 개발 일수가 늘어날수록 시간당 코드 변경 내역도 많아진다. 다음 표를 참고하자.



  • 커널 버전당 리펙터링 활동: 커널 버전이 올라갈수록 커널에 추가되고 제거되고 변경되는 코드가 많아진다. 지속적으로 살아 움직이는 프로젝트는 이런 추세를 따를거다.



  • 커널 버전당 참여하는 개발자 숫자: 커널 버전이 올라갈수록 투입되는 개발자 숫자도 늘어난다.



  • 리누스 토발즈는 더 이상 전체 코드 리뷰를 맡지 않는다. 프로젝트 규모가 커짐에 따라 분권적으로 움직인다는 의미다. 통계 자료를 보면 앤드류가 10.5%인 반면 리누스는 2.7%에 불과하다.




운영체제 만드는 작업이 후반부로 갈수록 인력 투입이 집중되고 코드 변경이 급격하게 일어난다는 사실은 그리 놀랍지 않다. 초반에 전체 아키텍처를 잡기 위해 핵심 코드를 작성하는 상황에서 벗어나 다양한 디바이스 드라이버를 추가하며, 그 동안 등한시했던 리펙터링 작업을 집중하기 때문이다. 여러분이 현재 수행하고 있는 프로젝트는 상태가 어떤가? 아무리 바쁘더라도 오후에 잠깐 코딩을 멈추고 SVN과 TRAC 통계자료를 한번 뒤적여보자.

EOB

목요일, 8월 20, 2009

[일상다반사] SOS! 죽어가는 프로젝트 재난 복구 대작전 예약 판매 개시



드디어 기대하고 고대하던 재난 복구(원제: Catastrophe Disentanglement: Getting Software Projects Back on Track) 한국어판이 SOS! 죽어가는 프로젝트 살리기: 프로젝트 재난 복구 10단계 실천 전략이라는 이름으로 예약 판매가 시작되었다. YES24 등에서 구매 가능하니까, 프로젝트 때문에 머리가 아파 쓰러질 지경에 놓인 관리자분들께서는 당장 장바구니에 이 책을 넣으시길...



SOS! 죽어가는 프로젝트 재난 복구 대작전 +출간이벤트라는 제목으로 에이콘 출판사 블로그에 올라온 글이 너무 좋아서 B급 프로그래머 필력으로 도저히 따라가기 어려운 관계상 이번에는 묻어가기 위해 저자(not 역자) 서문을 잠깐 인용하겠다.



몇 년 전, 식인종에게 잡힌 러시아, 프랑스, 일본, 미국 포로에 대한 이야기를 들었다. 펄펄 끓는 물에 집어 넣기 앞서, 추장은 포로들에게 마지막 소원을 말할 기회를 줬다.

러시아 포로는 마지막으로 보드카 한 잔을 요청했다. 프랑스 포로는 아리따운 식인종 처녀와 마지막 키스를 원했다. 일본 포로는 마지막으로 품질에 대해 한마디 하겠다고 했다. 그러자 미국 사람이 다음과 같이 말했다.

"저를 끓는 물에 제일 먼저 넣어주세요. 품질 이야기는 듣고 싶지 않아요."

모 든 것에는 때와 장소가 있는 법이고, 소프트웨어 프로젝트가 난관에 봉착했을 때, 개발 조직이 듣고 싶어하는 마지막 조언은 프로젝트를 어떻게 운영했어야 하는지 설명하는 뒷북이다. 하지만 소프트웨어 프로젝트가 심각한 문제에 부딪혔을 때, 따를 만한 PMI, IEEE, SEI, ISO 복구 절차는 시실 거의 없다고 보면 맞다. 이런 조직은 구제책이라기보다는 예방 차원에서 프로세스를 제공하기 때문이다. 프로젝트가 점점 끓는 물에 가까워져질수록 마지막 요청은 "다시 문제에 빠지지 않는 방법을 보여주세요"가 아니라 "살려주세요"가 된다.

이 책은 "살려주세요"를 다룬다. 실패하는 소프트웨어 프로젝트를 회복하고 정상으로 되돌리는 방법을 설명한다. 물론 간혹 예방 차원의 설명으로 빠져들기도 한다. 하지만 이 책은 기본적으로 실패하는 소프트웨어 프로젝트(또는 재난)에서 회복(또는 복구)하는 10가지 단계를 기술한다. 소프트웨어 개발자, 프로젝트 관리자, 선임 관리층, 소프트웨어 프로젝트 이해관계자(소프트웨어 프로젝트에 관심이 많은 모든 사람) 등 많은 사람에게 도움을 줄 것이다.


저자 서문을 읽어보면 알겠지만 이 책은 실패 직전 소프트웨어를 잠깐 멈춘 다음에 정상 궤도로 올리는 내용을 담고 있다. 지금까지 시중에 나온 대다수 소프트웨어 공학 책은 모두 프로젝트가 망가지기 전까지 사전에 예방조치를 취할만한 훌륭한 이야기를 담고 있는데, 사실상 소프트웨어가 망가지기 시작하면 아무 쓸모도 없다. 정부나 기업에서 비상사태에 대비하는 매뉴얼을 만들어 만반의 준비를 갖추고 있지만 IT 소프트웨어 개발 조직에서 이런 비상 매뉴얼을 보유하고 경우는 드물기에 이 책으로 시작하면 상당히 많은 도움을 받으리라는 생각이다.



이 책 주요 대상 독자는 최소한 경력 5년 이상 팀리더, 팀장, 프로젝트 관리자, 연구소장, 상부 관리층이다. 일반 개발자들도 이 책을 읽으면 좋긴 하겠지만 당췌 무슨 소리인지 모를 가능성이 높아서 조금 걱정이긴 하다. 하지만 향후 팀장이 되기 전에 미리 백신을 맞는다는 기분으로 읽어보면 살이 되고 피가 되리라...



자, 여러분이 기대하는 이벤트 시간이 다가왔다. 일단 출판사 이벤트는 SOS! 죽어가는 프로젝트 재난 복구 대작전 +출간이벤트를 참조하시기 바라며, B급 프로그래머가 출판사 협조를 받아 펼치는 이벤트는 다음과 같다.




  • 에이콘 출판사 협찬 이벤트: 예약판매로 'SOS! 죽어가는 프로젝트 살리기' 번역서를 구입하신 분들을 대상으로 다섯 분을 뽑아서 요즘 절찬 흥행 중인 'Hard Code'을 선물로 보내드리도록 하겠다. 역시 이번에도 선착순 + 추첨으로 선발하겠다. 예약판매로 구입했다는 증거물(온라인 서점 주문 내역 캡쳐)을 B급 프로그래머에게 전자편지(모두 모두 jrogue 에뜨... 쥐메일... 알죠?)로 보내주시면 예약 판매 날짜가 앞서는 분에게 가중치를 적용해서 추첨을 하겠다. 신청 기한은 일주일로 8월 26일 자정까지다.


아무쪼록 성공적인 프로젝트 진행에 도움이 되기 바라며, 블로그 애독자 여러분을 위해 기회가 되면 재난복구 오프라인 세미나도 한번 진행해볼 예정이오니 계속해서 뜨거운 관심을 부탁드리겠다.



EOB

목요일, 8월 13, 2009

[일상다반사] 신용카드를 분실했을 경우 주의 사항

오늘도 삶의 지혜(?)를 다루는 글을 준비해보았다. 한두 장씩은 모두 지갑에 들어있는 신용카드 이야기다.



남편 카드 분실했다고 전화했더니...라는 기사를 읽다보니 며칠 전에 신용카드를 잃어버려서 재발급 받았던 기억이 주마등처럼 뇌리를 스치고 지나갔다.



뭐 지갑을 잃어버린 정도로 큰 사고는 아니었고, 밤에 지하철 타고 가다 버스로 환승하는 도중에 신용카드가 흘러버렸던 모양이다. 개찰구에서 카드가 없어졌음을 인지하고 역무원에게 상황을 설명해서 나온 다음에 바로 카드사에 전화를 걸어서 신고를 했다. 여기서 몇 가지 사항을 주의 깊게 지켜야 한다.




  • 우선 카드를 잃어버렸다는 사실을 인지하자마자 바로 신고에 들어가야 한다. 카드를 잃어버렸다는 사실을 알고도 늦게 신고할 경우 분쟁의 소지가 있다. B급 프로그래머는 카드 분실을 인지한 즉시 콜센터에 신고했다. 콜센터에서는 잃어버린 카드의 마지막 승인 내역을 알려주므로, 이를 주의 깊게 들어서 잃어버린 기간 동안에 부정 사용이 없었는지 확인해야 한다.
  • 특별 주의: 신용카드에 현금 입출금 겸용 기능이 담겨 있는 경우에는 각별히 주의해야 한다. 은행에서 발급한 BC카드를 분실했을 경우 BC카드 콜 센터로 전화해서 신고했더라도 신용카드와 현금서비스만 중단될지도 모른다. 만일 마이너스 통장에 연계된 계좌에서 출금이 가능한 상태라면 문제가 생길 가능성이 있다. 만일의 사태에 대비하기 위해 은행 콜 센터에 전화해서 현금 입출금 기능도 별도로 중단해야 한다. 신용카드사는 겸용 카드 기능에 대해서는 책임지지 않는다.
  • 신용카드를 다시 찾았을 경우에도 절대로 바로 사용하면 안 된다. 반드시 다시 전화를 걸어서 신고 취소를 해야 한다. 안 그러면 경찰이 출동할지도... T_T (응용: 절대 길거리에 떨어진 신용카드를 함부로 쓰지마라)
  • 신용카드에서 공과금 출금을 자동으로 걸어놓았을 경우 카드가 중단되면 공과금이 출금되지 않는다. 나중에 카드를 재발급받을 경우에도 자동으로 결제 수단 변경이 새 카드로 반영되지 않으므로 변경을 위해 전화를 한번 걸어야 하는 수고가 있다.
  • 후불 교통 카드 기능이 들어있는 신용 카드일 경우 데이터베이스 갱신 전까지 유효하다. 버스는 회차해서 차고에 들어가야지 카드 데이터베이스 갱신이 이뤄질거다. T_T
  • 신고 후 빠른 시간 내에 반드시 은행이나 카드사를 직접 방문해서 서면으로 분실/재발급 신고를 하기 바란다. 전산 처리를 100% 믿으면 절대 아니 된다.


자, 이제 신용카드를 잃어버려도 당황하지 말고 차근차근 대응하자.



EOB

일요일, 8월 09, 2009

[일상다반사] Adrenaline Junkies and Template Zombies 번역 소식



지난 번에 2007년 17회 졸트 상 생산성 우수상을 획득한 재난 복구 번역서 관련 소식을 전했었다. 이번에 전할 소식은 2009년 19회 졸트상 일반 서적 부문 최고상을 수상한 Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior 번역서 소식이다. 모든 원고를 다 남겼기에 출판사에서 최종 마무리 작업이 한창이므로 조만간 독자 여러분에게 선보이지 않을까 싶다. 아, 인사이트 출판사에서 소개한 내용도 참고하면 좋겠다.



이 책 역시 아직 번역서 제목이 정해져 있지 않은 관계상 원서 표지를 그대로 올려보았다. 프로젝트 성공을 다루는 패턴과 실패를 다루는 안티 패턴 86개를 싣고 있는 이 책은 톰 디마르코, 팀 리스터 등 아틀란틱 시스템즈 길드 소속 여섯 분이 머리를 짜내어 만든 멋진 책이다. '피플웨어'와 '소프트웨어 프로젝트에서의 리스크 관리'를 재미있게 읽으신 분들이라면 이 책을 놓치면 땅을 치고 후회할지도 모르겠다.



이 책 특성을 잘 나타내는 아마존 서평을 일부 소개하겠다.



이 책은 신랄한 유머와 함께 통찰력을 발휘한다. 이 책은 프로젝트에서 특별히 무능한 역할을 하는 사악한 인물을 그림으로써 즐거움을 선사한다. 목표를 향한 작업 진행 상황이나 마감일을 하나도 언급하지 않고 항상 낙관적이고 장미빛 미래만 이야기하는 무드 링을 낀 관리자를 만나보지 않은 사람이 있을까? 프로젝트에 책임을 지지 않은 채 프로젝트에 돌을 던지는 평론가는 어떤가? 모든 사람의 능력이 평균치 이상인 워비곤 호수 이야기는 또 어떤가?


86가지 패턴을 차분하게 읽어보면서 프로젝트 성공과 실패에 드러나는 패턴과 안티 패턴을 머리 속으로 정리해보면 많은 도움이 될 것이다. 프로젝트 성공을 위해 관리자와 개발자 모두가 꼭 읽어야 할 필독서라는 생각이다.



뱀다리: 어쩌다 보니 재난 복구와 출간 시기가 맞물려 2007년 졸트 상 vs 2009년 졸트 상 대결 구도가 되어버렸다. 한국에서는 누가 더 인기를 끌지 벌써부터 궁금해진다.



EOB

[일상다반사] 미국 거주 이벤트 당첨자 목록

조금 늦은 감이 있지만, 미국 거주하시는 분을 위한 특별 이벤트에 당첨된 분들 주소와 책 목록을 간략하게 정리해보았다. 다행히도 응모하신 분들 중에서 주소가 중첩되는 경우는 없었으므로 충분히 구분 가능할 것이다.




  • Des Plaines, IL 60016: Hard Code: 나잘난 박사의 IT 정글 서바이벌 가이드, 초난감 기업의 조건
  • Gainesville, FL 32608: 조엘 온 소프트웨어, 소프트웨어 컨플릭트 2.0, Rapid Development: 프로젝트 쾌속 개발 전략
  • Plano, TX 75024: 열씨미와 게을러의 리눅스 개발 노하우 탐험기, 소프트웨어 크리에이티비티 2.0, 리눅스 디버깅과 성능 튜닝
  • La Jolla, CA 92037: Hard Code: 나잘난 박사의 IT 정글 서바이벌 가이드, 마음을 움직이는 프로젝트 관리
  • Smithtown, NY 11787: 조엘이 엄선한 소프트웨어 블로그 베스트 29선, Rapid Development: 프로젝트 쾌속 개발 전략, 이노베이션 게임
  • Urbana, IL, 61802: 이노베이션 게임, 리눅스 디바이스 드라이버 개정 3판
  • Cupertino, CA 95014: 리눅스 문제분석과 해결


당첨되신 분들께 박수를...



EOB

목요일, 8월 06, 2009

[일상다반사] 트위트 계정 공개: http://twitter.com/jrogue

B급 프로그래머가 소리소문없이 숨어서 트윗질(?)을 하고 있음에도 불구하고 어떻게 알았는지 followers가 계속해서 조금씩 늘고 있는 상황이다. 따라서 커밍아웃할 시점이 왔다는 생각이다. 관심있는 분들께서는 http://twitter.com/jrogue를 한번 방문해보시기 바란다.



EOB

화요일, 8월 04, 2009

[독서광] 여름나기 책 2선: 리버싱과 문제 해결 대작전

이번 달 developerWorks 서평은 '리버싱과 문제 해결'을 다루는 서적 두 권이다.




  • 리버싱: 리버스 엔지니어링 비밀을 파헤치다: 이 책은 x86/마이크로소프트 윈도우 환경에서 바이너리 코드를 리버싱하는 기법을 상세하게 다루고 있다. 제대로 읽으려면 어셈블리 코드에 ABI와 컴파일러 지식이 필요하지만, 리버스 엔지니어링에 관심이 있는 독자라면 이 정도 난관이야 충분히 뚫고 나갈 값어치가 있다고 생각한다.
  • 리눅스 문제 분석과 해결: 자기 얼굴에 금칠하기 싫어서 여기 소개하기가 곤란하다는 생각도 들었지만, 리눅스 개발자들이 잘 모르는 어두운 구석을 다룬다는 측면에서 감히(?) 용기를 내어 소개해봤다. 이 책을 제대로 이해하고 있는 개발자라면 확실히 리눅스 고수임에 틀림이 없다는 생각이다. 리눅스 개발자라면 꼭 한번 읽어보자.


연재물 마지막에서 소개한 '제1회 해킹 And 리버스 엔지니어링 대회'에 나오는 예제는 리버싱에서도 다루는 전통적인 암호 풀이 응용이다. 하지만 난독화기로 이리저리 꼬아놓았을테니까 쉽게 풀리지는 않으리라고 본다. B급 프로그래머야 차카고 순진하므로 이런 리버싱을 못하기에 주변 해커(동물 애칭이 붙는...) 몇몇을 찔러보았지만, 다들 바쁘단다. T_T



EOB

토요일, 8월 01, 2009

[일상다반사] 재난 복구 번역서 소식 + alpha



2007년 17회 졸트 상 생산성 우수상(Productivity Winners)에 빛나는 "Catastrophe Disentanglement"(by E. M. Bennatan, Addison-Wesley Professional) 번역서가 최종 마무리 작업에 들어간 상황이다. 재난 복구를 다루는 이 책 제목이 아직 안 정해졌기에(발음도 어렵지? ㅋㅋ), 원서 표지를 그대로 올렸다(실제로 번역서 표지도 원서 표지를 그대로 따를 계획이다).



이 책은 일정/예산/품질을 놓고 벌이는 프로젝트 게임에서 재난이 닥치거나 근일 닥치리라고 예상되는 시점에 어떻게 하든 통제력을 장악해서 마무리하는 작업에 초점을 맞춘다. 배구에서 3단으로 넘겨서 위험을 벗어난 다음에 다시 공격할 찬스를 잡는 경우와 비슷하다고 볼 수 있겠다. 책 내용을 살짜쿵 열어보자면...... 프로젝트 복구 10단계를 제시한 다음에 각 단계에서 수행할 내용과 주의 사항을 다룬다. 궁금해하시는 분을 위해 복구 10단계를 그림(미안하지만 급히 그림을 수배하느라 영어 버전이다)과 글자로 정리해보았다.






  1. 프로젝트 활동 중지
  2. 평가자 선발
  3. 프로젝트 상태 평가
  4. 팀 분석 평가
  5. 최소 목표 정의
  6. 달성 가능 여부 파악
  7. 팀 재구성
  8. 위험 요인 분석
  9. 계획 수정
  10. 조기경보시스템 설치


저자인 베나탄은 상기 10단계를 번개불에 콩볶듯 끝내야 한다고 속력을 무지 강조한다. 그도 그럴 것이 상기 재난 복구 과정에서 기존 프로젝트가 완전히 멈춘 상태가 되기 때문이다(all-stop). 과연 한국 실정에 이런 발칙한 이론이 맞아 떨어질지는 B급 프로그래머조차 무지 염려스럽긴 하지만 책을 읽다보면 확실히 끌리는 면이 있다. 목이 빠지도록 기다리는 애독자 여러분을 위해 늦어도 8월 말이면 서점에 배포되도록 노력할 계획이며, 책이 나오는 시점을 기념해서 특별 세미나도 기획하고 있다. 조금만 더 기다려주시라.



뱀다리) 재난 복구 번역서가 나오기 전에 (조만간 선보일) "IT 기업의 타산지석: 일등회사가 주는 교훈"과 (이미 선보인) "소프트웨어 크리에이티비티 + 컨플릭트" 시리즈를 먼저 읽고 계시면 좋겠다. 아무쪼록 휴가 기간 동안 시리즈 4권 모두 통독한 독자에게 행운이 있기를...







EOB