Part.1 포스트에 계속 이어 가겠습니다.

===========================================================================

방청 패널 질문 1 :

한국 고유의 Domain의 대해서 언급 하셨는데, 기존의 유행하던 CRM의 경우 현재 거의 활용이 되지 않고 있는데, 한국 상황의 적용하기 어려워 폐기된 Domain을 재활용 하는 것에 대해서 어떻게 생각 하십니까? ( 편집자. 주 - 이 부분은 정확한 질문의 요지를 전달을 못 한거 같습니다. )

양수열 :

일종의 양날의 칼이 되지 않을까요? 글로벌 솔루션이 한국에서 실패의 원인이.. , 한국적인 모델이 오히려 글로벌한 모델의 장애가 될 수 있다고 봅니다. ( 편집자. 주 - 정확하지 않습니다. )

이진행 :

trend + industry knowledge + domain 지식

사용하지 않는 domain은 퇴출퇴기 시작한 부분이라고 보면 된다고 생각합니다.

방청 패널 질문 2 :

현재 12년차의 개발자이며 PM 업무를 맡고 있습니다.

PM으로서 후배 개발자들을 어떻게 성장시켜야 하는지에 대한 고민이 많습니다.

1. 첫번째 질문입니다. 현재 근무하는 회사에서 회사 차원에서 개발자의 커리어 패스에 대한 지원을 하기 시작했지만 개발자의 역할을 평가하는 방법에 대해서 알고 있습니다. 현재는 경력/년차를 기준으로 직급을 산정합니다.

2. SI 업무를 하고 있는데, 계약을 하는 과정에 갑의 경우 developer 등급의 개발자의 경우 고객이 인건비가 비싸기 때문에 인력 투입을 꺼려하는 경향이 있습니다. 이런 경우에는 어떻게 해야 하나요?

Matt Thompson :

1. sun은 직무에 대한 등급 산정에서 근속년수, 년차, 경력은 개발자 등급 평가에서 제외 했습니다.

이제 갖 학교를 졸업한 개발자라 할지라도 많은 경력을 가지고 있는 개발자보다 개발 능력에 있어서는 뛰어 날 수 있기 때문에, 단순한 근속년수와 경력으로 승진을 시키지는 않습니다.

개발자의 승진 가능성을 결정하기 위해서 다음의 6가지의 기준을 가지고 있습니다.

mentoring, 고객 관리, 의사 소통, 팀워크, 기술 능력, XXX ( 편집자 주. 마지막 하나의 능력은 정확히 듣지를 못하였습니다. )

기술 능력의 경우 현재 직급의 업무뿐 아니라 다음 단계의 직급의 업무를 현재 수행할 수 있는 능력을 가지고 있어야 진급 대상이 됩니다.

그리고 위의 6가지 요소 중 하나라도 부족한 경우에는 진급을 하기에 무척 어렵습니다.

그리고 진급 대상이 된 직원은 현재 자신의 매니저 뿐 아니라 여러 매니저들의 공통적인 평가에도 통과가 되어야 상위 직급으로 승진이 가능합니다.

2. 기본적으로 고객의 예산이 부족하다면, 달리 해결 방법은 없습니다.

SUN이 수행하는 컨설팅 업무의 경우 참여하는 개발자의 근속년수를 기준으로 프로젝트 수주비용을 계산하지 않고, 프로젝트의 복잡도를 기준으로 산정을 합니다.

방청 패널 질문 3 :

S/W 개발에 있어서 현재의 SI 및 여러 개발에서 흔한 하도급 체계의 문제가 심각합니다. 한국에서는 하도급 체계하에서 개발자의 생계 자체가 위협 받는 경우가 많은데, 미국의 경우는 이런 문제가 있었는지 궁금합니다?

Matt Thompson :

미국의 경우 기회의 차이가 있다고 생각합니다.

미국에서는 startUp(벤쳐) 기업을 시작할 수 있는 여건이 상대적으로 많다고 생각합니다.

저 역시 여러개의 아이디어를 가지고 있고, 언제라도 startUp 기업을 시작할 수 있습니다.

양수열 :

회사에서 부당한 대우를 받을 경우, 그에 대항할 수 있는 무기 개발(아이디어)이 필요합니다.

자기 아이디어에 대한 형상화가 필요합니다.

개발자의 경력에 관한 이야기 있습니다.

1년짜리 경험을 3번한 개발자와 1년, 2년, 3년 동안 경험을 누적해 온 개발자는 차이가 납니다.

경력의 년차보다는 그 사람의 경력이 어떠한 퀄리티의 경험으로 채워져 왔는지가 더 중요한 평가 기준이 되어야 한다고 생각합니다.

업무에서 외부에서 고용된 컨설턴트가 도움을 줄 수 있지만, 해당 업무의 정통한 엔지니어라야 해결이 가능한 영역이 분명히 존재합니다.

그러한 관점에서 해당 업무의 정통한 엔지니에가 된다면 부당한 상황에 대응의 폭이 넓어질꺼라 생각합니다.

개발자의 경우 컨퍼런스에서 기술적인 부분에만 관심을 가지지 말고, 개발 경력 관리라는 측면에서의 접근도 필요하다고 생각합니다.

- To be Continue.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.