저는 불행인지 다행인지, 업무 일지를 강제하는 회사를 다녀본 경험이 없습니다.
대부분의 회사에서의 업무 관리는 redmine이나, 구두로 전달되어온 스케쥴에 의존했죠.
이렇다보니, 개인적으로 업무일지를 작성하기 시작했습니다. 왜냐하면 (다들 아시다시피) 기억력에 의존해서 업무를 진행하기란 한계가 있으며, redmine과 같은 업무 관리 도구로 모든 업무를 관리하고 트랙킹하기란 쉽지 않기 때문이죠.
특히나, redmine과 같은 도구에 (여러가지 이유로)개인적인 감상을 적기 어렵다는 점도 한몫합니다.
결국은 온전한 업무 기록은 개인적으로 따로 관리해야 한다는 건데, 그러다보니 자율적으로 업무 일지를 써왔습니다.
업무 일지의 목적은 히스토리.
업무가 많다보면 자연스레 기록을 필요로 합니다. 이 과정에서, 기록되는 주 공간은 text, 연습장, 메모앱 등등이 되겠죠?
그런 기록의 공간을 업무 일지 기록소 [개인적으로 note류 앱 중, one note, evernote, google docs 모두 사용해보았는데, 장단이 있습니다. 굳이 특정 앱을 사용할 필요는 없습니다.]로 옮겨간다라고 생각하면 편합니다.
업무 일지 요령은, 하루 동안 업무에 관련되어 겪은 일들을 정리하는 과정이라고 보시면 됩니다.
어떤 업무를 진행하는 데에 있어서의 과정을 최대한 많이 기록한다라고 보시면 되요.
특히 과정 [디버깅이건, 타 파트 업무 지원이건, 네트워크 장애건, PC 오류건, 개인 용무건 뭐든간에]을 기록해 업무에 방해되는 요소를 알 수 있습니다.
또는 내가 일을 굉장히 잘하는지 못하는지에 대한 계측 도구로도 사용가능하죠.
업무 일지는 많은 분들이 쓰시는데, 그 중 제가 사용하고 있는 방식에 대해 간략히 보충 설명 할게요.
- 월간, 분기간, 연간 리뷰.
- 리뷰를 하며, 기록한 업무 일지를 재정리 합니다.
- 큰 작업별 업무 기록 분리.
- 해당 업무의 예상 기간과, 실제 진행 기간간에 분리합니다.
- 주단위를 넘어가는 큰 개발 일정이 연간 생각보다 그다지 많지 않습니다. [많더라도 정리합시다]
- 작업별로 재정리된 예상 소요시간과, 실제 소요시간의 갭, 오차의 원인등을 같이 남겨서 아카이브합니다.
- 병목 지점 파악
- 회사별로, 동료별로 나의 업무에 영향을 주는 방식,정도가 다릅니다.
- 이를 파악하는 지표로 분석해야 합니다.
- 그게 장비나 툴의 문제라면 더더욱 개선해야 합니다.
- 예를 들어 빌드 내서 테스트 해야되는 작업인데, APK로만 테스트하느라 빌드 시간 10분*20해서, 3시간동안을 빌드에만 사용해서 디버깅 및 테스트를 진행했다라고 하면, 몇가지 접근이 나옵니다.
- 그게 장비나 툴의 문제라면 더더욱 개선해야 합니다.
- APK 빌드 시간을 단축.
- 테스트할 기능만 담은 새 프로젝트를 기반으로 테스트해 시간 단축.
- 자동화 테스트 스크립트 작성
이렇듯 시간을 아낄 수 있는 방법을 통해 생산성을 높여야, 잉여 시간을 만들 수 있습니다.
잉여 시간을 자기 개발 + 업무 개선을 반복함으로써 효율을 높여 개인 시간을 많이 만드시길 빕니다.
이상 간략한 업무 일지 및 정리 방법 요약이었습니다.