'pm'에 해당되는 글 3건
- 2007/07/12 데드라인 (The Deadline) - 소설로 읽는 프로젝트 관리
- 2007/06/27 프로젝트 관리를 위한 필수 요건
- 2007/05/17 깨진 창문을 내버려 두지 말라
 |
데드라인 톰 디마르코 지음, 김덕규, 류미경 옮김/인사이트 |
최근에 읽었던 책을 한권 소개하려고 합니다.
Tom DeMarco(톰 디마르코)가 쓴 데드라인이라는 책입니다.
프로젝트 관리와 관련해서도 몇몇 글에서 그 내용을 잠깐 인용하기도 했는데요~~
일단, 소설 형식을 띄고 있기 때문에 읽기가 편합니다.
내용도 그리 어렵지 않고.. 설명도 잘 되어 있습니다.
다만, 프로젝트 관리라는 점에 초점을 맞추기 위해서.. 소설 내용이 작위적이고 약간 개연성이 없다는 문제점이 있기는 합니다.
어차피 재미있는 소설책을 원한게 아니었으니 큰 문제는 없으리라 생각합니다.
그리고 각 장의 마지막 부분에 프로젝트 관리에서 중요한 내용을 다시 요약 정리해 놓은 부분이 있는데, 참고할 만한 자료인 것 같더라구요~
그래서.. 그 부분중 몇 가지를 올립니다.
모든 일에 있어서 변화는 필요하지만, 사람들이 쉽게 수용하지 않으므로, 변화를 받아들이도록 하기 위해서 어떤점을 고려해야 하는지 설명하는 부분입니다.
- 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
- 변화는 프로젝트를 성공시키기 위해서 (그리고 그많한 가치가 있는 대부분의 노력을 위해서도) 필수적이다.
- 안전성이 부족하면 사람들은 위험을 감수하려고 하지 않는다.
- 위험을 피하는 것은 치명적이다. 위험과 연관되어 있는 이점도 놓치기 때문이다.
- 사람들은 직접적으로 위협을 받거나 자신들에게 악용될지도 모르는 권력을 인지할 때 불안함을 느낄 수 있다.
관리자가 가져야 하는 필수적인 감각이라고 합니다. 지식보다는 감각이 중요하다고 보고 있네요~~
- 관리에는 마음과 본능과 정신 그리고 후각이 필요하다.
- 그러므로
마음으로 이끌고,
본능을 믿고(직감을 믿어라),
조직에 정신을 심어주고,
거짓말을 식별할 수 있는 후각을 키워라.
프로젝트를 관리하는 것은 프로젝트의 위험을 관리하는 것이라는 말.. 맞는 것 같아요^^
- 프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다.
- 각 프로젝트의 위험을 조사하고 관리한다.
- 궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다.
- 각 위험에 대한 발생 확률과 예상되는 소요 비용을 평가한다.
- 각 위험에 대해 위험이 구체화되는 것을 나타내는 초기 증상을 예방한다.
- 무엇이든지 '할 수 있다'는 자세를 갖고 일하지 않아도 되는 사람을 위험 담당자로 임명한다.
- 나쁜 소식이 조직의 계층구조 상위로 전달되는 데 용이한 (필요하다면 익명으로) 채널을 수립한다.
가끔 프로세스에 집중하다가 중요한 것을 놓치는 경우가 있습니다. 둘 사이의 균형이 중요하죠..
- 좋은 프로세스와 지속적으로 향상되는 프로세스는 모두 훌륭한 목표가 된다.
- 이들은 또한 매우 당연한 목표이기도 하다. 훌륭한 개발자들은 그렇게 하라고 말을 하든 안 하든 간에 여기에 초점을 맞춘다.
- 공식적인 프로세스 향상 추진 계획은 시간과 돈이 든다. 그러한 프로세스 향상 작업은 프로젝트 작업을 뒤쳐지게 할 것이다. 생산성 향상이 실현된다 하더라도 그 계획을 실행한 프로젝트가 프로세스 향상에 들인 시간을 상쇄하지는 못한다.
- 프로젝트에서 향상 방법을 하나만이라도 제대로 선정한다면 본전(그러한 변화에 투자한 시간과 비용)을 뽑을 수 있을 것이라고 생각한다.
- 프로젝트가 그 기간 동안 하나 이상의 향상 방법을 수용하기를 바라는 것은 무리다. 여러 가지 기술을 한번에 향상시키려는 계획(Multi-skill improvement programs)은 그 계획을 실행하지 않았을 때보다 프로젝트를 더 지연시킨다.
- 표준 프로세스는 사람들이 중요한 지름길로 갈 기회를 놓치게 할 위험성이 있다.
- 특히 인원이 과다하게 투입된 프로젝트의 경우 모든 사람들에게 돌아갈 만큼 일이 충분하지 않다면 문제가 발생하게 된다.
관리자가 화를 낸다는 점.. 직원이 무능하다기 보다는 관리자가 무능하다.. 느낌이 확 오는 것 같습니다.
- 관리에서 화와 모욕은 전염된다. 상급 관리자가 직원들을 학대하면 그 밑에 있는 관리자들도 그와 같은 행동을 따라한다.(학대받은 아이들이 학대하는 부모가 되는 것과 비슷하다.)휴.. 정리해 보려니.. 너무 길어질 듯 하네요~~
- 관리차원에서 모욕을 주는 일은 사람들이 자신의 능력에 좀더 투자하도록 만드는 자극제 역할을 해야 한다. 그것은 당근과 채찍 두 가지 관리법 중 가장 자주 사용되는 '채찍'인 것이다. 하지만 모욕이 능력을 더 발휘하도록 만든다는 증거가 어디에 있는가?
- 관리자가 직원들을 자극하기 위해 모욕을 주는 것은 직원이 무능하다기보다는 관리자가 무능하다는 표시다.
여기까지만 적으려고 합니다..
그럼.. 좋은 프로젝트 관리자 되세요!!!
'리뷰' 카테고리의 다른 글
| 초보자를 위한 PHP, MySQL, Apache (1) | 2007/09/21 |
|---|---|
| 실용주의 프로그래머를 위한 버전관리 - using CVS (0) | 2007/08/27 |
| 조엘 온 소프트웨어 - 유쾌한 오프라인 블로그 (2) | 2007/08/07 |
| Effective Java - 자바 유창하게 말하기 (0) | 2007/07/20 |
| 데드라인 (The Deadline) - 소설로 읽는 프로젝트 관리 (0) | 2007/07/12 |
| 구글 애드센스(Adsense) API.... (2) | 2007/07/06 |
프로젝트 관리에 대한 자료들을 참고하다보면.. 꼭 빠지지 않는 이야기가 있습니다.
여러분은 그것이 바로 무엇이라고 생각하나요?
간트차트(Gantt Chart)를 통한 일정관리 ??
CVS와 같은 프로그램을 이용한 소스관리 ??
PMP(Project Management Professional) 자격증을 통한 검증 ??
보통 가장 중요하게 이야기 하는 것은 바로 "인력관리"가 아닐까 생각합니다.
프로젝트라는 것도 어차피 사람이 하는 것이므로..
문제도 사람이 만들고, 해결도 사람이 하게 됩니다.
그러므로 문제를 만들고 해결할 수 있는 사람들을 관리하는 것이야말로
가장 중요한 프로젝트 관리가 아닐까 합니다.
그러나 여기에서 고려해야 하는 점은 바로 사람의 다양성을 인정해야 한다는 것입니다.
혹자의 글처럼 모든 개발자를 람보로 만들어야 한다는 생각은 매우 위험한 발상이라고 봅니다.
사람마다의 다양성이 있으므로 서로의 장점을 잘 찾아서 개발해 주는 것이 프로젝트 관리의 묘미가 아닐까 합니다.
솔직히 프로젝트 진행할 때,
개발자들을 3~4명만 두고 업무 분장을 해 봐도.. 개인적인 개발능력의 차이는 분명히 있습니다.
개발 능력이 떨어지는 것 처럼 보이는 A란 친구는 꼼꼼하게 모든 변수를 고려하는 면이 있고..
개발 스피드가 빠른 B란 친구는 눈앞의 문제만 해결하기도 합니다.
심지어 아무리 한심해 보이는 친구가 있어도.. 분명 그 친구가 잘하는 것이 있고~
그것을 이용해 프로젝트에 도움을 줄 수 있도록 만들 수 있는 것이 있을 것입니다.
이처럼 개발자들의 특성을 파악해 거기에 적합하도록 업무를 분배하고 관리하는 것이
프로젝트 성패의 중요한 요소인 것이지요..
A에게 스피드를.. B에게 꼼꼼함을 가르치려 한다면..
당장의 프로젝트에서는 좋은 결과를 기대할 수는 없겠죠~~
물론 서로의 장단점을 프로젝트 중간중간 미팅을 통해서 이야기 해주는 것은 좋죠^^
요즘 읽고 있는 "데드라인"이란 책에는 "훌륭한 관리를 위한 4가지 필수 요건"으로 다음과 같은 항목이 나옵니다.
1. 적절한 사람들을 구한다.
2. 그들에게 알맞은 일을 할당한다.
3. 항상 동기 부여를 한다.
4. 팀이 결속하도록 하고, 그 상태를 유지하도록 돕는다.
좋은 이야기인 것 같습니다. 실행하기 어려운 말이기도 하구요~~
마지막으로 ...
"믿지 못하면 맡기지 말고, 일단 맡겼으면 끝까지 믿어라"
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
깨진 창문 이론(Broken Window Theory)이라는 말이 있습니다.
'티핑 포인트'라는 책과 '실용주의 프로그래머'라는 책에서 인용되고 있는데요..
요약하면,
오랜기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 준다는 겁니다.
그래서 다른 창문이 하나 더 깨지고.. 낙서가 등장하고.. 심각한 구조적 손상이 시작되는 것이죠..
결국 건물 소유주가 고치려는 의지를 넘어설 정도로 건물이 손상되고, 버려진 느낌은 현실이 되어 버린다는 겁니다.
보다 자세한 내용은 다음 블로그들을 참고하시기 바랍니다.
http://www.nanael.net/48
http://blog.naver.com/chowyf?Redirect=Log&logNo=80034681435
'실용주의 프로그래머' 책에서는 실생활 뿐만 아니라 IT 프로젝트에서도 깨진 창문을 조심하라고 말하고 있습니다.
나쁜 설계, 잘못된 결정, 좋지 않은 코드를 눈에 뜨일 때마다 고치라는 것이죠~
흔히 프로젝트 초반에는 DB도 조금 변경하고, 로직도 변경하고.. 개발을 진행합니다.
하지만 어느정도 프로젝트가 진행이 되고 나면.. 고객의 요구사항이나 프로그램 구성상 변경이 발생할 때..
전체를 고치기 보다는 그 부분만 땜빵하듯이 고쳐나가는 경우가 있습니다.
DB를 수정하게 되면 너무 많은 부분을 손대야 하니 어쩔 수 없다고 말하면서~~
하지만, 점점 더 많은 변경을 적용하면서... 소스 코드는 더욱 지저분해지고.. DB도 누더기다 되어버리게 됩니다.
솔직히 지금까지는 이런 경우, 변명을 많이 했었습니다.
"고객이 생각지도 못한 요구사항을 추가한 것이다."
"초기에는 논의 되지 않았던 부분이다."
"데이터베이스를 변경할 수는 없으니 이런식의 꼼수 코딩은 정당하다."
하지만 최종적으로 유지보수도 어려운... 쉬레기 코드가 만들어지는 것이죠~
그렇다면, 실제 프로젝트에서 깨진 창문을 내버려 두지 않으려면 어떻게 해야 할까요?
일단, 프로젝트 팀원들의 마음가짐이 중요할 것 같습니다.
내가 먼저 창문을 깨어서는 안된다~ 는 각오가 필요할 것 같네요~
그리고 가장 중요한 것은 PM 혹은 PL의 역할이 아닐까 합니다.
외부의 변수에 의해 수정이 필요할 때, 전체적인 관점에서 고칠 것을 빠르게 결정하고 진행하는 것이 필요하지 않을까 합니다.
누군가 끊임없이 프로젝트를 관찰하고 있다면, 창문 하나가 깨지더라도 바로 복구할 수 있을 테니까요..
그러기 위해서는 소스코드에 대한 관리, 테스트에 대한 관리, 설계나 기획안에 대한 관리가 PM/PL에게 일정관리 이상으로 중요한 부분이 아닐까 합니다.
깨어진 소스.. 깨어진 설계를 찾아내야 하니까요~~
'프로젝트관리론 > 프로젝트지침' 카테고리의 다른 글
| 상습적인 야근을 자제하자~ (2) | 2007/07/10 |
|---|---|
| 소스를 모두 다 만들려고 하지 마라. (0) | 2007/06/12 |
| 소스코드 버전관리를 활용하라. (2) | 2007/06/01 |
| 프로토타입을 통해 학습하라. (0) | 2007/05/21 |
| 실패를 축하하라 (0) | 2007/05/19 |
| 깨진 창문을 내버려 두지 말라 (0) | 2007/05/17 |
