문서 보기문서 편집수정 내역 프로그래머/인사고과 (덤프버전으로 되돌리기) [목차] == 개요 == [[프로그래머]]의 인사고과 또한 [[인사고과]]의 일종이지만, 프로그래머의 채용이나 진급 등의 인사고과에 존재하는 차이점을 기술한다. == 평가의 기준 == === 개발 결과물 === 프로그래머는 업무 결과물 즉 개발 결과물에 대한 객관적인 평가를 하기 쉽다는 특징이 있다. 제아무리 [[스펙]]이 좋아도 개발 결과물이 나쁘면 인사고과가 나쁘게 나올 수밖에 없고, 반대로 스펙이 낮음에도 불구하고 훌륭한 개발 결과물을 내놓는다면 좋은 인사고과를 받게 된다. 즉 눈에 보이는 결과물 앞에서 정치가 통할 수 없다. 개발 결과물을 판단하는 기준은 주로 다음과 같다. ==== 개발 완료일 ==== 프로그래머는 혼자 일 하는 것이 아니라, 여러 사람과의 이해관계가 얽혀있는 채로 개발을 하게 된다. 당장, 프로그래머가 만들어내는 소프트웨어의 출시일을 예상하고 ~~혹은 일방적으로 위에서 정해 버리고~~ 마케팅 홍보 일정 등을 잡게 된다. 따라서 개발 일정은 프로그래머가 지켜야 하는 가장 중요한 팩터이기도 하다. 프로그래밍을 하다보면 [[버그]]나 요구명세의 변경 등 불가피한 일정 방해 요인이 발생하게 된다. ~~혹은 사용하던 컴퓨터가 뻗어 버려서 복구하다가 개발 일정이 딜레이되는 경우도 있다.~~ 이러한 경우 협의하에 목표의 범위를 축소 혹은 변경하거나, 부득이한 경우 일정을 변경하기도 한다. 개발 완료일을 정하는 기준은 조금씩 다르지만, 1) 개발 명세에서 언급되어있는 기능이 모두 구현되고 2) 주요 버그가 없어야 하고 3) 최소한의 유지보수가 가능할만큼 소스코드가 알아보기 쉽게 만들어져 있는 것을 완료로 간주하기도 한다. ==== 개발 결과물의 양과 품질 ==== 프로그래머의 인사고과를 위해 개발 결과물의 품질을 관찰하게 되는데, 이때 관찰하는 지표는 역시 회사마다 다르지만, 가령 다음과 같다. * 버그의 발생율 * 성능 * 소스코드의 가독성 및 유지보수성 * 개발된 결과물의 분량 개발 결과물의 양이 많더라도 품질이 낮은 경우 좋은 인사고과 평가를 받기 어렵다. 반대로, 결과물의 양이 적더라도 그것의 개발 주제가 난이도가 높거나, 기술적 수준이 높거나, 버그가 없이 잘 작동하는 무결한 소스코드를 작성한 경우 좋은 평가를 받는다. 개발 결과물의 양은 소스코드의 라인 수나, 형상관리툴에 커밋을 한 소스코드의 라인 수로 판단할 수도 있다. 동료 대비 커밋의 횟수가 현저하게 적거나, 작성한 소스코드의 라인수가 적은 경우 업무 성과가 낮게 보일수밖에 없다. 또한, 커밋이 많더라도 의미가 별로 없는 커밋이 비상식적으로 많거나, 커밋한 소스코드의 질이 형편없거나 ~~가령 복붙의 향연~~ 하면 좋은 평가를 받기 어렵다. === [[근태]]와 근로시간 === 프로그래머도 여타 직종과 마찬가지로 출퇴근 시간에 대해서는 엄격한 회사들이 대부분이다. 프로그래머 또한 여러 사람이 같이 일하는 환경에서 협업을 해야 할 의무가 있는 직종이기 때문에, 창의력이나 자율을 핑계로 출퇴근이나 근무태도에 대해서 자유롭게 용인하는 것이 오히려 역효과를 내는 경우들이 많다. [[재택근무]]를 시행하는 회사들의 경우, 개발 성과물만을 관찰하고 평가하여 인사고과를 하기도 한다. 재택 근무 특성상 정확한 근태가 확인되지 않으며, 심지어 착석하여 근무중인지 몰래 놀고 있는지도 구별이 되지 않기 때문에, 개발 성과물만 갖고 인사고과를 매기는 것이 오히려 정확하다는 견해도 있다. ~~못 한 것은 안 한 것과 동급으로 처우된다.~~ 프로그래머는 업무 특성상 [[버그]] 발생이나 외부 요인에 의해서 야근 즉 잔업을 해야 하는 경우들이 자주 발생한다. 혹은 컴파일이나 테스트 등을 위해 수시로 기다려야 하는 시간이 발생하기도 한다. 가령 버그가 많이 발생하는 경우 일정을 맞추기 위해 야근을 해야 하는 경우들이 있는데, 프로그래머의 실력이나 꼼꼼함의 부족으로 인해 버그가 더 발생하는 경우 더 많은 야근을 해야 하는 상황도 있다. 이러한 것으로 인한 야근을 연장근로수당을 지급하는 것이 형평성이 있느냐는 간혹 논란의 여지로 발생하기도 한다. 일부 IT회사들이 [[포괄임금제]]를 하는 이유로 이것을 들먹이기도 한다. === [[중간관리직]]의 조직 관리력 === 중간관리직이 프로그래밍을 잘 알거나 모르는 경우 팀 관리력은 극명하게 차이가 날 수 있다. 중간관리직을 넘어서 [[CTO]] 직위에 있는 사람들까지 프로그래밍을 잘 알아야 하는 이유가 여기에 있다. 중간관리직은 프로그래머들의 작업물의 양과 질을 파악할 수 있는 능력을 갖추어야 한다. 이에 따라 중간관리직에 있는 사람들은 직접 개발 일을 담당하기도 하지만, 자신의 일의 일부 혹은 전부는 팀원 개발결과물의 양과 질을 검토하는데 할애하기도 한다. 중간관리직은 프로그래머들의 코드를 검토(리뷰)를 하면서 잠재적 결점을 파악하고 지적하며, 이와 동시에 각 팀원들의 인사고과를 수시로 수행한다. === [[스펙]] === === 업무에 따라 가변적인 평가 요소 === === 다국적 기업 === === 공공기관 === [[분류:조직관리]]캡챠되돌리기