서비스기획, 인수인계가 처음이라면
서비스 기획자의 인수인계 문서 만들기
요즘 푹 빠진 드라마가 있다. 제목은 想見你(상견니).
대만 드라마인지라 생소하기도 하고 제목 역시도 우리나라 말로 읽으니 다소 우스꽝스러운 발음이지만, 그렇다고 편견을 가져선 안 된다. 편견을 한꺼풀 벗겨내면 무려 타임슬립(그리고 미스테리 스릴러! 로맨스물!까지..)을 주제로 하는 스토리와 분위기 모두 완벽한 고퀄리티의 드라마를 만날 수 있다.
想見你(상견니) 한번 시작하면 현생이 엉망진창이라는 그, 드라마.그러고 보니 타임슬립을 주제로 하는 콘텐츠는 만화, 드라마, 영화 곳곳에서 상당히 자주 만날 수 있긴 한 것 같다. 현재의 주인공이 과거로 돌아가 사건을 해결하고 미래를 바꾼다든지, 과거 또는 미래로 시간을 이동해서 사랑하는 사람을 만난다든지 뭐 이런 내용들이 대부분이긴 하지만. 흔한 것 같지만 또 재미있어서 소재로만 절반은 먹고 들어가는 느낌이 든다.
인수인계로 검색해서 이 글에 들어왔는데, 갑자기 무슨 뜬금포 드라마 영업이냐고? 당황하지 말고 계속 읽어주세요- 인수인계하면 이게 떠올라서 그래요.. (는 핑계고 사실 드라마가 너무 재미있어 후유증이 큰 영향일지도..)
인수인계 : 과거의 나에게로 타임슬립해서 업무를 알려준다고 가정하고-
누군가 인수인계란 도대체 뭔가요? 어떻게 준비해야 하나요? 라고 물어보면 나는 이렇게 대답하고 싶다.
"이 일을 하나도 모르는 과거의 나에게 타임슬립해서, 업무를 설명해준다고 가정하고 써 보세요.”
일반적으로 인수인계란 두 가지 상황에서 발생한다.
하나, 퇴사하기 전. 둘, 업무 담당자가 변경될 때.
퇴사라는 것은 한 사람의 인생에서 자주 겪기는 어려운 일이다. 이직이라는 것이 매달, 매년 주기적으로 발생하는 일이 아닐뿐더러 어느 누구에게는 아직 한번도 경험해보지 못한 일일 수 있기 때문에. 업무 담당자가 변경되는 일 역시 퇴사보다는 아마 더 빈번하게 나타날 가능성이 있겠지만, 이것도 마찬가지로 흔한 경험은 아닐 거다. 다시 말해 대부분의 직장인들에게 인수인계란 익숙한 상황은 아닐 수 있기에 누군가에겐 어떻게 준비해야 할지, 어떤 식으로 진행해야 할지 막막하게 느껴질 수 있으리라 생각한다.
인수인계가 답답하게 느껴진다면, 나는 저 대답을 해주고 싶다. 과거의 '나'에게 돌아가 미리 알려준다고 생각해 보세요.
"번호 체크는 정말 헷갈리기 쉬운 실수야. 이런 실수는 하면 안되니까 꼭 더블 체크해야 해."
"이 담당자는 예민해. 늘 이런 질문이 들어올 수 있으니까, 대비해 두자."
"데이터 확인은 이 페이지에 들어가서 볼 수 있어. 단, 00시부터 06시까지는 배치가 도는 시간이라 확인이 어려운 점 꼭 참고하고"
“이 정도면 되겠지” 말고
인수인계는 내가 진행했던 업무를, 다음 담당자에게 인계하는 작업이다. '다음 담당자'가 같은 팀의 사람이어서 여러 방면으로 나와 업무적 공유가 많았던 사람일 수도 있고, 아예 경험이 없어 0부터 접하는 사람일 수도 있다. 요약하자면- 나만큼 이 업무에 대한 지식이 없는 사람일 것이므로 최대한 상세히 성심성의껏 전달하려는 작성자의 의지가 중요하다. (개인적 감정이나, 인수인계 과정에서의 예외 상황 등은 차치하고..)
너무 바보같은가, 너무 정직한가.. 하는 마음도 들지만 ‘이 정도면 되겠지’가 아니라 ‘이 정도도 모자랄 거야’ 의 마음으로 알려주고 정리하는 것이 좋더라. 그리고 다음 사람을 위해서가 아니라 나를 위해서.
인수인계 문서 쓰는 법
IT업종 외 다른 대기업은 어떨지 모르겠지만, (듣기론 인수인계서라는 문서 양식이 있는 것으로 안다) 세 번의 이직 동안 인수인계 문서 작성 전에 나는 늘 자유의 땅에 버려진 느낌이었다. 전임자가 나에게 전달해준 방식을 기억에 더듬어가며, 혹은 다른 이들이 작성한 포맷을 참고하여 작성하곤 했기 때문에..
누구는 위키 문서만 달랑 던지고, 이거 보세요- 만 시전하기도 했고, 어떤 사람은 '효닝님 이거 다 아시죠? 참조 드렸던 거 그대로 하면 돼요.' 하고 가신 분도 있고... 그래서 나는 내 다음 사람에게 그런 똥은 떠안겨주고 싶진 않았다. 그래서 나름대로의 인수인계 문서 포맷을 정리해서 최대한 빠뜨리는 부분이 없도록 체크하며 작성하려 노력하는 편이다. 아래에 그 포맷을 다시 간단히 정리해 보았다.
<인수인계 문서에 꼭 들어가야 할 내용들>
1. 인수인계 일정
보통 인수인계 절차는 아래 3단계로 진행해 왔다.
1) 문서 작성 → 2) 담당자 인계 (문서/서류/회의 등으로) → 3) 담당자 변경 안내
상황에 따라 다르지만 인수인계를 받을 사람과 1:1로 진행하거나, 팀장님까지 1:2로 공유하는 편이 보편적이었는데, 구두상으로 일정을 잡거나 편한 시간대로 회의 일정을 보내 인수인계를 하기도 했다. 그러다 보면 시간상 부족하거나 빠뜨리게 될 부분들이 생기고 이걸 처리하려면 곤란한 상황이 발생할 수도 있겠다는 생각이 들었다. 그래서 가장 처음 '인수인계 일정'을 넣는 편이다. 퇴사 혹은 업무 변경까지 N일이 남았다는 것을 기준으로 일자를 조율해서 기재한다.
내용은 보통 아래 골자를 기본으로 구성한다.
Date : 인수인계 진행 날짜
Detail : 인수인계 내용
Check : 완료 여부 (O/X로 표시하고, 참조할만한 링크도 같이 첨부)
PIC : 담당자 이름
인수인계 일정 예시2. 서비스 개요
이 부분은 옵션인데, 해당 서비스를 한번도 접해보지 않은 당사자가 인수인계를 받게 될 경우를 가정했다.
서비스에 대한 간단한 히스토리를 확인할 수 있는 페이지 링크나, FLOW등의 정보를 확인할 수 있는 링크를 같이 기재해 두었다. 상세한 내용이 아니라 요약 정도의 정보로 '서비스 개괄' 및 '세부 내용 인수인계 전 참고해두면 좋을 문서' 정도로 전달해준다.
세부 내용 인수인계 전에, 서비스 이해를 위해 간단히 참고하면 좋을 문서들을 모아두었다. 히스토리, flow, url 등.3. 담당자 & 업무 채널
함께 일할 담당 부서 및 담당자, 업무 채널을 간단히 소개한다. 업무 소개를 먼저 한 후에 해당 내용을 전달해도 이슈는 없으나, 나같은 경우에는 프로젝트별 담당자를 간단히 먼저 짚은 뒤에 상세 업무 리스트를 설명하는 편이다. (그게 뭔가 설명하기가 더 쉬운 느낌이라..)
내용은 보통 아래처럼 정리하는 편이다.
구분 : 서비스 및 조직 구분
담당자 : 담당자명 및 리더명 기재
세부 내용 : 해당 담당자와의 업무 진행 시 참고할만한 점을 기재한다. 으레 다들 짐작할 수 있는 '개발 논의는 dev담당자와 진행' 이런 것이 아니라, 문서로 봐서는 이해가 어렵거나 보편적이지 않은 프로세스일 경우에 명시한다. 예를 들어 담당자가 여러 명인 경우 특정 담당자는 a업무만 담당하는 경우, 혹은 디자인 회의에는 마크업은 무조건 같이 논의해야 한다는 사전 협의가 있었을 경우의 케이스 등이 해당된다.
업무 채널 : 커뮤니케이션이 진행되는 채널을 기재한다. slack, 메신저방, 이슈 보고 (jira, github 같은 링크..) 등에 해당하는 내용이 있으면 모조리 다 적는다.
기본적인 담당 조직뿐만 아니라, 업무 진행 시 참고할 점과 상세 업무 채널도 함께 기재하는 편이다.4. 업무 리스트
이제 인수인계의 꽃.. 업무 리스트를 적는 부분이다.
보통 업무 리스트는 아래 두 가지로 크게 구분한다. - project / history + backlog
1) project
프로젝트는 말 그대로 진행 중 프로젝트 단위로 기재하는 부분이다. 보통은 서비스마다 앱이든, 웹이든 버전을 구분하여 릴리즈를 관리하기에 버전 단위로 스펙을 정리하였다. 이미 출시된 이슈의 경우에는 모두 기재하지는 않고, 가장 최근 릴리즈 완료된 이슈 2개 정도를 함께 기재하는 편이다. 이 외에 프로젝트도 신규 프로젝트 및 서스테이닝으로 구분하기도 하지만.. 그때그때 다르게 성격에 따라 편집하면 된다.
서비스 버전 : 앱 혹은 서비스 버전 분
페이지 : 해당 버전의 릴리즈노트나, 기획안 정리 링크 등을 첨부한다. (링크 혹은 파일 모두 첨부)
릴리즈 일자 : 출시일 기재. 아직 출시 전 이슈라면 공란 혹은 예정일을 적는다
진행 상황 : DONE(완료) 혹은 각 단계를 기재한다
업무&상세 내용 : 상세 업무를 기재한다. 이슈 단위로 구분하고 업무별로 링크를 단다. 각 업무별로 체크해야 할 이슈들을 상세히 적는다. (이슈마다 참조할 페이지가 있다면 링크는 빼놓지 않는 편이다. 위키/슬랙/jira 등등 모두) 링크가 아닌 메일 커뮤니케이션을 했다면, 관련 메일도 압축하여 파일로 첨부하는 편이다.
2) history + backlog
history는 위 포맷과 동일하게, 출시된지는 한참 되었더라도 출시 과정에서 이슈가 있었거나 추후에 논의하기로 결정된 아젠다가 있었거나..한 경우에 대해서 모두 기재한다. 사실 신규 담당자가 이전 히스토리를 찾아서 정리하는 것이 맞지만 모든 스펙을 다 아는 건 현재의 나이므로 최대한 상세하게 적어서 전달하려고 노력하는 편이다.
히스토리별로 일전에 논의되었던 backlog 이슈도 적는다. backlog란, 이전에 이슈로 등록되었으나 우선순위 혹은 일정 때문에 미해결된 이슈를 통칭하여 부르는 말- 정도로 정리할 수 있겠다.
5. 업무 페이지 / 툴 정보 / 커뮤니케이션 채널
사내에서 혹은 해당 프로젝트를 진행할 때 사용되는 페이지, 툴, 컴 채널 정보 등을 기재한다.
업무 페이지 / 툴 정보 : 업무 시 활용되는 페이지 및 툴 정보를 기재한다. 사내에서 활용되는 주 페이지들이 대상이 된다. 예를 들어 이슈 보고용 툴(github나, jira..) / 사내 CMS / Zeplin / data page 등이 해당된다.
커뮤니케이션 채널 : 슬랙 채널, 대화방 정보 등
6. 회의 정보
정기적으로 하는 회의가 있다면 해당 내용도 기재한다. 프로젝트마다 진행되는 스크럼이 있거나, 정기 회의 날짜가 있다면 해당 내용도 같이 기재하고 관련 회의록 링크가 있다면 첨부한다.
프로젝트별 관련 회의 정보가 있다면 모두 기재한다7. 잔여 이슈
인수인계 시점부터 남은 이슈나 처리해야 할 항목들이 있다면 체크리스트로 정리해두는 편이다.
내가 해결할 수 있는 부분은 최대한 마무리하고, 다음 담당자에게 인계되어야 하는 부분도 구분하여 명시해두면 진행 중인 이슈도 빠뜨리는 일 없이 확인하는 데 용이하다.
8. Q&A
인수인계 진행 중 궁금한 부분이나 문의사항 등이 인입되면 정리해두는 표이다.
아무래도 구두와 문서로 하는 데에는 한계가 있기 때문에, 해당 표에 상시로 질문을 받고 답변을 전달해주는 과정을 진행한다. 1에서 기재한 인수인계 일정과 맞물려 함께 관리해두기 좋다.
사실 나는 인수인계는 다음 사람에게 내 일을 주는 마음으로 하는 편이다. 홀가분한 마음이라기보다 내가 키운 아이를 잘 정리해서 다음 사람이 더 잘 키워줄 수 있으리라는 마음으로! 받는 사람이 느끼기에 똥이 아니라, 자식같은 프로젝트라고 생각해주었으면 좋겠다.
이상 긴~ 인수인계 문서 포맷이었다. 회사마다, 상황마다 진행되는 업무들이 너무나도 상이하고 다양해서 이렇다 할 정답지는 아닐지라도.. 인수인계를 처음 하는 기획자- 막막한 부분들이 있다면 어느정도 해소되었기를 바라며! 앞으로 할 나의 인수인계도 무사히 잘 마치기를 바라며..
