고과 자료 정리하는 법: 기록부터 자기평가까지

고과 자료는 일을 끝낸 그날 모아 두어야 합니다. 끝낸 일과 그 결과, 요청한 사람, 날짜를 한 줄씩 적어 두었다가 평가 때 프로젝트별로 묶고, 상황과 한 일과 결과가 들어간 문장으로 옮기면 자기평가가 됩니다. 반년 치 일을 평가 주간에 기억으로 되살리는 것보다 빠르고, 빠지는 일도 적습니다.

고과 자료는 왜 평소에 모아야 하나요?

석 달 전에 끝낸 일은 평가 주간에 거의 떠오르지 않기 때문입니다. 자기평가를 쓰려고 앉으면 최근 한두 달 일, 크게 문제가 됐던 일, 오래 끌었던 일이 먼저 생각납니다. 1월에 조용히 끝낸 일이나 다른 팀 부탁으로 반나절을 쓴 일은 빠집니다.

메신저와 메일, 커밋 기록을 뒤지면 무엇을 했는지는 어느 정도 복원됩니다. 그런데 그 일이 끝나고 무엇이 달라졌는지는 거기 잘 남아 있지 않습니다. 결과는 일을 끝낸 순간에 가장 선명합니다. 그날은 한 줄이면 되는 내용을 석 달 뒤에는 한참 찾아야 합니다.

평가 직전에 몰아서 쓰면 문장도 급해집니다. 떠오르는 대로 적다 보니 목록이 들쭉날쭉하고, 결과를 모르는 일은 ‘진행함’으로 끝나 버립니다.

무엇을 적어 두면 되나요?

일 하나마다 네 가지를 적습니다. 무엇을 끝냈는지, 결과가 어땠는지, 누가 요청했는지, 언제였는지입니다.

• 완료한 일은 나중에 봐도 무슨 일인지 알 수 있게 씁니다. ‘작업 완료’보다 ‘결제 실패 재시도 큐 배포’가 반년 뒤에 훨씬 쓸모 있습니다.
• 결과는 그 일이 끝나서 달라진 점입니다. 숫자가 있으면 숫자를 쓰고, 없으면 누가 무엇을 할 수 있게 됐는지 씁니다.
• 요청한 사람은 내 일이 팀 밖 어디까지 닿았는지 보여 줍니다. 다른 팀 부탁으로 한 일은 평가자가 모르고 지나가기 쉽습니다.
• 날짜는 일의 순서를 되살리고, 평가 기간 안에 든 일인지 가려 줍니다.

넷 중에서 가장 자주 빠지는 것이 결과입니다. 끝낸 일만 쌓으면 할 일 목록의 사본이 될 뿐이고, 결과 한 줄이 붙어 있어야 나중에 문장으로 바뀝니다. 결과를 아직 모르면 비워 두었다가 알게 됐을 때 채웁니다. 적는 시점은 일을 끝낸 그 자리가 가장 좋습니다. 금요일에 한 주를 몰아 적어도 되지만, 그때쯤이면 월요일 일은 이미 흐릿합니다.

모은 기록은 어떻게 묶나요?

프로젝트나 맡은 영역 단위로 묶습니다. 날짜순으로 늘어놓은 반년 치 목록은 평가자가 읽기 어렵습니다. 영역별로 모으면 한 영역에서 무엇이 쌓였는지, 일이 어떻게 이어졌는지가 보입니다.

묶는 단위는 평가서 양식에 맞추면 편합니다. 목표별로 쓰는 양식이면 목표별로, 자유롭게 쓰는 양식이면 프로젝트별로 묶습니다. 일을 적을 때부터 어느 영역인지 표시해 두면 평가 때 따로 분류하지 않아도 됩니다.

어디에도 넣기 애매한 자잘한 일은 기타로 모아 둡니다. 버리지는 않습니다. 비슷한 일이 반년 동안 여러 번 쌓였다면 그 자체로 한 줄이 됩니다. 신규 입사자 질문을 도맡아 받았다거나, 매달 다른 팀 데이터를 대신 뽑아 줬다거나 하는 일이 그렇습니다.

목록을 자기평가 문장으로 어떻게 바꾸나요?

한 문장 안에 상황, 한 일, 결과를 차례로 넣습니다. 상황은 이 일이 왜 필요했는지, 한 일은 내가 직접 맡은 부분, 결과는 끝나고 달라진 점입니다. 셋 중 하나가 빠지면 평가자가 그 빈칸을 스스로 채워야 하고, 대개 나에게 불리하게 채웁니다.

목록 한 줄이 문장 하나가 되지는 않습니다. 같은 문제를 풀려고 한 일 서너 줄이 한 문장으로 합쳐지고, 문장에 들어가지 않은 줄은 근거로 남습니다. 결과에 숫자가 없다고 억지로 만들 필요는 없습니다. 무엇이 가능해졌는지, 누가 더는 무엇을 하지 않아도 되는지를 쓰면 충분합니다.

예시: 반년 치 기록에서 자기평가 두 문장 쓰기

결제팀 백엔드 개발자 다은이 상반기에 남긴 기록을 워크스페이스별로 묶으면 다음과 같습니다. 결과를 적어 둔 일에는 그 아래에 한 줄씩 붙였습니다.

상반기 완료 기록 (1/1 ~ 6/30)

[결제팀]
2/03  결제 실패 로그 한 달 치 분류
      결과: 실패 대부분이 카드사 일시 오류
3/12  결제 실패 재시도 큐 배포
      결과: 일시 오류 건은 자동으로 재처리
4/21  재시도 횟수와 간격을 설정값으로 분리
5/28  데드레터 알림 붙이기 (요청자 지혜)
      결과: 수동 재처리 요청이 주 20건 안팎에서
      한두 건으로 줄어듦

[온보딩]
1/15  로컬 개발 환경 문서 다시 쓰기
      결과: 4월 입사한 민수가 첫날 혼자 서버를
      띄움 (4/08에 추가)
4/07  4월 입사자 두 명 코드 리뷰 담당
      결과: 두 사람 모두 둘째 주에 첫 PR 머지

[분류 없음]
6/28  정산팀 월말 데이터 추출, 1월부터 매달
      (요청자 서연)

다은은 이 목록에서 자기평가 문장 두 개를 썼습니다.

1. 결제 실패 로그를 한 달 치 분류해 대부분이 카드사 일시 오류라는 것을 확인하고 재시도 큐와 데드레터 알림을 만들어, 주 20건 안팎이던 수동 재처리 요청을 한두 건으로 줄였습니다.
2. 신규 입사자가 첫 주를 개발 환경 설정에 쓰는 일이 반복되어 로컬 개발 환경 문서를 다시 쓰고 4월 입사자 두 명의 코드 리뷰를 맡았으며, 민수는 첫날 혼자 서버를 띄웠고 두 사람 모두 둘째 주에 첫 PR을 머지했습니다.

첫 문장에는 결제팀 기록 네 줄이 모두 들어 있습니다. 4/21 설정값 분리는 문장에 이름이 나오지 않지만, 평가자가 재시도 큐를 어떻게 운영하는지 물으면 꺼낼 근거로 남습니다. 서연이 부탁한 월말 데이터 추출은 두 문장 어디에도 맞지 않습니다. 대신 반년 동안 여섯 번 반복한 일이라 기타 항목에 한 줄로 따로 씁니다.

자기평가에서 자주 하는 실수는 무엇인가요?

가장 흔한 실수는 바빴던 일을 그대로 늘어놓는 것입니다. 과정만 쓰고 결과를 빼는 것, 팀이 한 일과 내가 한 일을 섞는 것, 기여를 부풀리는 것도 자주 보입니다.

바빴던 일을 나열한다

회의 몇십 번, 문의 응대 몇백 건은 시간을 많이 잡아먹었지만 평가자가 알고 싶은 것은 그래서 무엇이 달라졌는지입니다. 반복 업무는 한 줄로 합치고, 그 일이 없었다면 누가 무엇을 못 했을지를 씁니다.

과정만 있고 결과가 없다

‘검토함’, ‘조사함’, ‘진행 중’으로 끝나는 문장은 읽는 사람이 결과를 짐작해야 합니다. 아직 결과가 없으면 어디까지 왔고 다음에 무엇을 하는지 씁니다. 해 봤는데 안 된 일도 결과입니다. 무엇을 알게 됐고 그래서 무엇을 접었는지 쓰면 됩니다.

남이 한 일과 섞는다

팀이 함께 한 프로젝트라면 내가 맡은 부분을 따로 적습니다. 팀원이 넷이면 평가자는 같은 프로젝트 이야기를 네 번 읽습니다. 네 명 모두 ‘재시도 큐를 배포했다’고 쓰면 누구의 기여도 드러나지 않습니다. 누가 요청했고 누구와 같이 했는지 적어 두면 이 구분이 쉬워집니다.

부풀려 쓴다

일부를 맡은 일을 주도했다고 쓰거나 팀 전체의 숫자를 내 성과처럼 쓰면, 그 일을 아는 동료나 평가자가 바로 알아봅니다. 한 문장이 과장으로 읽히면 나머지 문장도 의심받습니다. 기록에 있는 만큼만 쓰면 됩니다. 반년 치 기록이 손에 있으면 부풀릴 이유도 별로 없습니다.

띠롱에서는

띠롱은 할 일 관리, 일정, 업무 일지, 주간보고를 한곳에서 하는 한국어 웹 서비스입니다. 할 일을 한 줄로 적을 때 앞에 #을 붙이면 워크스페이스, @를 붙이면 요청자로 나뉩니다. 완료로 체크하면 결과 메모 창이 떠서 무엇이 어떻게 됐는지 그 자리에서 한두 줄 남길 수 있고, 건너뛰어도 됩니다.

평가 때는 완료한 기록을 고과용 텍스트로 복사합니다. 워크스페이스별로 묶여 할 일 제목, 완료일, 요청자가 들어갑니다. 결과 메모 본문은 복사되지 않으니 앱 화면에서 메모를 읽으며 문장은 직접 씁니다. 기록 기능은 무료이고 Google 계정으로 로그인합니다.