업무 공유를 하지 않으면 일도 안한것이다.

본 글은 선임자로서 지시 내리는 사람 입장에서 작성한것입니다. 읽을때 참고하세요

어떤 개발자 중에 일은 그런대로 하지만..
업 무 공유와 소통 능력이 부족해서 항상 업무 능력에 대해 좋지 않은 평가를 받는 사람이 있다.

고 객사에서 SW 문제점이 접수되어
담당 개발자에게 급한 사항이니 처리해서 보내라고 하였다.

그 렇게 어려운 내용도 아니라 당연히 당일 중에 처리 해서 보낼거라고 기대를 하였지만
하 루가 지나고 이틀째가 되어도 어떻게 되었는지 전혀 정보 공유가 없었다.
그 개발자가 다음날 몸이 아프다고 일찍 들어가서
다음날 다른 개발자에게 처리해서 보내라고 이슈 내용에서 담당자를 수정하였다.
그런데..
그 다음날 고객사에서 테스트 해서 확인하였다고. 메일이 날라왔다 물론 추가 요청 사항은 있었다.

나 중에 확인해 본  결과, 원래 담당 개발자는 내가 지시한 날 처리해서 메일로 보내 놓고서
나 에게 정보 공유(이메일)를 하지도 않았고, SVN 서버에 소스를 올리지도 않았으며,  이슈 관리 시스템에서 상태를 바꿔 놓지도 않았다. 3~4가지의 공식적인  업무 공유 및 소통 수단 중에서 단 한 가지도 제대로 처리하지 않은 것이다.
내가 그 진행 내용을 파악할 수 있는 방법은 전혀 없었다.

메일 보낼때 [참조] 란에  회사 전직원에게 보내도록 하는 습관만 있더라도 이런 문제는 없었는데 말이다.

그 개발자의 업무 소통 부재로 인해서 다음과 같은 문제점이 발생 했거나 가능성이 있다.

1. 고 객사 담당자가 나에게 진행 여부를 물어 봤을때 대답을 할 수가 없다.

2. 업무 지시 내용을 제대로 처리하지 않고 있다고 생각하기 때문에 그 개발자에 대해 불신이 생긴다.

3. 일 을 지시하는 입장에서 그 사람에게 시킨 일이 마무리 됐는지 알 수 있는 방법이 없으므로 답답하다.

4. 처 리가 안될 줄 알고 [이슈관리시스템]에서 다른 사람에게 담당자를 재할당하는 번거로운 문제가 생긴다.

5. 나 중에 진행 사실을 알게되어, 그 이슈는 이미 처리 된 것이므로  또 다시 이슈 담당자를 원래 개발자로 바꿔주어야 한다.

6. 만 약 재할당한 개발자가 소스 수정을 시작했다면.  똑같은 업무를 두 사람이 중복해서 한 것이기 때문에 회사 차원의 인력 낭비가 발생한다.

7. 재할당한 사람이 수정하고 SVN 서버에 까지 소스를 올려버렸다면. 나중에 원래 담당자가 소스를 올리려고 할 때  충돌이 발생한다. (물론  100% 원래 담당자의 책임이다  )

8. 위 의 모든 문제점이 발생하지 않아도 되는 것인데 생기게 되므로,  지시하는 사람은 엄청난 짜증이 몰려온다.

위 의 내용은 업무 공유에 대한 단편적인 예를 들었지만.. 회사에서 프로젝트를 진행하면서 업무 공유 부족으로 인해 발생하는 문제는 셀 수 없을 만큼 많을 것이다.
다만  정확히 지적하고 넘어가자니 쪼잔한거 같고, 계속 같이 일하자니 답답하고 이런 상황은 수도 없이 발생한다.

아주 간단한 업무 공유 방법을 제대로 지키지 않아서 위와 같은 수많은 문제점이 발생하여 회사 전체의 개발 효율을 좀 먹고 있는데도 불구하고 , 이것을 신경 쓰지 않고 별로 중요하지 않은 것으로 인식하고 있는 개발자가 있다면.. 하루 빨리 업무 공유의 중요성에 대해서 심각하게 고민해보고 실행하던가 , 그것을 못하겠다면 SW 개발이라는 직업을 떠나야 할 것이다. 그것이 더 이상 다른  동료와 회사에 피해를 주지 않는 유일한 방법일 것이다.