상대를 평가하기 전에 관찰하라..
무슨 의미 일까요? 

흔히 커뮤니케이션을 할 때, 우리는 판단을 하면서 상대방을 평가하려고 합니다.
그 말을 듣는 상대방은 그 평가에 대해서 당연히 반감을 가지게 되지요.

그것을 방지하는 방법은 내 판단을 상대에게 얘기하기보다는 상대방의 행동이나 표현을 구체적으로 언급하는 것입니다.

있는 그대로 보고 받아들이기 보다는 정의 내리거나 낙인찍어서 선입견으로 바라보게 되고
자신이 관찰한 것을 그대로 얘기하기 보다는 자신의 판단을 얘기해서 커뮤니케이션을 하기도 전에 상대방의 마음을 닫아 버립니다.

상대방이 가지고 있는 부분을 자신이 알고 있는 식견에 맞추어서 보는 자신의 습관이 상대방과의 커뮤니케이션을 방해하는 요소가 됩니다.

물론 우리들은 세상을 바라볼 때, 자신의 살아온 환경, 경험에 의해서 생각과 가치관이 자리잡았으므로 그런 자신의 시각을 제외하고 바라볼 수는 없습니다.

다만, 노력하자는 것이죠.

자신의 생각으로 눈앞에 하나의 막을 씌우고 세상과 사람들을 바라보는 것보다
그 막을 벗기고 실제로 보이는 것, 상대방이 보이고자 하는 것을 그대로 받아들이는 관찰이 커뮤니케이션을 위한 첫 단추가 됩니다.
이전에도 얘기했듯이 "상대방의 신발을 신고 걸어보라" 는 것은 말 그대로 온전히 상대방의 입장이 되어보라는 것입니다.
상대방의 입장이 되어서 상대방의 안경을 끼고 바라볼 때여야 만이 상대방이 생각하는 것을 알게 되고 그로 인해서 상대방과의 커뮤니케이션을 할 준비가 된 것입니다.

무슨 말을 하더라도 상대방이 자신의 시각으로 나를 규정 지으면서 말한다는 것은 언제 닥쳐도 불쾌할 것입니다.
그럴땐 이렇게 생각을 하죠
"왜! 내가 말하는 것을 , 행동하는 것을 있는 그대로 받아들이지 않는거야?"



"(캠코더를 들고 찍듯이) 판단하지 말고 상대방을 관찰하는 것이 커뮤니케이션의 첫걸음입니다."










블로그 이미지

[짱가™]

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




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

당시 프로젝트에 도입된 기술적인 요소는 웹서비스를 도입하였으며 화면단의 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. 그가 다른 사람과 소통하지 않음으로써 야기되는 업무적인 문제점들에 대해서 그와 공유했어야 했다.



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




블로그 이미지

[짱가™]

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





똑똑한 질문이 똑똑한 답을 낳습니다.
여기 예제 PT 에서는 긍정형의 질문이 미치는 효과에 대해서 설명합니다.
비난 성 질문에 좋은 대답, 긍정적인 대답이 나오는 경우는 거의 없습니다.
우리는 흔히 부하 직원이나 아랫 사람에게 질문을 할 때 ( 갈군다고 하죠? ) 부정적으로 바늘로 찌르듯이 질문을 하곤 합니다.
그렇게 질문하여 상대방이 움찔 하는 것을 보면서 속으로 생각하죠.
"봐~ 임마~ 내가 뭐라 그랬어... ", "내가 날카롭지? 그러니깐, 나 무시하지 말어..."
그렇게 상대방의 허물이나 잘못을 들춰내면서 찌르지 않아도 대부분의 사람들은 스스로의 행동에 대해서 생각을 합니다. 그리고 반성을 합니다.
반성을 못하거나 자신이 무슨 실수를 한지 모르는 사람이라면 긍정적인 질문으로 그 사람의 대답과 생각을 이끌어 내야 합니다.

네, 우리 개발자들도 마찬가지 입니다.
그렇죠? 개발자 격언중에 "Garbege in, Garbege Out" 이라는 말이 있습니다.
사람과의 의사소통도 마찬가지 입니다.
질문을 개판으로 하면 대답도 개판이 됩니다.
가끔 우문현답을 해 주시는 훌륭한 분도 계십니다만,,,

그런 경우가 있습니다.
업무 의사 결정에 관련하여 회의를 합니다.
"유스케이스 도출" 하는 회의라 합시다.
요즘은 그런 경우를 듣지를 못했습니다만, 몇시간의 회의가 "유스케이스" 정의 논쟁하다가 끝나버립니다.
원래 회의의 목적은 "도출" 이었습니다만, 우리는 그날 "누가 더 똑똑하냐?" 에 대해서 얘기하다가 끝나버렸습니다.

전에 개발자 커뮤니티에 질문을 올리시는 분들중에 이런 분이 있었습니다.
"자바로 게시판을 만들어야 하는데요.... 무엇을 공부해야 하나요?"
그래서 답변을 이렇게 달았습니다.
"라면을 끓이려고 하는데 어떻게 끓여야 하나요?" 라고 질문하신 것과 같습니다.
라고 달았죠....
네! 질문하신대로 답해드렸습니다... ( 제가 대답을 잘했다고 말하는 거 아닙니다. ㅋ )

요점은... 제대로 된, 자신이 원하는 답을 얻고 싶다면 제대로 된 질문을 해야 합니다.
직업적인 선에서 보면,
"선은 blur, blur 후는 blur, blur 한데.... 나는 xXX 를 하고 싶다.. 그 와중에 OOO 라는 문제가 생겼다"
이 정도 질문이면 매우 훌륭하겠죠?
그렇다면 답하는 사람도 맘이 편안해 집니다.
안다, 모른다, 이렇게 하면 된다... 형태로...
( 하지만 예외도 있습니다.... 뜽금없는 대답 하시는 분도 있죠.. )

모.. 위의 그림은 밑에서 예시로 든 얘기는 아니었으나 이렇게 이야기를 풀어버렸네요.

사람대 사람의 커뮤니케이션으로 생각해보면
긍정적인 질문과 긍정적인 대답을 유도한 질문은 상대방에게 의욕/열정 을 올릴 수 있는 좋은 계기가 된다고 배웠습니다.
이런 훈련을 꾸준히 해야겠죠.
우리는 컴퓨터와 보내는 시간이 많고 컴퓨터에게 명령을 내리고 있지만,
실제 우리가 풀어나가야 하는 문제들은 사람에게 있으니까요~

그럼 커뮤니케이션에 대한 두번째 이야기
"똑똑한 질문이 똑똑한 답을 낳습니다." 를 마칩니다.


p.s. [ 제 자신에게 하는 이야기 ]
커뮤니케이션에 대해서 아무리 공부하면 뭐하나요...
직장에서, 가정에서의 커뮤니케이션
가까운 사람과의 커뮤니케이션이 가장 어렵습니다.
내가 가진 단점과 치부를 다 아는 사람들이니까요... 그래서 내가 이성적으로 가리고 있던 부분들이 튀어나오기 시작합니다.

그것만 제어할 수 있고, 변화가 되면 성공하는 거라고 생각하고 있습니다.

본질적으로 변화하는 것이 Best 라고 생각하고, 본질적으로 변화하려고 노력해야겠죠... ( 가장 어렵습니다..)


블로그 이미지

[짱가™]

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


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 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발을 한다는 것, 일을 잘한다는 것.


블로그 이미지

[짱가™]

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




기존 블로그에서 가져옴 : http://blog.naver.com/knbawe/110030640122
 - 2008/05/01 작성 


말잘하는 사람보다 경청을 잘하는 사람이 되고 싶습니다.

경청

조신영, 박현찬 지음
위즈덤하우스 2007.05.02
평점

같이 읽으면 좋은 책

  

 

책이 주는 교훈보다도 스토리에 눈시울이 약간...

허허.. 이렇게 감정이입이 잘 일어나는 걸 보니 감성 소설 읽으면 펑펑 울겠군.

갈수록 감성적이 되어간다...

 

경청이 갈수록 중요하다는 것을 느껴간다.

 

얼마전부터 플래너를 다시 쓰면서 스케쥴 관리가 조금씩 변해 가는 것을 느끼고 있다.

작년 말부터 전공서적 외에 다른 책들을 읽으려고 노력하면서 삶의 자세가 조금씩 변해 가는 것을 느낀다.

올해가 되면서 새로이 세운 목표들에 ( 아쉬운 것은 업무적인 목표가 없다. 실제 내 일에서의 목표도 있어야 하는데... 아직까지 자기계발 외에는 관심이 없는 편인가 보네.. 내가.. ) 대한 도전을 시작하면서 조금씩 내가 달라지는 것을 느낀다.

집사람의 긍정적인 마음가짐과 서로간에 느끼는 공감대로 인해 마음이 편해지고 좋은 영향을 받고 있는 것을 느낀다.

아이를 바라보면서 내 마음가짐을 새롭게 한다.

 

책 "경청" 의 시작은 workHolic(?) 인 사람을 등장시키면서 시작한다.

그리고 그 주인공은 귀가 들리지 않을 것이라는 미래를 알고 자식의 악기를 자신의 손으로 만드는 것으로 이야기를 시작한다.

주인공은 원래 남의 이야기를 잘 듣지 않는 사람이었다.

자신의 주장을 내세우고 무엇보다 자신이 옳다고 믿는 그런 사람이었다.

우리는 흔히 그런 사람일 것이다.

우리가 잘 못 알고 있는 사실 중의 하나는 '내가 매우 논리적이므로 나는 다른 사람을 설득해서 내 의견에 공감이 가도록 해서 내 의사를 따르도록 해야해!' 라는 생각을 흔히 하고 있는 것이다.

주인공의 이야기를 통해 귀가 들리지 않고, 악기를 만들어가는 과정에서 다른 사람들에게서 무언가를 배우고, 새로운 스승을 만나서 경청의 중요성을 알면서 조직을 변화시키는 이야기를 통해서

우리에게 경청의 중요성을 전달하려고 한다.

 

나 역시도 항상 남의 얘기를 들으려 한다고 (스스로 노력한다고) 생각하지만,

그러지 못할 때가 많다.

얘기를 듣기보다는 듣기싫은 얘기는 자르고 내가 이야기를 정리하려고 노력하고 ,

대화의 결론을 내가 정리하고 결론내리려고 노력하는 모습을 종종 느끼고는 흠칫 놀라곤 한다.

"그 상황에서는 그럴 수 밖에 없었고 그게 가장 최선이었다" 라고 자조는 하지만,

당한 당사자가 받을 상처나, 주위의 다른 사람에게 똑똑하게 또는 깔끔하게는 보일 수 있으나,

진정으로 동의를 이끌어 낼 수는 없다고 생각이 된다.

이런 이야기 하나를 읽었다고 해서 내 습관, 내 성향이 온전히 탈바꿈을 할 수 있을 거라 생각하진 않지만, 이런 이야기들에 자주 노출됨으로써 내가 노력하게 되고 또한 습관이 되고 그게 인생이 될 수 있을 거라 생각한다.

 

"내 자신이 온전히 싫어야 변화가 생긴다" 고 말씀하셨던 구본형 님의 진의를 아직 파악 못했지만,

이렇게 조금씩 생기는 긍정적인 변화가 내가 되고자 하는 사람으로 가는 걸음들이 아닐까 싶다

블로그 이미지

[짱가™]

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

Tag 경청, 리뷰,



경청이라는 게 무엇인가?
우리가 가끔 착각하는 것 중에 하나가 경청은 그냥 말을 들어주면 된다고 생각할 수 있다.
그러나 경청이라는 것은 판단 이라는 잣대를 들이대지 않고 상대의 말에 집중해서 상대의 의도와 맥락에 대해서 충분히 공감하는 듣기... 그것이 경청인 것이다.

우리는 경청이라는 것에 대해서 충분한 훈련이 되어있지 않다.
그도 그럴 듯이 일상에서 토론을 할 때의 예를 들어보면,
상대방의 말에 반박하기 위해서 듣는 경우가 있다.
대꾸하면 길어지므로 그냥 한귀로 듣고 한귀로 흘리면서 마냥 바닥만 보고 있는 경우도 있다.
또한, 상대방의 말은 아랑곳하지 않고 독백만 하는 사람도 있다.

일상에서 많이 볼 수 있는 예들이다.

여기 경청의 수준의 예를 보면
배우자 경청
수동적 경청
적극적 경청
맥락적 경청으로 나뉘는 데...

우리는 일을 할 때, 자신의 특별한 관심사가 아닐 경우는 거의 수동적 경청을 하게 된다.

그럼 이제 본론으로 ...
개발업을 가진 우리 개발자의 세계를 예로 들어보자.

우리는 직업적 특성상 자신의 지식으로 인해서 소통이 방해가 되는 경우가 많다.

엔지니어라는 특성상, 내가 느끼는 가장 많이 보는 스타일들을 분류해본다.
1. 자신의 지식세계를 펼치느라 정신없는 스타일
2. 자신의 의견에 반하는 의견을 제시하는 사람이 있다면 자신을 공격하는 걸로 단정짓고 투사로 변하는 스타일
3. 남이 무슨 말을 하든 듣는 척은 할지라도 속으로는 자신의 의견이 옳다고 생각하고 돌아서면 자신의 생각대로만 추진하는 스타일
4. 자신이 아는 것이 많아서 주위 사람들을 항상 가르치려는 스타일
5. 모든 것의 시작과 끝을 자신이 주도해야 직성이 풀리는 스타일
6. 지식이 좀 떨어진다고 판단이 되면 그때부터는 상대방을 무시하는 스타일
7. 자신이 아는 것이 적다고 생각해서 의견을 말하지 않는 스타일
8. 무시받을 것이 걱정되어서 소통을 하지 않는 스타일
9. 경력에 대한 부풀림으로 인해 속으로 끙끙 앓고 있는 벙어리 스타일
10. 자신이 모르는 것이 무엇인지 몰라서 소통을 못하는 스타일 

등등을 보았다.

위에서 말하지 않은 스타일 중에 엔지니어 출신이 아니더라도 작업시에 흔히 볼 수 있는 스타일들을 분류해본다.
1. 자신이 아는 것이 없기 때문에 타인(엔지니어)에게 무조건 답을 내 놓으라고 요구하는 스타일
2. ....... 
너무 일반적인 사항이라 ... 기술하기가 쉽지 않다.

하고 싶은 이야기는 엔지니어의 성향상 "경청"에 대해서 이해하지 못한다는 것이다.
왜 이런 가정을 내리고 접근하게 된걸까?
경청이라는 것은 이전의 포스트에서도 말을 했듯이 먼저 상대방의 신발을 신고 걸어봐야 한다. 즉, 공감을 바탕으로 맥락적 경청까지는 안되더라도 적극적으로 경청을 해야 하는데... 

우리들은 흔히 상대방의 얘기를 경청하기 보다 자신의 논리를 펴는데에 바쁘다.
내가 똑똑하게 보여야 하기 때문이다.
자신의 지식을 믿기 때문이다.
엔지니어라는 직업의 특성상 기술적인 부분, 지식적입 부분에서 밀리면 큰일이기 때문이다.
나 자신도 가끔 토론이나 토의에서 스트레스를 받을 때가 있다. 
또한, 논쟁에서도 그러할 때가 있다.
나 역시도 항상 이런 성향사이에서 고민한다.
어떤 형태로 자신을 PR 해야 하고 의견교환하고 논쟁을 해야 하는지는 우리나라 교육에 젖어왔던 우리 문화에 젖어 왔던 나로서는 답을 내리기 힘들다. 
훈련과 고민을 통해서 풀어야 할 문제라고 생각을 하고 있다.

다만, 그런 것이 어떻게 결론이 내려진다 해도 상대방의 얘기를 온전히 상대방의 생각으로 듣는다는 것은 정말 중요하다.
"상대방의 신발을 신고 걸어보라"
"상대방의 안경을 쓰고 세상을 바라보라"
라는 말이 있듯이,,, 
적극적으로 경청하고 말하는 사람을 존중하며 그 사람이 이야기 하고 싶은 맥락을 이해하는 것이 진정한 경청의 자세라고 생각이 된다.

경청.... 아무리 강조해도 지나치지 않는 이야기이다.




-- 관련글 -- 

블로그 이미지

[짱가™]

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

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

 

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

이제는 정말 자신이 하고 싶었던 일을 하기 위해서 기존에 자신이 계속 공부해왔던 자바 기반의 프로젝트에 투입되게 된다. 여기는 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 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발자와 커뮤니케이션 글쓰기의 시작

블로그 이미지

[짱가™]

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