내가 PM이 될 상(像) 인가?
프로젝트가 진행될 때, 이상하게 업무가 계속 늘어난 적 있나요?
팀에서 결정한 기능과 정책이 갑자기 수정되거나 사라진 적 있나요?
업무가 늘고, 정책이 바뀌는 상황을 결정하는 사람이 한 사람인 걸 알고 있나요?
그는 바로 고객이 아닌 PM(Project Manager)이에요.
PM은 프로젝트의 총괄 책임자예요.
프로젝트를 관리하고 이와 관련된 상황을 파악하고 프로젝트를 완료하는 걸 목표로 해요.
프로젝트를 관리한다는 건 단순히 일정 관리를 말하는 게 아니에요.
PM은 전체 일정뿐만 아니라 월간, 주간 일정도 조율하고, 인력 관리, 사업 관리 등 프로젝트 전체를 통솔하고 이끄는 사람이에요.
PM은 각 팀의 팀장(PL)과 의견을 나누며 프로젝트 내에서 발생하는 모든 이슈를 파악하고 해결 방안을 모색하죠.
무엇보다 가장 중요한 업무는 고객 응대, 고객과의 소통이에요. 이 능력이 부족한 PM을 만나면, 프로젝트는 완료할 때까지 야근을 면치 못해요.
PM이 누구냐에 따라 적게는 수십 명, 많게는 수백 명이 천국과 지옥을 경험할 수 있다는 거죠.
PM의 업무 중 인력 관리가 있어요. 아시다시피 대부분의 프로젝트는 여러 회사에서 투입된 여러 명의 개발자로 구성되죠.
여기서 중요한 게 여러 회사와 여러 명이에요. 서로 모르는 상태에서 하나의 프로젝트를 위해 모인 불특정 다수를 규합하고 이끌어 나간다는 게 보통 일이 아니에요.
프로젝트 참여 인원 중에 지각이 잦은 개발자가 있다고 가정해 보죠.
그(녀)로 인해 팀 분위기가 흐려지고, 팀원이 함께 일하기를 꺼려 하는 상황까지 왔다면, PM은 팀과 프로젝트를 위해 그(녀)의 거취를 결정해야 해요.
PM이나 PL을 경험하지 못한 사람이라면, 당연히 그(녀)를 프로젝트에서 빼야 한다고 하겠죠. 하지만, 그렇게 간단한 문제가 아니에요.
PM이 그(녀)의 회사에 인력 변경을 요청하면, 그(녀)는 아마도 회사로 돌아갈 거예요.
문제는 근태나 개발 역량 이슈로 본사로 복귀하면, 정확히는 쫓겨나면, 인사 평가에 치명적이라는 거예요.
PM도 이런 부분을 알고 있기 때문에, 정말 심각한 상황이 아니라면 최대한 함께 프로젝트를 마무리하려고 하죠.
보통 경험이 풍부한 PM은 회사에 무언가를 요청하기 전에, 파견 나온 팀의 관리자 또는 시니어 개발자와 먼저 얘기를 해요.
PM의 의도를 파악한 그는 근태 이슈를 본사에 알리지 않아요. 대신 파견 나온 팀원과 내부적으로 논의해서 해결하려고 하죠.
PM은 어느 프로젝트에서나 존재하고, 프로젝트 시작부터 완료할 때까지 크고 작은 문제를 해결해야 해요.
해결사 역할을 하다 보니, 어떤 이에게는 편한 선배 같지만, 어떤 이에게는 거리를 두는 차가운 아저씨로 보일 때도 많죠.
하나만 알아두세요. 경력이 쌓일수록 개발과 관리의 업무 비율이 달라져요. 이 말은 언젠가 후배님도 PM이 될 수 있다는 거죠.
PM의 역할에 대해 한 번쯤 생각해 보세요.
막강한 권한을 추구하고 관리 업무가 성향에 맞는다면, 좀 더 빠르게 PM으로 성장하는 것도 좋은 선택지예요.
취업, 이직, 퇴사, 커리어 고민으로 힘든가요?
Notices를 확인하고 상담 서비스를 받아보세요.
1분만 투자하세요.
1분으로 1년을 아끼고, 10년의 커리어가 달라져요.