| 정말 오랜만에 단비를 만난듯한 느낌이었습니다. 책장을 한장한장 넘기기가 아까울 정도로... 오늘 출근길에야 다 읽었는데...이젠 무슨 낙으로 사나 싶습니다.^^; 과장이 너무 심했나요? 다른분들한테는 어떨지 모르지만 제 개인적으로는 100점을 주고 싶은 책입니다. 머리가 나빠 딱히 생각나는 구절은 없지만...아직도 인상깊은 부분은 "압력과 플젝과의 관계", "초과근무와 플젝과의 관계" 부분입니다. 얼핏 들으면 딱딱한 내용같지만, 저 자신도 너무나 당연스럽게 여겼던 부분이 실로 그렇지 않다는 부분에서 내심 놀랐습니다. 궁금하시면 읽어보시길~ ^^; 한가지 아쉬운 점이있다면...마지막 부분이 조금 어색한...아무래도 소설로써 결론을 지으려다 보니 어색하게 된것 같지만.. 그래도 저는 100점을 주고 싶은 책입니다. 앞으로도 몇번 더 읽을 생각입니다. 머릿속에 새겨두며..^^v |
| 프로젝트 관련 특히 소프트웨어 프로젝트 관련한 책을 주변에 추천할 때 디마르코의 'PeopleWare'와 브룩스의 'Mythical ManMonth'를 추천하곤한다. 사실 소설로 이 책을 평가한다면 후한 점수를 주기는 어려울 것 같다. 어설픈 스파이물과 기업의 성공담을 섞어놓은 듯하다는 느낌이다. 하지만, 소설이라는 구조가 독자를 소설 속의 프로젝트에 참여하게 만드는 아주 유용한 수단이 되어 준 것 같다. 책을 펼치면 소설을 읽는다는 느낌보다는 프로젝트에 참여하고 있는 제3자로서 소프트웨어 프로젝트와 조직, 그리고 저자가 피플웨어를 통해 보여주었던 인간이라는 - 감성을 지닌 - 지적 - 생명체를 둘러싼 당연시 여기던 편견들을 접하고, 이를 깨트려야할 타당성에 공감하며, 저절로 고개를 끄떡거리며 책장을 넘기게 된다. - 그것이 저자가 의도한 바라 생각한다. - 개인적으로 현재 몸을 담고 진행하고 있는 프로젝트를 돌이켜보니 일은 늘어만가고 사람은 늘 모자랄수 밖에 없다는 불만을 계속 이야기 해왔다. 하지만 정작 사람을 늘리는 대신 일을 줄여서 문제를 해결하겠다는 발상은 해보지 못했던 것이 사실이다. 프로젝트에 대한 다른 이야기들에도 '아하' 라는 감탄사를 연발했지만 업무를 줄인다는 발상은 책을 놓은 뒤에도 머릿속을 떠나지 않는다. 소프트웨어 프로젝트는 최신의 개발툴이나 대용량의 하드웨어가 아닌 사람이 문제를 해결하는 것이라는 사실을 다시 한 번 상기시켜준 책이다. 읽는 동안 행복했고, 통쾌했으며 읽고 나서는 많은 생각을 하게되었다. 인상깊은 구절을 억지로 찾는다면 "협상은 어렵지만 중재는 쉽다."는 대사 정도가 머릿속에 남아있는 것 같다. 진짜로 맘에 들었던 부분은 'PeopleWare'에서는 미지근하게 '꼭 좋은 것만은 아닐 수도 있다'는 정도로 한발을 빼고 있었던 CMM으로 대표되는 소위 '프로세스 향상'에 대한 저자의 공세가 신랄함을 넘어서 때로는 무시의 대상으로까지 읽혀졌다는 점이다. 그 공격이 맘에 드는 것이 아니라 '피플웨어' 이후 시간이 흘렀고 그에 따라 명확해진 의견을 읽을 수 있어서 좋았다. 개인적으로는 CMM의 험프리 교수도 디마르코 못지 않게 존경한다. CMM이 문제가 아니라이 책의 '벨록' 같은 관리꾼이 문제인 것이라 생각한다. |
|
최근에 읽었던 책을 한권 소개하려고 합니다. Tom DeMarco(톰 디마르코)가 쓴 데드라인이라는 책입니다. 프로젝트 관리와 관련해서도 몇몇 글에서 그 내용을 잠깐 인용하기도 했는데요~~ 일단, 소설 형식을 띄고 있기 때문에 읽기가 편합니다. 내용도 그리 어렵지 않고.. 설명도 잘 되어 있습니다. 다만, 프로젝트 관리라는 점에 초점을 맞추기 위해서.. 소설 내용이 작위적이고 약간 개연성이 없다는 문제점이 있기는 합니다. 어차피 재미있는 소설책을 원한게 아니었으니 큰 문제는 없으리라 생각합니다. 그리고 각 장의 마지막 부분에 프로젝트 관리에서 중요한 내용을 다시 요약 정리해 놓은 부분이 있는데, 참고할 만한 자료인 것 같더라구요~ 그래서.. 그 부분중 몇 가지를 올립니다. 모든 일에 있어서 변화는 필요하지만, 사람들이 쉽게 수용하지 않으므로, 변화를 받아들이도록 하기 위해서 어떤점을 고려해야 하는지 설명하는 부분입니다. - 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다. - 변화는 프로젝트를 성공시키기 위해서 (그리고 그많한 가치가 있는 대부분의 노력을 위해서도) 필수적이다. - 안전성이 부족하면 사람들은 위험을 감수하려고 하지 않는다. - 위험을 피하는 것은 치명적이다. 위험과 연관되어 있는 이점도 놓치기 때문이다. - 사람들은 직접적으로 위협을 받거나 자신들에게 악용될지도 모르는 권력을 인지할 때 불안함을 느낄 수 있다. 관리자가 가져야 하는 필수적인 감각이라고 합니다. 지식보다는 감각이 중요하다고 보고 있네요~~ - 관리에는 마음과 본능과 정신 그리고 후각이 필요하다. - 그러므로 마음으로 이끌고, 본능을 믿고(직감을 믿어라), 조직에 정신을 심어주고, 거짓말을 식별할 수 있는 후각을 키워라. 프로젝트를 관리하는 것은 프로젝트의 위험을 관리하는 것이라는 말.. 맞는 것 같아요^^ - 프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다. - 각 프로젝트의 위험을 조사하고 관리한다. - 궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다. - 각 위험에 대한 발생 확률과 예상되는 소요 비용을 평가한다. - 각 위험에 대해 위험이 구체화되는 것을 나타내는 초기 증상을 예방한다. - 무엇이든지 '할 수 있다'는 자세를 갖고 일하지 않아도 되는 사람을 위험 담당자로 임명한다. - 나쁜 소식이 조직의 계층구조 상위로 전달되는 데 용이한 (필요하다면 익명으로) 채널을 수립한다. 가끔 프로세스에 집중하다가 중요한 것을 놓치는 경우가 있습니다. 둘 사이의 균형이 중요하죠.. - 좋은 프로세스와 지속적으로 향상되는 프로세스는 모두 훌륭한 목표가 된다. - 이들은 또한 매우 당연한 목표이기도 하다. 훌륭한 개발자들은 그렇게 하라고 말을 하든 안 하든 간에 여기에 초점을 맞춘다. - 공식적인 프로세스 향상 추진 계획은 시간과 돈이 든다. 그러한 프로세스 향상 작업은 프로젝트 작업을 뒤쳐지게 할 것이다. 생산성 향상이 실현된다 하더라도 그 계획을 실행한 프로젝트가 프로세스 향상에 들인 시간을 상쇄하지는 못한다. - 프로젝트에서 향상 방법을 하나만이라도 제대로 선정한다면 본전(그러한 변화에 투자한 시간과 비용)을 뽑을 수 있을 것이라고 생각한다. - 프로젝트가 그 기간 동안 하나 이상의 향상 방법을 수용하기를 바라는 것은 무리다. 여러 가지 기술을 한번에 향상시키려는 계획(Multi-skill improvement programs)은 그 계획을 실행하지 않았을 때보다 프로젝트를 더 지연시킨다. - 표준 프로세스는 사람들이 중요한 지름길로 갈 기회를 놓치게 할 위험성이 있다. - 특히 인원이 과다하게 투입된 프로젝트의 경우 모든 사람들에게 돌아갈 만큼 일이 충분하지 않다면 문제가 발생하게 된다. 관리자가 화를 낸다는 점.. 직원이 무능하다기 보다는 관리자가 무능하다.. 느낌이 확 오는 것 같습니다. - 관리에서 화와 모욕은 전염된다. 상급 관리자가 직원들을 학대하면 그 밑에 있는 관리자들도 그와 같은 행동을 따라한다.(학대받은 아이들이 학대하는 부모가 되는 것과 비슷하다.) - 관리차원에서 모욕을 주는 일은 사람들이 자신의 능력에 좀더 투자하도록 만드는 자극제 역할을 해야 한다. 그것은 당근과 채찍 두 가지 관리법 중 가장 자주 사용되는 '채찍'인 것이다. 하지만 모욕이 능력을 더 발휘하도록 만든다는 증거가 어디에 있는가? - 관리자가 직원들을 자극하기 위해 모욕을 주는 것은 직원이 무능하다기보다는 관리자가 무능하다는 표시다. 휴.. 정리해 보려니.. 너무 길어질 듯 하네요~~ 여기까지만 적으려고 합니다.. 그럼.. 좋은 프로젝트 관리자 되세요!!! |
|
직접 PM의 역활을 하고 있는 나의 입장에서
주인공인 톰킨스가 진행하는 프로젝트 PM의 역활을 조금이나마 비교해 볼 수 있어서 좋았다.
또한 어렵게만 느꼈던 프로젝트를 소설형식을 빌려 독자에게 쉽게 풀이한점이 책을 읽을때 지루하지 않고 하루만에 읽게 만드는 묘한 매력이 있었던 책으로 기억될것 같다.
프로젝트 계획에서부터 프로젝트 완료까지 자세한 부분에 대해서는 다루지는 못했지만
프로젝트 전반적인 흐름과 프로젝트 진행시 위기 대처는
나름대로 참고자료로 활용할만 하다.
단 아쉬운것은 프로젝트 위기때마다 너무 쉽게 일이 풀린다는 점이다.
책의 엔딩부분은 약간의 허전함이 많이 남아 있다.
티비에서 보는 해피엔딩의 조건을 모두 만족하는 소설이라고 볼수있다. [인상깊은구절] 책 중간 중간에 톰킨스의 일지를 읽다보면 다시한번 프로젝트에 대한 정리를 할 수 가 있어서 좋았다.. 특히 톰킨스의 일지 중 가장 기역에 남는 부분은 첫장에 나온 훌륭한 관리를 위한 4가지 필수요건 였음 |
| 소프트웨어 프로젝트 분야의 대가인 톰 디마르코의 작품이다. 한 분야의 대가답게, 어려운 주제를 아주 재미있고 이해하기 쉽도록 서술하고 있다. 내 책장에는 톰 디마르코가 87년도에 쓴 '피플웨어'가 있다. 프로젝트 관리에서 사람을 관리하는 것이 얼마나 중요한 일인지, 그리고 사람들에게 어떤 환경을 제공해 주어야지 최고의 효율을 얻어낼 수 있는지에 대한 내용을 담은 그 책은 나에게 꽤 큰 감명을 주었었다. 톰 디마르코가 쓴 신간인 '데드라인'을 읽으면서 나는 아주 많은 것들을 생각했다. 내가 지금까지 어떻게 프로젝트를 운영했고 참가했는지를 되돌아보았다. 어제까지만 해도 난 지금까지의 프로젝트들이 문제가 있다고 생각했다. 하지만 소프트웨어 프로젝트에 이렇게 많은 문제들을 고려해야 하는지는 생각도 못하고 있었다. 구성원에서부터 회의 관리, 프로젝트 위험관리까지 각각의 문제는 들어보았지만, 솔직히 현실에서 어떤 식으로 문제를 도출하고 해결할 수 있는지에 대해서는 엄두가 나지 않았다. 이 책을 다 읽은 지금도 마찬가지로 암담하다. 하지만 이제는 안다. 무엇이 문제가 될 수 있고 어떤 식으로 관리될 수 있는지를 알게 되었다. 이제 남은 것은 실제로 부딪치는 문제들을 내가 제대로 해결할 수 있는가이다. 올해는 작년의 전철을 밟지 않도록 노력해야겠다. PS. 한 챕터가 끝나면서 주인공이 남기는 메모가 있는데 정말 좋은 내용을 담고 있다. 따로 정리해두고 싶지만 분량이 너무 많아서 포기하기로 했다^^ |
|
프로젝트 관리는 프로젝트의 규모가 증가할수록 어려워 지고, 다양한 분야의 지식과 경험을 요구하고 있다. |
|
최근에 차세대 프로젝트에 들어와 일을 하게 되면서, 전에도 느꼈었지만, 다시 한번 절감하게 된 대형프로젝트들의 비합리적인 일정과 프로젝트 관리에 대한 문제들을 보면서 나름 프로젝트 관리에 대한 고민들을 하고 있던 중 우연히 소프트웨어 프로젝트 관리에 대해서 소설로 풀어썼다는 이 책을 발견하게 되었다. 일단 소설로 썼다는 점이 맘에 들었다. 안 그래도 머리 아픈데 너무 딱딱하면 끝까지 읽지 못할 수도 있겠지만, 소설이라면 그래도 완독할 수 있지 않을까 해서였다. 읽기 시작한 후 느낀 점은 여타의 소설처럼 재미 있게 이야기를 풀어나가면서도 전해주려는 프로젝트 관리에 대한 주제들도 빠지지 않고 전해주고 있다는것이었다. 책을 읽으면서 인상깊었던 내용들이 몇 있는데, 그 중에 하나가 "프로젝트를 수행했던 팀도 프로젝트의 산출물이다"라는 내용이다. 그간 프로젝트가 수행되고 나면 각 개인적으로는 경험과 기술들이 쌓여가는 것을 보면서도, 그 프로젝트의 수행 노하우는 쌓이지 않던 문제들에 대해 고민이 됐었는데, 이 내용을 보고 그 원인을 약간이나마 알 수 있었다. 먹고 살기 바쁜 작은회사다 보니, 프로젝트가 종료되면 각 팀원들은 또 다른 프로젝트로 찢어져 일을 하기 바빴고, 그 결과 팀원들 전체로서는 훌륭한 프로젝트에 대한 노하우들을 쌓을 수 있는 여건이 조성이 안되었던것이다. 물론 이것이 완전한 이유가 될 수는 없지만, 그 원인의 가장 큰 부분을 차지한다고는 생각한다. 그리고 또 한가지 기억에 남는 내용은 프로젝트를 성공적으로 마치려면, 그간 같은 프로젝트를 성공적으로 수행한 팀들을 모아서 하는 것이 최선의 방법이라는 내용이다. 어찌 보면 위와 같은 맥락으로 이해 할 수도 있을것 같다. 결론적으로 이 책은 프로젝트에 대해서 수행되고, 진행하면서 생기는 일정에 대한 문제나 관리적인 측면에서 부각되는 인력배분에 대한 문제, 즉 어느 시점에 어느 정도의 인력을 투입하는게 적절한가라는 문제들, 그리고 프로젝트가 지연되고 있을 때 추가로 투입되는 인력들이 침몰직전의 프로젝트를 구해내는 데 어느정도 도움이 될까라는 주제들에 대해서 일정부분의 가이드(?)를 제시해 주고 있다고 본다. 그래서 한번쯤 프로젝트 진행과 관리에 대해서 고민했었던 개발자들이라면 읽어보면 도움이 될것이라고 생각한다. |
|
우연히 찾게 된 책이다..
소설로 읽는 프로젝트 관리..
프로젝트 관리에 대한 책은 많이 있다... 여러 재테크 책들 처럼.. 처세술 책들처럼.. 이러이러한 것을 하면 잘 될 꺼다.. 라는 류의 책은 많다..
하지만, 이 책은 이런 강의를 소설을 통해서 한다..
전문적인 지식은 완전히 이해한 사람이 쉽게 예를 들어 설명해 줄 때, 가장 확실하게 기억된다..
가상의 프로젝트 관리자를 주인공으로.. 6개의 소프트웨어 개발을 관리하게 한다.. 프로젝트가 진행되면서 나올 수 있는 많은 문제점들이 등장하고.. 이를 해결하는 방법을 통해서.. 프로젝트 관리의 방법을 전해준다..
결국 하고자 하는 말은.. 주인공이 한 챕터마다 작성하는 일지에 요약 정리해 주는데.. 그렇게만 보면 와닿지 않은 이야기가.. 소설속에서 주인공들의 대화를 통해서 설명되어질 때는.. 쉽게 머리속에 들어온다..
프로젝트 관리를 제대로 하기 위해 이 책을 보게 됬는데.. 실제 도움이 될까? 하지만 공감가는 내용이 가득하다...
프로젝트 관리에 대해 관심이 있다면 강력추천하고 싶은 책이다..
물론, 이 작가의 생각이.. 꼭 정답은 아닐 것이다.. 하지만, 이 책에서 한 두 개의 교훈만을 얻는다해도.. 성공이지 않을까?
|
|
개발 프로젝트를 관리하고 있는 프로젝트 매니저, 또는 최소한 5명 이상의 팀을 관리(만 하면 좋겠지만 -_-;;;)하고 있는 팀리더 등이 재미있게 읽을 수 있는 책이다. 읽으면서 언젠간 이런 용기 있는 프로젝트를 해보고 싶다는 생각이 들었고 전부는 아니지만 부분적으로는 지금이라도 (특히 야근 안 하기 같은 거 ㅋㅋ) 할 수 있는 것들이 아닐까라는 생각을 했다. 그렇다고 이 책의 내용들이 하나 같이 우리나라 개발 프로젝트의 실정과 동떨어졌단 얘기는 아니다. 그리고 이 책에 나오는 여러 유명한 컨설턴트-학계와 현장에서 인정하고 있는-들 만큼 실력과 존경을 받는 인물이 한국에 없다는 뜻도 아니다. 단지 전산 프로젝트 관리에 대해서, 그리고 그런 프로젝트 그 자체에 대해서 고민해 본 사람과 현재도 고민하고 있는 사람들한테는 좋은 영감을 줄 수 있는 책이라고 생각한다. 좋은 영감이라고 애써 한정한 것은, 문제는, 그러니까 현장에서는, 올바른 개념과 훌륭한 방법보다는 그런 것들을 얼마나 적절하게 응용할 수 있느냐이기 때문이다.
새삼스럽지만, 한 분야의 일을 이렇게 다양한 방법으로 표현할 수 있는 저자의 재주에 대해서 감탄이 절로 나온다(부럽다는 말이다 ^^;;). 그리고 마지막 마무리는 역시 소설이라는 재미를 놓치지 않게 해준다.
열정과 신념은 어떤 일을 '더' 잘 할 수 있는 원동력이 될 수 있을 것이다. 우리가 '바닥'이라고 스스로 폄하해서 부르고 있는 이 바닥에는 이 두 가지를 가지고 있는 사람들을 쉽게 만날 수 있는 특이한 분야가 아닌가 싶다. 이런 열정과 신념으로 관리 분야의 일을 더 잘 하고 싶으신 분들은 꼭 읽어보시길 바란다. |