Search

반응형

'Software/개발자이야기'에 해당되는 글 23건

  1. 2024.02.25 프로젝트 팀원의 단점만 보이는가?
  2. 2023.04.02 초급 개발자가 성장하는 방법, 이러면 안된다.
반응형

최근 프로젝트를 몇 번 실패하고 퇴사한 직원이 있었다.

입사한 지 갓 1년을 넘은 경력직으로 이전에 대기업 전산직으로 근무했던 사람이었다.

나도 같이 프로젝트를 한 번 같이 했다.

내가 리더였고 그 직원은 팀원이었다.

처음 분위기는 좋았지만 한 달 정도 지나면서 다른 프로젝트에서 실패하고 리젝(reject)된 이유가 슬슬 보이기 시작했다.

내 장점 중 하나라고 한다면 프로젝트를 하면서 만나는 팀원들의 장단점을 빨리 알아차린다는 것이다. 물론 나 또한 장단점이 명확하다. 특히 야근과 주말근무를 엄청 싫어하기에 윗 분들은 별로 좋아하지 않는 타입니다. 

위에선 큰 기대를 하고 경력직으로 뽑은 이 직원은 입사 후 첫 프로젝트에서 리더로 들어갔지만 두어 달? 정도 있다가 리젝 되었다. 물론 보통 사람들은 자신의 잘못을 쉽게 인정하지 않는다. 나도 그렇기에..

작은 프로젝트 리더를 맡고 그 직원이 같이 참여하게 되었다. 리젝된 후 두 번째 프로젝트인 것이다. 리더가 나였기에 팀원으로 들어왔다. 왜 리젝 되었는지 이야기를 들어보니 본인의 잘못은 없었다. 그저 고객사의 문제를 강조했다. 그 고객사는 최근 나도 프로젝트를 진행했기에 어떤 상황인지 금방 이해하게 되었다.

작은 프로젝트는 시작되었다. 역시 말도 안되는 개발팀을 구성해 주었고 정말 답답한 마음이 앞섰다. 하지만 크고 작은 모든 프로젝트가 거의 완벽에 가까운 팀을 구성하긴 힘들다.

요구사항을 정리하고 기획을 시작하면서 단점이 드러나기 시작했다. 사실 이 직원뿐만 아니라 비슷한 또래의 임직원들의 고질병 같은 상황이 나타나기 시작한 것이다. 최근 시작하는 프로젝트에도 비슷한 나이대의 임원과 회의를 하는데 한마디로 꼰대다. 90년대 스타일의 개발 방식을 내세우면서 요즘 트렌드를 이해 못 한다고 했다. 굴삭기가 있는데 배우는데 복잡하다고 삽질이 최고다를 외치는 그런 분위기다.

여하튼 이 직원도 업무를 진행하는데 약간의 문제를 만들기 시작했다. 사실 리더의 역할 중 하나는 고객과 개발팀과의 적절한 업무적 조율을 잘해야 한다. 고객 편에 서면 개발팀의 개고생과 반발이 심해지고 프로젝트는 지옥의 나락으로 떨어진다. 최종적으로 지연과 함께 회사의 이익과 신뢰는 떨어질 수밖에 없다. 반대로 개발팀 편이나 본인 편을 강조하게 되면 고객사는 엄청난 불만이 발생하고 결국 리젝 되는 상황까지 발생하는 것이다.

이 직원은 그 동안의 경력을 기반으로 정말 많은 기능을 추가하고 있었다. 처음 이야기 한 것처럼 이 프로젝트는 작은 사이즈이다. 많은 기능을 넣으면 좋겠지만 고객의 요구도 아니고 기간, 팀 능력 및 금액적으로 봐도 불필요한 상황이었다. 사이즈에 맞게 적절한 기능을 고객과 협의해서 구현하는데 최적의 상황인데 마치 대형 프로젝트인 듯 상황을 만들어갔다. 고객의 입장에서도 해주면 좋겠는데 할 수 있겠냐는 우려를 표현했다. 그런 상황이 고객과 개발팀원들의 문의로 알게 되었고 내가 고객과 다시 조율해서 현실성 있는 구도로 다시 각을 잡았다. 그리고 그 직원에게 이래저래 상황을 설명하고 협의된 내용대로 진행하자고 했다. 그런데...

그런 상황을 그 직원은 자존심이 상했는지 리더인 나 몰래 다시 고객을 만나 설득하기 시작했다. 세상에...

그런 사실을 모르고 있다가 다음날 고객이 다시 메시지로 연락이 왔다. 불편하다고...정리가 안되는 거 같다고...

그래서 그냥 나랑 얘기한대로 진행할 테니 그 직원과 한 이야기는 넘기라고 했다.

그 뒤로도 업무의 역할 때문에 다툼이 있었다. 본인이 할 일이 아니라면서 짜증을 냈다. 가장 큰 문제는 개발 팀원 중 한 명의 요청 때문에  중요한 변경에 대해서 리더나 설계자와 전혀 상의하지 않고 임의로 변경하고 보고도 하지 않았다. 그것 때문에 다들 많은 시간 고생했다. 바뀌었는지 모르고 잘 실행되던 것이 계속 오류가 났기 때문이다. 결국 내가 발견했고 누가 이걸 변경했냐고 하니 그 개발 팀원이 알려줬다. 이래저래 요청하니 저분이 수정해 줬다고. ㅎㅎㅎ

같은 내용에 대한 반복적인 문의와 잘 삐지는? 그런 성향때문에 고객도 좀 힘들어했다.

그런 과정을 지켜보니 왜 이전 프로젝트에서 리젝되었는지 이해가 되었다. 그 뒤로도 몇 번의 기회가 있었지만 프로젝트에서 모두 리젝 되었다고 들었고 결국 퇴사하게 되었다.

다들 그 직원 탓만 하고 그 직원이 문제가 많아서 퇴사하게 되었다고 생각한다. 과연 그렇게 말하는 본인들은 잘 하는가?

물론 그 직원은 프로젝트 리더로서 자격이 부족함은 맞다. 반면 장점도 있었다.

다들 그 직원의 단점만 가지고 평가하고 선입견을 가졌기에 장점을 활용할 생각을 못한것이다.

모든 직원이 완벽하기를 기대한다는 것은 잘못된 생각이다. 그렇게 평가하는 본인은 정말 완벽하냐는 것이다.

사실 나에 대한 평가도 대충 알고 있다. 장점을 아는 사람들은 내 능력을 잘 활용하는데 그저 단점만 보는 리더들 때문에 답답한 늪에 빠지고 있다는 생각이 종종 든다.

나는 작은 프로젝트를 하면서 그 직원의 단점만 본것이 아니라 장점도 봤다. 그래서 그 장점을 최대한 활용하고 그 직원의 능력을 높이 평가해 줬다. 감정적으로 부딪힌 적도 있지만 최대한 빨리 정리했다. 그것도 리더의 능력이다.

하지만 보통 리더들은 자신의 주장과 자존심이 강해서 조금만 다른 의견을 보이면 화를 내거나 짜증을 내고 가버린다. 팀원들에게 엄청 무례한 행동이다. 그리고 자신에게 다른 의견을 제시하거나 바른 정보를 제공하면 감정적으로 대하기 시작하고 결국 진급이나 연봉에 영향까지 주기도 한다. 흔히 꼰대라고 한다.

진정한 리더라면...

우선 리더는 팀원을 존중해야 한다. 근태나 업무진행에 문제가 있는 경우는 당연히 조치를 해야 한다. 그리고 그 직원의 장점과 단점을 빨리 파악해서 장점을 잘 활용할 수 있도록 도와줘야 한다.

IT는 정말 빠르게 변하고 발전한다. 스마트 폰 앱을 만드는데 2G 폰 시절 개발방식을 라떼는~ 하면서 요구한다면 프로젝트는 산으로 갈 것이고 팀원들은 실망하게 될 것이다. 리더라면 직접 개발하지 않더라도 최신 트렌드는 꾸준히 이해하면서 팀원들과 커뮤니케이션을 해야 한다. 회의를 하는데 현재 프로젝트에서 요구하는 신 기술과 전혀 관계없는 라떼를 외친다면 빨리 그만둬라. 최근에도 회의를 하는데 엉뚱한 옛날이야기를 하길래 이 부분은 이런저런 신기술에 대한 부분이다라고 이야기해 주니 살짝 삐져서 가버렸다.

리더라면 회의 시간에 좋은 의견을 주는 팀원에게 긍정적 리액션을 해줘야 한다. 그런데 의견을 제시하는 것에 샘이 나는건지 무슨 의견만 내면 "그럼 니가 해" 라는 말을 툭툭 던지는 리더가 있다. 실제로 내가 일하는 곳에서도 있다.

그렇게 대응하면 어떤 팀원도 좋은 의견이 있어도 이야기 하지 않을 것이다. 발전도 없고 시간 낭비 회의가 될 것이기 때문이다.

프로젝트가 잘 진행되기 위해서는 리더의 역할과 능력이 정말 중요하다. 고객과 팀원과의 관계가 엄청 중요하기 때문이다. 그리고 리더는 항상 공부를 해야 한다. 라떼는 카페에서 맛있게 주문해서 먹는 걸로 끝내야 한다. 

그렇다고 그들의 오랜 경력과 경험을 무시하면 안된다. 프로젝트가 꼭 기술력으로만 성공하는 것이 아니기 때문에다.

멋진 리더가 되는 방법 중 하나는 팀원의 장점도 잘 살펴보고 응원하고 잘할 수 있도록 활용하는 것이다.

 

요즘은 정말 답답한 상황이 많이 발생하고 있다. 무엇이 중요한지 그래서 어떻게 해야 하는지 꼼꼼히 챙기고 진행하는 것이 필요한데 그저 대충대충 아무나 아무나 식으로 프로젝트를 준비하는 것을 보면서 정말 되기를 바라는 것일까 의문이 든다.

오늘도 열심히 스킬을 업 하는 신기한 연구소였습니다.

반응형
반응형

안녕하세요. 신기한 연구소입니다.

제목 보고 들어온 우리 초급개발자 분들.

환영합니다.

프로젝트를 하면 다양한 성향의 개발자 친구들을 만났습니다. 물론 초급 개발자 기준으로 이야기해 볼게요. 사원, 대리 직위를 갖는 개발자가 보통 초급 개발자입니다. 초급 개발자는 간단한 스크립트 개발 또는 사수를 도와 한 땀 한 땀 배워가며 프로젝트에 참여하게 됩니다.

그런데, 간혹 성장이 어려운 초급 개발자를 보게 됩니다. 어떤 경우가 초급 개발자의 성장을 방해하는지 살펴보겠습니다.

 

보고하지 않는 초급 개발자

사실 가장 큰 문제중 하나이기 한데요. 개발 업무 지시를 받은 초급 개발자는 업무를 시작하고 반드시 매일 일정을 체크해야 합니다. 특히 일정이 촉박한 경우에는 문제가 발생하기 전에 보고를 해야 하는데요. 간혹 강한 책임감과 자존심 때문에 보고를 하지 않고 본인이 해결하려고 시간을 엄청 사용하는 경우가 있습니다. 또한 곧 끝난다, 금방 해결된다고 허위보고를 하는 경우도 있는데요. 이는 아주 심각한 상황을 만들 수 있습니다. 신뢰를 잃게 되고 프로젝트 일정이 지연되는 상황이 발생할 수도 있습니다. 초급 개발자는 책임을 지는 자리가 아니기에 더 조심해야 합니다. 본인의 무모한 지연이 리더들을 난처하게 만들 수 있기 때문이죠. 

리더는 항상 개발을 하면서 매일 체크를 해야 합니다. 모든 초급 개발자들이 어려움이 발생할 때 바로 도움을 요청하거나 보고를 하지 않거든요. 그래서 초급 개발자들이 개발을 하면 중간 중간 물어봅니다. 그리고 진행하면서 어려움이 생기면 30분이든 시간을 정하고 이것저것 진행하다 안되면 바로 보고하라고 합니다. 하지만 그렇게 하라고 알려줘도 끝까지 보고 안 하고 시간을 질질 끄는 초급 개발자들이 있습니다. 그러면 본인의 성장은 멈추게 됩니다. 안 되는 것을 계속 혼자 안고 있으면 어느 누구도 모릅니다. 시간은 흘러가고 마지막 순간 폭탄이 될 수 있거든요. 결국 개발자로 성장은 없고 문제아로 낙인찍히게 됩니다.

 

부정적이고 핑계만 둘러대는 초급 개발자

한번은 이런 상황이 있었습니다. 화면 개발을 해야 하는데 사용자가 1명입니다. 개발자는 바로 불평을 늘어놓습니다. 1명이 쓰는 것을 왜 만들어야 하냐, 왜 하는지 모르겠다. 진짜 이걸 만들어야 하느냐? 1명을 위해 너무 많은 희생을 하는 것이 아니냐, 그 사람은 이 프로그램으로 편해지면 일 안 하나? 그냥 혼자 고생하는 게 낫지. 월급 받았으면 일을 해야지 왜 개발자가 이걸 만들어줘야 하냐...

이런 개발자는 자격이 없습니다. 1명이든 100명이든 요구가 있으면 그에 해당하는 급여를 받고 개발을 해주면 되는데 사용자가 1명이든 100명이든 무슨 상관이 있을까요? 근무시간에 급여를 받고 개발자로 앉아 있다면 개발자로 할 수 있는 코딩은 해야하지 않을까요? 반대로 생각하면 본인도 월급을 받았으면 일을 해야죠??

 

공부하지 않는 초급 개발자

이건 정말 심각합니다. 사실 급변하는 IT 환경에서 살아남기 위해서는 전문성이 정말 중요합니다. 나이, 직급과 관계 없이 공부는 계속해야 합니다. 공부는 근무시간에 하는 것이 아니지요. 공부는 언제 어디서든 나를 위해서 하는 겁니다. 근무시간에 공부한다는 발상은 직장은 학원도 도서관도 아닙니다. 직장에서 근무할 수 있는 능력은 미리 준비해야겠지요. 최신 기술과 나의 전문 분야에 대한 공부는 꾸준히 해야 합니다. 

 

근태불량 초급 개발자

정말 매일 지각하고 근무 시간에 1-2시간 자리를 비우기도 하는 근태 불량 개발자들이 있습니다. 또한 근무시간에 게임을 하거나 잡담을 시도 때도 없이 하는 초급 개발자도 있습니다. 그렇게 기본을 지키지 않으면서 퇴근은 칼처럼 합니다. 퇴근 시간을 지키고 권리라고 주장하고 싶으면 출근시간도 지키고 근무시간도 잘 지켜야 합니다.

 

위 사항에 해당 된다면 성장하는 개발자가 되기 어렵습니다. 또한 연봉에도 악영향을 미치게 됩니다. 그럼 다른 회사로 이직하면 된다고 생각하는 초급 개발자들도 있는데요. 다른 회사도 다르지 않습니다. 결국 도태되고 일을 못 구하는 상황이 발생할 수 있습니다. 프로그래머가 되고 싶다면 항상 전문성을 가진 프로 개발자를 위해 꾸준히 노력하고 그에 맞는 자세가 필요하다고 봅니다. 

꼭 초급 개발자가 아닌 시니어 개발자도 새로운 환경과 기술에 대해 꾸준히 공부해야 합니다. 

여러분 모두 성장하는 개발자를 꿈꾸며 열심히 스터디 합시다.

반응형