출처: http://www.ppomppu.co.kr/zboard/view.php?id=humor&no=124605
작은 게임 개발 업체의 팀장입니다.
약 5년간 지금의 회사를 다니면서 작년부터 야근을 거의 없애다 시피 했습니다.
물론 저 혼자의 노력은 아니고 사장님부터 전 직원이 모두 합심해서 이뤄낸 결과지요.
그 과정을 잠깐 설명 드리겠습니다.
우리 회사의 경영진은 개발 업무에 대해서는 전혀 모릅니다.
그래서 개발 담당 이사를 빼곤 개발에 관한한 전혀 간섭하지 않습니다.
그런데 사장님이 어느날 그러시더군요.
"다들 죽어라 일을 하는데 왜 우린 예정일도 못 지키고 만드는 것 마다 버그 투성이에
결과물에 대한 평가도 만족스럽지 못할까?"
다시 말해서 대체 열심히 일을 하는건 알겠는데 왜 성과가 없는거야?라는 거겠죠.
각 팀 팀장들이 이런 저런 이야기를 합니다.
그래서 사장님이 지시를 내렸습니다.
예정일을 지킬 수 있는 작업 프로세스 먼저 제시해봐라.
팀장들이 모여서 논의를 한 결과 다음과 같은 분석이 나왔습니다.
첫째,
개발 계획이 바뀌면 바뀐 순간부터 전체 예정일은 다시 산출해야 한다.
개발 담당 이사가 주로 일정을 잡는데 이사의 판단에 따라 개발 순서가 바뀌는 경우가 종종 있었습니다.
이 과정에서 많이들 헷갈리시는데 예를 들어서 A라는 3개월짜리 컨텐츠 개발 진행 중 2개월이 지나서 중단하고 B 컨텐츠를 만들면 다시 A컨텐츠를 개발하는데 1개월이 걸릴거라고 생각합니다.
천만의 말씀입니다.
B 컨텐츠로 인하여 게임 구조가 얼마만큼 바뀌었는가에 따라서 A는 개발 기간이 달라집니다.
그리고 처음부터 다시 만든다고 생각하지 않으면 어느 부분에서 버그가 나올지 아무도 예측 못합니다.
즉, 뭔가를 추가하거나 변경하고자 한다면 계획을 끝내고 다시 계획을 잡아서 진행해야 합니다.
그런데 게임 뿐 아니라 대부분의 IT 업계에서는 그렇게 안 합니다.
이 부분을 사장님께 이야기 드렸더니 앞으로는 무조건 승인된 것 먼저 완료 한 이후에 다시 계획 잡아서 진행하는 것으로 결정하셨습니다.
둘째,
개발과 테스트, 그리고 디버깅에 대하여 각각 일정을 별도로 잡아야한다.
아주 단순하게 스킬 하나를 만드는걸 예로 들어 보죠.
기획이 나오고 기획팀은 완료 보고 합니다.
기획서를 보고 프로그래밍 하는 동안에 그래픽 리소스 나오고 그래픽팀도 완료 보고 합니다.
그래서 다 얹어서 구동합니다.
구동 완료 되는 것을 보고 프로그램팀은 완료 보고 합니다.
전 팀이 다 완료 보고 했지만 업데이트는 못합니다.
왜? 그래픽 싱크가 안 맞고 밸런스 수치도 이상한데다가 가끔 클라이언트가 튕깁니다.
사장님은 묻습니다.
다 작업 끝나다면서 왜 업데이트 안돼?
그래서 다음부터는 개발과 테스트와 디버깅은 모두 각각의 일정을 잡기로 했습니다.
셋째,
일정은 개발자가 잡되, 일정내에 못 마칠 경우 야근을 하든지 집에서 하든지 개발자 스스로 잡은 일정에 대하여서는 책임진다.
마케팅팀에서 기획서가 나오면 한마디 합니다. 이거 3주면 만들지? 테스트 1주 하고 디버깅 1주하면 5주니까 넉넉잡고 1달 반 뒤에는 업데이트 할수 있겠지? 그럼 2주후부터 마케팅 준비하면 되지?
기획서도 제대로 검토 안해보고 답할수 없죠.
당연히 검토 해보고 대답하겠다고 합니다.
그러면 팀장회의에서 지.랄합니다. 능력없는 팀장 되는거 한순간이죠. 울며 겨자먹기로 알겠다고 합니다.
팀원 모아놓고 기획서 검토 들어가면 택도 없는 일정입니다.
방법 없죠. 팀장 권한으로 야근 지시합니다.
이런 악순환을 끊어야 된다고 이야기 했습니다.
사장님께선 테스트 끝나고 업데이트 준비되면 그때부터 마케팅 계획 잡는걸로 하라고 하십니다.
넷째,
기획은 기획자가 하고 기획서 검토는 실무진이 한다.
어느날 이사 중 한명이 팀장회의에서 이야기 합니다.
어느 게임에서 어떤 컨텐츠 업데이트 했더니 대박 났댄다 우리도 만들자.
기획은 그냥 갖다 배끼랍니다.
기획팀은 별 고민 없이 기획 합니다.
개발팀도 별 고민 없이 개발 합니다.
그래픽팀은 죽어납니다. 세계관도 없고 배경 설명도 없이 그냥 만들라고 하니 만듭니다.
테스트 해봤더니 재미 하나도 없습니다.
재미있게 하려면 다른 컨턴츠와 연계 방안을 찾아야 되고 몇가지 보조 시스템도 만들어야 됩니다.
배보다 배꼽이 더 크게 생겼습니다.
개발까지 끝냈는데 업데이트는 언제할지 모릅니다.
게임을 제일 잘 아는것은 기획자입니다.
게임이 어떻게 되어야 하는지는 그래서 기획자가 결정해야 됩니다.
사장님께서 이야기 들으시더니 기획단계를 두단계로 나눠서 컨텐츠 설명위주의 기획서 초안을 만들어 브리핑 하고 팀장회의에서 충분히 가치가 평가되면 그 다음에 개발에 들어가도록 하자고 하십니다.
마지막,
일정 중 테스트와 디버깅은 무한정 할 수 없으니 최대 기간을 정한다.
사장님이 위의 이야기를 다 결정하시더니 한마디 하십니다.
개발 한달하고 테스트 석달에 디버깅 반년 이렇게 잡으면 다른 부서에서는 아무것도 계획할 수 없게 되니까 테스트 및 디버깅의 최대 기간은 반드시 고정해야 된다고 하십니다.
그 이내에 끝내지 못하면 귀책 사유를 찾아서 그 팀에 불이익을 주겠다고 하십니다.
최종적으로 조율된 것은 개발기간의 절반을 추가로 테스트와 디버깅에 사용하는 것으로 확정 지었습니다.
즉 6개월 개발하면 3개월 이내에 테스트와 디버깅을 마치는 것이죠.
위와 같이 결정된 이후 3개월간은 야근이 더 늘어났습니다.
팀간 업무 협의 과정이 원활하지 않은것도 있었고 개발자들이 개발 기간 산출을 잘못한 경우도 많았습니다.
그리고 다음 3개월간은 야근이 점차 줄더군요.
그러더니 올초 들어서는 평시 야근은 완전히 사라졌습니다.
물론 사안에 따라 야근을 하거나 주말 출근을 하는 경우는 종종 있습니다.
그러나 한 개인으로 놓고 보면 야근은 한달에 1일 이내 정도이고 주말 출근은 5개월 동안 두번 있었습니다.
-----------------------------
야근을 해야 하는 원인은 아마 회사마다 다를겁니다.
그러나 그 원인을 찾아서 해소하는데에 전 직원이 다같이 노력해야 되는 것은 모든 회사가 같을 겁니다.
야근을 없애는 과정에서 개발이 무척 더디게 진행되는 것 처럼 보여서 6개월간은 정말 답답했습니다.
그 답답함 때문에 혹시 회사가 망하는 것은 아닐까 불안하기도 했습니다.
그러나 그 과정을 겪고 나니까 정말 잘 했다고 생각됩니다.
야근을 바꾸고 나서 얻은 것은 다음과 같습니다.
1. 일정을 잡을 수 있게 되었다.
2. 자신의 작업 결과물을 다시 분석해 볼 여유가 생겼다.
3. 왜 작업을 해야 하는지에 대한 분명한 이유를 공유하게 되었다.
4. 회사에 대한 애착이 생겼다.
5. 연애를 시작하는 사람들이 늘었다.
회사를 아끼고 사랑하신다면, 그리고 그만한 위치에 있으시다면,
야근을 없애는 것에 대하여 깊은 고민을 해보시기 바랍니다.
리더쉽에 관한 강의를 받던 중 다음과 같은 말이 깊이 와 닿더군요.
"문제가 생겼을 때 그 문제를 해결하는 방법은 문제가 생긴 사람이 가장 잘 알고 있다."
"리더쉽이란 가르치거나 이끄는 것이 아니라 앞으로 나아갈 방법을 찾을 수 있게 해 주는 것이다."
PS. 첨언 이지만 이것도 깁니다.. 스압 주의.. ^^;
야근이 우리 부서만 없어진것처럼 생각하시는 분이 있는데
물론 아직도 야근 많이 하는 부서도 있습니다만 대부분의 부서는 야근이 거의 없어졌습니다.
그런데 이 야근이라는것이 필요할 때가 있기도 하고 아주 안 좋은 결과를 야기하기도 합니다.
먼저 야근이 필요할 때는 다음과 같은 경우입니다.
1. 반드시 오늘 또는 내일안으로 처리해야 하며 처리 되었을 경우 다음날은 충분히 쉴수 있을 경우
2. 프로젝트 초반에 시간 = 작업량 일 경우
3. 소수의 인원이 최대한 빠른 시일안에 처리해야 회사 전체가 움직일 수 있는 경우
우리 회사도 초반에는 위와 같은 경우였기에 야근을 밥먹듯이 했었습니다.
그런데 이 야근을 하는 문화가 한번 형성되고 나니까 점차 악영향이 만들어 집니다.
프로젝트의 진행 초반에는 키맨들이 야근을 참 많이 하게 됩니다.
이들의 업무가 과중하기도 하고 회사 창립 맴버인 만큼 회사에 대한 애착도 강합니다.
일부는 지분을 갖고 있기도 합니다.
그렇게 프로젝트가 점차 점차 복잡해지기 시작하면서 첫번째 결과물이 나오게 됩니다.
이 결과물로 투자도 받고 사람도 뽑아서 조금 편해지는가 싶더니 다음 단계에 대한 압박이 시작됩니다.
그런데 여기서부터 문제가 시작됩니다.
우선 새로 입사한 사람들과 초반의 키맨들의 업무 시간에 차이가 발생합니다.
야근을 하면 당연히 다음날 늦게 나옵니다.
또한 키맨들이므로 팀장급이고 경영진과의 친분도 두터워서 누가 뭐라고 하기 어렵습니다.
그러면 그 팀의 팀원들의 업무는 관리 받지 못하게 됩니다.
또한 타팀과의 업무 협조도 원할하지 않게 됩니다.
출근시간도 들쭉날쭉하고 출근 직후에 회의를 갖는것도 아닌데다가
다른 일들도 많아서 일정 조차 잡기 어렵습니다.
이렇게 팀 간에도 대화가 부족하고 팀원들 사이에도 대화가 부족하다 보니
사소한 실수가 발견되지 않고 넘어가게 됩니다.
이 사소한 실수가 조금씩 쌓이면서 점점 복잡해지는 프로젝트를 좀먹게 됩니다.
처음에는 버그 하나 해소하는데 1시간이면 되던것이 나중에는 1주일이 걸려도 해소가 되지 않습니다.
처음에는 현상만 봐도 아 이게 문제구나 하고 바로 바로 원인이 유추 되던것이
나중에는 로그를 다 뒤져봐도 원인을 못찾아서 헤메게 됩니다.
결국 치명타가 발생합니다.
테스트 중 서버가 멈춥니다.
원인 찾느라 분주합니다.
프로젝트 올 스톱입니다.
회사내의 분위기가 아주 험악해 집니다.
알아서 야근 합니다.
물론 다음날 지각합니다.
계속 이러한 현상이 반복됩니다.
못버티고 퇴사하는 사람들이 한마디씩 합니다.
그게 소문이 되서 회사내에 돌아다닙니다.
원래도 개인주의가 강한 성향의 개발자들이 점차 점차 더 소극적이고 더 개인적이 되어 갑니다.
협업 개념이 거의 실종되어 갑니다.
일정은 무조건 딴팀때문에 늦어지는 겁니다.
마침내 키맨 중 일부가 지칩니다.
아주 아주 중요한 사람이라고 생각되던 사람이 그만두면서 프로젝트가 흔들립니다.
어떻게 어떻게 비슷한 실력자 델고 옵니다.
당연히 전임자가 무엇을 잘못했는지를 지적하고 그걸 고치자고 합니다.
순식간에 전임자는 나쁜놈 됩니다.
여지껏 진행된 과정을 정확히 모르는 상태에서 맘에 안 드는 것을 뒤집으려 합니다.
당연히 시간이 부족해지고 그래서 야근은 그냥 일상화 되어 버립니다.
또 다른 키맨이 지칩니다.
그런데 이사람은 안 그만두고 그냥 회사에서 놉니다.
가끔 정말 중요할 때에는 눈부신 활약을 하면서도 그 외에는 그냥 놉니다.
경영진은 아주 가끔씩 그 눈부신 활약을 보이는 것 때문에 뭐라고 말을 못합니다.
새로온 키맨과 태업하는 키맨이 충돌합니다.
드디어 배가 산으로 가기 시작합니다.
이 모든 과정의 원인이 야근 때문이라고 한다면 당연히 말도 안되죠.
정확히 말하면 개발 프로세스가 정립되지 않았기에 생기는 현상이고
개발 프로세스가 잘 정립되었는지 알수 있는 방법이 바로 야근입니다.
개발 프로세스가 제대로라면 야근을 하는것은 개인의 선택이 되지만
그렇지 않다면 회사의 강압이 되기 때문입니다.
어떤분이 댓글에 쓰셨던데 폭포수 이론을 누구나 알고 있습니다만
어떻게 적용해야 하는지는 다들 잘 모릅니다.
그래서 다 같이 고민하고 노력해야 하는 겁니다.
누구 한명이 잘나서 고칠 수 있는 문제가 아니라
문제라고 인식되면 충분한 설명을 통해서 그걸 문제라고 직원 전체가 동감해야 하는겁니다.
우리 회사는 지각이 문제라고 다들 이야기 했고 지각의 원인은 야근이라고 다들 동감했습니다.
사장님은 지각을 먼저 고쳐보고자 했으나 실패했었고 그럼 야근을 없애보자고 해서 성공했습니다.
그래서 이젠 지각과 야근이 거의 없어졌습니다.
아침에 정시 출근하면 사무실의 절반이 비어있던 시절이 우리 회사도 있었습니다.
저녁 7시 반쯤 저녁 시켜먹자고 하면 절반 정도가 메뉴 고르던 시절이였죠.
지금은 둘다 사라져가고 있습니다.
