PM의 역활에 따른 좋은글

아래 내용은 http://www.okjsp.net/seq/246260 에 올려진 글을 옮긴글입니다.

글을 올리신분에 글을 읽다가 닮고싶은 모습이다라는 생각이 들어 글을 옮기게 되었습니다.

각 개개인에 따라 다르기도 하겠지만 좋은 모습은 많이 닮아갔으면 하는 바램입니다.

제가 PM할때 요약해서 도움이 될까하여 간략히 적어 봅니다.

1. 팀원들 개인 프로필 숙지(거의 달달 외워요)
- 거취형태 (자취, 자가, 고향은 어디인지)
- 가족관계 (가족중 건강상에 문제가 있다던가 자녀중에 질병이나 선천 질환이 있는지)
* 가족이 아프면 일에 집중이 안돼니 필요할때 병원에 다녀오라 합니다.
- 생일 : 생일전날이나 당일날 하청업체 직원이라도 무조건 휴가 하루 줍니다.
- 이전에 일했던 장점이 뭐였는지. 성격. 성향이 어떠한지. 관심사. 취미가 뭐인지
* 팀웍에 도움이 됩니다.

2. 개인 건강상태는 늘상 관심사로 ^^
- 건강과 체력이 되어야 공부도 잘하듯 일도 능률이 있잖아요.
- 여직원의 경우 생리주기는 체크해 둡니다. 
* 서랍에 쌍화탕 1박스, 생리통약 1통, 피로회복제 1통은 개인비용으로 구입해 놓고
조용히 책상위에 놓아 줍니다. 너무 힘들어 하면 눈치보지 말고 조퇴하라고 조치하구요.

3. 일에 성과에 대한 보상을 잘해줘야 합니다.
- 일잘하는 사람에게 일을 뭉텅이로 던져주는 일을 절대 하지 말자(병죽고 약주고)
- 성과가 좋으면 칭찬해 주고 교양도서 1권씩 사다 줍니다.
* 일에 진척이 월등히 좋으면 다른 팀원이 벅차할 수 있으니 잘하는 사람은 쉬엄 쉬엄하라고
책 읽고 팀원들한테 tea 타임때 이야기 해주라 합니다. 
- 성과가 좋은 사람은 적절한 휴가를 주거나 업무시간에 관련 전문 서적 공부를 추천 합니다.
* 일만 하는 기계로 생각들지 않도록 도움을 주는 차원 입니다.

4. 상하 수직관계 파괴. 수평구조의 인식과 어울림 참여의식 고취 시키기
- 수직관계는 일하는데 아무런 도움이 되지 않습니다.(갈등을 많이 조장하고 뒷담화가 많아요)
- 수평관계를 계속해서 리더가 이야기 하면 점점 변화 합니다. 
* 명령식의 하달 업무가 아닌 협업과 회의를 통해서 오해가 없고 뒷말이 없으니 기분 상할
일이 줄어 듭니다.

5. 평상시엔 유하고 여유롭게 잘못된것은 확실하게
- PM이 조급증에 시달리고 팀원을 닥달하면 모두가 불안해 합니다. 일정이 조급해도
여유로운 표정을 지어야 팀원이 맘편히 일합니다. (적벽대전 최후의 조조처럼요(?) )
- 오히려 바쁠때 사무실 돌면서 한명씩 손잡고 나가서 스타벅스 갑니다.
* 강제적인 쉼은 여러모로 보약이 되구요. 일하는데 어려운 점이 개인사 이야기 합니다.

- 업무시간에 웹서핑을 지나치게 하거나 근태가 심각하거나 일을 아니하게 하는 태도가
보이면 가차 없습니다.
* 정규 업무시간에 바둑을 두고 게임하는 팀원에게 2차례 경고 했지만 고쳐지지 않아
3번째 경고하는 날 인수인계 없이 바로 퇴출 조치 시켰습니다. 

6. 팀원간의 소통이 가장 중요.
- PM은 전체 팀원들에게 그리고 PL에게 이 프로젝트가 어떤 시스템이고 현재 진행상태가
어떠하고 고객의 성향과 그들의 의중이 이러하다. 프로젝트 흘러가는 분위기 등의 전반
적인 이야기 우리가 목표하는것을 계속해서 공감 시켜 줍니다.
* 확실히 참여도와 적극성이 눈에 띄게 달라 집니다.
- 아침 출근시 tea time 30분은 필수
* 허겁지겁 잠도 안깬 눈으로 모니터 키고 일이 되나요? 30분간 오늘 할일 review 하구요.
어제 오늘 시사/뉴스 거리도 이야기하고 화이팅 외치고 중요한 사항 전달 합니다.


7. 늘 공부 하도록 독려 합니다. (초반에는 업무 강의를 제가 직접 해줍니다.)
- 일만하는 기계가 아닌 프로젝트에서 소득을 얻어 가라고 지속적으로 전달 합니다.
* 담당 업무 모듈에 대한 깊이 있는 이해 - 10년이 지나도 술술 나올 수 있는 지식
* 그래야, 어디가서든 이 모듈 좀 해봤다 명함 내밀고 PL이 되어서도 설계에 어려움
겪지 않고 진정한 전문가가 된다. 난 코딩만 잘하면 장땡이고 잘만 돌아가면 된다는 
사람은 난 원치 않는다라고 말해 줍니다.

8. 스케쥴링 미리미리 챙기기
- 개발 진행상 앞뒤 선행관계를 잘 알아야 합니다.
* 서버는 구비 되었지만 WAS,DB,연계,UI툴 교육,레포팅툴교육 등 순서가 미리미리
준비 되지 않아 개발파트가 대기상태에 있는것은 전적으로 PM 잘못입니다.
- 뭘먼저 챙겨야 팀웍에 좋고 일을 효율적으로 할 수 있는지 매일매일 고민 해야 합니다.
* 예) 개발이 한 참 진행중에 Meta , 용어 정리를 시킵니다. 그제서야 화면 UI, 변수명
뜯어 고치는데 1주일 잡아 먹습니다. 

9. 개발자는 배우자 처럼 신중하게 뽑자.
- 싫으나 좋으나 정해진 기간 성공 프로젝트를 위해 함께할 팀원 입니다. 5-10분 인터뷰로
결정하기 힘들지요.
* 보통 저는 1인당 1시간씩 잡고 인터뷰 합니다. 가족관계, 자라온 성장 환경, 학교,
전공, 취미, 꿈이 뭔지, 주말 여가 생활, 친구, 로또에 당첨된다면~ , PM에게 바라는 점
개인의 성격, 건강 문제, 가정환경, 프로젝트 경험 등등
- 저는 인터뷰시 가장 중요시 생각하는게 사람의 성향과 열정을 먼저 보고 그 다음 주관을
보고 마지막으로 스킬을 봅니다. 
* 기술적 문제는 TA, AA가 대부분 해결해 주고 안되면 외부에서 도움을 받습니다.

10. PM는 전체를 보는 관점과 고객 - 수행 팀원들간의 가교 역할이 성패를 가릅니다.
- 고객사에겐 모든 기능 다 해 주겠다 큰소리치고 팀원들은 야근/철야/주말 아우성 치는데
아랑곳 하지 않는다면 이게 정말 PM이 능력 있다 할까요? 협상 능력 부재이겠지요.
- 팀원의 시간적 자원의 문제 있어 한계가 느껴진다면 반대로 고객을 설득해야겠지요.
- 당근과 채찍.
- 고객과 팀원이 직접 대면하는 일은 많지 않습니다(SI 라면요) 중간 소통 역할이 중요한거죠.

마지막으로

11. 시스템은 성공이여도 팀원 생활이 불행했다면 실패한 프로젝트다.
- 극히 주관적이고 개인적인 내용입니다.
- 고객에겐 칭찬 받고 박수 받았어도 팀원은 가정이 파탄날 지경이 되고 애인과 불화가
생기고 이별했다면 이게 과연 사람을 이롭게 하는 시스템입니까? 반문해 봅니다.
- 다같이 잘살아야 한다는 관점에서 시스템을 사용할 사람도 만든 사람도 행복해야
정말 좋은 품질의 시스템이 아닌가 싶습니다.
- 숭례문 단기 완공과 정치적 밀어 붙임이 나은 사례
* 단납, 전통기법, 대목장의 의견은 말살되고 좋은 품질은 없던거죠. 
참여했던 목수들 맘도 편하지 않고 모든 국민이 숭례문 바라볼때 마다 불행 합니다.

PM 교육을 받으러 가면 PMP 내용 일부와 대부분 원가계산, 구매(하청인건비), WBS관리등을
집중 교육 받습니다. 이런건 조금만 공부하면 익혀 지는거구요. 위 사항은 제가 수습-개발자
-모델링-PL-사업관리-품질-PM 을 역임하면서 이렇게 꼭 좀 해보고 싶어서 늘 고민하고
팀원들 반응도 좋아서 실천한 내용을 중점적으로 몇가지 요약해 본 내용이구요.
아주 가끔이지만 강의 요청 받으면 이런 내용 위주로 강의 하는 사항 입니다.