제목 : 직장상사와의 마찰의 원만한 해결방법은 없을까요..
글쓴이: 손님(guest) 2006/12/06 09:41:48 조회수:4258 줄수:26 |
|
사람이란게 자신의 입장에서 자기가 보고자하는 것만 보기에 저의 편협한 생각과 제 기준으로
작성된글이란걸 참고해서 읽어주셨으면 합니다.
정말 참다참다 사람이 싫어서 회사를 옮겨야하나.. 이런생각을 하고 있습니다.
정말 기분같아선 현재 진행중인 프로젝트 어찌되든 난 일못하겠다고 BJR하고 싶은 심정입니다.
직장상사가 몹시 갈군다던가 뭐 그러는 문제는 아닙니다.
뭐 하루종일 지켜본건 아니지만 진나가다 화면을 보면 항상 웹서핑중입니다.
PM이 아무리 코딩을 잘 안한다지만(전체 플젝에서 보면 PL도 안됩니다.) 코딩에선 완전 손을 땐 상태입니다.
그건 이해하더라도, 설계, 문서작업까지 안합니다. 다 떠넘기다 시피 합니다.
그런데 더욱 열받는건 팀원은 야근하는데 항상 일찍 퇴근합니다. 한달에 한두번 야근하는거 같네요.
이걸 정말 사이 이상해지더라도 본사에 찔러야하나 싶습니다.
원만하게 잘 해결하고 싶은데 말이죠..
뭔가 일을 마치고 완료 보고해도 어떻게 했나 점검도 제대로 안하고.. 나중에 뒷북치고..
뭔가 요청해도 듣고 무시고.. 나중에 문제되면 오히려 뭐라고 그러고...ㅡ_ㅡ;;
아..선배님들 좋은 방법 없을까요..
|
제목 : Re: 오히려 좋은거 아닌가요?
글쓴이: 손님(guest) 2006/12/06 15:21:21 조회수:915 줄수:4 |
|
성공론을 읽어 보면 자기 일을 떠넘기는건 권한을 넘기는겁니다.
전 권한을 넘겨주는 윗사람 덕에 전 그 만큼 노력을 짜내서 더 발전을 했거든요.
그 덕에 그렇게 프로젝트를 거듭하며 지금은 나이도 어린데 상당히 중요한 임무를 맡으며
그 정도 대우를 받고 일하고 있답니다.
|
제목 : Re: 음..
글쓴이: 손님(guest) 2006/12/06 20:37:15 조회수:836 줄수:20 |
|
pm이나 개발자나 보는 view나 역할자체가 다릅니다.
pm이 코딩하고 쿼리짜고 하면 그 PM이 오히려 이상한거죠.
사업관리나 품질, 고객사, PMO조직들하고 원만한 관계를 조정하고,
이슈될것을 전체적으로 한번 잡아주고, 중요한 결정 바로바로 해주고,
사기 북돋와주고 긍정적인 자세로 프로젝트에 임해야 하는게 PM이죠.
저녁되면 술한잔에 이슈한건 덜어내고 완화시키는게 pm의 롤이죠.
같이 밤늦게까지 남아서 코딩하고 쿼리짜고,
잘디잘은 회의란 회의 다 참석하고 밤늦게까지
누가 가나 감시하고,. 그런 pm이 오히려 이상한겁니다.
|
제목 : Re: 상대적인거죠.
글쓴이: 손님(guest) 2006/12/07 00:39:56 조회수:869 줄수:21 |
|
원글 작성자입니다.
저도 개발자, 코더, PM의 역할을 모르고 있는것은 아닙니다.
PM이 개발을 안한다고 불만인게 아니란 말이죠.
제가 감정적으로 적어서 좀 잘못 전달된것 같네요.
PM이라면 현재 진행되는 프로젝트를 어떻게해야 성공적으로 수행할 수 있을까를 고민하고
일정이 지연되고 있다면 이를 극복하기 위해 고민하고 노력해야 한다고 생각합니다.
프로젝트에 대한 책임감이 있어야 하는데, 그런걸 전혀 못느끼겠다는게 문제죠.
상황을 자세히 적지는 못하겠지만, 그렇다는 겁니다.
제가 너무 어린 푸념성 글을 적은거 같아 좀 부끄럽네요.
프로젝트는 잘 안풀려서 스트레스 받는데 정작 PM(제 입장에서의 PM은 총 2~3명정도의 팀의 책임자를 뜻합니다.)
은 천하태평에 협의, 설계, 문서, 개발 전부하게 하면서 놀고 있는 모습을 보니 꼭지가 돌아서..^^;
혹시 저같은 상황을 겪었던 분들은 어떻게 대처하셨었는지 궁금해서 글을 작성했었습니다.
|
제목 : Re: 그게 말입니다..
글쓴이: 손님(guest) 2006/12/08 10:19:04 조회수:820 줄수:49 |
|
PM이라고 해서 대규모의 프로젝트를 진행하는 줄 알았습니다.
고작 2,3명의 팀의 책임자라고 한다면 .. PM이라는 이름이 어색할 정도군요.
시스템 개발 과정은 '개발 프로세스'와 '관리 프로세스'가 있습니다.
대규모의 경우에는 각각의 PM이 따로 있는 경우가 많고 중간규모의 프로젝트에서는 같은 PM이
개발과 관리를 맡는 경우가 많고 이번 경우와 같이 초소형의 프로젝트에서는 '관리' 라고 하는
프로세스가 아예 없습니다.
즉, PM 포함 전 구성원이 개발에 투입되어야 한다는 말이지요.
일반적으로 그렇다는 말씀입니다.
글쓰신 분이 업무 지시를 받아서 정해진 양을 코딩하는 입장이라면 맡은 업무만 하시면 되고
PL에 해당하는, 그러니까 통상 총대를 지고 있는 입장이라면 이번 프로젝트만 무사히 넘어
가도록 PM을 무시하고 진행하는 수 밖에 없습니다.
다음 프로젝트에서는 이 문제의 PM 은 기필코 피하는 수밖에 없죠.
위에 어떤 분이 보니까 책의 내용을 인용하셨는데.. 중요하다고 느낀 부분이 사람마다 다른
모양입니다.
제가 좋아하는 부분은,
'정말로 훌륭한 설계자 , Architect라면 자신의 설계를 구현으로 확인하는 사람이다'
입니다.
PM이 전체를 관장하는 사람이라는 의미는 맞지만 공무원처럼 무사안일주의로 '관리'라는 명확치않는
일을 하라는 말은 아닙니다.
개인적으로 10명이하의 프로젝트에서는 PM은 Core를 설계하는 그 집단의 최고수준의 인물
이 맡아야 합니다.
관리? 이건 50명 이상 넘어가는 프로젝트에서 고려해야 할 사항입니다.
안타갑게도 사회 초년의 개발자중에 PM == 관리자 라는 공식을 너무나 당연하게 받아들이는
것 같아 우려가 됩니다.
더 우려가 되는건 이와 같은 PM이 주위에 너무나 많다는 것이죠..
어떡하겠습니까? 이 바닥 절반 이상이 이런 NATO (No Action Talk Only) 인것을..
프로젝트의 완료가 최우선입니다. 참고바랍니다.
P.S.
PM 이 코딩하고 쿼리 만드는게 왜 이상하다는 것인지 모르겠네요..
최고의 로직과 쿼리가 나올 수 있는데 이것이 비정상이라면 참으로 웃긴 현상입니다.
이거.. 어쩌다가 이런 논리가 대세가 되었는지 안타깝습니다.
자신들의 손에 들린 바이블 같은 책들의 저자들, 이른바 대가들은 모조리 지금도 코딩한다는 사실을 알고나 하는 소리인지..
|
제목 : Re: 좀더 생각해 본다면..
글쓴이: 손님(guest) 2006/12/08 13:27:11 조회수:903 줄수:97 |
|
이 글만을 놓고 본다면 여러가지의 상황들이 떠오르게 되네요.
단순하게, 자신이 보아왔던 형태의 모습으로만 생각하는건 문제가 있다고 생각이 듭니다.
PM이 코딩하느것이 났다고 생각하는 분들도 계시고 , 왜 PM이 코딩을 해야 하는가라고
생각하시는 분들도 있는것 같네요.
그런데 좀더 원론적으로 생각해 본다면 PM의 역활에 대한 정의가 계속해서 변해가고
시대에 따라서 요구하는 PM의 위치와 해야할 영역도 변경되어져 가는 이러한 상황에서
명확히 정의된 PM의 롤은 없는것 같습니다.
원질문자의 글만 보고서는, 그 프로젝트의 성향, 그 소속된 사람들의 암묵적으로 정해진
롤과 진행되어져 가고 있는 상황등을 파악할 수 없기에 정확한 대답을 내릴수는
없지만 일반적인 저의 생각속의 상황에 비추어 이야기를 해볼까 합니다.
PM의 역활의 가장 중요한것은 (프로젝트의 인원,규모등을 떠나서) 리더라고 생각합니다.
PM의 존재 이유 자체가 프로젝트의 매니저라는 것은 누구나도 다 알수 있는 사실이죠.
그렇기에, PM은 책임감을 가지고 프로젝트를 효율적으로 기간내에 완성하는것이
가장 주된 목적이겠지요.
정말 단순하게 세줄로 적은 글이지만 저 글에는 수많은 할일들과, 책임등이 담겨져
있다고 생각합니다.
그리고 PM밑의 PL, 팀원들의 가장 중요한 역활은 PM의 지시를 잘 따르고 PM의 의사결정에
도움이 되도록 하는 적극적인 마인드의 자세라고 생각합니다.
이 말또한 두줄이지만 굉장히 많은 의미를 내포하고 있지요.
이 두가지의 요점을 놓고 본다면 서로 매칭되는것은 한가지 밖에 없습니다.
즉 PM과 팀원들간의 의사 소통이라는 거지요.
그 둘간의 의사 소통에 문제가 없다면 이러한 논쟁 자체가 없을테니까요.
근데 의사 소통의 문제는 완전히 없앨수가 없는 상황이고요.
ㅎㅎ 난감하네요? ^^
하지만 해결 방법은 있습니다.!
박수는 두손이 쳐야 소리가 난다고 하잖습니까? ^^
한쪽이 문제라면 본인이 그것을 받아 들이는 방향으로 해보세요.
문제 제시도 좋지만, 그것보다 중요한것은 그 문제를 효과적으로 풀어가면서
방향을 잡아가는 것일 테니까요. 그냥 PM이 해야 할 일이라고 방관하시지 마시고
그러한 부분들 까지도 질문자님이 바꾸실수 있도록 지속적인 대화와 방향을 정립해
나갈수 있다면 더욱 많은 능력을 소유한 사람으로 평가 받지 않을까요 ^^
위와 같이만 할 수 있다면 어떠한 상황(컴퓨터 분야를 떠나서도)에서도 정말 필요한 인재가
되지 않을까 하네요.
더 많은 이야기들을 하고 싶지만 업무중이라 그러지 못함이 아쉽네요^^
혹 글중에 실례를 범한 것이 있다면 넓은 아량으로 용서해 주시기를 바라겠습니다.
즐거운 하루들 되세요!
|
제목 : Re: 재밌는 사진이 있어 한장 올립니다.
글쓴이: 손님(guest) 2006/12/12 19:52:36 조회수:2644 줄수:4 |
|
어디서 퍼온건데 이 사진 보고 웃음이 피식 나더라고요.
제목은 teamwork 이라는군요!
 teamwork.jpg (167534 Bytes)
|
제목 : Re: 책임은 PM의 일
글쓴이: 손님(guest) 2006/12/13 16:05:18 조회수:891 줄수:15 |
|
[뭔가 요청해도 듣고 무시고.. 나중에 문제되면 오히려 뭐라고 그러고...ㅡ_ㅡ;;]
위부분 정말 문제라고 생각합니다.
그분이 해야 할 부분들은 못하고 계신거 같네요.
어떻해서든지 책임을 그 PM한테 넘기셔야 할 꺼 같은데요.
프로젝트 망해도 글쓴님이 잘못하신건 없잖아요.
스트레스를 어느 정도 줘야 감당하져.
그런 사람하고는 두번 일하긴 어렵죠.
it업종이 아닌 다른 기업이어서 어쩔수 없이 그런 사람하고 10년 이상
일하는 사람들 보면 존경스럽더군요.
다른 이들과 한 회사에서 일하려면 나를 버려야 하는가..--;;
근데 BJR이 멀까???...
|
제목 : Re: 추가로...
글쓴이: 손님(guest) 2006/12/13 16:08:18 조회수:725 줄수:2 |
|
프로젝트 매니저 교육이 있는 걸로 알고 있는데요..(자격증도 있지 않나요?)
PM분! 이런거 교육 좀 받으셔야겠네요..
|
제목 : Re: BJR은 배째라입니다.
글쓴이: 손님(guest) 2006/12/13 17:08:19 조회수:823 줄수:3 |
|
유용하면서도 잘못된 정보도 많이 알려주는 네박사에게 물어보니 바로 답이 나오네요.
|
|
