프로젝트를 성공적으로 이끄는 관리방법등에 관한 책은 참 많습니다.
책 제목은 잘 기억이 안나지만,
프로젝트 생존전략(스티브 맥코넬)... Rapid development,
그리고 마이크로소프트는 개발하는 방법론등을 인용한 책이 무수이 있습니다.
이 책도 그러한 부류입니다. 다만 큰 차이점을 꼽으라면,
실제로 매우 성공적인 프로그램인 Numega 의 제품들을 관리한 사람이
그 노하우를 알려준다는 것입니다.
저자의 직접 경험을 바탕으로,
인재 채용 및 관리, 요구사항 관리, ... 릴리즈, 프로젝트 마감까지..
구체적이고도 실제적인 내용들을 설명해줍니다. (경험 사례들도 제공합니다)
대부분의 이 책을 읽은 사람들 입장에서 보면,
이 내용이 실제 현실과 맞지 않는다는 느낌이 들긴 합니다.
우리에게 구경하기 힘든 각종 전문성을 갖춘 팀들(QA, 인지공학, 마케팅, 등등)..
우리와는 너무 먼 현실 같이 느껴집니다.
하지만 저자도 말하지만 처음부터 완벽한 것은 없습니다.
저자도 이런 환경을 만들고 갖추어 나갔습니다.
아마 우리들 보다 더 어려운 기술과 일정압박,
주위의 변화, 비즈니스의 위기등을 겪었을 것입니다.
Softice 의 nt 버전을 만든 사례를 포함한 여러 사례를 보면 그것을 알 수 있습니다.
하지만 그는 성공한 사람답게 팀과 함께 이런 것들을 헤쳐나갔습니다.
그 노하우가 바로 이 책에 나와있는 거구요.
국내 IT 환경이 너무 안 좋다고 생각하시나요??
하지만 이런 환경을 준비 여부는 우리의 실천에 달려 있다는 거 아시죠?.
- 김중곤님이 2005년 9월 5일에 작성하신 강컴 서평 발췌
영어이름을 보아하니.. 언더 프레셔즈 앤 온 타임이다. ㅎㅎ
그냥 순간적으로 언더 프레셔즈 라는 단어에 웃음이 나와버리고 말았다. 아마도 늘 압박에 시달리는 우리가 아닌가 하는 생각이~~ ^^ 그리고, 골룸의 목소리랑 함께 귀가에 멤돌고 있다~~ "마이 프레셔즈~~~"
이책은 다른책과는 달리 팀단위의 장점을 최대한 살려 프로젝트 시작부터 끝까지 어떻게 관리를 하며 계속 달음박질하느냐를 설명해 놓은 책이라 할수 있겠당.
저자 에드 설리반은 누메가라는 회사에서 윈도우 c/c++ 애플리케이션에 대한 메모리 누수 체크및 에러탐지 기능을 가진 BoundsChecker라는 프로그램을 만들었다. 워낙 자바코딩만 하다보니, 누메가라는 회사를 전혀 몰랐었는데, 알아보니까. 꽤나 유명한 제품이었다~~
에드 아저씨는 이 책에서 진짜 내공을 보여준다. 가장 먼저 중요한 것은 바로 사람.. 인재의 중요성을 강조하며, 글을 시작하고 있다. 학부시절때 자주 듣는 얘기가 혼자서 2억짜리 프로젝트를 했데... 누가 무슨 프로젝트 혼자서 했데. 이런 얘기였다.
요즘은 거의 듣지를 못하고 있지만.. 인재는 훌륭해야 한다. 훌륭한 기준에 대해서 아주 잘 설명해 놓았다. 그것도 인사관리자처럼 말이다......
진정한 Commercial한 S/W Product를 만들기 위해 대충 어떤 스타일의 인재가 필요한지, 고려해볼필요가 있다.
하튼, 우리 SW 엔지니어의 모습으로 되돌아가보자~~
그리고, 국책과제를 하든, Product를 만드든, SI 프로젝트를 하던간에..
그 Project를 실행해가며, 정확한 요구사항과 기술, 사용모델.. 스케쥴을 통해 설계한다.
그리고, Product를 만드는 과정, 즉, 실행, 테스트, 릴리즈, 완료때까지의 과정을 쉽고 나름대로의 잘 된 과정을 지내지 않은가?
이런거 잘 알고 있다고 하겠지만, 이책을 통해서, 다시 한번 재점검을 할 필요가 느낀다...그것도 아주 뼈져리게.. 난 PM이나 팀장의 위치에 있지는 않지만, 언제가는 서야 될 자리인것은 분명할 것이다. 우리 주변엔 훌륭한 인재가 그리 많지 않을 수도 있구, 많을 수도 있다. 내가 그 훌륭한 인재가 되는 건 얼마나 큰 영광인가?
정확한 인지력과 마인드, 형상관리, 리더쉽을 이책에서 많이 배웠다. 꼭!!! 훌륭한 인재가 되어 훌륭한 팀원을 이끌러 훌륭한 작품을 만드는 재미~ 기대되지 않는가??
엔지니어가 엄청난 약점이 있는데. 바로 Macro적인 시각이 부족하다는 것과 Communication 능력이 아닐수 없다. 이책에 바로 그 내용이 있다..그리고, PM이나 팀장의 중요성을 다시 한번 느끼는 책이 이것이지 않을 수 없다.
프로세스는 정말 중요하다. 전에 5명있는 벤처회사에 죽는 줄 알았다.. 프로세스가 없으니.. 혼자서 Requirement를 정의하고, 개발하고, QA를 하다가 릴리즈하는 때를 놓치는 어리석은 우를 많이 범했다는 것이 기억이 난다..
이책을 통해서, 업무 프로세스를 다시한번 생각해보는 좋은 방편이 되었으면 좋겠다.
(강컴에 올렸던 제 서평을 발췌하였습니다.)
재밌는 일이다.
C, C++, JAVA라고는 오래전에 끄적끄적 배워본게 다인 나로서 이 책을 읽었다는건 그저 신기에 가깝다.
왜냐하면 이 책을 읽을 당시는 2003년 가을쯤에 프로젝트 매니저로서 관리에 대한 지식에 갈증에 허덕이며 스스로 체계를 잡고자 손에 들고다니던 책인데 그때 당시로서는 거의 60%를 이해하지 못했던게 사실이기 때문이다.
그도 그럴것이 나는 웹개발 SI를 전문으로 하고 있었고 따라서 APPL쪽은 당연 그 속사정을 몰랐기 때문이다. 나중에 알았지만 누메가라는 회사는 그 방면에 매우 유명한 회사인 것을 알았다.
물론 당근, 읽을 때는 대체 뭔 회사이길래 이리도 자랑을 해 놓았나 싶었다.
그래서 한번 읽고는 "재수없어~온통 지 자랑뿐이네"하고는 저쪽 책장 구석에 꽂혀서 다시는 빛을 보지 못한 책이였는데 얼마전 책 정리를 하다가 다시 빛을 보고야 말았으니 빛을 보자마자 책정리하던 손을 멈추고 몇시간동안 다시 읽을 수 있는 행운을 잡은 건 나로서는 엄청난 행운이였다.
서두가 길었다. 다시 돌아가자..
서두에 잠깐 말했지만 이 책은 초보자가 읽기에는 좀 무리라는 생각이 든다.
왜냐하면 서두에 그랬듯이 초보자(입문자라기 보다는 경험으로 뛰다가 스스로 책을 펴는 사람)이면서 웹개발쪽 PM을 하는 사람으로서 너무나 어려운 얘기들이 많았기 때문이다.
생각해보라..우리나라 웹개발 SI에 무슨 릴리즈가 있으며 무슨 테스팅 프로그램이 있단 말인가..
(그냥 운영 서버에 이관하고 사용자 혹은 개발자가 테스트하고 넘어오는 수정사항 처리하면 끝인게 사실이다) 게다가 메모리 누수라니...웹개발에는 아주 먼 얘기였던 것이였다.그러니 당연하게도 이책의 마지막장을 넘기면서 이 책은 웹개발 PM이 읽을 만한 책은 아니다라는 결론에 자연스레 도달한 것이다.
그러나 지금와서 돌이켜 보면 이 책을 읽었던 시점부터 뭔가가 달라졌다.
인적자원 관리는 아주 인상적이였다. 인재를 고르는 방법부터 활용하고 유지하는 법까지, 모든 프로젝트에서 우선적으로 프로젝트는 사람이 하는 것이라는 근본적인 원리에 충실했다.
처음 읽자마자 가장 빨리 적응할 수 있는 부분이 이 부분일 것이다. 자신의 개발팀을 다시 한번 점검하는 계기를 마련해 준다. 과연 내가 적절한 사람들과 프로젝트를 진행하고 있는 것일까..
무엇을 잘하고 있고 무엇을 잘못하고 있는지 스스로 점검할 수 있게 해주며 같이 일할 사람을 찾는 법까지 설명해 주고 있다.
그때부터 지금까지 본인 역시 팀의 인력관리에 가장 중점을 두어야 한다고 생각하고 있다.
두번째로 그때(2003년 가을)까지 생소했지만
경험상으로 막연하게 접했던 프로토 타이핑이란 방법과
가장 등한시 되던 QA팀이란 존재까지
- 사실 그때 QA팀의 개설을 주장하다가 욕만 얻어먹은 기억이 난다. 회사 입장에서는 그다지 중요한 부서가 아니라고 판단되었기 때문일까 -
머리 속으로 막연하게 필요하다라고 느껴질 수 있었으니까 말이다.
그러나 반드시 QA팀은 필요하다. 그것도 명색만 갖춘 조직이 아닌 철저히 관리되는 조직으로서 말이다.
끝으로 한가지 아쉬운 건, 본인 역시 약간의 현실과 동떨어진 느낌을 지울수가 없던게 사실이였다.
그건 응용프로그램이 주가 되어서가 아닌 책에서 설명하는 조직을 과연 우리나라에서 갖춘 회사가 얼마나 될 것이며 갖출 회사가 얼마나 될 것인가에 대한 의문때문이였다.
필요한 것은 안다. 하지만 현실은 그렇지 못하다. FM은 알지만 못하는 군대같은 느낌이랄까...
이 책은 저자의 경험을 바탕으로 멋진 프로젝트를 경험하게는 해주지만 현실에서 같은 경험을 하기는 어렵다는 괴리감을 심어주기는 하다. 하지만 FM을 알아야 AM도 하는 법이다.
지금도 프로젝트 일정 압박과 엄청난 스트레스를 견디며 밤을 새는 개발자와 관리자들을 생각하면 이 책의 제목이 자연스레 떠오른다.
적어도 한번쯤 아니 곁에 두고 두세번을 펼쳐볼 수 있는 몇권 안되는 책임에는 분명하다.
이 책에서 가장 기억에 남았던 경험사례가 있다.
"모든 일정을 준수하면서도 개발자들은 자신들이 하고 싶었던 일들을 야근까지 하면서 업무외시간에 진행하고 있었다. 상급 관리자가 개발자들에게 하고 싶었던 일들은 당분간 접어두고 좀더 프로젝트에 매진해서 더 빨리 완료하라고 지시 했을때 그 날 야근한 개발자는 한명도 없었다."
출처: 강컴서평중 강성민님
이 책에 대한 평가는 상당히 갈리는 편입니다.
"최고의 프로젝트 관리 서적이다."
vs.
"현실과 맞지 않는 이상적인 서적이다."
혹시 중고등학교 시절에 학습지 회사에서 나누어 주던,
합격자 수기 같은 것 읽어보신 적 있으신가요?
설마 그것을 읽고 그대로 믿고 따라해본 적은 없으시겠죠?
또, 예전에 "공부가 제일 쉬웠어요." 같은 합격자가 쓴 책들이 인기 끌던 때도 있었죠.
이런 책들을 한마디로, 쓰레기다라고 하는 사람들도 있었고,
있는 그대로 받아들이고, 실천하는 사람도 있었습니다.
저 같은 경우는...합격자 수기를 즐겨 읽었습니다.
그럼, 그런 책들을 그대로 따라했냐구요?
절대로 아니죠.
그 사람들과 저희 성격, 특징, 환경, 지망하고자하는 학과...
학력, 실력, 특질 등등..
많은 것들이 같지 않은데, 아니 같더라도...
있는 그대로 그 사람들이 써놓은 것을 실천한다는 건 참 바보같은 일이라고 생각합니다.
그대신...
그런 수기를 읽을땐...무언가 얻으려고 했습니다.
어떤 사람의 수기를 읽고는 자투리 시간을 활용하는 방법을 얻었고,
어떤 사람의 수기를 읽고는 서브노트에 대한 아이디어를 얻었고,
또 어떤 사람의 수기를 읽고는
시험 보는 방법같은 것을 깨우쳤고,
그런 내용들을 나름대로, 제스스로 정화시켜..
저만의 공부방법..노하우를 만들어서 제가 딱 맞는 방법론을 세우고,
실천했죠.
좀 딴 소리를 많이 했지만,
이 책도 마찬가지 입니다.
기존 자신이 속한 회사, 단체가...
현재 저자 설리반이 속한 누메가가 처한 환경과 같을리가 없습니다.
만들려는 제품도 다르며, 개발자들의 성격도 다양하고...
문화적인 차이도 존재하며...
기술적인 요소도 차이가 날겁니다.
게다가 설리반은 누메가 초창기 시절부터 자신들만의 프로젝트 방법론을 만들어온 겁니다.
그러니, 기존 개발그룹에 적용하기에 적당하지 않는게 당연한 일일지 모릅니다.
그러나,
제가 이 책을 높게 평가하는 건...
좋은 교본이 되어준다는 거죠.
이 책을 읽어봄으로서,
프로젝트 성공적인 진행을 위한 아이디어를 얻을 수 있다는 겁니다.
누메가에서 많은 시행착오끝에 얻은 많은 내용들을
..많은 아이디어를 얻을 수 있다는 점에서..
정말 훌륭한 책이라고 생각을 합니다.
그렇다면, 이 책을 읽은 독자는 무엇을 해야만 하는 건가요?
이 책에 나온 모든 것을 받아들일 필요는 없다고 봅니다.
이 책에서 나온 것 처럼...
누메가라는 회사는 우선...
R&D 중심의 회사로...
개발자들의 분업화가 확실한 회사입니다.
거기에 맞게 방법론이 만들어졌다면,
여기서는 우선 착상만 얻고...
우리 입장에서 최상의 방법론을 만들어 내는 겁니다.
이런 아이디어를 주는 것만으로도..
모범적인 교본이 되어주는 것만으로도..
이 책은 충분히 가치있는 책이라고 생각합니다.
이 책의 신상명세부터 간단히 알아보자.
원제는 Under Pressure and On Time이다. 번역 제목의 데드라인이나 원제의 "압력" 같은 단어만 봐도 느낌이 오는 개발자와 개발 관리자는 이 책을 읽어야 한다. 책을 쓴 에드 설리반은 누메가에 초기에 입사해서 바운드 체커를 비롯한 여러 소프트웨어의 개발 관리를 맡았던 사람이다. 입사할 당시에 누메가의 직원이 14명이었다고 하니 꽤 초기 멤버였던 셈이다.
이 책은 3부로 구성되어 있는데, 1부 사람, 조직, 체계가 책의 절반이 조금 넘는다. 1부에서는 훌륭한 사람을 찾아내는 방법, 면접을 보고 채용하고 유지하는 방법, 프로젝트를 위한 조직, 조직의 문화, 빌드 시스템과 버그 트래킹을 포함한 여러가지 소프트웨어 도구, 여러 단계의 테스트를 통한 품질 보증, 빌드 관리 등을 다루고 있다. 1부 150쪽의 내용을 이해하고 제대로 하기만 해도 프로젝트는 반 이상 성공한 것이라고 생각한다. 2부에서는 요구사항 분석, 프로토타이핑, 사용자 인터페이스, 스케줄링 등을 다루고 있는데, 모두 현장의 생생함이 살아있는 내용들이다. 3부에서는 프로젝트의 수행, 베타 테스트, 릴리즈 후보, 프로젝트 마감 등을 다루고 있다. 프로젝트가 본 궤도에 올라서 제품을 내고 프로젝트를 마감하는 과정까지인데, 패키지 소프트웨어의 경우이기 때문에, 이 부분은 프로젝트마다 다르게 적용해야 할 것이라고 생각한다.
이 책은 훌륭한 소프트웨어 개발을 위해서는 훌륭한 조직이 필요하고, 훌륭한 조직은 결국 훌륭한 사람들로 이루어진다는 것을 보여주고 있으며, 프로젝트 관리자가 "잘" 해내야 하는 많은 일들, 좋은 사람을 뽑고, 좋은 조직을 만들며, 스케줄 관리를 통해 좋은 제품을 출시하는 일들을 실제 프로젝트 관리자로서의 경험이 풍부한 저자가 생생하게 보여주고 있는 멋진 책이다.
270쪽 밖에 안 되는 책의 정가가 18,000원이라서 비싸다고 생각할지 모르겠지만, 이 책은 어떤 종류이든 소프트웨어 개발 프로젝트에 참여하고 있는 사람이라면, 지위와 역할을 막론하고 읽어야 할 책이라고 생각한다. 요즘 번역서에 대한 평가를 쓰면서 빼놓을 수 없는 것, 역자도 실제로 개발 프로젝트에 참여한 경험이 있는 사람이라서 번역의 수준은 충분히 만족스럽다.
