현재 업무에 대한 고찰

현재 나는 코더가 아니다.

그렇다고 설계자도 아니다.

지금은 개발자를 관리하는 업무를 맡고 있다.

지금 속해 있는 팀이 조직된 시기는 올해 초였다.

그리고 지금까지 현재 소속팀으로 활동하면서 가지게 된 여러가지 생각들을 정리 할 시간이 필요하게 되었다.

원래부터 우리 팀이 생기게 된 이유는 개발자가 개발만 전념하게 하는게 주 목적이었다.

그렇게해서 조직된 우리팀은 무엇을 하면 개발자가 개발에만 전념할 수 있을까에 대해서 고민하기 시작했다.

이전에 연구소 조직은 최상위가 전무님 이하에 그룹장님 그 밑에 팀장 또는 리더로 운영되는 조직이었다.

각 팀들이 존재하였고 규모에 따라서는 팀들을 묶어서 그룹으로도 구분하였다.

하지만 제품 라인이 많아지고 고객의 신규성 요구사항이 늘어나며 신제품을 위한 제품 라인도 생기면서 조직의 인력은 늘어가기 시작했고 기존의 조직운영 방식에서의 한계가 점점 드러나게 되었다.

이전엔 팀장급에서만 진행되던 관리상의 업무가 점점 리더급으로 내려오기 시작했으며 그로 인해 발생한 문제점은 개발 생산성이 가장 높을 수 밖에 없는 리더급 개발자들의 개발업무가 방해받기 시작했다는 것이다.

물론 그것을 메꾸는 방법으로는 개발자 인력을 충원하면 되겠지만 회사 사정상 자원투자에 한계가 있었고 충분히 유능한 개발자들을 관리업무로 낭비하는게 올바르지 못하다는 판단을 하였기에 그에 대한 고육지책으로 팀장급이 개발에 참여하거나 중급 개발자들을 양성해 나가기 위한 노력을 시도했었다.

하지만 그것 역시 근본적인 해결이 되지 못했기에 어쩔 수 없이 우리 조직이 생겨나게 되었다.

소규모 프로젝트 환경에서는 고객은 한명이고 고객을 상대하는 PM 역시 한명이다.

둘의 관계는 요구사항을 전달하고 진행상황을 보고 받으며 긴밀하게 엮어가게 되어 있다.

하지만 어느 순간 고객은 한명, 두명 늘어나게 되고 한명의 PM으로는 고객 대응이 원할하게 되지 못하게 되면서 1차 고객대응을 위한 개발자가 생긴다.

이 사람이 CS의 시초가 된다.

이 역시 고객이 늘어감에 따라 CS 인력이 점점 늘어가게 되며 요구사항의 갯수도 기하급수적으로 폭발한다.

모든 요구사항을 모니터링 하면서 고객들에게 바로 바로 피드백 해주려면 CS들의 역할이 점점 더 중요해지게 되었다.

그리고 그렇게 걸러진 요구사항이 다시 PM에게 넘겨지게 된다.

PM은 이렇게 전달받은 요구사항을 개개의 개발자들에게 건네주며 해당 요구사항이 해결되도록 도와주고 요구사항의 진행상황을 CS에 전달하게 된다.

하지만 요구사항의 갯수가 늘어나면서 PM의 업무는 요구사항 관리가 아닌 이슈에 대한 관리자로 변질하게 된다.

이슈는 그것만으로 비용이 엄청나게 소요되는 업무이다.

이슈는 일반적인 요구사항과는 다르게 부가적인 추가 업무를 발생시킨다.

가령 대책회의, 보고서 작성 등등

이런 업무들은 요구사항 해결 자체에는 전혀 도움이 되지 않으며 단지 고객의 불만을 조금이라도 덜어주기 위한 관리 요소일 뿐이다.

또한 그에 대한 비용도 사실상 만만치않다.

이를 수행하기 위한 사람은 개발에 대한 지식뿐만 아니라 결정 권한과 책임을 위해 조직에서의 지위도 어느정도 필요하다.

물론 우리팀이 그런 이슈들을 해결하기 위해 구성된 것은 아니다.

그런 이슈들의 교통정리를 위해 생겨난 팀이라고 보는게 더 맞다.

과거 리더와 팀장들이 이슈들의 혼돈속에서 허우적거리는 것을 방지하기 위해 짜잘한 이슈들은 우리선에서 개발자들이 해결할 수 있도록 직접 조정해주고 민감하고 크리티컬한 이슈들은 별도로 분류하여 팀장, 리더들이 해당 이슈들을 놓치지 않게 관리해주는 역할을 담당하기 위해 존재한다고 생각된다.

만일 우리가 이런 역할을 제대로 해주지 못한다면 다른 유효한 기능이 존재한다 하더라도 최초의 근본 취지에 어긋나기 때문에 존재의 의미가 없다.

그리고 이제는 Job운영방식이라는 새로운 시스템을 또다시 도입하고 있다.

조금은 엉성하고 몇몇 사람들은 부정적인 시각으로 바라보는 사람들도 있지만 우리는 변화해야 한다는 취지에 의해 일단은 새로운 운영방식을 현재 연구소 조직에 적용했다.

그리고 커다란 문제점에 봉착했는데 운영방식 자체가 Job 중심으로 구성되다 보니 Job 은 수도없이 계속해서 생기는데 인력은 이미 한계를 드러내고 있고 경영진은 계획을 위해 제한된 시간내에 완료될 Job들을 꾸겨넣는데 그에 대한 압력이 고스란히 개발자들에게 전달되는 양상으로 현재 진행중이다.

이것은 내가 이번에 새롭게 생성된 Job을 진행하면서 겪은 일이기도 하다.

과연 인력 부족이라는 절대적인 어려움 속에서 연구소 운영만을 위한 조직을 구성한 것이 얼마나 도움이 될까?

우리가 실패한다면 그제서야 부랴부랴 인력을 충원하지나 않을까 생각도 해본다.

확실한 통찰력으로 사람들이 올바른 길로 갈 수 있도록 가이드하는 보스와

역경과 고난도 함께한다는 믿음으로 모두를 이끌 수 있는 리더...

현실적으로 보스 보다는 리더가 팀을 유지하는게 좀 더 수월하다.

보스형 관리자는 사람들에게 질타를 많이 받는다.

왜냐하면 항상 결과로만 평가 받기 때문이다.

성공이 쉬우면 누구나 보스하지...