일을 잘하는 나만의 방법

이전 글에서 ‘일을 잘한다는 것’에 대해서 알아보았다. 그럼 이번 글에서는 일을 잘하는 나만의 방법에 대해서 이야기하고자 한다. 이전 글을 잠시 되짚어보면, 일을 잘하는 것은 ‘완성도를 챙기며 빠르게 구현하는 것’이다. 여기서 ‘완성도’는 기본값이고, ‘빠르게’가 궁극적으로 ‘일을 잘하는 것’의 기준점이다. 그럼 나는 어떻게 이 둘을 잘하기 위해서 노력하고 있을까? 나는 ‘업무 프로세스’라는 시스템을 만들고 그 시스템을 가꾸는 방식을 채택했다. 내가 뭐든 잘 하기 위해서 사용하는 방식 중 하나이기도 하다.

1. 기획서 숙지

   개발자에게 코드 작성은 업무 중 일부에 불과하다. 개발을 하기 위해서는 그 개발을 하기 위한 기획이 있고, 이 기획서를 숙지해야 하는 등 다양한 것들을 함께 해야 한다. 여기서 업무를 시작할 때 가장 먼저 전달받는 것이 바로 이 기획서이다. 그럼 ‘이 기획서를 어떻게 할 것인가’가 바로 내가 일을 시작하기 위해서 해야 할 일이다. 입사 초반에 나는 기획서를 제대로 읽지도 않은 채로 작업부터 시작해 쓴맛을 본 적이 있다. 기획서를 숙지하지도 않은 상태에서 AI가 만든 작업 결과물을 보니 ‘이게 뭐야, 기획서 어디의 어떤 기능을 구현한거지?’ 모르겠는거다. 그렇다고 AI가 만든 작업 결과물을 그대로 제출할 수도 없는 격이다. 이게 제대로 구현했는지 전혀 모르는데? 잘못 구현했을 경우 책임은 오로지 내가 가지는데? 이건 나 혼자만 일하는 게 아니라 네이티브/백엔드/기획팀과 소통하면서 일하는 거라 내가 알아야 물어보고 답변도 해줄 수 있는데? 결국 내가 직접 구현한 것이 더 빨랐을 정도로 시간이 더 오래 걸린 적이 있었다. 결국 기획서를 숙지하는 것은 일을 완성도 있고 빠르게 구현하기 위한 첫 걸음이다.

   그래서 기획서 숙지 어떻게 하는데! 할 것이다. 나는 기획서를 받으면 가장 먼저 한 장짜리로 요점을 옮겨 적는다. 관련 작업자, 일정, 관련 자료, 추가로 확인할 것, FE 구현 리스트. 이 다섯 칸을 작업 카드에 먼저 채워 두면 이 업무의 지도가 생긴다. 그리고 이제 이 업무의 대략적인 정보를 알았다면, 기획서 본문을 파악한다. 이 때는 자유롭게 하는 편이다. 보통 기획서를 혼자서 처음부터 끝까지 읽어보고(결국 SSOT는 기획서이기 때문에), 이해가 잘 안 되거나 복잡한 내용이라면 두세 번 더 읽는다. 그럼에도 이해가 안 되면, 기획서가 없는 내용이거나 실제로도 애매한 내용이라면 타파트에 질문을 하면서 해소하고는 한다.

2. 업무 일지

   나는 업무 일지와 각종 일지를 매일매일 작성한다. 그 중에서 내가 일을 잘하는 데에 가장 도움을 준 것은 ‘업무 일지’와 ‘피드백 일지’ 이다. 이에 대한 자세한 내용은 다른 글에서 이야기하도록 하겠다. 간략하게만 이야기하면 매일 나는 느낀 점과 KPT회고를 업무 일지에 작성하고, 매일매일 더 개선할 점을 찾는다. 그리고 업무를 진행하면서 받은 피드백을 전부 피드백 일지에 작성하고 자주 들여다보며 상기시키고 체화를 하고는 한다.

3. 체크리스트

   입사 초에는 업무 프로세스를 숙지하는 것도 버겁다. 정보량이 너무 많다. 그래서 나는 이를 하나하나 체크리스트로 만들어서 하나씩 체크하면서 작업을 진행하고는 했다.