개발 일지 feat. Notion

TO DO 리스트

현재 회사에 다니기 전까지는 업무 내용에 대해 일반적인 TO DO 리스트를 작성했다. 그냥 칸반 보드에 그날그날 할 일을 적고 체크하고 처리하지 못한 일은 다음 날로 넘기며 그렇게 흘러갔다. 문제 인식 → 커뮤니케이션과 개발 → 문제 해결 그리고 다시 처음으로 돌아간다. 물론 이 기록을 다시 방문하는 일은 매우 드물었다.

이직 결심을 하고 블로그를 시작하면서 기록하는 방식에 변화를 주기 시작했다. 단지 작업한 내용만 정리하는 것이 아니라 내 생각과 경험 또는 시간을 쏟아 만든 예제를 곁들인 것이다. 내 생각이 남들의 생각과 크게 다른 것은 아니지만 인터넷에 넘쳐나는 훌륭한 글들을 어설프게 복제하고 싶지 않았기 때문이다.

개발 일지

이러한 기록 방식의 변화는 매일 업무를 기록하는 데에도 영향을 미쳤다. 출근 첫날부터 지금까지 3개월간 빠짐없이 작성한 개발 일지는 점차 개인 저장소로 변해갔다. 기능이나 이슈와 관련하여 어떤 어려움이 있었고 어떻게 해결했는지, 오늘 작성한 코드에서 개선할 부분은 없는지(당연히 있다!), 누구와 상의하고 협업할지, 작성해서 공유한 개발 문서들, 해결하기 위해 참고한 링크들, 마지막으로 그날에 대한 총평까지 종합적으로 내용을 정리하고 있다.

이렇게 기록한 업무 일지를 통해 내가 무엇을 얻었을까? 매일 작업을 되돌아봄으로써 내가 뭘 해왔고 뭘 하고 있으며 앞으로 뭘 해야 하는지 맥락을 잃어버리지 않게 되었다. 매일 쏟아지는 작업 목록들 속에서 우선순위를 설정해 중요하고 급한 일은 먼저 처리하고 사소한 일은 빼먹지 않고 중간중간 끼워 넣을 수 있었다(✨기억력이 좋아 보이는 느낌을 주는 건 덤이다).
덕분에 주 1회 있는 스프린트에서 회고하기 위해 내가 해야 할 일은 지난 한 주간의 업무 일지를 살펴보는 것뿐이다. 내가 배운 것, 인식한 문제점, 개선을 위한 아이디어 중에 팀원들과 공유하고 싶은 내용을 염두에 두면 보다 주도적으로 회의에 참여할 수 있게 된다.

템플릿

개발 일지는 간단한 일기 형식으로 작성하는 것도 괜찮지만 참고한 템플릿과 내 입맛에 맞게 어떤 항목을 추가했는지 공유하고 싶다. 내 경우에는 노션에 진심인 사람이 만든 업무일지 2 노션 템플릿을 기반으로 변형하여 사용 중이다. 어디까지나 내 스타일에 맞춘 것이므로 참고하여 본인에게 맞는 스타일을 찾아가길 바란다.

먼저, 개발 일지 페이지를 살펴보면 3가지 항목이 있는데 각각 Backlog, Issue, Idea이다. 페이지에 들어오자마자 한눈에 보이게 하려고 중앙에 배치했다. Backlog에는 학습/조사/분석/문서화/공유할 사항을 모아두었다가 시간을 내서 처리한다. Issue에는 개발 과정에서 발생한 이슈 중 까다로운 문제들을 뽑아 놓았는데 팀 노션과 내용이 중복되지만 리마인드를 위한 것이다. Idea에는 말 그대로 생각난 아이디어를 적고 기회를 봐서 업무 과정에 반영한다.

개발 일지 상세 페이지는 가져온 템플릿과 크게 다르지 않다. 태그라는 속성을 추가했는데 'live 배포', '스프린트' 등으로 이벤트를 강조할 수 있도록 했다.

1. 출근하면 출근 시간을 기록한다.
2. 어제 개발 일지와 팀 노션을 보고 우선순위를 정해 오늘 할 일에 추가한다.
3. 업무 상세에 작업한 내용을 자세히 작성한다. 이때, 무엇을 개발하고 어떻게 문제를 해결했는지뿐만 아니라 그 과정에서 무슨 생각이 들었고 왜 그런 판단을 내렸는지 최대한 '나'를 중심으로 적는다.
4. 오늘 마무리하지 못한 일이 있다면 내일 할 일에 간단히 정리한다.
5. 특별한 이벤트가 있었다면 태그를 추가한다.
6. 아이콘(😀 🙂 😑 😨 😱)을 통해 업무 만족도를 평가한다.
7. 야근했을 경우 발생한 이슈 속성에 야근한 시간과 어떤 문제 때문이었는지 작성한다.
8. 퇴근 시간을 기록하고 퇴근한다.

개선 아이디어

• 구글 검색 히스토리: 온종일 어떤 걸 검색했는지만 봐도 문제 & 솔루션을 동시에 확인할 수 있을 것 같다.
• 월간 리뷰: 블로그 글감도 찾을 겸 좀 더 긴 기간의 기록을 되돌아보고 정리하는 시간을 가지고 싶다.
• 예상 소요 시간 vs 실제 소요 시간: 내 능력에 맞는 개발 일정을 산정하는 능력을 기를 수 있지 않을까?
• 병목 지점: 업무를 방해하는 요소는 없는지 체크해볼 필요가 있다.

개발 일지를 더 활용할 수 있는 아이디어를 떠올려 보았는데 적다 보니 과유불급이 아닌가 싶어 우선 병목 지점이 있는지만 체크하기로 했다. 무엇보다도 일지인 만큼 지금처럼 매일 기록을 남기는 것이 중요한데 항목을 늘리면 부담을 줄 수 있다는 생각이 든다. 다음 3개월은 오히려 일지에서 뺄 부분이 있는지 고민해보고 덜어내는 시간을 가지려 한다.

2022년 7월 31일자로 개선 사항이 있습니다. 자세한 내용이 궁금하시다면 다음 글을 참고해주세요.