SI 프로젝트 온보딩 프로세스 문서화 후기
온보딩 프로세스 문서를 만들기로 한 이유
프로젝트 투입 후 일주일 동안 뭘 해야할지 몰랐다. 가지고 온 Java 책만 주구장창 읽었다. 여긴 어디 나는 누구... 계정이 생기고 내 컴퓨터가 설치됐지만 뭘 봐야할지 잘 모르겠어서 혼란스러웠다. 프로젝트 투입 직후... 아무도 내게 관심이 없어서...며칠 동안 좀 외로웠다. 마음 속으로 '날 챙겨주지 않는군.. 책이나 봐야겠다 또르르..' 하고 있었음. (당시 날 안쓰럽게 본 다른 팀 선임 한 분이 챙겨주긴 했지만 전반적으로 분위기가 차가웠다. 이후에 차례로 소개받은 동기들과 프리랜서분들이 잘 챙겨줘서 빠르게 적응할 수 있었다.)
그래서 신규 유지보수 인력이 투입됐을 때 나와 같은 멘붕을 겪지 않도록 온보딩 문서를 만들어야겠다고 생각했다. 이미 컨플루언스에 가이드가 준비돼 있지만... '신규 인력을 위한 온보딩 가이드'로 정의할 수 있는 문서는 없었다. 설치부터 개발, 테스트까지 전체 흐름을 한눈에 볼 수 없었음. 그래서 하나하나 탭을 들어가봐야 했음..^^..
프로젝트 오픈 직전, 코드프리징 상태라 할일이 없을 때 온보딩 가이드라인을 작성했다.
대상
신규 투입 개발자, 유지보수 개발자. 특히 신입! 내가 신입이었으므로 신입 눈높이에 맞춰서 작성.
구성
- 필요 계정 리스트. 신청 방법과 ID, 초기 비밀번호 공유
- Front, Back 설치 가이드 / 빌드 오류 발생 시 대처 가이드
- DB DataWare 가이드라인 : 축약어 검색, ERD
- Back 디렉토리 및 코드 템플릿 (Controller, Service, DTO, Return / Parameter type 등)
- Front UI 라이브러리 , 그리드 라이브러리 소개
- Front 디렉토리 및 코드 (추가 예정. 현재 소속돼 있는 스크럼의 Front와 타 스크럼의 구성이 달라서 나눠 작성할 필요 있음)
- 개발/운영 로그 보는 법 (추가 예정)
- 그 외 트러블슈팅 (추가 예정)
이렇게 구성한 이유?
하나하나 따라가면서 전체적인 업무 프로세스를 익힐 수 있도록 했다.
전체 스크럼이 공통적으로 사용하는 기술로 내용을 구성했다. 어떤 스크럼에 소속돼 있어도 도움 받을 수 있을 것!
피드백
- 신규 유지보수 분들 교육에 해당 자료가 쓰였다!
- 신규 유지보수 동료분이 긍정적인 피드백을 주셨다: "이렇게 정리를 해두니 보기 편하다!"
- 동료들 : 정리해두니 괜찮네~
한계
공식 온보딩 가이드가 아니라서 이 문서도 결국 암암리에 전해지게 될 거라는 거 😥😥
후기
이전까지 문서화를 해본 적이 없었는데.. 해보니까 파편화된 지식들이 머릿속에서 하나로 정리된다. 또 내 지식이 다른 사람에게 도움이 된다는 점도 좋았다. 구전설화마냥 말로 진행되는 온보딩 가이드 이제는 링크 하나로 전달 끝! (물론 전체적인 설명은 필요하다) 전달할 내용을 빠뜨릴 일도 없고, 일관성도 생긴다. 엥.. 이렇게 좋은 기능을 나만 빼고 사용하고. 있었어..? 같은 일도 경험할 필요 없을 것.
SI 프로젝트에서는 그 누구도 책임을 지고 싶어하지 않아하는 거 같다. 특히 도망가버리면 그만이라는 인식이 팽배하다... 그래서 스쳐지나가는 사람들이 많은 듯. 때문에 조직장들도 팀원 하나하나에게 정을 주지 않으려는 느낌이 강하다. 프로젝트 진행 내내 매니지먼트가 잘 안 된다는 느낌을 받았다. 주니어가 오든말든 그냥 내버려두는 경우도 많은 거 같다.
그런 상황에서도 난 열심히 살아남았고... 프로젝트가 곧 끝나가지만.. 내가 겪은 차가움을 다른 사람을 부디 겪지 않길 바라며... 누구에게라도 도움이 됐으면 하는 마음으로 온보딩가이드를 작성하고 있다.
뿐만 아니라, 문서화의 강력함도 경험했다. 일단 1) 정보전달이 편리하고 2) 머릿속 지식이 정리되는 느낌 3) 까먹었을 때 다시 보기 좋음. 인간의 기억력은 유한하므로, 문서화를 해두는 게 정신건강에 좋다. 현재 맡은 화면들에 대한 문서화도 시작함!