좋은 인수인계에 대한 생각

한 팀에서 이동 없이 쭉 있었지만,
내부에서 업무의 확장과 변경 등의 인수인계는 몇 번 거친 적이 있다.
선임에게 새로운 일을 인수인계 받기도 했고,
내부에서 업무 분장을 조정하며 선임에게 인수인계를 하기도 했고,
부사수에게 내가 하던 일을 넘기기도 해 봤고,
프로젝트에게 인수인계를 받기도 했었다.

만두 대리가 다소 귀찮겠지만, 올해는 옆에서 김사원 앉혀놓고 작업할때 설명하면서 진행해 주세요.
교육도 같이 다녀와요.

 
 
오랫동안 해오던, 나름대로의 애착을 가지고 있던 시즈널 업무를 떠나보낼 때가 가까이 왔다.
판단의 주체가 오롯이 나였던 건 아쉽게도 아니지만,
상황상 다른분야 업무 로드가 늘어가면서 어쩔 수 없는 위에서의 결정이었을 것이라고 생각한다.
 
사실 후임자에게 내 업무를 떼어주는 인계자의 역할이나, 멘토/사수로서의 경험이 없는건 아니다.
하지만 한번도 이에 대해 곰곰이 생각해본 적이 없었다.
좋은 사수로서, 업무에 무사히 온보딩시키는 것도 시니어로 가는 역할 중 하나일 것이라는 생각이 든다.
그래서 어떤 마음을 가져야 할 지 생각해보게 되었다.
 

다 일을 넘기기 위한 빌드업이었던 것이다.

 
신입사원 시절, 여름이었는데 연말정산 과년도 조견표를 넘겨주면서
만두 사원, 이런 건 직장인의 기본 소양이야. 미리 알아두라구~ 하던 나의 사수.
이런것도 미리 챙겨주는 제법 스윗한 사람인 줄 알았는데, 반 년 후 나는 그 업무를 하고 있었다.
키워서 잡아 먹어야지 라는 말이 딱 어울리는 그런 빌드업.
 
그정도의 빌드업을 하기에는 시간이 충분치 않은 것 같아 리더의 의중을 파악하기 위한 몇 가지 질문을 했고
3가지 정도의 근거를 도출할 수 있었다.

과장님, 인수인계 준비하라는 말씀으로 이해하면 될까요?

 
1. 내 업무 로드 증가가 확실시되고 있는데, 내 업무를 덜어갈 사람이 필요하다.
-> 팩트다. 업무의 양이 증가하고 있고, 커버해야 하는 조직도 많아졌다.
완전히 새로운 처음부터 개척해 나가야 할 긴호흡의 많은 일들이 기다리고 있음을 알고있다.
 
2. 백업으로 시작하여, 개념을 이해하고 나면 자잘한 것부터 김사원에게 시킬 수 있는 일들이 많아진다.
-> 이 업무는 다소 도전적일 수 있지만, 김사원 정도의 연차에서 적절한 성장이 가능하다.
 
3. 나의 경우, 사수를 백업하며 자체 결과 검증 프로그램을 별도로 만들었다.
이를 통해 업무내용을 이해함은 물론,
기존 소스를 고도화하고, 클렌징하여 가독성과 유지보수성을 높이고 성과를 내는 데에도 도움이 되었다.
이런 별도의 과제를 통해서 흡수와 체화, 그리고 그 이상의 새로운 성과 창출까지 기대할 수 있다.

반응형

 

선배, 일단 교육 다녀오래서 신청을 하기는 했는데...
이거 제가 들어야 하는 이유가 뭘까요?

 

회사가 교육비와 시간을 괜히 투자하지 않는다.
다 업무에 써먹으려고 하는거다.
교양 상식을 위한 교육이 아닌, 실제로 업무를 투입하기에 앞서 이에 대한 개념을 이해하기 위한 공부가 필요하다.
왜 필요한지에 대한 이해를 시켜주기 위해 노력했다.
긴 기간이 될 텐데, 무난하게 흘러가길 바란다.
나는 이 내용을 어떻게 하면 잘 전달할 수 있을지를 이만큼 고민하고 있는데,
고민한 보람이 있는 기간이 되었으면 좋겠다.

---

무난한 담당자 변경이나, 원만한 퇴사가 아닌 다소 껄끄러운 상황에서 억지로 인수인계를 받은 적도 있었다.
아니, 말이 좋아 인수인계지만 사실상 자료 파일 한두개와 엉망 진창 소스만 남아있는정도.
(그 사람이 만든 소스로는 몇 년 동안 잊을만하면 한번씩 문제가 생기곤 했다.)
당연히 히스토리를 알 수도 없었고, 왜 이걸 이렇게 해야 하는지도 알 수 없었다.
주어진 자료가 부실해서, 자료만 보고 쫓아 가기에도 벅찼다.
두 세 사이클 정도를 허덕거리며 버티고 나니, 그나마 겨우 조금 숨을 쉴 수 있을 것 같았다.
원만한 인수인계 체계가 작동되었다면, 시행착오는 훨씬 줄었을 거라고 생각한다.

---

 
그런 경우가 아닌 보통의 경우,
사용하는 변수, 어떤 작업인지에 대한 설명, 관련 이슈사항 등을 정리한 목록을 주로 받게 된다.
시간이 남으면 이를 재구성 및 현행화 해 보기도 하고, 코드의 수정 이력을 따라가 보기도 한다.
나의 경우 작업 일지를 남긴 적도 있다.

실제 일지가 아닌 이미지입니다.

예를들면
2023년 12월 6일, 오둥 책임님한테 QQQQ 건에 관련하여 문의전화 옴. -> AAAA라고 응대함
2023년 12월 5일, 곽철 수석님하고 꽥꽥 작업 진행
이런식.
메일 백업은 기본에, 메신저 대화 내용까지 아예 박제하여
다음 사이클이 되었을때 어떤 질문이 자주 나오는지, 이에 대한 답변은 어떻게 하면 될지,
작업은 어떻게 해야하는지 정리한 그런 일지.

728x90

나는 이 작업에서 꾸밈 양식을 별로 중요하게 생각하지는 않는데,
(그럭저럭 깔끔히 볼 수 있을 정도면 된다고 생각한다. 미술이 아니니까.)
내 옆자리의 동료는 이를 완벽히 깔끔하게 체화해서 새로운 문서를 미적으로 깔끔하게 만들어 내어 인수인계 하는 걸 봤다.
그렇게까지 디테일한 문서정리 작업 까지는 사실 필요 없을 수도 있지만, 심미적으로 일단 멋지다.
일을 잘 하는 사람의 범주 안에는,
주어진 일에서 새로운 체계를 발견하고 조직하는 걸 잘 하는 사람이 포함된다고 생각한다.
그런 사례였다.
 
 
다른 조직에서는 어떻게 인수인계가 발생하는지에 대한 사례도 궁금하다.
이 글을 쓰기 전에 본 어떤 글에서는, 이런 일이 애초에 안 생기도록 평소에 코드 리뷰를 잘 해야 한다는 주장도 읽었다.
하지만 평소의 리뷰와 업무 공유, 백업체계 구축도 당연히 중요하겠지만
당장 사람 들고 나며 손이 바뀔때에 대한 단기속성 대비도 필요한 일이라는 생각이 들어서,
이 글을 쓰면서 나는 인수인계 기간 어떤 태도를 취해야 할 지 생각을 해보게 되었다.
 
항상 좋은 일만 있을 순 없겠지만,
나에게 인계했던 분들을 생각하면서 어떤 점은 반면교사로, 어떤 점은 배울점으로 받아들여야지.