개발자로 십몇년을 일하다가 개발자들의 업무역량? 등을 향상시키는 업무를 하게 되었는데요
가급적 정량적인 지표를 만들어 공정하게 평가하고
또 잘한 직원들에 대해 의미있는 포상을 하고 붐업을 시켜줄수 있는
방법을 고민중이라 여기 개발한당 당원들에게 의견을 구합니다
기본적으로 생각할 수 있는 개발의뢰건수, 배포건수, 프로그램 오류율, 일정준수율
등은 정량화 할수 있으나(수치를 위해 마음만 먹으면 언제든 건수를 늘릴수 있는 것도 인지를 하구요)
이 외에 어떠한 것들이 있느면 좋을까요?
크게 의미는 있지 않겠지만 관련 자격증 획득 등도 생각중인데
이외에 여러분들이 생각했을때 어떠한 방안들이
있을지 궁금합니다
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=saltynut&logNo=220784340927
스토리 포인트 개념이 나오는데 실제로 겪어 본적이 없어서 어떤지 모르곘습니다.
https://www.clien.net/service/board/cm_app/16435548CLIEN
예전 논의도 있었네요
https://im-porori.tistory.com/entry/%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%9D%98-%EC%97%85%EB%AC%B4-%EC%84%B1%EA%B3%BC%EB%A5%BC-%EB%86%92%EC%9D%B4%EB%8A%94-KPI-%ED%95%AD%EB%AA%A9
개발자용 KPI 항목들도 한번 참고해 보시구요
건수로 따지면 한건이 다른일 수십건에 해당하는 만큼 중요하고 어려운 일인 경우가 많고요.
작업량으로 따져도 코드 한줄이 엄청나게 중요하고 어려운 이슈를 해결하기도 하고요.
정량적 평가는 어렵다라는걸 인정하고 정성적 평가를 어떻게 하면 모두가 인정할 수 있는 객관적 방법을 할 수 있을까를 고민하는게 더 나을듯 합니다.
/Vollago
폐기하게 됐네요ㅠ
https://www.clien.net/service/board/cm_app/16435548CLIEN
---
경영에서는 이것을 수치, 도표 등으로 쉽게 -- 그리고 공정하게 하고 싶다고 하지만,
실상은 사실 불가능하다고 저는 생각합니다.
위의 분들이 이미 쓰셨듯, 개개인의 능력, 실력, 분야가 다르고, 팀워크이기 때문에 쉽게 안 됩니다.
각각의 일(task) 또한 예상 못 한 일들이 일어나서 단순히 마감을 넘긴다고 점수를 낮게 줄 수도 없습니다.
스토리 포인트와 스크럼은 제 경험으론 이론과 말하는 것 좋아하는 팀리더/팀장과 경영진에게 편리하지만, 어떻게든 프로세스는 있어야 하니 할 수밖에요.
두 가지 다른 방향은:
- 스토리 포인트/스크럼을 밀어붙이고 관리팀을 만족시킨다.
- 스토리 포인트/스크럼은 관리팀을 위해 어느 정도만 하고 실제 진행및 팀멤버의 역량은 팀장이 잘 관리/파악을 한다.
요새는 첫 번째를 선호하던데, 그 이유는 관리자들의 만족도가 가장 크고, 수치와 증거, 그리고 반박을 무마하기 쉽기 때문입니다. 하지만 어떤 방법을 쓰더라도 결국은 팀리더/팀장의 평가로 결론 납니다.
개발 경험이 적지만 프로젝트 매니저로 일찍 시작한 분들이나, 관리 경험이 적은 분들은 책으로 배우고 그 프로세스를 강하게 적용하려 하지만, 그런 식으로 하면 팀원들의 불만이 많아집니다.
스토리 포인트가 가장 조심해야 한다고 생각합니다만, 개개인의 능력/실력의 세트가 (어떤 사람은 C++를 잘하지만, python은 약하던가, 자바는 잘하지만, 설계가 부족하던가, 소통이 뛰어나지만, 코딩은 떨어지거나, 빨리 만들지만, 버그나 설계가 취약, 반대로 느리지만 튼튼하게 만든다던가, 코딩과 설계가 뛰어나지만, 문서는 전혀 없는, 일은 잘하지만, 동료들과 계속되는 마찰 등)... 이런것들 때문에 스토리 포인트를 어떻게 결정하느냐의 방법에 또 고민하고 논의 돼야 합니다.
옛날에는 코드라인수, 늦게 까지 일하는 날의 수, 최근 들어서는 커밋의 수, 심지어 개발자의 컴퓨터에 어떤 프로세스가 어떻게 쓰여지는가 감시, 등등 빅데이타를 종합해서 평가 하기도 하는 모습을 봤습니다. 하지만, 사람의 일은 기계처럼 평가하기가 쉽지 않겠습니다.
회사, 팀의 문화와 관리팀의 성향과 바라는 점, 그리고 회사의 특성에 따라 달리할 수밖에 없다고 생각됩니다.
전반적으로는 = 팀워크(peer review) + 마감준수 + 퀄리티 + 개인 역량 발전 + 소통, 등으로 카테고리와 하면 그나마 수치화 하는데 도움이 되지 않을까 합니다.
웬만하게 뛰어나거나, 웬만하게 나쁘지 않으면 다들 보통으로 평가받고, 웬만하게 뛰어나거나 나쁜것은 너무나 쉽게 들어나서 평가하기가 쉬워서 궂이 그렇게 수치를 뽑고 그럴 이유가 없다 생각합니다. 그렇지만 경영/관리진이 원하니 어느정도 하기는 합니다.
결국은 어떤 방법을 써도 결국에는 팀리더/팀장/관리자의 평가가 끝인데, 정량화/수치로 밀어 붙이면 거기에 불만을 가질때 그런 정량화/수치로 반박을 막고 회사를 보호(공정하지 못한 평가라는 등)하는 도구로 전락하기 쉽상입니다. 그리고 팀의 성향도 그 정량화/수치만을 위해 일을 하는 성격이 되버리기 쉽습니다.
저 역시 은행에서 일할 때 그렇게 생각했습니다. 지식과 경험이 서로 많이 달라서 이 포인트를 어떻게 정하는지, 그리고 속도가 다른데 높게 잡으면 그것을 좋게 평가해야 할지 낮게 평가해야 할지 말이 안 됩니다. 저는 그래서 이 방법에 반대하는 편입니다. 사람의 다양한 지식, 경험, 일 처리를 공평하게 시험지처럼 점수를 매긴다는 게 가능한가 싶습니다.