"실전파"  그의 자부심은 하늘을 찔렀다.
이 사람은 기술적인 역량은 뛰어났고, 그 누구에게도 뒤지지 않을 식견과 경험을 가지고 있었다.
다만, 그에게도 단점이 있었으니 자신을 제외하고는 누구도 인정하지 않는다는 것이다.
프로젝트의 모든 기술적인 요소들을 그가 책임지고 리드했고 그를 몹시도 신뢰하는 책임자가 있었다.
그의 기술적인 부분에 대한 고집은 타의추종을 불허했고 사람들을 좀 함부로 대하는 습관이 있었다.
그럼에도 불구하고 "나초보"는 "실전파"를 신뢰하고 그를 추종하여 "실전파"의 멘토링으로 인해 성장중이었다.

당시 프로젝트에 도입된 기술적인 요소는 웹서비스를 도입하였으며 화면단의 framework 를 자체적으로 구축하여 시도중이었다. 그러나, 개발복잡도는 매우 높았고 프로젝트는 계속해서 지연되고 있었다.
원래 오픈을 계획한 1년정도의 시간이 지난 후에도 프로젝트의 오픈은 꿈도 꿀수 없었고 아직도 해결해야 할 문제가 너무 많았다.
 
결과적으로 PM 의 교체가 이루어지고 기술적인 요소들을 보완할 새로운 TA, AA  들이 투입되었다.
보름정도의 기나긴 회의와 조율끝에 F/W를 재작성 이라는 카드를 들고 프로젝트는 무기한 연장에 돌입되었다.
이때 "나고수" 의 투입과 더불어 나초보의 시각 역시 조금씩 변화하기 시작하였다.
"나고수"가 투입되면서 기존의 웹서비스 기반의 기술구조를 일반 J2EE 기반의 기술구조로 변경하고 업무 개발시에 Translation 해야 할 Cobol 기반의 프로그램들을 자동으로 읽어서 Java 기반의 Logic 으로 변경하는 Tool 을 제공하여 생산성에 많은 영향을 끼치게 되었다.

"나초보" 는 "나고수"의 가르침을 받고 싶었으나 기회가 되지 않아서 배우지 못하는 것이 안타까울 따름이었다.

"실전파" 의 실전적 감각과 지식은 더할나위 없었으나 그에겐 자신의 자부심으로 인하여 남을 인정하지 않고 다른 사람을 배려하는 것이 부족한 단점이 있었다.
그럼으로써 허풍선과의 사건이 발생했고, 현 상황을 통찰하지 못하여 프로젝트의 기술적인 주도권을 놓는 상황까지 가게 되었다.

"나초보"는 "실전파" 의 곁에서 그의 장/단점을 모두 보면서 커뮤니케이션의 중요함과 다른 사람을 인정하지 않고 자신이 아는 것 외에는 다 쓸데 없는 것이라 치부하는 사람들의 좋지 않은 점을 느낄 수 있었다.





블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|





용감한 "허풍선"
프로젝트에 있는 동안에도 계속해서 문제를 일으켰던 사람이 나가면서도 프로젝트를 뒤집고 나갔다.
그가 왜 그런것일까를 생각해 보았다.
표현적인 것으로 보면, 기존에 있었던 인력인 "나초보" 에게 물어보는 것도 자존심 상해했다... 
그리고 팀의 다른 인력들과도 커뮤니케이션 하지 않고 같이 투입된 다른 팀의 사람과 커뮤니케이션만 하고 있다. 
팀에서 작업하고 있는 내용이 무엇인지, 어떻게 개발해 왔는지 등등을 같이 작업하는 사람과 커뮤니케이션 하고 서로의 생각을 맞춰가고 자신보다 먼저 알고 있는 이가 있으면 그 사람에게서 배우고 내가 알게 된 것이 있으면 알려주는 형태의 커뮤니케이션이 가장 권장 할만 한데... 

프로젝트에 있는 두어달 동안에도 그는 계속해서 커뮤니케이션의 문제를 일으켰고 자신의 문제를 쌓아두기만 했다.
일정 관리하는 이에게는 벌써 다 되었다고 보고 된것이  다섯개의 프로그램
그런데 CVS 에 공유된 소스는 없다.
물어보면 다 되었다고만 한다.
"실전파" PL 이 확인을 해 보면 데이타가 어디선가 나오긴 하는데 모두다 다른 데이타다..

애초에 이 프로젝트는 ERD 등을 그려서 하는 정상적인 ERP  가 아닌 COBOL Regacy 에서 Data 를 끌고와야 하는 프로젝트 이기에 기존 Cobol 로 작성된 코드의 흐름을 쫓아서 개발해야 하는 사항이라... 
이게 어느 테이블에서 데이타를 끌고와야 되고 하는 것에 대해서 직관적으로 평가를 할 수가 없다.
그래서 Cobol Source 와 Java Source 를 서로 비교해가면서 봐야 하는데.. 
누가 그렇게 검증해 주겠는가?
모두다 바쁜 프로젝트 상황이다.

그렇게 자신의 문제를 쌓아두고 있다가... 안되는 부분을 우리의 "실전파" PL 의 까칠함과 은근히 사람 무시하는 듯한 표현으로 인해 "허풍선" 폭발하고 말았다.
사고 치고 나가서 수습하는 과정에서 "나초보"는 "허풍선"의 코드를 보고 경악했다.
'뭐야... 무엇을 보고 코딩을 한거지?'  , "다시 개발 하겠습니다. PL님"

며칠 후 "허풍선" 과 그 회사 사장이 프로젝트에 들어왔다.
사고에 대한 해명을 하러 온 것 같은데... 
"팀원들이 저만 왕따 시켰어요."
"PL 이 사람을 스트레스를 너무 줬습니다."
"맡은 거 개발은 다 끝냈습니다."

지나가면서 들은 "나초보"  그리고 그의 동료들은... 정말 할말이 없었다.

허풍선은 정말로 저렇게 생각하고 있었는지 모르겠다.
가끔 사람들을 보면 자신이 생각한대로만 세상을 바라보고 사실이 아닌데도 자신이 생각한대로 사실로 인지하는 사람이 있다.
그런 스타일인지 모르겠지만, 여하튼!   허풍선의 문제점은 분명히 있었다.

1. 자신의 문제를 혼자서 싸 짊어지고 있다. - 비밀이 많다.
2. 남의 얘기를 들으려 하지 않았다.
3. 이상한 자존심을 가지고 있다.
4. 결론적으로 사실이 아닌 것을 사실인것처럼 얘기하고 있다.

이 사람과 커뮤니케이션을 하려면 어떻게 했어야 했을까? 

<답을 생각해 보자...>  

하루 생각해보고 글을 올린다. 

리더는 왜 자신의 문제를 다른이들과 공유하지 않는지를 파악했어야 했다.
( 경력의 문제인지, 성격의 문제인지 등, ) 
그래서 그와 함께 문제와 해결책에 대한 내용을 공유해야 했다. 
그런데, 여기서 문제가 있는 것이 일반적인 개발 프로젝트의 특성상 중급 이상의 개발자를 외주로 투입했다면 그에게서 필요한 첫번째 능력은 기술적인 능력 즉, 해당 프로젝트에 얼마나 기여할 수 있는가? 라고  생각한다. 
즉, 그가 해야 할 책임을 먼저 해야 하는 것이다.
그 생각이 먼저이므로 관리자는 아마도 그를 이끌어가는 것에 대해서 초보자에게 접근하는 방법을 쓰지 않았을 것이다.
여기서 서로간의 이해가 상충했을 수 있다.
해당 팀의 리더라면 두가지중 선택했어야 했다.
1. 그와 충분한 상황과 생각에 대한 공유와 리더쉽을 통해서 그의 문제를 해결해 감으로써 같이 나아가는 방법과 
2. 외주개발자 이므로 그 책임을 다하지 못하는 것을 알게 될때 인력교체에 대한 것을 심각하게 고려해 봐야 한다. ( 물론 나역시도 이런 부분에서 자유로운 사람은 아니지만, 객관적으로 봤을 때는 이렇다는 얘기이다. ) 

리더는 두번째의 결정을 미루면서도 첫번째의 시도를 해보지 않은 것이 해당 인력으로 인해서  프로젝트팀에 좋지 않은 영향을 미치게 되었다.

또한, 허풍선의 네번째 특징인 사실이 아닌 것을 사실인것처럼 얘기하는 사람이 놀랍게도 가끔 있다.
그가 일부러 그러는 사람일수도 있지만, 진정으로 자신이 그렇게 믿는 사람도 있다.
이 부분은 심리 부분에 대한 연구를 좀 해봐야 알겠지만, 
지금까지 내가 경험한 바로는 '자의식' 이 강한 사람들, 자신이 생각한 것을 그대로 믿는 사람들 ( 시간이 갈수록 그의 머릿속은 정확하게 사실이 되어간다. ) 이 있더라... 

다른 것은 차지하고라도 그와의 소통을 하려면 
1. 그의 말을 들어보려고 노력해야 했다.
2. 원인이 무엇인지 같이 파악했어야 했다.
3. 그가 다른 사람과 소통하지 않음으로써 야기되는 업무적인 문제점들에 대해서 그와 공유했어야 했다.



결론은 없지만, 주변사람들이 어떻게든 그와 '소통'을  하려고 노력하지는 않았다는 것은 자명하다.




블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|


2008/12/05 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발을 한다는 것, 일을 잘한다는 것.
2008/12/07 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 나초보씨의 일화 두번째 - 이젠 팀의 키맨으로...


허풍선은 앞에서도 소개했듯이 7년차 개발자이다.
이력을 보면 PM 경력도 있으며 무언가 많이 아는 듯 행동한다.
우리의 나초보 다른 개발자들에게도 그러했듯이 허풍선에게도 여기 프로젝트의 환경과 개발툴, 데이타베이스 구조등을 설명했다.
훔... 허풍선은 다 안다는 듯 별 설명을 듣지를 않는다.
물론 우리의 나초보 설명 잘 하지 못한다.
그도 그럴것이 프로그래밍에 소질도 없던 사람이 한 5개월? 남짓 빨리 들어와서 개발환경에 익숙해져있다고 고수는 아니지 않겠는가?
거기다가 이 나초보는 사회 초년생에 혼자서 모니터만 바라보던 공부 습관이 남아 있어서 커뮤니케이션에 그다지 익숙하지 않은 터였다. 그래서 다른 사람에게도 실수를 많이 했으나 다른 이들은 어느정도 이해를 해 주는 편이었다. 평소에는 싹싹하게 잘 구는 성격탓이라고 할 수 있겠다.
다시 허풍선의 얘기로 넘어오면 이 허풍선은 다른 사람과는 좀 달랐다.
설명하면 듣지도 않고 다른 층에 있는 자신과 같은 회사와 계약한 사람과 놀고 있다.
아니 놀고 있다기 보다 이 프로젝트의 환경을 거기가서 물어보는 듯 보였다.
나초보는 다른 경험이 없었기에 의심을 하거나 할 식견은 되지 않았고.. 다만,
"아.. 내가 성격이 참 그런가 보다.... 저 사람은 참.. 희한하게 따로 놀고 다른 팀에 가서 놀고 있네..."
라는 생각을 했다.

우리의 "실전파" PL 은 항상 일정관리를 하고 있다.
모두 일정을 잘 지키고 있었고... 이제 나초보가 속한 팀의 업무가 마무리를 향해 달려가는 중반 이후의 시점이었다.
실전파 PL 은 각 개발자들의 프로그램을 테스트 해 보고 있다....
헉! 그런데 이게 왠일인가?
프로그램이 하나도 제동작을 하지 않는다...
이런!!! 썩을!
"이봐 허풍선 이리 와봐! 이거 왜이래? "
"어? 이상하네요... 다시 볼께요.."
그들의 대화는 이렇게 시작되었다.
일주일동안 그들은 그렇게 고치고 또 고치고.. 희한한 데이타가 나오고...
실전파는 급기야 허풍선의 코드를 직접 까뒤집기 시작한다.
"이런... 야야.. 나와봐.. 이게 뭐냐? ...이렇게.. 이렇게.."
한 2주일 정도 그렇게 실전파가 허풍선을 가르치거나 면박 주면서 개발을 도와주나 싶었다...
우리의 영웅 "허풍선" 우리의 기대를 져버리지(?) 않았다. 솔직히 좀 잘난체 하고 배려 없이 말을 툭툭 뱉었던 실전파 덕분에 스트레스 좀 받으셨나보다~. 
갑자기 우당탕!!!!! 소리가 나면서 허풍선이 실전파와 몸싸움을 하고 있다..
그러더니.. 사무실을 발칵 뒤집고.. 사무실에서 고함을 한동안 지르다가 나간다...
"이런... "
그 이후... 일은 뭐.... 프로젝트에서 짐싸고 며칠후 계약회사 사장과 같이 와서 그동안 일한거라도 돈주라고 그러고 있고... 그리고 자신이 팀에서 왕따를 당했다고... 한쪽에 와서 그러고 있다..
그꼴을 보는 나초보.. 분통이 터지고 ~~~~

실전파... 일이 어떻게 되든 간에 나초보에게 "일단, 허풍선이 개발하던 코드 니가 보고 다시 고쳐라.." 라고 지시를 내렸으나 나초보가 그 코드를 본 결과..
"와!.... 이건 프로그램이 아니라 그냥 다른 코드 복사해 놨네... ㅡㅡ;; 테이블도 전혀 다른 테이블에서 조회하고 있고... 화면 코드는 전혀 되지 않았고.."
"실전파 PL 님, 이건 전부 다시 만들어야겠는데요..."



이쪽 업계 경험이 많은 사람이라면 이 상황을 보고 잠깐 생각해 보면 알 수 있는 것이...
허풍선은 아마도 개발 경험이 별로 없었던 듯 하다..그리고 경력을 부풀려 왔다고 생각이 되는것이..
전혀 다른 팀에 가서 물어보고 있고.. 도움을 팀에서는 전혀 받지도 않으려 했다.



( to be continued.... )
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

우리의 나초보씨...
몇달간 나잘난과의 스트레스를 잘 견디고 프로젝트에서 어느덧 자리를 잡았다.
Ant 기반의 프로젝트 빌드 통합과 CVS 사용법을 독학 형태로 ( 물론 고수의 결과물을 보면서 배웠지만... ) 깨우치고 코딩은 프로젝트 표준은 Editor 를 통해서 ant 빌드하는 형태로 구성되어 있지만, 스스로의 생산성을 위해서 IDE를 혼자서라도 사용하면서 프로젝트의 특이한 기술 기반에 적응을 한다.

프로젝트의 가장 Risky 한 것은 기존 Cobol 기반의 레거시를 어떻게 자바 기반으로 개발할 것인가 였다.
업무가 녹아 있는 host 의 Cobol Code와 연동할 Presentation Layer 의 코드는 Cobol 에서 ( C/S )  Web으로 변경하는 작업이었다.
다행히 PL 실전파 의 멘토링과 나고수의 프로젝트의 생산성의 증가에 많은 영향을 미쳤던 빌드 스크립트로 인해서 프로젝트는 엄청난 지연에도 불구하고
이제는 머나먼 여정의 끝이 보이기 시작했다.

프로젝트의 여러가지 난항에도 굴하지 않고 열심히 일했던 나초보...
어느덧 그 파트의 key-man 이라는 말을 듣게 된다....
기존 개발자들이 모두 계약이 끝나고 나갔고 PM이 바뀐 상황에서 다시 프로젝트를 끝내 보자고 중급 개발자 급으로 ( 우리가 흔히 겪듯이.. ) 밀어 넣어서 끝내려는 책임자들.. 그 틈바구니에서 나초보는 그냥 열심히 학습하고 일하고 있다보니 기존의 개발환경과 변경되는 개발환경 간의 간극과 나초보가 속한 팀의 업무를 아는 개발자가 없다는 것이 나초보의 경험에 긍정적인 영향을 미치기 시작한다.

나초보의 팀에도 7,8 명의 개발자가 투입된다.
나초보는 신규 투입된 개발자들에게 가이드 하게 되는 역할이 당분간은 중요해졌다.( 프로젝트에서 오래 있었고, Framework 이 변경된 와중에 작업을 진행하였다는 이유와 프로젝트 환경을 안다는 이유하나만으로.. ^^;; )
그래서 신규 개발자들을 가이드 하고 개발하는 것을 Support 하게 되면서 나초보는 재미있는 사람들을 한사람 한사람 보게 되는데..

그 중 한사람은 "허풍선"
경력을 보니 7년차 개발자다.
PM 경력도 있고 개발 경력도 많았다.
다른 사람에 비해서 다른 팀에 아는 사람도 있고... 적응을 잘하는 것 같았다.
그러나 정작 나초보가 겪어본 허풍선은 좀 달랐다.

그리고 이미 알고 있었지만 성격 강하고 자부심 강한 실전파씨
그는 개발자 출신이어서 커뮤니케이션이 약하고 코드로 말하는 스타일이다.
그러나 현재는 아키텍트라고 부르는 역할을 그 당시 프로젝트에서 수행하고 있었으므로 책임이 막중했다 하겠다.
실전파는 가장 커다란 단점이 다른 사람을 인정하지 않는데 있었는데...  그 부분은 그 사람의 성향과 자신에 대한 자신감/자존심 이런 것들이라 하겠다.
그런 부분은 향후 프로젝트의 지연을 책임지기 위해서 투입되었던 나고수를 대하는 부분에서 발견되게 되는데..



이 세사람에 대한 얘기는 다음에 하도록 하겠다.

( to be continued.... )




2008/12/06 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 안하무인인 나잘난씨
2008/12/05 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발을 한다는 것, 일을 잘한다는 것.


블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|


나초보의 일화 두번째의 연장이다.
"나잘난"의 부하 직원형태로 프로젝트에 투입되었던 아무 것도 몰랐던 나초보는 아무래도 "나잘난" 에게 의지 할 수 밖에 없다.
그래서 개발하는 데 있어서 로직상의 문제라던지 트릭을 사용해야 하는 일이면 어김없이 "나잘난"에게 물어봐야만 하는 경우가 생긴다.
그런데, 이게 참 재미있는 상황인 것이... 이 나잘난 은 프로젝트에서도 건방지기로 유명한 사람이다.
자신이 경험이 많다는 거만한 생각을 가진 탓에 자신이 하고싶은 일만 하고 기본적인 프로젝트의 규칙도 잘 따르지 않았다.
남이 어떻게 하든, 공통팀이 어떻게 만들든 그놈을 뜯어 고치기 일쑤였고 맘대로 형상관리 쪽에 반영해버리기 일쑤였다.
이 나잘난이 어떤 사람을 멘토링이나 지도하는 형태는 모든 것이 자신의 우월감을 드러내는 형태이다.
나초보가 화면의 어떤 로직을 만들면서 부딪힌 ( 일반적으로 초보 개발자들은 초반에는 업무 화면의 처리에서 트릭성의 또는 처리상의 팁 격인 경험치가 없어서 힘든 경우가 많다. ) 문제를 나잘난에게 물어볼 때면 어김없이 모멸감을 느끼게 한다.
"나초보씨, 공부좀 더해야겠네~~~, 뭐 이런 걸 몰라요.. 잘 봐요.. "
꾸짖으면서 가르친다.. 아니, 코드 짜는 걸 보여준다..
그리고 나서는 오늘도 어김없이  "내가 프로그램 처음 할땐 말이지..... 어쩌고 저쩌고.." 영웅담을 늘어놓고 있다.
나초보는 이 나잘난이 나이도 같은 놈이 조금 경험 일찍 했다고 너무 잘난체 한다고 생각했다.
그래서 최대한 빨리 이 사람과 헤어지고 싶다는 생각을 하게 된다.

나잘난 같은 사람과 일할 때는 어떻게 하면 잘 지내고 스트레스 받지 않고 많은 것을 배울 수 있을까?
최대한 그 사람을 인정해주고 배우는 자세로 대해야 할 것이라고 생각을 한다.
아무것도 가르쳐주지 않으면서 X랄 한다면 그것은 문제가 있지만, 이사람은 표현의 문제가 있고, 자기 잘난 맛에 사는 사람이므로 이 사람과의 소통은 그 잘난 것을 인정해 주는 것이 첫걸음 일거라 생각을 한다.

개인적인 생각으로는 팀 프로젝트에서 나잘난 같은 사람이 있는 것은 그 사람이 가진 생산성이 아무리 좋든 간에 팀의 생산성에 영향을 미치므로 ( 선택의 기회가 얼마나 있겠냐마는.. ) 같이 일하고 싶지 않은 부류 중 하나이다.

나 역시도 흔히 하는 실수중 하나인데...  무언가를 알려주면서 상대방이 모멸감을 느끼게 할 경우가 있다. 빈정상한다고들 하는데... 특히 배우자와의 대화에서 가장 많이 일어나는 경우중 하나라 생각이 된다.
자신이 알고 있거나 경험한 것을 상대방이 모를 때, 나도 모르게... "내가 한수 가르쳐 줄께!" 라는 생각을 하게 된다.
그리고 상대방을 보는 시각은 내려보게 된다.
이미 자세부터가 상대방의 머리위에 서려고 하는 자세다..

무언가 물어오는 사람이 있다면
"그 사람이 이 질문을 하는 이유가 무엇일까?"
"왜 이것을 모르는 것일까?"
"그 사람의 이전 경험치는 무엇인가?"
등을 고려해서 가이드를 해줘야 할것이다.

그런 고려 없이 가르쳐주거나 가이드 해준다면 대부분의 사람은 위와 같은 실수를 저지르게 된다.
그리고 나서 속으로 생각한다.
"내가 애써서 알아 낸것을 아무 댓가 없이 또 내 시간을 써 가면서 가르쳐줬는데... 이런 식으로 대해도 돼!"
또는
"이런 것도 못 받아들이면 배울 생각 말아야지.."
이런 형태로 생각하게 될 것이다.

이 전 글에서도 한말이지만, "상대방의 신발을 신고 걸어보자."

 

이 다음엔 우리의 "허풍선" 씨와 "나잘해" 씨의 재미난 사례를 보고 얘기를 나눠보자.

--- 관련 글 ---


2008/12/05 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발을 한다는 것, 일을 잘한다는 것.


블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

개발자 나초보의 일화 두번째

 

첫 경험에서 큰 깨달음을 얻은 개발자 나초보

이제는 정말 자신이 하고 싶었던 일을 하기 위해서 기존에 자신이 계속 공부해왔던 자바 기반의 프로젝트에 투입되게 된다. 여기는 4개월 계약을 하고 투입되게 되었다.

투입되고 이틀 뒤 PM 이 전체 개발자 40여명을 소집을 한다.

지금 우리 프로젝트는 위기입니다. 금일부터 10시 이전 퇴근을 금합니다!” 라는 청천벽력 같은 선언. 우리의 초짜 개발자 나초보씨. 그게 무슨 의미 인지 몰랐다. 그냥 SI 프로젝트 바닥이 다 그런줄만 알았다. 우리의 PM은 또 다시 부연 설명을 한다.

우리의 프로젝트에서 쓰인 기술은 여러분에게 정말 도움이 많이 될 거라 자신합니다. 열심히 해 주시고 프로젝트 목표 달성을 위해서 최선을 다해주시기 바랍니다.”

 

이런 프로젝트도 있구나.. 싶은 나초보씨.

아무 생각없이 그냥 열심히 일했다.

나초보는 이 프로젝트 현장에서 재미있는 사람들을 많이 목격한다.

이번엔 나초보가 경험한 여러가지 스타일의 사람들에 대해서 얘기 하려 한다.

7년의 경력을 자랑하고 다 된 것 처럼 얘기 했지만 실제 확인해보니 프로그램을 한건지 C&P를 한건지 아무 업무도 맞지 않는 개발자 허풍선 씨,

7년정도의 경력을 가졌으나 나이나 겸손은 경험에 걸맞지 않게 건방짐을 자랑하는 나잘난씨

자바가 도입될 때부터 개발을 해 왔고 실전에 무척이나 강하고 자존심 강한 PL 실전파 씨,

무조건 밀어부치면 다 된다고 생각하는 새로운 PM 막가파씨,

중간에 투입되었지만, 자신이 터득해온 신기술로 프로젝트의 생산성에 지대한 영향을 끼치고 좋은 사례를 보여준 나고수 씨

 

일년간 이들을 보면서 나초보는 많은 성장을 경험하게 된다.

그리고 그들을 통해서 커뮤니케이션을 어떻게 해야 하는지 , 일을 어떻게 해야하는지, 어떤 능력을 키워야 하는지를 생각하게 된다






 이 기회에 소설가로 전향? ㅡㅡ;;; 

( To Be Continued..... )


-- 관련글 --

2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 피드백의 중요성
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 말 잘하는 사람이 성공한다.
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 굳이 말하려고 하는 이유
2008/12/03 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발자와 커뮤니케이션 글쓰기의 시작

블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|



개발자 나초보의 일화 첫번째

 

개발자 나초보는 약점이 있었는데, 프로그래머의 피가 좀 부족하다는 것이다.

알고리즘이나 자료구조, 파일 처리론 등을 공부를 열심히 했고,  자바 랭귀지는 몇 년간 공부를 해 왔으나 희한하게 창의력 즉, 문제가 주어졌을 때 풀어나가는 능력이 자기 자신이 생각해도 한심할 정도로 떨어졌다. 그도 계속해서 공부를 하다 보니 이제야 감을 좀 잡나 싶었다.

그러나 웬걸?

첫 직장에서 개발자는 선임 개발자 한 명 이고 그 선임 개발자 마져도 남을 지도하는 데는 별 취미가 없었던 사람이다. 그러다 보니 모든 문제를 자신이 알아서 하는 형태여야 했고 웹 호스팅 회사에서 전임 개발자의 소스를 뜯어다가 붙여 넣는 C&P 신공에만 주력하게 되었다.


그에겐 DB Modeler 가 되는 꿈이 있었다. 그러나 모델링 관련해서 job search 를 해 봐도 눈에 띄지 않았고, 전공도 하지 않은 터에 지방 학교.. IMF 를 지난 지 몇 년 안된 시점.. 그를 써줄 회사는 눈 씻고 찾아봐도 쉽지 않았다.

그래서 나초보는 방향 선회를 결정했다.

그래, 개발을 좀 해 보다가 Database 설계 쪽 일을 해 보는 거야!”

마침, 아는 사람을 통해서 웹호스팅 회사를 소개 받게 되었고, 서로간의 약속의 불이행으로 인해 6개월 후 퇴사하기까지 그 회사에서 자신의 의지와는 상관 없이 정말 배운 것 없이 지낸 시절 이었다.

그러나 정작! 문제는 그 다음 이었다.
6개월 일 하는 동안에 쌓지 못한 Skill 이 나초보의 발목을 잡게 된다.

 

개발자 사회에 대해서 잘 모르는 나초보는 잡코리아에 자신의 경력서를 올리게 되었고 전화를 한 통 받게 된다.
*** 은행에 들어가는 프로젝트란다
경력관리에도 도움이 될거고 금액은 이정도를 준단다..
회사에서 제시하는 금액은 일반 신입사원의 반정도 밖에 못 받았던 그 전에 다니던 회사와
거의 동일한 금액으로 3개월 계약직을 얘기한다.
( 나중에 알게 된 사실이지만, 이 계약 형태가 프리랜서의 계약형태였다... 아마도 그 회사는 나초보에게 주기로 한 금액만큼 폭리를 취하려 했던 것 같다.. ) 
자신의 개발 경력이 6개월밖에 되지 않아서 나초보는 해당 계약에 동의를 하게 된다.
그리고 3개월동안 나초보의 하루 하루는 정말 지옥같았다.

투입된 지 한달 후부터 인원을 바꿔달라는 PL의  요청은 매일같이 전화기 소리 너머로 들렸고 프로그램 설계자의 태도는 가르치는 수준에서,,,, 아예 대놓고 무시하고, 차별하고, 설계서를 내 던지는 수준까지 가게 되었다. 그러나 "나초보" 인생 살아가는 데에는 열정이 있고, 오기가 있는지라...
여기서 물러나면 더 이상 갈 곳이 없다는 배수진을 치고 바늘방석에 기꺼이 앉아서 버텼다
매일 12시 넘어 퇴근에 주말에도 출근하고 밤샘도 기꺼이 했다


그러나 계약 만료전 나초보가 계약한 회사의 사장은 PL과 설계자가 

나초보씨는 아는 것도 없으면서 잘 물어보지도 않는다. 하나 고치면 하나 에러난다. 같이 일 못할 정도로 불안하다.”라는 말을 했고 그래서 나초보에 대한 급여에 대한 잔금을 지불하지 못하겠다고 했다 한다.
그래서 월급을 못주겠다는 말을 하고 있다.


그러나 나초보의 입장은 달랐다.

개발경력 6개월로 솔직하게 넣었고, 금액도 거기에 맞춰서 정말 박봉으로 받았다.

그리고 같이 투입된 계약 회사의 4년차 개발자 "나중수" 그는 그 프로젝트에서 이미 베테랑 이었다.

"나중수"는 같은 회사 소속이었으므로 리드를 해 줬어야 하는데 기존에 있었던 멤버들과의 친분이 이미 있었고, 프로젝트가 2차였으므로 혼자 작업하기 바빴다..


나초보는 무언가 모르는 게 생길 때에도 프로젝트 경험이 없기 때문에 무엇을 어떻게 수정해야 하고 어디서부터 접근해야 할지 접근법 조차도 모르는 신입이다.

또한 질문조차도 어떻게 질문해야 하는 지도 모르는 초짜 신입 개발자 이다.

그에게 일을 시킬 때 일반 프리랜서 개발자 ( 나초보는 자신이 프리랜서라는 것도 모른다.) 에게 일을 시키듯이 시키고 나서 아무런 의사소통도 없이 나초보씨를 투입시킨 회사의 책임으로 돌린 것이다.

 

나초보씨가 실수한 것은 자신의 입장을 충분하게 표현하지 못한 것이다.

, 자신은 신입이고 이런 일처리에 대한 감각이 없다는 것을 주위에 적극적으로 알리고 도움을 받았어야 했다. 프리랜서의 입장은 가만히 있어도 누군가 이끌어주고 하는 선/후배가 거의 없다고 봐야 한다. 자신의 앞가림을 자신이 모두 해야 하고 자신의 역할을 다 해야 하는 것이다.

아무리 무엇을 물어볼지 모른다지만, 계속해서 물어보고 발전 시켜나가야 한다.

흔히 개발자에겐 자신에게 문제가 주어지면 다 완성되면 보여줘야 한다는 생각에 모든 문제를 끙끙대며 안고 간다.

그러다가 한,두달 정도 지나고 스케쥴 확인과 완성된 프로그램을 확인할 때 사태는 걷잡을 수 없는 상황으로 달려간다.

자신에게 지시를 내리는 사람이나 설계를 한 사람, 현업에의 끊임없는 피드백과 커뮤니케이션은 아무리 강조해도 지나치지 않다.

 

그 프로젝트의 PL의 소통 능력도 매우 의심 스럽다.

자신이 이끌고 있는 팀원의 자질에 문제가 있다면, 그가 무슨 문제가 있는가를 적극적으로 알아보고 리드 했어야 했다.

리드를 해야 할 사람이 자신의 역할은 하지 않고 상대방에게 책임만을 요구한다면, 그것은 그 팀이 깨질 수 밖에 없는 요인이 된다.

 

설계자 역시 자신의 일만 하는 것이 아니라 개발자의 문제를 보았다면 win-win 할 수 있는 방안을 만들었어야 했다.

 

서로간의 커뮤니케이션의 부재에서 문제가 발생했다.

나초보만의 문제가 아니라 개발자의 일반적인 성향으로 인해서 발생한 문제라고 해도 과언이 아닌 사례이다.

 

우리 개발자들은  일반적으로 피드백에 약하다.

모두 완성되면 한방에 보여주려 한다.

중간 중간에 보여주면

혹시나 내가 한 작업을 별볼일 없다고 무시 받으면 어떻게 하지?”

내가 짠 코드를 감히 누가 뭐라고 해?”

등의 생각을 하고 접근하게 된다.

 

모든 사람간의 관계가 그렇듯이 피드백은 정말로 중요하다.

그것이 긍정적 피드백이든, 무언가 고쳐줘야 하는 피드백이든….

피드백은 서로의 상황을 공유하는 첫번째 단계이다.

 

위의 사례에서는 또 하나의 촛점이 있다.

바로 적극적인 자신의 의사표현이다.

자신의 의사표현을 적극적으로 하지 않은 탓에 나초보는 자신이 받아야 할 정당한 대우조차도 받지 못하고 자신이 일하고 있는 상황 역시 최악으로 치닫게 되었다.

우리는 흔히 결과물로 얘기해야 한다고 말한다.

그리고 한방에 보여주려 한다.

그러나, 사람간의 관계는 자신을 적극적으로 표현하지 않으면 항상 손해보게 마련이다.

 



--- 이전 글---
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 말 잘하는 사람이 성공한다.
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 굳이 말하려고 하는 이유
2008/12/03 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발자와 커뮤니케이션 글쓰기의 시작

패턴 그리고 객체지향적 코딩의 법칙 상세보기

자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 상세보기



블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|