[SSUL] SI 신입개발자로 살아남기 (19)

사탄도 아.. 이건 좀.. 하는게 PM임.

 

오늘은 한 사례를 주워듣고와서 아 이거 소재로 써야겠다. 라는 생각이 들어 왔다. 어떤 PM을 만나면 당장 탈출해야하는지 이야기를 한번 해보려고 한다. 이전에 PM 욕을 한바가지 써놓은 적이 있긴한데, 오늘은 "절대 탈출해야만 하는 PM" 으로 이야기하려고 함. 

 

뭐 썰을 풀자면 모 PM 한 명이 일정관리, 인원관리, 진척도관리 등 걍 모든게 똑바로 되지가 않아서 개발자들이 삽질 + 철야 + 매일 야근 + 매주 주말출근 까지 하는 놀라운 프로젝트였다. 뭐 심지어 팀원들 사이에 갈등 조장 + 팀원 중 한 명과 감정적인 마찰 + 중간 리더 견디다 못해 퇴사, 하지만 돈을 벌어야하니 있는 애들 갈궈서 어떻게든 결과물 제출 이런 식으로 최악의 결과물을 낳으신 대단한 PM이시던데.. 디테일하게 한번 얘기해보자. 

 

1. 기본적인 일정 관리가 안되면 그냥 도망쳐라. 할 가치가 없다.

이거 상당히 중요한 건데, 뭐 그냥 일이 좀 밀리고 초반엔 한가했는데 막판에 바쁘다고 일정관리가 안된다고 볼 순 없다. 내가 얘기하는 건 "기본적인" 이 워딩이 중요한거임. 예를 들어서, 테스트일정이 다음달이다. 그러면 더 이상 큰 요구사항들은 수용하지 않아야하는 것이 맞다. 고객이 뭐 지랄맞든 어떻든 다음 달에 테스트하고 안되는거 디버깅 해야하는데 새로운 요구사항 들고 와서 담주까지 해야해? 할 수 있지? 이 소리... 진짜 손에 칼만 쥐고 있었으면 바로 찌르는거 가능하다.

 

왜 이게 안되냐면, PM들은 일단 기본적으로 전체 프로젝트를 보는 사람이지 이게 구현이 되냐 어떠냐는 개발자가 판단하는 거다. 근데 PM들이 개발자들한테 물어보지 않고 대부분 지들이 PM전엔 개발자였으니 걍 된다고 OK 맨이 되어버리는 경우가 있다. 이게 정말 문제가 되는거다. 예를 들어, 대부분 PM하는 애들은 전자정부프레임워크 이딴거 찌끄리던 아재들인 경우가 많은데, 그거 밖에 안해봤으면서 Unity 같은 게임엔진으로 개발하는 클라이언트 기능 고객한테 된다고 씨부리는거임. 이러면 말은 뱉어놨으니 개발은 해야하고 어거지로 끼워맞춰서 만들어두면 완성도 내려가서 만들어놓고도 욕먹고 그거 고칠 때까지 돈 못 받는 사례가 된다. 여기까지도 입에 걸레물고 욕하면서 만들면 만들긴 한다고 치자. 

 

근데 이게 테스트 한 1주일 정도 직전이면 진짜 기가차서 말도 안 나온다. 공수가 얼마나 잡히는지 기간이 얼마나 걸리는지 알지도 못하면서 된다고 일단 일벌려놓고 개발자한테 책임전가하는 PM만큼 꼴뵈기 싫은게 없음. 이런 애들은 심지어 테스트 기간에도 신규 요구사항 주워옴. 이래놓고 "개발자들이 아직 주니어다보니 프로젝트를 잘 따라올 만큼은 안되나보네요. 시간을 조금만 더 주시면.. ^^" 이 소리 하면서 개발자 책임으로 넘기고 있으면 머리통 터트려버려야함. 플젝 한번 해봤는데 이따위 PM이라는 각이 보인다. 그러면 바로 사직서 던지고 탈출하도록 하자. 남아있으면 매일 우리집에 있는 내침대는 구경도 못하는 수가 생김.

 

2. 감정에 휘둘리면 도망쳐라. 특히 나한테 악감정이 있다면 진짜 도망쳐라.

이것도 정말 문제가 되는 케이슨데, 공사가 구분이 안되는 제정신 아닌 애들이 있다. 일단 좋소 바닥에서 굴러본 내 생각은 개인적으로 성격이 안 맞고 대화만 하면 다툼이 생기는 사람이 있다하더라도 업무에 있어서는 존중하고, 맡기는 태도가 필요하다. 그냥 일을 못한다고 하면 그렇다고 치겠는데 악감정있다고 업무에서 배제시키는 PM은 도대체 뭔가 싶다. 심지어 대기업만큼 대체인력이 차고 넘치는 거도 아닌데, 공수 감당할 인원도 못채워서 한명이라도 아쉬운 좋소인데 업무 배제 시키는건 그냥 자기 자존심때문에 플젝 엎겠단 얘기로 밖에 안보임. 이러면 악감정있는 당사자 두 명 말고 주변인원도 피보는 케이스니까 그냥 도망쳐라. 미친놈이라고밖에는 볼 수가 없다.

 

심지어 내가 악감정이 있는 상대다? 그럼 진짜 빠른 시일내로 일자리 알아봐라. 내가 업무배제 당하고 있는 처지에 있다면, 일단 시간낭비가 가장 큰 문제다. 프로젝트는 했지만 제가 한 건 없습니다. 라는걸 경력기술서에 쓸게 아니라면 당장 나가서 다른 프로젝트 하나라도 더 뛰어야 더 좋은 곳으로 이직이 가능해진다. 또, 요즘 개발회사들이 진짜 맘에 안드는 채용문화를 하나 도입했는데, 그게 레퍼런스 체크임. 레퍼런스 체크가 뭐냐면 전에 재직하던 회사에 연락해서 그 사람 어땠냐고 물어보는거다. 솔직히 나도 이 체계가 디테일하게 어떻게 이뤄지는지는 모르겠긴하지만, 이게 아예 접점만 있고 큰 연관없는 사람을 찾아서 물어보는거면 몰라도 나를 싫어하는 누군가에게 안 갈거란 보장이 없다. 그럼 내 잘못은 하나도 없지만 나한테 악감정있던 PM이 별로라고 하면 별로인 사람 되어버리는거임. 물론, 개같아도 참고 인내하면서 예예 하는 사람이 대부분이겠지만 이런 일이 혹시라도 있다면 정말 어떻게든 다른 회사로 런하는게 좋을 것 이라고 생각한다.

 

3. 팀원의 역량 파악이 안되는 PM도 거르는게 좋다. 

PM은 프로젝트를 성공적으로 이끌어야하는 직무다. 근데, 프로젝트를 성공적으로 이끌려면 팀원들의 역량 파악이 중요하다. 누가 어떤걸 잘하는지, 누가 똥을 싸서 업무의 효율성을 저해하는지 이런걸 귀 기울이고 파악을 한 다음 뭔가 조치를 취해야하는데 도대체 PM 들은 회사만 오면 인터넷 쇼핑하고, 커피 마시고, 담배피우면서 월급루팡하는거 말고는 할 줄 아는게 없는건지, 일을 못해서 똥을 퍼질러 싸고 있어도 한량처럼 돌아다니다가 나중에 와서 진척도가 왜 이래? 이러고 앉아있다. 이게 가장 문제가 될 때가 언제냐면 주니어들이 일을 못하는건 PL이 알아서 업무를 재분배한다던가 해서 해결 할 수 있지만, PL이 일을 못하면 문제가 되는거임. 주니어들은 능력없는 PL 만나서 삽질만 주구장창하고 있는데, PM은 짬이 있으니 알아서 하겠지~ 라는 마인드로 손놓고 있어버리는거다. 앞에 서술한 두가지 문제점이 있더라도, 역량파악 잘되고, 팀원들이랑 사이 좋고 좀 유대라도 있고 하면 PL들이 알아서 캐리해주는데 역량 있는 PL 보는 눈도 없으면 그냥 플젝 산으로 가버리는 경우가 생김.

 

만일 당신이 꽤 오랫동안 능력없는 PL 밑에서 일을 하고 있고, 본인이 캐리할 수 있는 역량이 있는게 아니라면 도망치는게 가장 빠를 거라고 생각한다. PM은 당신의 PL을 바꿔주지 않을테니까. 도망을 못 친다면 줄야근에 주말출근까지 해서 본인이 캐리할 수 있는 역량을 키우는게 두번째로 빠른 길이다.

 

마무리하면서

PM은 프로젝트의 성공적으로 마무리 지어야하는 책임자이고, 프로젝트를 가장 잘 알아야하는 사람이기도 하지만 프로젝트를 가장 모르는 사람이기도 하다. 때문에 자존심이 가장 필요 없는 사람이라고 생각함. 고객들 한테는 당연한거고 개발자들한테 역시 강압적이어봐야 민심잃고 개발자들 떠나가면 손해는 자신이 보기 때문에 회유하고 달래서라도 프로젝트를 마무리 지어야하는데, 무슨 대단한 자리에 올라간거마냥 개발자들 부리고 처 놀면서 돈 벌 궁리는 좀 안했으면 좋겠다. 어쨌든 PM은 개발에서 손을 뗀 사람이고 지금 만들어지는 코드들은 개발자들이 누구보다 잘 알고 있을텐데, 되도 않은 자존심 부리면서 이래라 저래라 감 놔라 배 놔라. 안했으면 함.

 

PM이 해야할 일은 고객들의 쏟아지는 요구사항들을 알아서 잘 판별하고, 일정에 맞춰서 할 수 있게끔 과도한 공수는 설득해서 막아내서 완성도가 높은 프로그램을 제공하는거지 이유 없이 고객 빨아주고 술 쳐마시러 다니는게 아니라는거다. 그럴거면 기술영업하러 가라.