'프로젝트관리론/인력관리'에 해당되는 글 7건
- 2008/09/29 프로젝트 팀원 역할 어떻게 설정해야 할까요?
- 2007/12/11 변화해야 산다.
- 2007/08/31 프로그래머의 멀티플레이와 컨텍스트 스위치... (2)
- 2007/07/27 프로젝트 관리자의 의사소통 능력!~
- 2007/06/27 프로젝트 관리를 위한 필수 요건
- 2007/05/18 프로젝트 참여자들의 역할
- 2007/05/16 프로그래머?!?
프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다.
- 품질관리 - 범위관리 - 위기관리 - 통합관리
- 일정관리 - 원가관리 - 인력관리 - 의사결정 - 구매관리
모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다.
프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다.
물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다.
이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다.
가능성....
Project Management - A systems approach to Planning, Scheduling, and Controlling이란 책에 보면 프로젝트 관리자가 마주치게 되는 팀원들의 역할을 설명하고 있습니다.
즉, 협력적인 역할을 하는 사람도 있고 반면에 부정적인 역할을 하는 사람도 있다는 것이죠..
부정적인 팀원들의 역할을 방해하고 협력적인 팀원들의 역할을 극대화 시키는 것이 바로 프로젝트 관리자의 중요한 역할이라는 겁니다.
먼저 부정적인 가능성을 가진 팀원들의 성향을 살펴보죠..
| 침략자 | 팀원들을 비판하고 아이디어에 이의를 제기하며 자존심을 꺽는다. |
| 지배자 | 조정하고 (업무를) 인수받으려고 시도한다. |
| 악의 옹호자 | 모든 사물에서 결점을 찾아내고 모든 아이디어에 이의를 제기한다. |
| 문제에 대해 갈팡질팡 하는 팀원 | 아이디어 사이를 왔다 갔다 하며 초점을 맞출 수 없도록 불균형을 조장한다. |
| 인정을 받아내려는 팀원 | 항상 지위에 대해 논쟁하고 성공의 공로를 차지하려고 시도한다. |
| 탈퇴자 | 참여하지 않고 정보를 공개하지 않는다. |
| 방해자 | 계획이 진행되지 않는 것에 대해 여러 가지 이유를 댄다. |
이어서 협력적인 가능성을 가진 팀원들을 살펴보면 다음과 같습니다.
| 선창자 | 새로운 아이디어를 찾고 "한번 해보자"란 말을 사용한다. |
| 정보 탐색자 | 보다 정보로 무장하려고 노력하고 자원과 지원 데이터를 찾는다. 팀의 이익을 위한 연구를 한다. |
| 정보 제공자 | 자신이 알고 있는 것을 공유하여 팀의 지식을 증대시킨다. |
| 촉진자 | 다른 사람들의 아이디어에 대해 눈에 보이는 지원을 보여준다. |
| 분류자 | 모든 사람이 이슈나 의사결정 사항을 확실히 이해하도록 도와준다. |
| 조화자 | 팀 사이의 단결된 감정을 형성한다. |
| 문지기 | 모든 정보가 적절하고 팀이 당면하고 있는 이슈에 대해 집중하도록 보증한다. |
정리하면서 보니 역시 사람에게는 양면성이라는 것이 존재하는 듯 합니다.
저 역시 문제에 대해 갈팡질팡 하면서 동시에 정보 제공자로서의 역할을 하는 듯 합니다.
결국은 팀원들의 협력적인 가능성을 극대화시키고 부정적인 가능성을 최소화 시킬 수 있는 능력이 필요하다는 것이겠죠..
여러분은 어디에 속하는 팀원이라고 생각하나요?
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 프로젝트 팀원 역할 어떻게 설정해야 할까요? (0) | 2008/09/29 |
|---|---|
| 변화해야 산다. (0) | 2007/12/11 |
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
Trackback 0 And
Comment 0
개발자로서 살아가는 것은 정말 쉬운 일이 아닙니다.
왜냐하면 끊임없이 변해야만 하기 때문이니까요..
보통의 직업은 한번 익힌 기술을 가지고 어느정도는 평생 먹고 살수가 있습니다.
물론 그들도 끊임없이 자기 발전을 위해 노력하는 면은 있을 겁니다.
그러나 우리 개발자만큼은 아닐거라고 생각합니다.
끊임없이 나오는 새로운 용어와 기술들, 발전하는 하드웨어, 진보하는 플랫폼, 여기에 새로운 언어들까지..
새로운 것을 배워서 2~3년 써먹다 보면 어느덧 구석기 시대의 기술이 되어버리는 느낌이라고나 할까요?
변하기 위해서는 끊임없이 배워야 하지만,
의외로 개발자들은 변화에 익숙하지 않은 것 같습니다.
새로운 것을 받아들이는 것을 두려워하기보다는 귀찮아하는 면이 많은 것 같습니다.
지금 기술로도 충분한데.. 왜 그걸 써야 하는데?
하는 이야기를 많이 합니다.
하지만 2~3년이 지나면 어느덧 지금 기술은 옛날 기술이 되어 버리고..
그런 개발자들은 점점 도태되기 마련이라고 생각합니다.
추가적으로 개발자들에게 변화하는 기술만큼 중요한 또 하나의 요소는 바로 경험이라고 생각합니다.
그동안 프로젝트를 하면서 쌓아온 노하우는 다른 어떤 것과도 바꿀 수 없는 소중한 자산이니까요..
이 경험과 기술발전에 따른 변화의 조화가 이 시대의 개발자에게 요구하는 것이 아닐까 합니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 프로젝트 팀원 역할 어떻게 설정해야 할까요? (0) | 2008/09/29 |
|---|---|
| 변화해야 산다. (0) | 2007/12/11 |
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
Trackback 0 And
Comment 0
멀티플레이어..
월드컵에서 한국축구가 4강을 이루었던 2002년 많이 들었던 말 같습니다.
박지성으로 대표되는 멀티플레이어는 다양한 포지션을 소화할 수 있어야 경기의 운영이 수월해진다는 것이죠..
프로그래밍에서도 이런 멀티플레이어는 필요합니다.
하나의 언어, 하나의 플랫폼, 하나의 방법론만 고집해서는 문제를 해결할 수 없는 경우가 대다수죠..
그런데, 한편으로 축구의 멀티플레이어를 생각해 보죠..
아무리 박지성이 다양한 포지션을 소화한다고 해도, 90분 축구경기 도중 10분마다 혹은 5분마다 포지션을 변경하지는 않습니다.
즉, 90분 경기중 선수교체에 의해 한번이나 혹은 많아야 두번 정도 변화를 주는 것이죠..
다시말해 멀티플레이어란 다양한 환경을 다룰 수 있다는 것이지..
동시에 여러가지 프로젝트를 수행할 수 있다는 것을 의미하지는 않습니다.
(여기서 동시란 시분할 정도로 이해하시면 될 것 같습니다.)
그렇다면 왜 동시에 멀티플레이어가 어려울까요?
그것은 바로 Context Switch에 들어가는 추가비용 때문이지 않을까 합니다.
A 프로젝트를 수행하고 있는 도중에는 A 프로젝트에 생각으로 머리속이 꽉차 있게 되지요..
그러다가 B 프로젝트를 수행하려면 A 프로젝트의 고민과 노력을 버리고 다시 B 프로젝트에 대한 고민으로 머리를 채워야 합니다.
이러기 위해서는 시간이 필요하다는 겁니다.
경험적으로 볼때, 최소 2시간 ~ 4시간은 걸리는 것 같았습니다.
또, Context Switch 도중에 간간히 잡생각도 들어오구요~~
그렇다면, 어떤 방식으로 멀티플레이어를 지원하는 것이 바람직할까요?
최상의 방법은 한가지 과업만을 주는 것이지만, 현실적으로 어려움이 있는 경우가 많습니다.
그렇다면 여러가지 업무를 시간을 두고 변경하면서 처리할 수 있도록 하는 것이 차선책입니다.
즉, 1주일이나 2주일을 90분 경기로 보고 한번 정도 포지션 변경이 일어나게 해 주는 것이죠..
그래서 XP에서도 반복의 주기를 2주정도로 잡았는지도 모르겠습니다.
(경험적으로 하루마다 바꾸더라도 역시 비효율적이더라구요.. -.- 일주일 단위가 가장 바람직한 것 같아요..)
결론적으로 프로젝트관리자는 Context Switch에 발생하는 비용을 최소화할 수 있도록 일정을 조율하고..
각각의 팀원들은 꾸준한 학습을 통해 스스로 멀티플레이어가 될 수 있도록 항시 몸을 만드는 것이 중요하지 않을까 합니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 프로젝트 팀원 역할 어떻게 설정해야 할까요? (0) | 2008/09/29 |
|---|---|
| 변화해야 산다. (0) | 2007/12/11 |
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
Trackback 0 And
Comment 2
프로젝트 관리자에게 중요한 능력중의 하나가 바로 의사소통 능력이라고 생각합니다.
개발자들, 디자이너들, 영업팀, 고객, 그리고 회사 책임자들까지~~
모두들 생각하고 원하는 바가 다름에도 불구하고, 서로를 이해하려는 부분이 약한 것이 사실입니다.
이것을 프로젝트 관리자 즉 PM이 해결해 주어야 한다고 생각합니다.
고객이 원하는 시스템을 파악하고,
개발자들이 원하는 형태로 설명해 주고,
디자이너와의 마찰을 줄여주고,
영업팀이 더 많은 프로젝트를 수주할 수 있도록 파워포인트의 기술 자료를 보완해주고,
회사 책임자에게 프로젝트 진행 상황과 위기관리에 대해 보고해야 하는...
정말 다양한 부류의 사람들과 의사소통할 수 있는 능력~~
그래서 흔히 PM을 개발자들 중 최고의 프로그래머에게 맡기는 것은...
프로젝트가 실패로 돌아가는 지름길이라고들 합니다.
최고의 프로그래머일수록 조용한 자기만의 공간에서 다른 사람의 방해를 받지 않고 작업하기를 좋아하니까요..
또한 자신의 개발자적인 언어로 다른 사람들에게 이야기 하려는 경향이 많으니까요.
오히려 팀 내에서 가장 빨빨거리고 이야기 잘하는 친구를 PM으로 삼는 것이 더 낳지 않을까 하네요~~
다음 이야기를 참고해보시기 바랍니다.
프로젝트 관리자는 소프트웨어에 대한 지식이라고는 델타 항공 기지내에서 읽은 내용이 전부인 양 뻐기는 선임 부사장이 던진
"도대체 오라클 대신 자바를 사용하지 않는 이유가 무엇인가?
들리는 소문에 따르면 자바가 좀더 통합적이라고 하던데?"
와 같은 황당무계한 질문을 처리해야 합니다.
조엘 온 소프트웨어에 나온 이야기 입니다만, 이런 경험 혹시 해본 적 있나요?
(저는 이걸 읽으면서 잠깐 웃음이 터져 나왔었다는...)
의사소통의 중요한 요소는 다른 사람의 이야기를 경청해주는 거라고 합니다.
뛰어난 의사소통 능력을 바탕으로 팀 융합을 이끌어 내는 훌륭한 프로젝트 관리자가 되시기 바랍니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
Trackback 0 And
Comment 0
프로젝트 관리에 대한 자료들을 참고하다보면.. 꼭 빠지지 않는 이야기가 있습니다.
여러분은 그것이 바로 무엇이라고 생각하나요?
간트차트(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 |
Trackback 0 And
Comment 0
프로젝트를 수행하다보면 많은 사람들이 참여하게 됩니다.
기획자, 개발자, 디자이너, PM, PL…
어느 하나 중요하지 않은 것이 없다고 생각합니다.
톱니바퀴가 물려 돌아가듯이 서로 협력하고 앞으로 나아갈 때만 좋은 결과가 나오지 않을까 하네요~~
그런 의미에서 얼마전 블로고스피어에 나온 글들을 나열해 봅니다.
Linus님의 개발자와 기획자 상생의 길
본인의 경험에 따라 개발자와 기획자 사이의 의사소통 해결부분에
대해서 이야기하고 있습니다.
기획하시는 분들이 아주 좋아할 만한 스타일의 개발자라는 생각이 드네요~~
개발자와 기획자가 서로 이해하지 못하는 이유에 대해서 적어놓고 있습니다.
서로간의 조금씩 양보하고 서로의 입장이 되어준다면 이정도 문제는 해결해 나갈 수 있을거라 생각합니다.
이제 다 큰 어른들이니까요.. ^^
마지막으로 ENTClic님의 프로그래머와 유치원생 입니다.
훌륭한 개발자가 되기위해서는 어릴 때 유치원에서 배웠던 대로 하면 된다는 이야기네요~
원문을 All I Need To Know To Be A Better Programmer I Learned In Kindergarten을 번역한 것입니다.
이번 주는 간단히 블로그 글을 토대로 정리해봤습니다.
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
Trackback 0 And
Comment 0
마틴파울러는 이렇게 말했습니다.
컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.
워드 커닝햄은 다음과 같이 이야기했습니다.
저는 작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다. 누군가가 똑같거나 혹은 더 나은 걸 이미 만들었다는 데에 절대 신경쓰지 마세요. 유용성과 복잡성 간의 균형 감각을 얻기 위해서는 당신 자신이 만든 프로그램의 유용성을 직접 느껴봐야만 합니다.
둘 다 매우 감동적인 이야기입니다. 정말 부럽기도 하구요~~
그러나 IT 개발자의 현실은 그렇게 여유롭지만은 못한 것 같습니다.
몇주전 블로고스피어에 올라왔던 아메바님의 그림일기를 보면 아주 적나라하죠.. ^^
이런 현실을 벗어나 즐겁게 일하면서 사람이 이해할 수 있는 코드를 만드는 방법을 함께 고민해 보도록 하겠습니다.
그래서 모두 불쌍한 개발자가 아닌 생명력이 있는 프로그램을 만드는 창조자가 되시기 바라겠습니다. ^^
# 참고할 만한 글:
김창준님의 “프로그래머의 위기지학”
신영진님의 “Why Programming is Fun“
미니님의 “Refactoring - 마틴파울러“
'프로젝트관리론 > 인력관리' 카테고리의 다른 글
| 변화해야 산다. (0) | 2007/12/11 |
|---|---|
| 프로그래머의 멀티플레이와 컨텍스트 스위치... (2) | 2007/08/31 |
| 프로젝트 관리자의 의사소통 능력!~ (0) | 2007/07/27 |
| 프로젝트 관리를 위한 필수 요건 (0) | 2007/06/27 |
| 프로젝트 참여자들의 역할 (0) | 2007/05/18 |
| 프로그래머?!? (0) | 2007/05/16 |
Trackback 0 And
Comment 0
