저작권이 있으므로, 무단 전제 및 복사를 금합니다.

추천해 주셔서 작은 이야기 하나 더 올립니다.

'개발자의 꿈' 글과 이어지는 글입니다. 

it업무 중 일어난 일들의 직장인 에피소드 입니다.

공감이 가시면 추천 부탁드립니다.

===================================================================================

  시계가 돌아간 것일 뿐 많이 일을 하고 있다고 생각하지 않는다  _ 무모한 야근 비판

 내가 속한 팀은 펌웨어 팀인데 야근이 너무 많았다. 이미 육체적 한계가 온 상황이라 보는 것이 맞았다.

야근보다는 심야근무 후 출근을 늦게 하는 것이 일상화 되어 있었다.

이 분들에게 폭탄 같은 말을 했다.

"힘들게 늦게 까지 일하시는 분들께는 미안하지만, 시계가 돌아간 것일 뿐 많이 일을 하고 있다고 생각하지 않습니다."

"매일 밤 늦게까지 자리를 지켰다고, 일 잘했다는 말은 절대 들을 수 없습니다."

"매일 힘들게 늦게 까지 일한 결과로 어떤 성과가 나왔는지 저에게 설명해 주셔야 합니다."

"분명 윗 분들은 여러분의 성과에 만족을 못하고 있을 겁니다. 물론 노력을 인정하시기 때문에 꾸중까지는 하지 않으시겠죠."

"저는 정시 출근해서 10시정도까지 일합니다. 저하고 실제로 일한 시간을 비교해 보시면 어느 정도나 차이가 나죠?"

"여러분의 실제 출근시간 퇴근시간 일한 시간을 비교해 보시면 저와 차이가 얼마나 되나요? 일하는 방법이 잘못 된 겁니다."

"집중해서 8시간 프로그램을 짜면 머리가 멍해져서 더 이상 일할 수 없는 상태가 됩니다. 그 정도 집중해서 일했으면 그날은 가서 쉬세요. 그래야 더 많은 성과가 나옵니다."

"이미 시계가 돌아 간 상태라, 시차적응을 해야 해서 갑자기 바꿀 순 없으니 천천히 바꾸세요."

"지금 처럼 일하면 '수고한 사람'은 되어도, '일 잘하는 사람'은 절대 될 수 없습니다."

매일 심야까지 야근 하시는 후배에게 강한 말을 할 수 있었던 것은 기존 일하시던 후배님과 교감을 가지고 있어서 가능한 것이었다. 

아무런 교감이 없이 이런 말을 하게 되면 '싸우자는 거지' 그 이상이 되기 힘들다.

심지어 이런 말도 했다.

"저는 왜 망치는 것도 힘들게 하는지 이해 못하겠습니다. 많은 프로젝트들이 망치는 것도 힘들게 합니다. 최소한 망하는 건 쉽게 해야죠."

  업무를 천천히 해라.

 우리 팀 분들은 펌웨어 전문가가 아직은 아니었다. 

펌웨어 분야는 소프트웨어와 하드웨어를 모두 이해해야 해서, 업무를 배우는데 많은 시간이 필요하다.

모르는 상태에서 빨리 업무를 진행 하려고 하니 결과에 집착을 하게 되고, 완전히 이해하지 못한 부분들로 인하여 버그가 종종 발생했다.

그래서 이렇게 후배들에게 이야기 했다.

"일 좀 천천히 해."

"천천히 하라는 사람은 처음 보는 거지"

"이해하면서 천천히 하는 방법이 젤 빠른 거야."

"나하고 처음 일하는 사람들은 나한테 이것도 모르느냐고 항상 말해, 난 모르는 건 모른다고 하거든"

"나는 처음 하는 일이라 모르는 것부터 이해하고 파악부터 하고 있거든, 자기들은 아는 건데 삽질하고 있으면 답답해 보이겠지. 그런데 나중 되면 나한테 어떻게 빨리 했냐고 물어봐"

"'천천히 해라'는 뜻은 정확히 이해하는 시간을 가져 라는 거야. 그래야 버그가 없이 한번에 끝나."

"참고로 난 다 안다는 사람 안 무서워 해. 뭘 모르는지도 모르는 사람이 뭐가 무서워. 근데 모른다고 하는 사람은 무서워, 안다는 걸 확실히 알고 있거든"

"예전에 차량관련 업무 처음 할 때 3개월 만에 해야 하는데 2개월 동안 코딩을 한 줄 안 한적도 있어." 

"우리 팀장이 나를 맨날 불러서 물어 보면 어찌어찌 하겠다는 계획은 다 대답했지. 코딩을 한 것이 있냐고 하면 아직 하나도 안 했다고 답했어. 그게 사실이거든"

"결국 3개월 기간 중 2개월을 코딩을 한 줄 안 하다가 2주간 코딩 해서 프로젝트 일정 맞추어 본적도 있어."

"뭘 해야 하는지도 모르는데 어떻게 코딩을 해, 뭔지도 모르고 하는 코딩이 제대로 될 꺼 같아. 몽땅 다시 해야 하는 거야"

"몽땅 다시 하는 반복이 없이 한번에 하는 게 가장 빨라" 

"이것이 내가 아는 가장 빨리 일을 끝내는 방법이야!!" 

소프트웨어 개발 방법론에 따르면 요구사항분석-설계-개발-검증의 단계를 거쳐서 한번에 진행하는 폭포수방법론이 가장 빠른 방법론이다.

물론 오류발생시 수정이 어려운 단점이 있지만, 방법론적으로도 가장 빠른 방법이 맞고, 내가 좋아하는 방법론이다. 

차량업무를 처음 할 때의 설명은 그런 일도 있었다는 정도만 언급 드리고, 다음 기회에 자세히 이야기 드리겠습니다.

  내가 시킨 건 내가 시켰다고 해

"내가 시킨게 혹시 잘못 되어서 다른 분이 뭐라 하면, 내가 시켰다고 해."

"그분이 나 한테 뭐라고 할 수도 있겠지."

"그래도 상관없어."

"내가 잘못 시킨 것은 나도 알아야 해."

"나는 어떻게 할꺼냐고?"

"잘못했다고 하면 되지 뭐."

"담당자로서 잘못될꺼 같으면, 나에게 미리 이야기는 좀 해줘."

슬프게도, 자기가 지시한 것이 잘못 되었을때, 숨어버리는 매니저들이 의외로 많다. 

 

 

  사장님 간담회

우리 팀 후배 한 분이 사장님 간담회에 참석하면서 나에게 이렇게 말한다.  

후배 : "어쩌피 이야기해도 지금까지 요청하지도 않았다고 할건데 의미가 없어요."

       "요청해도 그 부서에서 해주지도 않아요."

나   : "당연하지, 사장님 간담회는 요청한 게 안된걸 터뜨리는 자리지, 가만히 있다가 뭐가 안된 다고, 불평하는 자리가 아니야. "

       "하루 이틀 장사하는 거 아니잖아. 안 해주는 거 알지 그래도 정당한 건 다 요청하고 거부당한 거 쌓아둬."

       "거부 당했단 근거를 만들어 두는 거지."

       "근거를 기반으로 이러한 정당한 요청을 했는데 거부당한 거라고 터뜨려야 해."

       "그래야 바뀌는 거야"

       "아마, 사장님은 '아무것도 안하고 가만있다가 뭔 뚱단지야'라고 생각 하실 거야."

남이 바꾸어 주기를 바라기만 해서는 절대 바뀌지 않는다.

자신은 가만이 있다가, 바뀌기만을 기다려서 이익만 보려고 하는 것을 '무임승차'라고 한다.

무임승차가 잘못된 것은 아니지만, 무엇가 바꾸어 보려고 하는 사람들을 바보같다고 생각하진 말자.