| 'Professional 소프트웨어 개발' 책을 통해 스티브 맥코넬의 진수를 맛본 이후 바로 이 책을 구입하여 두번을 정독해서 읽었다. 저자는 소프트웨어 프로젝트 개발은 비가시성, 복잡성의 소프트웨어의 본질적 특성과 열악한 소프트웨어 개발 환경 등으로 인해 성공하기는 매우 어렵고 실패할 주1)확률이 높기 때문에 소프트웨어 프로젝트는 '생존'의 문제로 인식해야 한다고 전제한다. 저가 수주, 하청, 불평등 계약관계, 야근 등으로 인해 프로젝트 현실은 불타는 갑판위에 서 있다. 여기서 프로젝트를 실패하지 않고 무사히 끝내는 건 '생존'이라 아니할 수 없다. 소프트웨어 프로젝트 생존의 문제는 매슬로우의 '욕구 5단계' 이론의 가장 기본적인 욕구인 생리적(식욕, 성욕 등)욕구와 매핑되는 것이다. 이 책은 CMM 2 Level 기반의 프로젝트 관리를 위한 프로젝트 계획서로 PMBOK 등 일반 이론서와 다르게 저자의 경험이 곳곳에 스며들어 있다. 시사하는 메시지는 간단하다. 생존확률을 높히려면 프로젝트 계획, 요구사항 주2)개발, 아키텍처 등 상류(upstream)에 보다 더 집중하라고 조언한다. 대부분의 프로젝트 관리자, 개발자들의 인식은 상류 단계의 활동은 빨리 진행해서 가급적 코딩에 신속하게 몰입해야 프로젝트가 성공할 것으로 착각한다. 그러나 상류에서 발생하는 오류 수정에 발생하는 비용은 하류의 그것과 비교해서 최대 200배 이상 차이가 나기 때문에 프로젝트 전반부에 신경을 써야 한다. 또 상세설계, 구축, 테스트, 릴리즈의 하류(downstream)단계는 단계별 납품 방식을 택해서 진행할 것을 요청한다. 단계별 납품 방식은 점진적, 반복 개발 프로세스와 유사한 개념으로 하류 단계의 활동들을 몇개의 단계로 나누어 반복적으로 릴리즈를 수행하는 방식이다. 핵심 메시지가 강조하는 의미는 프로젝트의 위험을 조기에 해결하라는 것이다. 이제 저자는 위의 두가지 생존전략의 실현을 위한 구체적인 생존 기술을 몇가지 제시한다. 1. 프로젝트 계획 수립 프로젝트 착수가 시작된 지 약 10%가 경과된 시점에 프로젝트 계획 체크리스트 검토를 통해(PCR, Planning Checklist review) 프로젝트의 Go/No Go를 재결정하라. 왜냐하면 위험이 크다면 중지하는 것이 더 효율적이다. 보통 프로젝트 규모를 구체적으로 산정하기 전에 실행계획금액이 보통 결정되는 것이 일반적이므로 저자는 그 대안으로 2단계 예산 집행 방식을 제안한다. 규모 산정이 비교적 정확히 산정되는 시점(보통 경험상 수행계획서 작성 시점이 아닐까 생각하는데...)에 1차 계획 대비 차이분에 대한 예산 집행을 제도적으로 보장할 것을 제시한다. 2. 프로젝트 위험관리 프로젝트 위험관리는 이제 선택이 아닌 필수적인 문제다. '프로젝트의 리스크를 적극적으로 공격하지 않으면 그 리스크한테 공격을 당한다.'는 Tom Glib의 말을 인용하면서 저자는 사용자의 지속적 참여가 리스크를 줄이는 근원적 방법임을 역설한다. 사실 개인적인 생각이지만 프로젝트 위험관리는 반드시 변화관리가 수반되어야 한다. 어느 프로젝트이건 위험은 항상 존재한다. 경중만 차이가 있을 뿐이다. 따라서 프로젝트 초기부터 위험요소를 적극적으로 발굴(?)하여 대응방안을 마련하는 것은 문제해결능력이 탁월함을 보여주는 것이다. 그러나 문제가 있으면 프로젝트 관리자의 능력을 의심하는 게 우리의 우울한 현실이다. 3. 프로젝트 가시성 향상 소프트웨어를 개발하는 데 있어서 가장 어려운 점의 하나는 눈에 보이지 않는 다는 점이다. 진척율 파악이 어려울 뿐더러 결과물이 프로젝트 종료시점에 가까워질 때 드러나기 때문에 제대로 길을 가고 있는 지에 대한 의문이 들게 마련이다. 비가시성만큼 리스크는 잠재되어 있다. 가시성을 향상시키기 위해서는 첫째 프로젝트의 비전과 목표를 분명히 정립하고 팀 차원의 공유를 해야 한다. 둘째 가급적 상세 마일스톤을 작성하고 주기적으로 계획이 제대로 진행되고 있는 지를 파악해야 한다. 셋째 프로토타이핑, 정기적 릴리스를 수행해야 한다. 4. 피플웨어(Peopleware) 톰 디마르코가 처음 사용한 개념인 피플웨어는 소프트웨어 개발에 있어서 사람의 중요성을 인정하는 관리 방식이다. '인간의 얼굴 모습을 가진 소프트웨어 개발'이 되기 위해서는 먼저 개발자가 원하는 일을 시키라고 주장한다. 둘째 개발자들을 진심으로 인정하라. 셋째 사색할 수 있는 분위기를 만들어라. 넷째 나만의 공간을 제공하라. 피플웨어 책에 나오는 사무실 파티션도 세심하게 배려하라는 이야기가 생각나는 대목이다. 5. 사용자 참여 우리가 만드는 소프트웨어의 궁극적 목적은 사용자가 효율적으로 업무에 활용하게 하는 것이다. 이러한 미션을 달성하기 위해서는 사용자의 지속적이고 적극적인 참여는 당연하게 이루어져야 한다. 6. 제품의 단순화 소프트웨어 개발은 단순한 방식으로 수행되어야 한다. 처음부터 복잡하게 설계된다면 구현의 문제뿐 아니라 최종 사용자의 운영에 큰 부담이 된다. 볼테르가 말한 것처럼 더는 덧붙일 것이 없을 때 끝내는 것이 아니라, 더는 뺄 것이 없을 때 끝내야 한다. 7. 출시 지향 Microsost사는 성공적인 런칭과 관계없이 개발자들의 릴리즈 마인드를 심어주기 위해 Ship It이라는 인센티브 제도를 시행하고 있다. 그래서 버그가 많은 건가? 아뭏든 우리의 목적은 최종 성과물이며 결국 제품이 모든 것을 웅변해 주기 때문이다. 이후 저자는 상류와 하류 단계의 활동(Activity) 단위별 수행 방법과 팁을 제시한다. 상세한 내용은 앞에서 언급한 생존기술과 일부 중복되는 감이 있어 아이디어 차원에서 몇가지 소감을 소개하고자 한다. 1. 테크니컬 리뷰 품질보증의 중요한 활동 중의 하나인 주3)테크니컬 리뷰는 코딩단계만 진행되는 것이 아니고 프로젝트 초기부터 수행되어야 한다. 또한 단지 검토한다는 개념보다 결함 발견에 초점을 두어야 한다. 예전의 경험에서도 뼈저리게 느꼈지만 테크니컬 검토는 의외로 시간이 많이 소요되고 또 리뷰 후 수정시간을 반드시 확보해야 한다. 2. 프로젝트 이력 배포 프로젝트가 종료된 후 대부분 피드백 작업을 소홀하게 된다. 군대처럼 떠올리기 싫은 안좋은 추억이 연상되어서 그런가? 성공/실패 프로젝트에 대한 분석이 이루어지긴 하지만 대부분 품질보증조직에 의해 수행되는 게 현실이다. 프로젝트 철수 후 팀 차원에서 구체적으로 리뷰가 이루어져야 한다. 프로젝트 리뷰 설문서가 준비되어야 하고 전사적 교훈(lesson learned)으로 전파되어야 한다. 차기 프로젝트 계획 수립에 활용할 수 있어야 한다. 3. 사용자 매뉴얼을 요구사항 개발단계에 작성 보통 사용자 매뉴얼은 소프트웨어 개발이 완료된 후 사용자 교육이 실시되기 전에 부랴부랴 작성된다. 그러다보니 내용이 빈약하고 형식적으로 작성된 매뉴얼이 다반사다. 사용자 매뉴얼을 프로토타이핑처럼 요구분석 단계에 작성해보자. 이후의 상세설계 공정은 신속히 이루어질 수 있을 것이다. 4. 리스크 Top 10 관리 가요 Top 10도 아니고 리스크 Top 10이다. 10가지는 무조건 작성하게 하고 매주 순위는 바뀔 수 있다. 혜성처럼 새로 등장하기도 하고 5주 연속 수상을 하여 사라지기도 할 것이다. 5. 프로젝트 예산을 리스크 감안하여 수립 우리 현실에서는 이상적인 얘기처럼 들리겠지만 리스크 분석은 반드시 비용을 수반한다. 그래서 주4)우발손실 준비금(contingency plan)과 일반적 준비금(management plan)을 반영할 것을 PMBOK에서는 공식적으로 명시하고 있다. 소프트웨어 개발 특성 상 위험요소가 많으므로 이를 규모산정과 추정에 제도적으로 반영하고 주기적으로 갱신하는 프로세스가 정립되어야 한다. 이 책의 각 장 맨 끝 부분에 생존진단표를 요약하여 체크리스트 형태로 제시한 점은 매우 유익한 아이디어라고 생각된다. 이 책은 프로젝트 관리 교재로 사용하기에 충분하다. 한가지 프로젝트 관리는 PM의 역량과 직결된다는 점에서 PM의 역량과 책임, 자질 등에 대한 언급이 없는 점이 아쉬움으로 남는다. 또한 1차원적 생존의 욕구를 넘어서 자아실현, 전문성 개발 등의 욕구로는 어떻게 가야 하는가라는 문제도 남는다. 물론 'Professional 소프트웨어 개발'에서 일부 언급했지만.. 좋은 책은 오래 곁에 둔다는 데 이 책은 프로젝트 할 때 마다 꼭 봐야겠다는 생각이 들 정도로 프로젝트 관리의 정수로 기억될 것이라 믿어 의심치 않는다. 주1) Standish Group의 2001년 보고서에 의하면 전 세계 소프트웨어 개발의 28%만이 성공한다고 함 주2) 요구사항은 개발(Development) 차원의 활동이 되어야 한다고 저자는 강조. 따라서 분석이 아닌 개발로 표현함 주3) CMM에서는 일반적으로 동료검토로 호칭됨 주4) 우발손실 준비금은 프로젝트 관리자가 예측 가능한 위험에 대비해 수립하는 예산인 반면 일반적 준비금은 예측 불가능한 위험에 대비해 경영층에서 수립하는 예산을 의미함 |
| 이 책을 기다리고 있던 것도 아닌데, 우연히도 거의 발행과 동시에 주문을 하게 되었다. 초반 발행이 5일에 주문 일자는 7일, 손에 쥐게 된 게 8일이었다. 몇 권의 책을 함께 주문했었는데, 멋진 겉표지에 마음이 동해 가장 먼저 읽어보게 되었다. ^^ 마침 나는 내가 속한 단체의 새로운 프로젝트 관리 시스템을 구축하기 위해 고심하고 있었다. 실상은 반년도 더 전부터 시작은 하고 있었지만 이러저러한 일들로 본격적으로 시작한 것은 얼마 되지 않았다. 평소 프로세스, 프로젝트 계획 등으로 불리우는 개념들에 관심이 많았고, 이런저런 프로젝트를 하면서 많은 것들을 테스트해보았다. 그런데 백명이 훌쩍 뛰어 넘는 인원들로 구성된 단체의 프로젝트 관리 시스템이 너무 소극적이라, 실패 위험이 크고, 서로 간의 노하우 교류 등이 거의 이루어 지지 않고 있음이 항시 못마땅했다. 이리하여 그간 연구와 테스트의 주 대상이었던 Unified Process를 바탕으로 여러 가지 체제를 만들어 보려고 하였으나, 역시 문제는 너무 급격한 변화와 통제는 심한 반대 여론에 부딪칠 것이란 우려였다. 나 혼자야 충분히 유용성을 깨닫고, 피부로 느끼고 있지만.. 이런 개념들에 익숙치 않은 사람들에게 어떻게 하면 효과적으로 설득시키고 이해시키는가 하는 문제, 최고의 성과를 얻으면서 가장 적은 변화만을 줄 수 있는 것들은 무엇인가? SPSG는 이런 고민들에 대한 훌륭한 가이드를 제공해 주었다. 다양한 의문점들에 대한 명쾌하고 설득력 있는 설명들, 쉽게 적용해 볼 수 있을 만큼 간략하면서도 가시적인 예제들.. 특히나 '결함 추적', '테크니컬 리뷰', '진척도 추적', '프로젝트 이력' 등은 지금 몸담고 있는 단체에 꼭 필요한 사항들이 아닌가 싶다. |
| 개인적으로 별 넷이 최고 점수인 짠돌이 입장에서 SPSG는 만점 - 별 넷-을 흔쾌히 줄 수 있는 책이라 생각된다. 한글 제목만 봐서는 소프트웨어 프로젝트에 참여하는 경우 개인으로서 살아남는 전략을 설명하는 책 같다. 물론 책이 말하고 있는 "생존"은 프로젝트에 참여하는 인력이 아니라, 프로젝트 자체를 살아남게 만드는 비법들을 이야기 하고 있음은 금방 알 수 있었다. 요새 PMP에 관심을 두고 있어서 '프로젝트"라는 단어가 제목에 포함된 책들을 관심있게 보고 있는데 단연 발굴이라 할 수 있을 것 같다. 소프트웨어 프로젝트를 진행 할 때 방법론을 따르건 주먹구구식의 진행이 이루어지건, 일을 해야 하는 당사자로서 가장 어려운 점은 6하원칙에 따라 해당 업무를 '왜'하는지, '무엇을', '어떻게' 하는지가 명확치 않은 경우일 것이라 생각한다. (물론 지금까지 해왔던 프로젝트에서 언제라는 의문을 가진적은 없었다. 언제나 '당장','ASAP'가 답이었으니까... -_- ) 그런 면에서 이 책은 수많은 소프트웨어 책들처럼 너무 학문적이라는 느낌을 주기보다는 실무에서 한 번 시도해 볼 수 있겠구나 라는 생각이 드는 내용들을 한번 시도해 볼 수 있는 수준으로 설명하고 있다는 점이 매력이라 생각한다. SPSG를 손에 넣고 나서 행복한 고민이 시작됐다. 개인적으로 책꽂이에 책을 꽂을 때 점수를 매겨 순위별로 꽂아둔다. 현재까지는 '피플웨어'와 'Mythical ManMonth'를 두고 어느 책을 1등 칸에 꽂을지 고민하곤 했는데 이 두 책과 자리를 다툴 책이 한 권 더 늘어난 것이다. 팀원들과 함께 읽어야겠다는 생각이 드는 책이다. - 흠, SPSG에 대해 쓴 윗글을 다시 읽어보니 아직 나에게도 '칭찬회로'가 남아 있었구나 하는 생각도 해보게 된다. |
| 이 책은 피플웨어, 이 책의 저자인 스티브 멕코넬의 다른 책 Professional 소프트웨어 개발, 와 같이.. 어떻게 하면 프로젝트를 성공적으로 끝낼까 라는 주제를 놓고.. 그에 따른 스티브 멕코넬이 생각하는.. 프로젝트의 단계적인 개발과 관리.. 등에 관하여 실제 사례들을 놓고 설명하고 있다. PM 급 이상의 사람들이 봐야 할 책이겠지만.. 개발자의 입장에서 보아도 괜찮은 책이라 생각한다. 어떤 기술이나 코드가 나오는 책이 아니기 때문에 가볍게 읽어볼수 있는 책이다.. |
|
프로젝트 진행의 위험 요소와 이에 대한 예측에 대해 많은 것을 알려주는 책이다. 전반적으로 프로세스에 의한 프로젝트 진행에 무게를 두고 있다. 프로젝트 관리업무를 맡은 사람이라면 한번 읽어볼 필요는 있다.
이 책은 프로세스의 개선이 프로젝트의 성공으로 이어진다는 명제를 전제로 전개된다. 나는 이 의견에 전적으로 동감하지는 않지만, 적절한 프로세스의 선택은 프로젝트의 효율성을 높일 수 있다고 생각한다. 그런 면에서, 이 책이 제시하는 여러가지 방법론을 숙지하고 취사 선택하는 작업은 프로젝트의 효율성에 도움이 될것으로 본다.
예를들어, 마일스톤에 의한 프로젝트 진행 관리는 현실적으로도 의미가 을 수 있다. 위험 요소 목록을 만들고 수시로 보고하는 시스템은 정상적으로 동작하지 않을 것이다.
결론적으로, 이 책의 독자에게 당부하는 바는, 이 책은 프로세스의 입장에서 프로젝트를 설명하고 있고, 이는 전체 관점중 일부임을 기억하며 읽기 바란다. |
| 많은 사람들은 행복해지는 비법에 상당히 관심을 가진다. 하지만 막상 누군가 그 질문에 답을 하면 평범하다고 무시해버리는 경향이 있다. "성공적인 소프트웨어 개발을 위한 방법은 무엇인가?"라는 질문도 같은 결과를 얻게 되는것 같다. 먼저 이글은 읽은이로써(지극히 개인적인 생각입니다.) 추천하고 싶은 말은 이책을 읽고 하나라도 적용해보겠다고 생각하는 분만 읽었으면 좋겠다. 마치 특별한 비법이 있을거라고 생각하고 읽으신다면 다소 후회스러울수도 있으니까요. 이책을 읽으면서 좋았던 점 1. 실사례를 적절히 들었다. 2. 책의 흐름이 일관되고 요약이 잘되어있다. 3. 객관적인 통계자료와 도표를 통해 이해를 돕고있다. 4. 창의성을 해치지 않는 범위내에서 가이드를 제시하고 있다. 아쉬웠던점 1. 아키텍쳐에 관한 내용이 다른 토픽에 비해 적다. 사실 난 이부분 만큼은 저자와 다른 생각이어서 좀더 자세히 알고 싶었다. 저자가 이책을 쓴 시점이 1997년 이란 사실이 놀랍다. 그리고 진심으로 감사드린다. 아마 RUP를 잘 아시는분들은 쉽게 읽을수 있으리라 생각된다. 끝으로 번역판을 읽는다는 생각을 하지 못할만큼 깔끔하게 번역해주신 분들에게 감사한다(오타도 하나밖에 찾아내지 못할만큼). 덕분에 많은 시간을 줄일수 있었던것같다. |