들어가며
팀이 3인 체제로 들어선 지 이제 3개월 정도가 되었습니다. 9월부터 지금까지 메인 개발자로서, 팀 빌딩이나 업무 분배 등에 대하여 어느 정도 자율성을 보장받은 상태였기 때문에 위한 이런저런 새로운 시도들을 해볼 수 있었고. 그럭저럭.. 성공적으로 두 번의 컨텐츠 업데이트를 완수했습니다. 이것은 그 결과에 대한 기록입니다.
1. 온보딩 페이퍼
원래는 인수인계문서였지만. 한 프로젝트 더 진행하게 되면서 방향을 바꾸어 온보딩페이퍼로 전환했습니다. "누구든 이 페이퍼 하나로 세팅부터 커밋까지" 할 수 있게 만드는 것을 목표로 작업했는데, 2개월 전에 잡아뒀던 제주여행 날짜에 첫번째 신규개발자 입사일이 겹치게 되면서 이 성능(?) 효용(?) 검증을 강제로 진행하게 되었습니다.
다행히 새로 들어오신 분(이후로 DEV_1이라고 지칭합니다)이 잘 수행해준 덕분에. 여행을 마치고 회사를 복귀했을 때 몇 가지 승인을 기다려야 하는 사항 외에는 전부 세팅이 완료되어 있었고, (프로젝트의 코드베이스에 대한 감도 잡을 겸) 몇 가지 작업을 즉시 부탁할 수 있었습니다. 이후 1주일 텀을 두고 한 분이 더 들어오게 되었고 (이후부터는 DEV_2라고 지칭합니다). 온보딩 페이퍼를 통해 1:1로 세팅을 가이드해주지 않아도 되어 3일 정도 시간을 벌 수 있었습니다.
나름 성공적인(?) 온보딩 페이퍼가 될 수 있었던 이유를 꼽아보자면 다음과 같은 요소들이 주요하지 않았나 생각하는데.
- 해외유학을 준비하는 미대생들을 대상으로 프로그래밍을 가르쳤던 경험을 바탕으로. "아무것도 모르는 사람"에게 무언가 알려주기 위해서는, 어디서부터 어떤 것들을 전달해야하는지 대충 알고 있었고.
- gif 파일로 각 스텝들을 촬영해두어 이미지만으로는 전달할 수 없었던 디테일을 제공할 수 있었고
- "시간이 떠서 멍하게 앉아있는 순간"이 최대한 발생하지 않도록, 최대한 이것저것 읽어볼 수 or 건드려볼 수 있는 컨텐츠를 제공했던 것
들을 통해 조금 긍정적인(?) 결과를 만들어낼 수 있지 않았나. 생각합니다.
2. 코드리뷰
코드리뷰는 무사히(?) 협업하기 위해서는 정말 필요한 테스크라고 생각해서 강력하게 도입을 추진하고 있지만.. 환경적인 요인으로 인해 현재는 조금 난관에 부딪히는 중입니다.
다만, 다행히도 "코드는 읽을 수 있는 사람이 많을수록 좋다"는 명제는 합의가 된 것 같아 다행이라고 생각합니다.. 현재 프로젝트의 코드베이스에는 "_" 한 글자만 적혀있는 커밋메시지나, 3~5개 변경점을 한 번에 푸시했던 흔적 등이 있는 상태라.. 제가 메인을 맡고 있을 때엔 이런 커밋이 히스토리에 남는 것을 가급적이면 진짜 지양하고 싶다고 양해를 구했고. 다행히 합의가 잘 되어서 현재는 작업을 작은 단위로 쪼개 최대한 상세하게 메시지를 작성하여 푸시하며, 애매한 부분에는 주석을 남겨서 최대한 쉽게 코드를 파악할 수 있도록 하고 있습니다.
그리고, 비록 코드리뷰를 공식적으로 진행하고 있지는 않지만. 출근 후, 점심 먹고, 퇴근 전 30분씩 새로 브랜치에 푸시되는 작업들을 하나씩 검토하면서, 나름대로 변경점들을 최대한 팔로업하여 숙지하려고 하는 중입니다.
특히 내가 짜지 않은 코드라고 할지라도, 어떤 요청이 들어오건 어떤 이슈가 제보되건 내가 1차적으로 대응할 줄 알아야 일을 도와주는 사람들(DEV_1, DEV_2)가 안심하고 작업에 집중할 수 있을 것이라 생각하기 때문에 의식적으로 이와 같이 행동하고 있습니다. (아직까지는, 프로젝트 규모가 크지 않고 변경점도 많지 않아서 그럭저럭 할만한 일이라고 느껴집니다).
손이 빌 때에는 틈틈이 명문화된 코드 컨벤션을 작성하고 있는데, 구글 C# 스타일 가이드나, MS C# 가이드 등을 참고하고 있습니다. 다만 완성하더라도 현재의 프로젝트에 바로 적용하기는 어려울 것 같고.. (MS가이드 에서도, "컨벤션적으로 올바른 것보다 프로젝트가 이미 따르는 규칙을 준수하라고 했기 때문에..) 24년 상반기에 곧 시작할 신작에서부터 적용할 수 있을 것 같습니다.
※ 9월 말부터 지금까지.. 퇴근하고 나면, 코드 컨벤션과 온보딩문서를 작성하는데 대부분의 연구시간을 소모했기 때문에 개인적으로 공부한 내용들을 정리하여 공유할 수 없었습니다. 조만간 작성이 다 끝나고 나면, 근거자료로 사용하기 위해 개인적으로 쌓아둔 자료들은 (주로 인터넷에 공개된 자료이기 때문에) 한번 정리해볼 수 있을 것 같습니다.
3. 업무시트
개발 중 발생하는 이슈 관리 파이프라인 일원화를 위해 만들었던 QA시트가 현재 개발자가 어떤 일을 하고 있는지 보여준다는 것에서 착안하여. 해당 시트를 확장해 개발자 업무시트를 만들었습니다.
그리고 해당 링크를 기획 & 디자인분들에게 공유하여, 있었으면 좋겠는 기능들, 버그, 사소한 수정 등을 기입할 수 있도록 했고, 업무일지 페이지를 신설하여 매일 어떤 작업을 하는지, 이번 업데이트에는 어떤 기능들이 들어가야 하는지, 이번 분기에는 무엇을 추진하고 있는지 등을 각 페이지별로 한눈에 알아볼 수 있도록 리스트업 해 두었습니다.
이를 통해, 각 개발자가 어떤 작업을 하고 있는지 같은 개발자 뿐만 아니라 다른 분야의 팀원들도 한눈에 파악할 수 있도록 하여 "이 작업 지금 누가 하는 중이에요?"를 물어보기위해 낭비되는 시간을 줄였습니다.
-
"시트 내 일일 업무일지 페이지에 각자 하루하루 뭐했는지 기입하세요" 지시하면 쓸데없는 일 + 1이 된다는 것을 알고있기 때문에 (보고하는 사람은 읽는사람이 어떻게 느낄지 모르기 때문에, 뭔가 쓰기 애매한 날에는 억지로 항목을 짜내느라 극심한 스트레스를 느끼게된다.) 제가 주도권을 가지고 대부분의 관리를 수행하고 있습니다.
구체적으로는, 업무종료 후 따로 30분~1시간 정도 푸시된 파일들을 검토하는 시간을 갖는데 (2번항목 참조) 해당 검토가 끝나면 한문장 정도로 정리해서 업데이트를 진행합니다.
마치며
과연, 잘 하고 있는건지.. 뭐, 일단 해 봐야 아는거겠죠. 발버둥 치는 중 입니다. HAHA
'DevLog' 카테고리의 다른 글
| DevLog - 5년짜리 사이드 게임 계획 (2) | 2024.01.29 |
|---|---|
| DevLog - 2023 결산 (0) | 2024.01.01 |
| DevLog - 바쁘지 않습니다! (2) | 2023.10.09 |
| DevLog - 바쁩니다(2).. (0) | 2023.09.05 |
| DevLog - 메인을 맡으면서 달라진 것과 달라지지 않은 것 (0) | 2023.08.04 |