아마존같은 데서는 어떻게든 역영별로 정량평가 한다고 들었는데 저도 동료평가 외에 어떤 기준 세울만한게 있는지 잘 모르겠습니다

궁금한 주제네요

업무 체계가 잘 되어 있고 시장 상황에 따라 계획의 변경도 매우 적은 경우를 제외하고는 정량적인 평가는 제한적일 수 밖에 없다고 봅니다. 정량적이라고 하지만 정성적이 되어버리죠. 대부분 본업과 잡무가 있고 어떤 경우는 잡무의 비중이 더 클 때도 자주 있잖아요? 전 기술보단 책임감, 열정, 협업, 동료애 등에 더 높은 점수를 주었던 것 같습니다.

예전 회사에서...

미리미리 챙겨서 문제가 안생긴다 => 한 일이 없으므로 저평가
안챙겨서 생긴 문제를 해결한다 => 한 일이 많으므로 고평가

우왕 ㅋ굳ㅋ

회사가 어떤 비즈니스를 하느냐에 평가 지표가 따라 다르겠죠. 개발자도 회사 직원이고 회사 비즈니스를 위해서 일하는 사람이니까, 회사 비즈니스에 어떻게 정량적으로 도움되었느냐 고민해서 봐야할 것 같아요. 아무래도 가장 중요한건 회사 매출/순이익에 얼마나 기여했는가 이겠죠.

완전히 똑같은 일을 둘에게 시킨다면야 평가가 가능하겠지만, 그런 건 불가능하니...

개발자 외에도 마찬가지의 평가 기준이 존재하나요?

이런 질문과 회사의 여러 정책(개발직군 역량평가 시스템)을 볼때면 참.. 답답합니다.

급여를 받고 일하는 자라면 응당 회사에 얼만큼 기여하고, 능력치 혹슨 기여도 등에 따라 차등 평가하는게 맞긴 합니다만..

저희는 이슈 해결 및 완료된 PR 개수로 가늠합니다.

사실 개발이라는 직무는 너무 광범위하고 정의도 애매합니다. 개발은 역량 이지 직무는 아니라고 봅니다.
개발은 어떤 개발(업무)인지가 직무 정량평가에 활용된다고 볼수 있습니다.
예를 들어 SM개발자는 이슈나 PR 처리 개수가 보통 많이 쓰이고 SI개발자는 WBS 진척도가 평가에 많이 사용됩니다.
물론 각각의 ITEM별 난이도나 업무볼륨이 적절한가는 또다른 문제입니다.....

예를들어 운전직무평가 라는건 의미가 없는거져....카레이서와 버스운전은 같은운전이지만 완전히 다른업무입니다. 그래서 평가방법도 카레이서는 얼마나 빠른가 가 주요평가지만 버스운전은 얼마나 안전하고 정확하게 운전하는가 가 평가항목이 됩니다.

요구사항 처리(기능 개발, 추가, 버그 수정 등) 혹은 높은 품질의 아웃풋이 많으면 많을 수록 평가가 좋지 않을까요?

자신에게 주어진 일만 On Time에 처리 하는게 아니고,
모두가 바쁜 시간에 누구는 자기 할일 다 처리하고 남이 힘들어하고 있는 것을 도와서 처리하면
그것 역시 양적으로 더 많이 기여할 수 있다고 생각해요.
다들 바쁜데 추가 일감들이 툭툭 치고 들어올 때 그것을 소화해주는 팀원을 이뻐하지 않는 리더는 없다고 봅니다.

저희 회사는 범용적으로 다른 팀에서도 사용할 수 있는 시스템을 몇 개 이상 개발하고 발표하면
평가에 반영하며, 향후 승진에 기준이 되는 Factor로 작용합니다.

경영에서는 이것을 수치, 도표 등으로 쉽게 -- 그리고 공정하게 하고 싶다고 하지만,
실상은 사실 불가능하다고 저는 생각합니다.
위의 분들이 이미 쓰셨듯, 개개인의 능력, 실력, 분야가 다르고, 팀워크이기 때문에 쉽게 안 됩니다.
각각의 일(task) 또한 예상 못 한 일들이 일어나서 단순히 마감을 넘긴다고 점수를 낮게 줄 수도 없습니다.
스토리 포인트와 스크럼은 제 경험으론 이론과 말하는 것 좋아하는 팀리더/팀장과 경영진에게 편리하지만, 어떻게든 프로세스는 있어야 하니 할 수밖에요.

두 가지 다른 방향은:
- 스토리 포인트/스크럼을 밀어붙이고 관리팀을 만족시킨다.
- 스토리 포인트/스크럼은 관리팀을 위해 어느 정도만 하고 실제 진행및 팀멤버의 역량은 팀장이 잘 관리/파악을 한다.

요새는 첫 번째를 선호하던데, 그 이유는 관리자들의 만족도가 가장 크고, 수치와 증거, 그리고 반박을 무마하기 쉽기 때문입니다. 하지만 어떤 방법을 쓰더라도 결국은 팀리더/팀장의 평가로 결론 납니다.

개발 경험이 적지만 프로젝트 매니저로 일찍 시작한 분들이나, 관리 경험이 적은 분들은 책으로 배우고 그 프로세스를 강하게 적용하려 하지만, 그런 식으로 하면 팀원들의 불만이 많아집니다.

스토리 포인트가 가장 조심해야 한다고 생각합니다만, 개개인의 능력/실력의 세트가 (어떤 사람은 C++를 잘하지만, python은 약하던가, 자바는 잘하지만, 설계가 부족하던가, 소통이 뛰어나지만, 코딩은 떨어지거나, 빨리 만들지만, 버그나 설계가 취약, 반대로 느리지만 튼튼하게 만든다던가, 코딩과 설계가 뛰어나지만, 문서는 전혀 없는, 일은 잘하지만, 동료들과 계속되는 마찰 등)... 이런것들 때문에 스토리 포인트를 어떻게 결정하느냐의 방법에 또 고민하고 논의 돼야 합니다.

옛날에는 코드라인수, 늦게 까지 일하는 날의 수, 최근 들어서는 커밋의 수, 심지어 개발자의 컴퓨터에 어떤 프로세스가 어떻게 쓰여지는가 감시, 등등 빅데이타를 종합해서 평가 하기도 하는 모습을 봤습니다. 하지만, 사람의 일은 기계처럼 평가하기가 쉽지 않겠습니다.

회사, 팀의 문화와 관리팀의 성향과 바라는 점, 그리고 회사의 특성에 따라 달리할 수밖에 없다고 생각됩니다.
전반적으로는 = 팀워크(peer review) + 마감준수 + 퀄리티 + 개인 역량 발전 + 소통, 등으로 카테고리와 하면 그나마 수치화 하는데 도움이 되지 않을까 합니다.

웬만하게 뛰어나거나, 웬만하게 나쁘지 않으면 다들 보통으로 평가받고, 웬만하게 뛰어나거나 나쁜것은 너무나 쉽게 들어나서 평가하기가 쉬워서 궂이 그렇게 수치를 뽑고 그럴 이유가 없다 생각합니다. 그렇지만 경영/관리진이 원하니 어느정도 하기는 합니다.

결국은 어떤 방법을 써도 결국에는 팀리더/팀장/관리자의 평가가 끝인데, 정량화/수치로 밀어 붙이면 거기에 불만을 가질때 그런 정량화/수치로 반박을 막고 회사를 보호(공정하지 못한 평가라는 등)하는 도구로 전락하기 쉽상입니다. 그리고 팀의 성향도 그 정량화/수치만을 위해 일을 하는 성격이 되버리기 쉽습니다.