협업 지수 측량

IT에서 개발자라는 존재는 너무나도 중요한 존재 입니다.

재료나 재화가 아닌 아이디어와 정보가 소모되는 특성을 가지기 때문에

사람에서 시작되고 사람에서 끝나는 것이 IT입니다.

 

이렇게 중요한 개발자의 능력을 측량할 방법이 너무나도 부족합니다.

자격증이란 것이 있지만 개발자의 전체 능력이 아닌 일부 능력(언어 표현력,알고리즘)만

평가하여 이 사람이 프로젝트를 수행하는 데 적합한 사람인가라는 의문에 부족한 답을

줄뿐입니다.

 

그 사람이 진짜로 일을 잘해 낼 수 있는 사람이냐?? 동료들과의 협업과 커뮤니케이션을 얼마나 해내느냐는

지금의 현실에서는 전적으로 면접관의 판단에 따를 수 밖에 없습니다. 이도 중요한 개발자의 스킬인데도 불구하고 말이지요.

 

그래서 많이들 회자하는 것이 국가단체에서 객관적인 개발자 면허를 만들어달라고들 합니다.

그러나 역사를 살펴보면 이런 일들은 국가에서 주도적으로 한 것이 아니라 민간에서 조합이 결성되어

그 단체가 강력한 영향력을 가지게 됨에 따라 그 단체의 일원이 되기 위한 시험에서 태동된 사례가 적지 않음을

우리는 볼 수 있습니다.(참고: 스티브 맥코넬 저 Professional Software Development)

 

먼저 개발자들이 깨어서 후배 개발자를 테스트하는 것을 만들면 어떨지요??

 테스트 과목은 다음과 같습니다.

• 알고리즘, 디자인 패턴 적용 능력
  
  - 완성도 높은 (유지보수가 용이하고 확장가능한 성능이 높은) 프로그램을 만들기 위한 필수 능력입니다.
  
   통상 코딩 테스트이겠지요.


• 프로그램 구현 능력/언어 표현
  
  - 언어에 대한 지식을 테스트 합니다. 알고리즘이나 디자인 패턴을 알고 있어도 실제로 구현하지 못한다면 무용지물이겠지요.


• 협업
  
  - 프로젝트에서 얼마나 기여도가 높은가??어떤 행동패턴인가??


• 커뮤니케이션
  
  - 문서를 얼마나 잘 이해하는가??애매한 요구 사항을 주었을 때 얼마나 올바르게 구현해 낼 수 있는가??


• 관리 능력


• 미래 성장가능성

이렇게 테스트 해보는 것이지요.

 

그러나 이 모든 것을 한번에 테스트 할 수 있는 방법은 MOCK 프로젝트 수행

즉,개발 환경(IDE,형상 관리 툴,DOC)만 있는 상태에서 요구사항만 던져주고 과제를 완수하라고 하였을 때

얼마만큼 실행 할 수 있는지 실제 테스트를 하는 것이지요. 팀에 평가관 한명 비슷한 경력의 피시험자 5~8명 정도로 하고

평가관이 누구인지는 모르게 합니다. 이렇게 해서 협업 커뮤니케이션 발전 가능성 프로그램 구현 능력/언어 표현 알고리즘,

디자인 패턴 적용 능력 테스트가 가능하게 됩니다. 그러나 이렇게 되면 모든 테스트를 평가관의 능력에 의지해야 하기 때문에

그 이전에 필답고사를 통한 테스트도 병행해야 합니다. 그리고 개발자는 연이어 응시가 불가능하고 3년마다 한번씩만 시험쳐야 합니다.

 

이 테스트가 미칠 영향력으로는

기존에 회사가 부담해야 했던 인재 측정의 일반적인 내용은 경감 시키고 각 회사의 고유 내용만 테스트하면

되기 때문에 그에따른 비용을 줄일 수 있으며 개발자의 능력에 맞게 일을 시킬수 있어서 잦은 야근 근무,낮은 개발 품질,

개발자에 의해 프로젝트가 공중분해 되는 일을 미연에 방지 할 수 있습니다.

개발자는 개발자 자신의 능력이 어느정도되는지 스스로 점검해 볼 수 있습니다.

 

또한 이것은 좋은 비즈니스 모델이 될 수 있으리라 봅니다.

개발자를 인증해주는 일반적인 모델이 국내에서는 없었기 때문에

이 사업을 하고 이것이 민간표준으로 인정만 받는다면

거두어들일 수익은 막대하겠지요.

 

참고 : 송치형의 InnoLab

자바 초창기 때 나왔었던 기술 JINI

이 글은 스프링노트에서 작성되었습니다.