믿음
4k
2014-10-22 14:42:22
2
11697

14화 - 프리랜서 가이드라인(이런곳은 피해라)


8. 이런 곳은 피해라


어떤 프로젝트를 피해야 될까?
이 문제는 사람에 따라서 기준이 다를 것 같다.
아래 언급하게 될 피해야 될 프로젝트도 본인의 주관이 많이 실린 부분 인지라 최종 판단은 개인이 해야 될 부분이다.

1. 인터뷰 중에 야근, 주말 출근 이야기를 꺼내는 곳 

이런 곳은 현재 일정이 지연되고 있는 곳이다.
아직 프로젝트가 시작 전 이라면 PM이 판단하기에 프로젝트 기간에 비해 개발할 내용이 많은 경우일 수도 있다. 또는 PM이나 PL 마인드 자체가 개발자는 절대로 놀지 못하게 죽도록 일 시켜야 된다는 곳일 수도 있다.
강조해서 말한다


   ‘저런 곳은 무조건 가지 마라’
  

당신을 위해서도 다른 프리랜서들을 위해서도 절대로 도움이 되지 않는다.
당신이 그래도 가겠다고 생각이 들면 최소 야근과 주말 출근 한 것에 대한 비용을 청구해라. 하지만 건강을 중요하게 생각한다면 돈을 더 준다고 해도 가지 않는 것을 추천한다.
물론 당신이 엄청난 실력과 말빨을 가지고 있다면 그런 프로젝트에 들어가서도 사내 분위기를 바꾸고 노동법에 의거한 근무를 할 수 있을 것이다. (경우에 따라서는 자유 출퇴근 할 정도가 될지도 모른다.)
PM이 잔소리 못할 정도로 그 곳의 업무 환경을 지배 하고 인간적인 신뢰를 쌓아야 한다. 그런 것이 자신 있는 사람이라면 말리진 않는다.
그런데 본인의 경험 상 가끔 이상한 성격의 PM은 야근을 너무 좋아해서 개발자들이 야근을 하도록 유도하면서 간혹 야근을 하지 않으려고 하는 개발자가 있으면 분위기 조성을 위해 해고 시키는 경우를 본다.
이런 경우가 걸리면 당신이 아무리 잘난 개발자라고 해도 어쩔 수가 없게 된다.
당신이 실력 있는 개발자라면 그 훌륭한 실력을 이런 곳에 썩히지 마라. 당신의 능력을 필요로 하는 곳은 많다.

2. 요구 사항이 명확하지 않은 프로젝트 

요구 사항 문서를 보니 뭘 만들라는 구체적인 언급이 없다. 그냥 뭉뚱그려서 이렇게 됐으면 좋겠다. 라는 애매한 표현만 있다.
이런 경우 개발자가 자기 나름대로 고민하여 프로그램을 완성해서 보여주면 고객이 ‘어 이런 게 아닌데...’ 라는 말이 날아올 가능성이 크다.
이렇게 되면 처음부터 다시 해야 된다.
문제의 원인을 따지면 요구 사항이 명확하게 하지 않은 고객과 그걸 명확하게 받아 내지 못한 PM 등에 있겠지만, 결국 책임은 당신이 져야 한다.
고객의 반응이 저렇게 나온다면 PM은 긴급 회의를 소집하여 오늘부터 야근 하자는 말을 꺼낼 것이다.
이런 경우 물론 안 가는 것만이 대안은 아니다.
PM이나 PL에게 ‘요구 사항이 명확하지 않기 때문에 일을 할 수가 없다’라는 점을 설득 시켜 고객과 협의를 통해 요구 사항을 명확하게 만들면 된다. 이렇게 했음에도 불구하고 그냥 만들라 라는 식의 주먹구구식 개발을 하는 경우, 그때 계약에 대해서 다시 생각해보는 것도 좋다.

3. PM이나 PL이 우유부단한(힘이 없는) 프로젝트 

야근의 책임이 누구에게 있느냐 라는 문제를 따지고 보면 여러 단계의 책임이 있으나 보통 일정 관리를 제대로 못한 PM과 PL의 책임이 크다.(때로 개발자의 실력 문제가 언급되기도 하지만 일반적으로 제대로 된 프로젝트라면 몇 일 이내에 개발자 누군가 이 부분을 제대로 못하고 있다는 것이 이슈가 되어 그 부분에 대한 대책을 세운다. 당신이 악의적으로 혹은 쪽팔린다, 라는 이유로 일정 진행을 숨기고 있다면 모를까. 일반적으로 당신의 일정 진행 상태는 PL이 철저히 체크하고 있다. 만약 PL이 그걸 체크하지 않고 있다면 당신이 가서 말을 해야 한다.)
경우에 따라서는 PM이 처음부터 야근을 넣고 일정을 산정한 경우도 있다. 사실 인터뷰만 봐서 PM이나 PL의 성향을 파악하는 건 쉽게 할 수 있는 일이 아니다. 어느 정도 경험이 쌓여 눈치가 생겼을 때 또는 실제로 프로젝트에 투입돼서 한동안 같이 일을 해봐야지 알 수 있는 경우가 많다.

   PM이 우유부단하면 고객의 요구 사항을 거부하지 못한다. 고객의 요구 사항은 프로그램을 만들기 전과 만든 후가 많이 달라지기 마련이다. 베타 버전의 프로그램을 본 고객은 그 순간 즉흥적으로 뭐가 필요하다 라는 생각이 든다. 즉, 요구 사항이 늘어난다.
  

경우에 따라서 그 요구 사항이 상당히 중요하여 없으면 안 되는 내용인 경우가 있으나, 반대로 애초에 사업에도 포함되지 않은 엉뚱한 새로운 요구 사항인 경우가 있다. 이럴 때 PM이 힘이 없어 고객에게 YES 만을 날린다면 그때부터 프로젝트는 점점 산으로 가기 시작하고 일정은 계속 늘어난다.


   일정이 늘어나는 거면 그나마 다행이다. 보통 일정은 고정 되어 있고 그 안에 어떻게 하던 만들어 내라는 경우가 대부분이다. 게다가 이런 PM을 보고 화가 난 팀원들이 PM의 지시를 제대로 따르지 않거나 중간이 이탈을 하는 경우도 생긴다. 
이런 것이 진정한 hell 프로젝트이다.
  

PL이 우유부단할 경우는 어찌 보면 개발자에게 좀 더 직접적으로 영향이 온다. 규모가 좀 큰 프로젝트에서는 PM과 개발자가 대화할 경우가 그렇게 많지 않다. (실제로 몇몇 대형 프로젝트에 본인의 경험으로는 투입 될 때 면접 장소에서 단 한번 본 적도 있고 아예 대화 자체를 못해본 경우도 있다.)
PL과 직접적으로 대화할 일이 훨씬 많다. PL도 결국 PM의 지시에 따라서 움직이는 사람이지만, 적어도 PM이 무리한 요구를 했을 때 그렇게 안된다 라는 의견을 제시 할 수 있는PL 이어야 한다. PL 또한 YES 맨 이라면 당신의 고생 길은 매우 환하다.
이 부분도 경험담인데 PL이 확고한 의지가 있다면 당신의 야근이 사라지기도 한다. PL이 절대로 야근을 하지 않겠다 라는 마음을 가지고 일하면 다른 팀이 다 야근을 해도 그 PL의 팀은 야근을 하지 않는다.
앞으로 PL을 할 사람 현재 PL을 하고 있는 사람 반드시 야근을 하지 않겠다는 마음을 가지고 일해라! 당신 혼자의 문제가 아니다.
당신의 생각에 따라 팀원들이 어떻게 일할 지가 바뀐다.
물론 이런 마음가짐 이전에 팀원들을 이끄는 리더십과 기술적인 이슈를 해결 할 수 있는 실력이 바탕이 되어야 하는 건 기본이다. 문제가 생겨서 일정이 진행이 되지 않는데 칼 퇴근 하겠다 라고 말하는 당신을 납득하는 관리자는 없을 것이다.


에디터: 1, 2, 3번 항목 모두 암 걸릴 거 같지만 그래도 역시 암 중의 암은 3 번인 거 같아서 네모칸 남발했습니다. 암요, 그렇고 말고요. 다음 화 <이런 곳은 피해라 2>로 이어집니다.

○ Copyright(c)2014 by OKJSP.net. All Page content is property of OKJSP.net
(모든 저작권은 OKJSP에게 있습니다. 모든 페이지 내용의 소유권은 OKJSP가 가지고 있습니다.)
1
0
  • 댓글 2

  • kenu
    48k
    2015-02-26 04:34:03

    CopyRight 수정 안 해도 될까요?  업그레이드

    1
  • 믿음
    4k
    2015-02-26 11:39:07

    넵, 업그레이드 수정 하겠습니다.

    감사합니다.

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.