'주말근무'에 해당되는 글 1건

  1. 2010/08/30 글뻥 야근이 과연 절대 악인가?

월요일 새벽 4시.
현재 월요일 오후 고객사 사업팀장님 시연때문에 금욜 오후부터 토욜, 일욜 (특히 오늘은 철야모드) 버닝중이다.
문득 버닝중에 과연 철야 또는 야근이 절대악인지를 묻고 싶어 졌다.

예전의 내 포스팅을 보면 야근에 관련된 이야기가 많이 나온다.
애자일 용어로 Sprint 즉, 스스로 치열하게 일하는 것에 대한 이야기가 많이 나오고 있다.

그럼 꺼꾸로 한번 스스로에게 되물어 보도록 하자.
철야 또는 야근은 절대 악인가?
그리고 프로젝트 기간동안 제일 기억남았던 좋던가 싫은 기억은 무엇인가?

대부분의 개발자는 야근, 철야, 주말근무를 떠올릴 것이다.

그럼 우리가 알고 있는 야근, 철야, 주말근무는 왜 나쁜것일까?

첫째, 개발자 스스로의 건강을 깨트린다. 나역시 아침에 일어나기 힘들고 주말에는 퍼지기 일수이다.
거기다 고칼로리 야식으로 인해 살이 비둥비둥 쪄간다.
둘째, 능률 저하가 발생한다. 어차피 야근하는 문화라면 뭐하러 근무시간내에 일을 마치려 바둥바둥 하겠는가?
어차피 야근이라면 근무시간에 일에 집중하기보다 놀기바빠지기 마련이다. 그리고 이런게 습관화 되면 습관으로 인해 스스로의 인생조차 장담 할 수 없게 된다.

즉, 상시 야근 및 철야, 주말근무는 결국 개발자 나아가 개발팀 더나아가 회사의 장기적 손해를 끼친다.
그래서 나쁜것이 바로 야근, 철야, 주말근무인 것이다.

그럼 왜 이런 좋게 말해 필요악이 발생하는가?
가장 큰 이유는 일정이다.
일정 계획이 무계획, 무기준으로 짜여져서 결국 프로젝트를 지옥으로 빠트리는 상황이 가장 많을 것이다.
그다음이 원가 절감이다.
갑또는 을의 원가 절감으로 인해 절대적 업무량이 많은 경우이다.

그런데 야근, 철야, 주말근무가 반드시 나쁜것일까?
내 생각에는 리더인 PM이 직접 하는 야근, 철야, 주말근무는 필요악이다. 스스로 희생양으로 삼아 고객에게 좋은 점수를 딴다면 그가 이끌고 있는 팀은 어찌됐건 차기 프로젝트를 수주할 확률이 올라간다.
문제는 무능력한 PM이 이끌고 있는 팀은 PM스스로 업무를 처리할 수 없기에 물귀신 처럼 밑에 팀원들 데리고 자폭하는데 그 문제의 심각성이 있다.

이제 야근의 장점을 이야기해보자.
야근을 함으로써 얻을 수 있는 것은 팀원간의 친밀도와 팀웤이다.
짧고 강렬한 경험을 공유하면 그 경험으로 인해 팀원의 팀웤을 일시적으로 상승시킬수 있다.
군에서 고생을 같이 하고나면 전우애가 생기듯이 사회도 똑같은 원리로 이러한 효과를 기대할 수 있는 것이다.

현명한 PM이라면 이를 적절하게 활용해야만 한다.
모든 품질은 정량화에서 부터 시작된다는 이야기를 많이 하였다. 업무가 70% 정량화되어 팀원들에게 할당되면 70% 예측이 가능할 것이다. 즉, 업무를 세부적인 메소드 수준까지 정량화시키고 이를 팀원들에게 할당하면 업무의 우선순위를 정하고 일정기간 그것을 완성하기위해 Sprint하고 그 보상으로 1~2일의 휴가 또는 오후 3시 이전에 조기 퇴근할 수 있는 권한을 준다면 업무의 효율성을 재고할 수 있다.
이건 경험적인 것으로 이러한 보상을 통해 팀웤을 끌어올리면서 업무 효율성을 재고하는 2마리의 토끼를 다 잡을 수 있는 기회이기도 하다.

따라서, 무조건 절대 악이라는 것도 절대 선이라는 것도 없다는 것이다.
최선은 그 사이에 있기 마련인 것이다.

정리하자면
1. 야근, 철야, 주말근무해야 한다면 PM이 직접하라. (리더일수록 팀원에 비해 근무시간이 더 늘어나는것은 당연하다)
2. Sprint 기간을 설정하고 Sprint한 후 그 몇배의 시간 만큼은 정시 출퇴근 혹은 쉴 수 있는 시간을 부여하라.
3. 현재 팀원이라면 자신의 환경적, 신체적, 가정 컨디션을 팀 리더에게 수시로 알려라. (최소한 이메일정도는 남겨야 한다)
4. 이유없는 야근은 하더라도 2주 혹은 3주에 한번 정도로 제한하고 어쩔수 없이 야근하는 경우는 그 자체를 즐겨라.
5. 왠만하면 퇴근할 시간에는 집으로가서 재택을 하자.
가 되겠다.

2010/08/30 04:18 2010/08/30 04:18