프로그래밍 영웅과 독불장군, 이런 사람 만난 경험 있으신가요?

aw2310의 이미지

프로그래밍 영웅과 독불장군

출처 : 'Professional 소프트웨어 개발' , 스티브 맥코넬

부족한 기술 인력과, 너무 낙관적으로 일정을 잡는 일반적 성향을 더하면
어떤 일이 일어날 것 같은가? 그렇다. 이제는 일당백의 능력을 가진 프로그래밍
영웅(programming hero)을 말할 차례다.

프로그래밍 영웅은 항상 자기 능력을 시험해 볼만한 일을 선택하고,
어마어마한 코드를 써 나간다. 그런 사람은 대부분 야근을 밥먹듯 하고,
곧 프로젝트에서 절대로 빼놓을 수 없는 사람이 된다. 성공은 그들의
어깨에 달려 있는 것 같이 보인다.

프로젝트 관리자는 이 영웅 프로그래머를 사랑하지만, 두려워하기도 한다.
그들은 똑똑하지만, 성미가 까다롭고 독선적인 성격인 경우가 많다. 그러나
그들이 없는 프로젝트 수행은 상상할 수 없다.

수급 불균형 노동 시장에서 그들을 대체하는 것은 절대로 선택 사항이
아닐 것이다.

그러나 안타깝게도 엄청난 양의 코드를 뽑아내는 능력이 있는 대부분의 프로그래밍
영웅들은 다른 사람들과 같이 일하는 방법을 모른다는 치명적인 요소가 있다.
이런 사람들은 대부분의 설계 정보와 소스코드를 자기만 볼 수 있도록 숨겨놓고,
테크니컬 리뷰(technical reviews)에 참여하는 것을 거부한다. 또, 팀이 정해 놓은
표준을 따르지도 않는다. 이러한 행동들은 결국 다른 팀원들의 프로젝트에 가치있는
공헌을 할 수 있는 기회를 박탈하게 된다. 많은 프로그래밍 영웅들은 결국
전혀 영웅이 아니다. 그들은 단지 프로그래밍 독불장군일 뿐이다.

개개인의 탁월한 능력이 프로젝트 성공에 큰 영향을 미칠 수도 있지만, 일반적으로는
팀워크가 더 큰 영향을 미친다. IBM의 연구에 의하면 평균적인 프로그래머는
약 30%의 시간만 혼자 일하는 데 보내고, 나머지 시간은 팀 동료나 고객 같은 다른
사람들과 같이 일하는데 쓴다. 31건의 소프트웨어 프로젝트들을 조사한 결과, 전체
생산성에 가장 큰 영향을 미치는 요소는 바로 팀의 융합이라는 것을 알 수 있었다.
물론 개개인의 능력도 생산성 증가에 공헌하지만, 팀 융합이 더욱 큰 힘을 발휘한다.

많은 사람들이 자신의 능력을 더 높일 수 있는 도전적인 프로젝트에 참여하고 싶어한다.
그러나 자신의 한계를 테스트하려는 의지가 있고 효과적인 소프트웨어 개발 지침들을
따르며 지속적으로 동료와 협업하는 사람만이 진정한 프로그래밍 영웅이고, 프로젝트에
참여할 자격이 있다.

-------------------------------------------------------------------------------------

혹시 일하시면서 위와같은 소위 독불장군을 만나보신 적이 있나요?
저는 현재 제 직속 선임자가 바로 이런 스타일입니다.

정말로 능력은 인정할만하지만... 팀웍이라는 단어의 의미를 아는지조차
의심스러울 정도로 자기 위주로 일합니다.

가뜩이나 개발일이라는 것이 돈만 보고한다라는 것보다는 더 뭔가 자기 만족이라는 측면을
보고 힘들어도 이 길을 가는 사람들이 많을텐데.. 일뿐 아니라 사람때문에도 스트레스를 받아야한다면 정말 힘들겠지요?

요즘 저를 힘들게하고 이렇게까지해서 이 개발자로써의 길을 계속가야하느냐 하는 고민,
아니 회의까지 들게하는 문제이기도 합니다. 일이 힘들고 돈이
많이 안벌리는데, 앞으로 같이 일해야하는 사람들이 이런 부류가
많다면 암울하겠죠?

혹시 여러분들은 이런 사람을 만난 경험이 있으신가요?
이런 사람들에게는 어떻게 대처해야하셨는지요?

closeyes의 이미지

자기 소스코드도 안보여주시나요?

앙마의 이미지

Quote:

그러나
그들이 없는 프로젝트 수행은 상상할 수 없다.

이 말이 모든것을 말해 줍니다. 최대한 서로 맞춰 가면서 프로젝트를 진행하는 수 밖에요. 아무리 협업이 중요하다지만, 개인의 능력 또한 무시못합니다. 상급자이고 능력이 출중하다니 그냥 그 선임자와 최대한 맞춰 가면서 그 사람에게 배우면서 일하시기 바랍니다. -_-;(원하시는 대답을 드리지 못한 것 같군요.)

autography

인간에게는 자신의 운명을 거부할 권리가 있다.

aw2310의 이미지

소스를 안보여 줄 정도는 아닙니다. 그랬다가는 미친놈 소리 듣죠..

그 사람의 문제점은 팀원들간의 대화를 중요시하지 않습니다.

한번은 저랑 크게 말다툼했는데... 분위기 전환을 위해 마련한 회식자리에도 빠지고... 대화를 하려고해도 비협조적입니다.

자신도 인정하더군요.
자기가 좀 독단적인 면이 있다고..

뭘 물어보면 짜증내죠.. 분명히 자기만 알고
있어야하는 것이 아니라 모두와 공유해야하는
것인데도 저를 비롯한 팀원들과 정보공유를
하려고 하지 않습니다. 주로 팀장하고만 정보공유를 합니다.

팀장을 제외하고는 다른 팀원들도 쉽게 말걸거나 하지 않습니다.

하지만 프로젝트에서 차지하는 비중은 아주 큽니다.

팀장도 이 사람의 문제점을 알고 있지만...
팀장왈.. '지금 이 사람이 빠지면 어떡하느냐?'라고 말합니다.

지금까지 살면서 여러 사람 많이 만나봤지만
이렇게까지 대처하기 힘든 사람은 처음 봤습니다.

aw2310의 이미지

얼마전에 여기 BBS에서 죤 카멕이라는 사람에 대한 글을 읽었습니다.

둠시리즈를 만든 3D게임계에서 전설적인 프로그래머로써 출중한 능력을 가졌으나 독단적인 면도 있어서, 자기와 뜻이 맞지 않는다는 이유로 같이 동고동락했던 동료(존 로메오?)를 해고시켰다죠?

그리고 그는 '프로그래밍은 나 혼자로도 충분하다. 다만 각 분야에서 최고인 녀석들 한명씩만 있으면 된다'라고 말할 정도로
프로그래밍에 자신감을 갖고 있더군요.

이 존카멕이라는 사람의 이야기를 듣는 순간 저는 저의 선임자 가 떠오르더군요.

저는 대학원때 '소프트웨어공학'을 공부했습니다. 소프트웨어공학에서는
프로젝트관리라는 주제로, 팀원관리, 의사소통관리 등을 중요시 합니다.

하지만 현실세계에서는 소프트웨어공학의 이론적인 측면보다는
개인의 능력있는 한 사람이 더 중요시되고, 그에 의해 프로젝트
가 좌지우지 되는 것을 보면서 아이러니를 느낍니다.

이게 다 능력없는 사람의 넋두리일까요?

체스맨의 이미지

사실 영웅적이기 위해서는 어느정도 독단적인면은 배제할 수 없다고
생각합니다. 얼마나 조화로운가가 중요해겠죠.

해결책은 글쎄요...
경쟁해서 이기십시오.
그 사람한테 갈 일 자기한테 오도록 하면 상황은 역전될 겁니다.
그런 사람은 절대로 지기 싫어하기 때문에, 한번 상황이 기울면
가속은 엄청나죠.

그리고, 그런 사람이 나 자신은 아닐까 한번 반성도 해봅니다...
하지만, 저는 뭐 정보를 숨기거나, 물어보면 짜증내거나 절대
그러지는 않습니다. 8)

Orion Project : http://orionids.org

ㅡ,.ㅡ;;의 이미지

그사람이 말하지 않은것은 말할필요가 없는것일수도 있습니다.
그렇지 않고 타인과의 인터페이스를 정할 필요가 있음에도 말하지 않고 한다는건 상식적으로 이해가가지 않는군요.

또한 모르는것을 물어봤을때 쉽게 가르쳐주지 않는것은 프로젝트를 이끄는 분위기에 문제가 있을수 있습니다.
당사자는 가르쳐주지 않는것이 자신을 보호하는데 유리하다고 생각하고 있는것이죠.. 그러한 분위기를 이끌어버린 팀장이나 혹은 프로젝트 성격에 문제가 있죠.

또한 서로간의 개인적인프로그래밍스타일이 굳어진 상황에서는 상대의 스타일을 존중할줄알아야합니다. 상대에게 자신의스타일을 강요하거나 강요당하게 되면
그불만의 표출이 그런식으로 나타나기도 합니다.


----------------------------------------------------------------------------

theone3의 이미지

소스 열심히 보시고...
팀장한테 많이 물어보셔야 되겠네요.
팀장에게 자꾸 물어서 귀찮게 하면, 팀내 의사소통이 잘 안된다는 것을
팀장이 잘 알게 될것 같고, 어떤 조치를 취하겠지요.
제 상황이라면 위와같이 할 것 같습니다.

당신은 사랑받기 위해 태어난 사람.

비행소년의 이미지

전 팀장이 저런 스탈이라 아주 미칩니다. :evil:

코딩할때 띄어쓰기 전혀안하고, 줄 띄움도 없어 따닥따닥 붙어 있는 소스 분석 할라문, 아주 환장합니다.
ansi도 못 믿겠으니 다 만들어 써야 직성이 풀린다고 까지 합니다.

높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ

IsExist의 이미지

그런 사람과는 업무 분장만 칼같이 하면 됩니다.

인터페이스도 칼 같이 정의하고요.

그런 사람을 잘 이용할 줄 알면 참 편합니다. :-)

그리고 괜히 코딩 스타일 같은거 가지고 뭐라 하면 안되요.
될수 있으면 일의 분장을 모듈 단위가 될수 있게 하세요.

그 사람의 장점은 취하고 단점은 타산지석으로 삼으십시요.

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

LoKi의 이미지

전 그런분들을 상사로 두번 겪었습니다.. 한번은 직접 개발까지 하는 사장님이었고 한번은 순수한 s/w 엔지니어로서 여기저기서 억대연봉 터진 제 상사였습니다.(모바일쪽도 아니고 억대연봉 터지기 정말 어렵습니다)

네.. 님말대로 일을 할 당시에는 힘듭니다. 그러나 플젝 끝나고 되돌아 보면 제 경우는 얻은것이 더 많았답니다. 그리고 많은 시간이 지나서 알게 되는 것이지만 당시에 독선적이라고 느끼게 되는 부분도 그렇게 하는게 최선인데 대부분의 팀원들이 이해를 못해서 그냥 밀고 나가는 경우도 있답니다..
시간이 지나니 이해가 되더군요..

전 님이 말한 경우와 다른 경우를 지금 겪고 있습니다..
정 반대의 경우죠 개발의 능력보다 인맥을 이용하여 플젝 만드는 능력이 몇배더 좋은 사람들이 동료로 있습니다. 전 지금 독불장군이 그립습니다.. ㅡㅡ;;
플젝 시작해도 걱정입니다. 저 개발을 누가 다 할란지..

paw의 이미지

체스맨 wrote:

해결책은 글쎄요...
경쟁해서 이기십시오.
그 사람한테 갈 일 자기한테 오도록 하면 상황은 역전될 겁니다.
그런 사람은 절대로 지기 싫어하기 때문에, 한번 상황이 기울면
가속은 엄청나죠.

같은 경험이 있었습니다. 제가 능력이 있어서가 아니라 우연히 제가 아는 일이라서 독불장군한테 갔던 일이 저한테 온 적이 있고, 그걸로 인해서 회사내에서의 입지가 바뀐적이 있습니다.
결과는 -_-; 대놓고 저를 왕따시키더군요. 다른 팀원들도 독불장군이 워낙 유명한데다 장기적으로 저보다는 독불이한테 얻을게 많다는 계산인지 다들 독불한테 붙더이다. 뭐, 그런 소시민적 근성을 원망하는건 아니지만......
아무튼 윗분이 쓰신 의견은 저의 경우에는 독이되더군요.

기본적으로 "독불"이란 말에는 인성결여의 의미가 있기 때문에 "반성"이라든지 "역지사지"등을 기대한다는것이 넌센스같습니다.

24시간형 인간

체스맨의 이미지

paw wrote:
같은 경험이 있었습니다. 제가 능력이 있어서가 아니라 우연히 제가 아는 일이라서 독불장군한테 갔던 일이 저한테 온 적이 있고, 그걸로 인해서 회사내에서의 입지가 바뀐적이 있습니다.
결과는 -_-; 대놓고 저를 왕따시키더군요.

글쎄요, 페어플레이로 경쟁해서 우위를 점한 것을 대놓고 시기 질투하는 것 (물론 속으론 썩 기분 좋지 않겠죠. ) 은 너무 유아적인 발상이군요. 사람들 좀 이상하네요. :?

하지만, 그것은 초기에 겪는 진통일 뿐 그게 조금씩 쌓이면 결과는 달라질 수도 있었을 것이라 생각됩니다만... 조금 장기적으로 바라볼 필요가 있지 않을까요?

Orion Project : http://orionids.org

astronux의 이미지

그런 문제들이 의외로 많군요.
위의 문제들도 문제지만, 또 다른 문제는 '프로그래밍 영웅=> 독불장군'을 역으로 적용하는 사람들도 있더군요.
'독불장군=>프로그램영웅'으로 말이지요.
자신이 괴팍한 성격을 가진것을 알면, '천재는 모두 괴팍한 성격의 소유자이다'를 '괴팍한 성격을 가진 사람은 천재'라는 식으로 생각하는 사람들도 꽤 많더군요.

Astronomy+Linux

unipro의 이미지

IsExist wrote:
그런 사람과는 업무 분장만 칼같이 하면 됩니다.

인터페이스도 칼 같이 정의하고요.

그런 사람을 잘 이용할 줄 알면 참 편합니다. :-)

그리고 괜히 코딩 스타일 같은거 가지고 뭐라 하면 안되요.
될수 있으면 일의 분장을 모듈 단위가 될수 있게 하세요.

그 사람의 장점은 취하고 단점은 타산지석으로 삼으십시요.

이 글에 동의합니다. 덧붙여서 어디선가 읽은 글을 인용합니다.

Quote:
중요한 일에 집중하기 위해서는, 다른 사람이 할 수 있는 일은 다른 사람에게 맡긴다. 권한 위임의 진정한 목적은 자신이 할 수 없는 일을 떼어내 다른 사람에게 주는 것이 아니라, 진정으로 자기 자신에게 중요한 과업에 집중하기 위한 시간을 확보하는 것이다.

내 블로그: http://unipro.tistory.com

LispM의 이미지

그런 사람들은 대부분 경험이 부족해서 그럴 것이라고 생각합니다. 우물안 개구리죠.

아무리 잘났다고 하더라도, 더 잘난 사람이 항상 존재하기 마련입니다.

저는 다행히 그런 독불장군 스타일을 만나보지는 못했지만, 잘난 사람들은 그래도 꽤 만나보았습니다. 그 중 가장 독불장군 스타일에 가까운 사람도 위 글에서 이야기 한 내용과는 판이하게 다르지만 그중 제일 비슷해서 경험담으로 남깁니다.

예전 직장 동료였고, 미국의 유명 대학 인공지능 분야 박사학위자로, 나이는 50대 초반, 줄곳 인공지능 분야에서 거액(?)의 연봉을 받으면서 일했던 특급중에 특급 - 거의 위자드 급 - 이었습니다(방 12개 짜리 저택 사진을 보여주면서 자기 집이라고 자랑하더군요. 근데 그 큰 집에서 혼자 산답니다) 지적이고, 아는 것 많고 한데 가끔 협력이 잘 안되었답니다. 지금 돌이켜보면 자신보다 못한 사람과 일하는 것이 비효율적이고 시간 낭비라는 생각을 했던 것 같습니다.

그런 약간의 괴팍성만으로도 다른 사람들이 같이 일하기를 꺼렸습니다. (참고로, eXtreme Programming했었기 때문에 거의 항상 짝 프로그래밍 해야 했었고, 코드는 공동의 소유로 모두의 책임이며, 누구나 손댈 수 있었습니다). 결국 제가 그와 가장 많이 일하게 되었는데, 처음에는 상당히 힘들었지만, 한 두번 그가 해결하지 못한 일을 제가 해결함으로써 마음을 열더군요.

이 같은 문제가 있을 때 생각할 수 있는 두가지 방법은 문제 자체를 회피하는 것과 적극적으로 해결하는 것이 있습니다. 첫번째 방법에 대해서는 이미 앞에서 언급이 많이 된 듯 하니 생략합니다. 두번째 방법은 XP같은 방법으로 아예 함께 일하면서 벽을 허무는 것입니다.
만일 거부감이 심하면, 회사외부에서 상대적으로 실력이 좋은 사람(협동심과 경험도 있어야 겠죠)에게 의뢰해서 독불장군과 단기간 같이 일하게 하고, 스스로 깨닫게 하는 방법도 있습니다.

회사입장에서는 독불장군은 득보다 실이 많기 때문에 경영진에도 이같은 문제를 파악하고 해결하는 것이 필요합니다.

우연히 오늘아침 주성엔지니어링의 황철주 대표의 강연을 듣게 되었는데, 그 회사는 인재를 가장 중요하게 생각하지만 그 인재에 의존하지 않는 회사가 되려고 노력하는 것을 알게되었습니다. 제 나름대로 해석하자면, '인재 집단에 의존하고 개인에게는 의존하지 않는 회사' 라고나 할까요? 실제로 제가 인도의 어떤 CMM Level 5 회사에 근무했을 당시 그 회사가 그와 비슷했었거든요.

아뭏든, 본인이 독불장군이라면 아직 우물을 벗어나지 못한 개구리를 생각하면서 촌티를 벗으셔야 겠고, 독불장군에게 시달리고 계시다면 적절한 해결책을 찾아 내셔야 할 것입니다(경영진과도 상의해 보세요. 제대로 된 회사라면 경영진에서 그런 일 해결해 줘야 합니다)

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

익명 사용자의 이미지

CMM Level5 라.. 과연 울나라에 Level 5의 회사가 있을까요? 대부분의 벤처는 레벨 1이나 2도 차마 못되고 삼성SDS는 레벨3인가로 알고있는데.. 헐..

kihlle의 이미지

포스데이타는 전부문 4이상이고, 삼성엘쥐 등등 다 Level3~5까지입니다.

homeless

LispM의 이미지

kihlle wrote:
포스데이타는 전부문 4이상이고, 삼성엘쥐 등등 다 Level3~5까지입니다.

히히 글타래가 곁길로 새는 군요.

국내에서 그간 알아본 내용을 간략히 소개해 보죠.

CMM 레벨은 국내에서는 크게 상관이 없는 듯 합니다. CMM 스펙만 맞으면 되는 것으로 생각하는지 정확히 "노가다"로 그 스펙을 맞춘 경우가 대부분 인 것으로 알고 있습니다.

제가 잠시 있었던 인도 회사는 그런 면에서는 '양질의 소프트웨어 개발을 위해 여러가지 활동을 하다보니 자연스럽게 CMM 스펙을 맞추었다'고 하는 편이 옳을 것 같습니다. 일례로 개발자 아무나 언제든 한달정도 휴가가도 프로젝트에 끼치는 영향은 미미했고, 팀내 총 인원 15명 정도, senior급 7명 정도에서 senior급 2명정도가 동시에 빠져나가도 그 충격을 최소화하고 프로젝트를 빠른 시간에 다시 궤도에 올려놓았습니다.

그런 점에서 CMM 레벨은 회사의 능력을 평가하는 한 방법은 될수있지만, 전부는 아닐 것입니다. 실제적인 평가는 회사 내부가 어떻게 돌아가느냐에 달려있으며, 이것이야 말로 CMM 레벨보다도 훨씬 더 중요하다는 의견입니다.

다시 원래 글타래로 돌아와서...

결국 독불장군을 제거할 수 있는 회사라면 회사의 능력이 그만큼 뛰어난 것입니다.

하루하루 잠자리에 들기전에 내일은 회사에서 어떤 일을 해야 할까 가슴 설레며 잠들어 본 경험이 있는 사람은 복받은 사람임에 틀림없지만, 회사나 그 경영진은 회사의 구성원들이 그런 경험을 해볼 수 있도록 최소한의 노력을 해야 한다는 것이 제 생각입니다. 독불장군은 팀내에서 모두가 이기는 방법으로 자연스럽게 제거하는 것이 최선이지만, 이런 시도가 실패하면 경영진에서 극약처방을 내리는 것이 장기적인 안목에서 회사 전체에 득이 된다는 의견입니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

atie의 이미지

팀장이 팀을 제대로 이끌지 못하는 것을 aw2310님이 마음 고생하시는 것으로 보이는 군요.
지금 상황에서는 팀장에게 "모든 팀원은 테크니컬 스펙을 수시로 꾸준히 업데이트하자"라고 건의해서 최대한 사수의 참여를 이끌어내는 것이 한가지 방법일 수 있다는 생각입니다. (프로젝트가 끝난 후에도 그 사람이 없으면 곤란한 지경이 되지 않도록 최대한 업데이트 되어야겠죠.)

ps. 항상 내 마음같은 사람하고만 일할 수는 없겠죠. 그러녀니 하고 스트레스 받는 것을 줄이십시요. 같이 치고 받으면 똑같은 nom 취급 받습니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

buffmail의 이미지

Unipro wrote:
어디선가 읽은 글을 인용합니다.

Quote:
중요한 일에 집중하기 위해서는, 다른 사람이 할 수 있는 일은 다른 사람에게 맡긴다. 권한 위임의 진정한 목적은 자신이 할 수 없는 일을 떼어내 다른 사람에게 주는 것이 아니라, 진정으로 자기 자신에게 중요한 과업에 집중하기 위한 시간을 확보하는 것이다.

여담이지만, 경영학의 대가 피터 드러커의 책에 나온 말이네요 :)

익명 사용자의 이미지

실력이 있다니 '천국' 아닙니까?

실력도 없으면 도대체 어떻게 처리해야합니까...

익명 사용자의 이미지

헐 인터페이스 부분 정해놓고 파트 정해놓고 시작 안 하나요?

프로젝트 시작하면서 파트 정한다 말인가요? 프로젝트 하면서 파트 정하면 말 다한거 아닌가...

exilan의 이미지

저희 회사는 확실히 일부 부서는 CMM level5에 맞춰 일을 잘하고 있고, 대부분 level 4를 맞추려 노력하고 있습니다만, 이 글타래와 관계가 깊을 지는 잘 모르겠습니다.

아무튼, 그리 경험이 길진 않습니다만 그래도 생각하건데 똑똑한 개발자 한 명 보다는 보통 개발자 세 명이 의논하고 결정한 일이 탈이 덜 났었더라고 기억됩니다만.

경영진에서 어느 정도 나서서 해결해야될 일 같군요.

동지여, 우리가 있다!

albertyun의 이미지

최악의 경우는 실력도 없는데
짭밥만으로..................독불장군(?)인
경우 입니다... :oops:

Think..

익명 사용자의 이미지

인도 WIPRO 문서를 본적이 있는데, 대단히 대단히 훌륭합니다.
Week단위로 문서들을 나누어놨는데, 정말 모르는 사람도 문서만 보고 프로젝트를 이해하고 진행이 가능한 정도로 만들어놨습니다.

허다한 프로젝트의 문서들을 봐왔지만, 참 거시기하다는 느낌만 받아왔는데,
그 사람들 문서는 정말 눈에 확들어오더군요. ( 영어인데도 불구하고 말입니다... )

하지만 포인트는 인도사람들 대단하다는 것보다는 문서에 대한 그들의 문화와 관점이라고 생각됩니다. 문서는 그냥 "문서"일 뿐이 아니라, 일을 하기 위해서 반드시 필요한 그 "무엇"이라고 보는 관점말이죠.

alsong의 이미지

Quote:
정말로 능력은 인정할만하지만... 팀웍이라는 단어의 의미를 아는지조차 의심스러울 정도로 자기 위주로 일합니다.

둘다 갖추면 금상첨화겠지만 능력있는사람이 훨씬 좋은겁니다.
능력 없는사람과 일하면 독불장군이 좋다는걸 느낄겁니다.

업무적인 내용이 아닌 기술적인 부분에 한에서는
스스로 알아나가는 수 밖에 없습니다. 적어도 소스를 보고 이 특정부분에서 자신의 의견을 밝히고 그에 대한 답(맞습니다., 또는 그렇지 않습니다. 10에 9정도는 맞습니다. 라는 답이 나오도록....)을 얻으려고 해야지 그냥 어떻거냐고 물을때는 위와 같은 사람은 대답을 잘 안해줍니다.
위와 같이 질문을하면 대하는 태도가 약간은 달라지기 시작할수도 있을겁니다.

의외로 문서에 작성돼어 있거나 이미 언급한 내용을 다시 묻는 경우도 많습니다.
문서에 다 적어 놓았는데 물을 경우는 대략 난감합니다. 한두번정도는 괜찮치만... 문서에 대한 인지 못했을수 있으니까요.. 몇번넘어가면 대략 난감합니다.

그나저나 백수 언제 탈출하냐... ㅡㅡ; 배고파라.

frowt의 이미지

제가 좀 독불장군식인데요
어쩔수가 없네요..
개발인력은 모자르고 할일은 많고 위에서는 많은걸 바라고..
국내 업체들의 공통사항이 아닐련지요..
그 상황에서 릴렉스 하게 하느냐 타이트 하게 하느냐 차이인것 같군요..
밑에사람에게 소스는 보여줘도 설명은 에지간해서는 안해줍니다.
정보공유는 물론 좋지만.
북한퍼주기처럼 일방적으로 주는거는 싫어요..
혹시 위에 글쓰신분들중에 받는거만 생각하시는건 아닌지요..

익명 사용자의 이미지

frowt wrote:

북한퍼주기처럼 일방적으로 주는거는 싫어요..
혹시 위에 글쓰신분들중에 받는거만 생각하시는건 아닌지요..

동의합니다 회사를 학원으로 아는 사람들이 몇명 있죠.

PSI의 이미지

제가 있는 곳은 개발 분야는 아니지만.., 토론과 같은 내용이 어느 곳에서나 존재하는 주제 같습니다.

저희 매니저도 주제와 관련 있는 그럽 타입의 사람이죠. 저희쪽의 독단은 애매한 문제의 발생시에, 여러 의견을 수렴하고 종합하여 결론을 이끌어 내는게 매니저라고 생각되어 지는데, 이 분이 또 그렇지는 않거든요. 자신의 의견을 한 번 내놓으면 그 의견에 반하는 의견들에 대해 서로 수렴을 하지 않고, 반하는 의견에 대해 무효화 시킬 수 있는 기술 자료를 찾아 제시합니다. 안타깝죠.

의견 대립으로 인해 술자리에서 한 번 싸운적이 있는데, 전말은 이렇습니다.
처음 매니저와 저는 A라는 주제에 대해 이야기를 하다, 회식중인 전직원이 끼어드는 사태가 발생합니다. 그 다음으로 이야기가 엄청나게 삐딱선을 타면서, 삼천포로 빠져 버립니다. 나중에 되니까, 말하는 것 자체가 귀찬아 지더군요.

주제와는 다른 내용이지만, 사회 생활에서 자신의 의견을 떳떳히 밝히고 밀어 붙이는게 이렇게 힘든 줄 몰랐습니다. 사회 초년생이라 충격적으로 느껴지는 것 같지만, 앞으로도 더욱 많은 일이 생길 것 같아 인간 관계가 두렵군요..,

이상, 무슨 말인지 알아 듣지 못할 정도의 넉두리 였습니다.

앞으로 한 걸음..., 뒤로 두 걸음.., 일상에의 고찰..

mudori의 이미지

그냥 노세요..