brunch

매거진 일잘러의 한 끗 차이

라이킷 25 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by kaily Nov 12. 2023

성과평가, 나는 어떤 동료에게 최고점을 주었나?

중요하다고 생각한 세 가지 기준에 따른 동료 평가방법

벌써 2023년 그동안 내가 회사에서 잘했는지, 못했는지 돌아볼 수 있는 연말 성과 평가 시즌이 다가왔다.

우리 회사 성과 평가는 본인 평가, 동료 평가, 리더 평가로 나뉘어 있으며 평가 기간은 대략 3주에서 4주 정도 소요되는 것으로 파악했다. 10년이 넘는 기간 동안 벌써 여러 회사를 이직하면서 각 회사마다 어떻게 평가하는지 경험했는데 동료평가는 작년 현 회사에서 처음 경험해 봤다. 처음 왔을 때 동료들이 너무 따듯해서 '와! 지금까지 다녔던 곳 중 문화와 사람들은 제일 좋은 것 같다!' 생각했는데 아마도 동료 평가의 영향도 있지 않았을까 싶다. 동료 평가를 처음 할 때는 사실 어떻게 해야 할지 잘 감이 잡히지 않아 그동안 느꼈던 것들을 정성적으로 평가했던 것 같은데 올해는 여러 상황을 바탕으로 조금 더 객관적으로 파악하고 피드백을 주기위해 노력했다.

그리고 나에게 동료 평가를 신청한 동료들의 강점과 보완할 점 위주로 최대한 객관적인 평가 피드백을 작성했다. 여러 동료의 피드백을 작성하다 보니, 어떤 동료는 강점에 대한 피드백은 바로바로 생각나는데, 보완할 점은 아무리 생각해도 작성할 게 없는 동료도 있었다. 내기준 일잘러 동료들이었고, 같이 일하면서 좋았던 부분만 있었으므로 당연히 평가도 최고점을 주게 되었다. 그리고 평가를 마치고 곰곰이 생각해봤다.

나는 왜 이 동료를 왜 높게 평가했을까?

평가는 보통 동료의 강점과 부족한 부분이 뭔지 선택하고, 어떤 상황에 그 동료가 어떤 행동을 했고, 그로 인한 업무상의 영향은 무엇이었는지 구체적으로 작성하라고 가이드되었다. 내가 생각하기에 좋았던 동료들, 좋은 점수를 줬던 동료들은 어떤 강점을 가지고 있었는지 아래 3가지로 나눠 설명할 수 있을 것 같다.

1. 얼마나 적극적인 협업 태도를 가지고 있는가?

세 가지의 기준이 모두 중요하긴 하지만 그래도 가장 중요한 건 협업 태도라고 생각했다. 좋은 점수를 준 동료의 태도를 돌아보면 그들은 대체로 '적극성이 높은' 특징을 갖고 있다는 걸 알 수 있었다.

예를 들어, 현재 진행 중인 프로젝트가 끝나면 어떤 프로젝트를 할지 아이데이션 미팅을 갖는 자리가 있다고 하면 그 자리에서 한 마디도 하지 않는 동료가 있고, 적극적으로 본인의 의견을 말하는 동료가 있다.

프로젝트를 할 때 기획에서 A라는 기능을 기획했는데, 어떤 동료는 그 기능의 목적이나 플로우 등을 한번 더 생각하고 의견을 주고, 또 어떤 동료는 그냥 기획서에 기획해 둔 그대로 작업을 한다.

같이 프로젝트를 하며 겪는 많은 상황들을 마주하며, 동료의 협업 태도가 어떤지 알 수 있을 정도로 데이터가 쌓이면 평가 시점이 도래했을 때 '아, 이 동료는 적극적이었어', '이 동료는 본인의 의견을 거의 내지 않았어'등의 생각이 바로바로 떠올랐다. 나는 '기획이 되어있으니, 기획자가 알아서 잘 생각했겠지. 그대로 개발해야지'하며 고민 없이 바로 작업에 들어가는 동료를 선호하지 않는다. 프로젝트는 여러 명의 동료가 함께 진행하는 것이므로, 같이 생각해야 결국엔 더 좋은 방향으로 갈 수 있다고 믿기 때문이다.

2. 높은 업무 역량을 가졌는가?

업무 역량도 정말 중요한 부분인데, 직무에 따라 요구하는 업무 역량이 다르고 평가자의 기준에 따라서도 평가가 달라질 수 있는 부분이라고 생각한다. 나는 같은 직무인 PO를 평가할 때는 프로젝트를 진행하며 어떤 목적과 목표를 가지고 하는지, 그 프로젝트를 하는 배경이 무엇인지 등 얼마나 논리적으로 프로젝트를 전개해 나가는지에 대한 기준으로 평가하고, 개발자를 평가할 때는 프로젝트의 난이도, 개발 기간, 버그 발생비율, 배포일 지연 등 여러 가지 항목에 대해 나누어 고민하고 평가했다.

예를 들어, 비슷한 규모의 2개의 프로젝트를 각각 A개발자와 B개발자가 개발하게 되었다. A 개발자는 2주의 개발 기간을 잡았고 B개발자는 1주의 개발 기간을 잡았다. 그리고 QA 기간이 되어 테스트를 하는데 A개발자가 개발한 부분은 오류도 적고 로그도 정상 집계되도록 꼼꼼하게 처리되어 있는 반면, B개발자는 개발 기간은 짧았으나 디버깅해야 하는 버그의 수가 많았다. 결국 B개발자와 진행하는 프로젝트는 개발 수정기간, QA기간이 추가로 소요되며 결국 배포가 지연되었다.

위의 예시와 같다면 나는 A개발자에게 더 높은 점수를 주었다. 우선 본인이 작업해야 하는 개발 기간을 잘 알고 그에 맞춰 개발이 되었고, 약속된 배포일에 맞춰졌으며, 버그 발생률도 현저히 낮았기 때문이다. 수많은 프로젝트를 하다 보니 생각보다 많은 개발자가 본인이 예상한 개발 일정 내 일정 수준의 퀄리티를 맞추지 못하는 경우가 많았다. 예상치 못한 케이스가 존재해서, 타 팀 디펜던시가 있어서, 본인을 과신해서 등 다양한 이유가 있겠지만 나는 약속한 일정 내 높은 퀄리티로 배포하는 것이 업무 역량이 좋다고 판단했다.

3. 커뮤니케이션을 얼마나 투명하고 유연하게 하는가?

지난 여러 개의 글을 통해 커뮤니케이션이 얼마나 중요한지 이야기했다. 특히 기획과 개발자의 커뮤니케이션은 매일, 매 순간 발생하게 되고 제품의 퀄리티와도 직결되므로 매우 중요한 부분이라고 생각했다.

이번 연도에 프로젝트를 진행하면서 타 회사와 함께 협업해서 진행해야 하는 프로젝트가 있었다. 주로 커뮤니케이션을 하는 주체는 나와 그 회사 PO였는데, 기술적인 부분은 각각 내부에서 확인하고 PO가 전달해 주는 식으로 진행되었다. 우리는 필요한 기능인 A에 대해 요청했는데 상대 회사에서 A에 대한 사이드이펙트가 있을 수 있으니 기술적으로 확인해달라는 요청을 해왔다. 소스 코드의 일부를 주며 확인해달라고 했는데, 나는 정확히 어떤 부분을 파악해서 피드백을 드려야 할지 파악하기가 어려웠다. 요청한 내용을 슬랙으로 그대로 붙여넣고 내부 개발팀을 멘션하니, 개발자 중 한 분이 이해하기 쉽게 현재의 요청사항을 설명해주셨다. 현재 기술적으로 어떤 부분이 문제가 될 수 있고, 어떤 부분을 누가 어떻게 확인해야하는지 명료하게 정리해주시니 정확하게 현황을 이해하고 타 회사와 커뮤니케이션을 할 수 있었다. 종종 개발자만 이해할 수 있는 문장이나, 어려운 부분이 있을때는 PO가 이해하기 쉽게 예를 들어 설명해주신 부분도 너무 큰 도움이 되었다.

정리해서 요청 주시고 타 팀 개발자와 커뮤니케이션을 이어나갔다.

중간에서 이렇게 정리해주는 개발자분이 계시지 않았다면, 이해하고 진행하기 어려웠을 것 같은 부분이었는데 덕분에 프로젝트가 수월하게 마무리 되었다. 이러한 상황과 태도는 내 기억속에 하나씩 쌓여있다가 평가 시즌이 되어 이 동료와 진행한 프로젝트를 되돌아보며 다시 떠올랐다. 과거 프로젝트를 하며 쌓였던 긍정적인 경험들이 동료에게 최고점을 줄 수 있는 근거가 되었다.

마지막으로

동료 평가를 많이 해 보지 않아서 첫 해에는 그들에게 도움을 줄 만한 피드백을 하지 못한 것 같다는 생각이 들었다. 그래서 올해는 동료들에게 도움을 줄 수 있는 보다 객관적인 피드백을 해야겠다고 다짐하고, 동료 한 명, 한 명과 어떤 프로젝트를 했고 그들이 프로젝트를 할 때 어떤 점이 좋았는지, 보완해야 할지 고민하고 피드백을 작성했다. 평가를 요청한 동료 중 평가하기엔 같이 일한 경험이 충분하지 않아 잘했는지, 못했는지 판단하기 어려울 경우 피드백에 판단할 수 없다는 코멘트를 작성해 두었다.

이번에 동료평가를 작성하면서 다음 동료 평가를 할 때 더 디테일하게 평가하기 위해선 1년간 프로젝트 중간중간의 과정을 별도로 기록해 둬야겠다는 생각을 했다. 업무를 같이 진행하며 마주하는 모든 순간들을 자세히 기록해 놓는다면 보다 정확하게 동료를 평가할 수 있을 것이고 보다 정확하고 객관적인 피드백을 주게 된다면 그들에게도 더 도움이 될 것이라고 생각했기 때문이다. 포맷은 아래와 같이 만들어두면 유용할 듯 하다.

<앞으로 작성해놓을 예상 포맷>

1. 대상자
2. 프로젝트명, 진행 기간
3. 디테일한 상황
    e.g) 프로젝트 진행 시, 타 팀 디펜던시가 있는 업무라 타팀과 커뮤니케이션 후 개발이 필요했음
4. 태도
   e.g) 타 팀 개발자와 커뮤니케이션이 불편하다는 이유로 직접 커뮤니케이션 하지 않고 개발 진행
5. 업무상 영향
   e.g) 커뮤니케이션 누락으로 크리티컬 오류 발생

그럼, 1년간 함께 프로젝트를 진행한 모든 동료들에게 감사를 표하며 이번 글을 마치도록 한다.

keyword