아, 공동작업은 왜이리 힘든지..
글쓴이: snowavalanch / 작성시간: 목, 2004/04/08 - 7:35오후
공동작업 할 때마다 느끼는 거지만, 환장할 경우가 많습니다.
그래도 성질 많이 죽였는데, 같이 일하다 보면 화이바가 히꺼덕...하는 느낌이 드는 경우가 있습니다.
자세한 내막을 적어 하소연하고 싶은 마음이 꿀떡같은데, 괜히 여기 적었다가 당사자가 볼까봐 자세한 내막도 못 적고...
개발자간의 고집이란...
필요악인 듯......
서로간에 고집 피우다간 죽도 밥도 안 되니, 맘 약한 놈이 죽어야지....
아... 내가 성질이 드러운건지....
얼굴이나 이쁘면 귀여워나 해 줄텐데... 항상 표정은 맹한 표정이고...
으.... 내명에 살 수나 있을꺼나?
Forums:
-_-; 정확한 이유와 근거를 두고 주장하신다면 상대방도 이해하실 수 있
-_-; 정확한 이유와 근거를 두고 주장하신다면 상대방도 이해하실 수 있으실 것 같은데요.
여자이기 이전에 인간아닙니까?
인간적으로 서로 절충하시죠. -_-;;;
설득을.. :-)
엔지니어간에 보면 서로 설득하는 모습을 보기는 힘든 것 같습니다.
내가 맞네. 니가 맞네. 언성 높이는 모습은 많이 봤지만요.
자신이 보기에 B보단 A방법이 더 좋은데, 동료가 B를 고집한다면.
A가 더 좋은 이유를 얘기하시고 설득하는 것이 좋다고 생각됩니다.
말이야 쉽지만, 설득한다는 것. 힘들지요. 상대방이 이해못한다고 언성을 높이거나 한심하게 보는 일이 없어야 하고. 기본 Base부터 얘기해야 하는 경우가 많죠. :-)
그렇지만, 엔지니어에게 필요한 능력중의 하나도 "설득력"이라고 생각되고 두루두루 써먹을 수 있을거라 생각합니다.
연봉 협상때도... :-)
[니 칼은 니가 갈아라]
Re: 설득을.. :-)
공감...합니다.(울먹)
특히 "연봉협상때도... :-)" <-- Great!!
내가 왜 이 일을 하고 있으며 이 일이 어떤 과정중에 있다. 그리고 앞으로 이런식으로 간다는걸 상대방에게 납득시키는게 그렇게 말만큼 쉬운 일이 아니더군요.
http://redage.net
상대방이 꼭 그렇게 해야겠다고 우기는 경우에는 그냥 그렇게 해 주면 됩니
상대방이 꼭 그렇게 해야겠다고 우기는 경우에는 그냥 그렇게 해 주면 됩니다.
사실 이긴 쪽의 단점과 진쪽의 장점은 부각되기 마련이라, 지는 것이 이기는
것이라는 것이 정말 딱 들어맞습니다.
그리고, 아무리 당시에 자신이 완전히 옳다고 생각하는 주장이라도, 시간이 좀
지나보면 상대방의 주장에도 나름대로 장점이 있다는 생각에 부끄러워지는
경우는 공동작업하다가 의견 충돌이 있어본 분이라면 웬만큼은 경험해
보셨으리라 생각됩니다. 사실 저도 의견 대립이 있을 때, 제 뜻대로 하자고
우기다가, 상대방 아이디어에도 좋은 점이 많았다는 것을 깨닫고는 고민에
휩싸였던 적이 많습니다. :oops:
우선은 감정을 삭히시고, 일단은 시간에 맡기고 상대방의 의견에 맞게
전적으로 추진해보세요. 그 의견이 잘못됐다고 생각되면 얼른 방향을
틀어야 하니까, 최대한 협력해 주는 것이 중요합니다. 그 후에는 빚을
한 번 졌으니 상대방도 서로 의견을 존중할 것입니다.
물론 이런 절충은 일반인이라면 거의 모두에게 적용되는 방법이겠지만, 가끔
적용이 안 되는 경우가 있을 수도 있습니다. 그래도, 인류 역사나 사상/종교적 신념에
치명적인 영향이 있는 것만 아니라면, 자기가 가급적이면 양보 해야 합니다.
같이 맞서면 똑같은 사람이 되니까요.. 자꾸 화내면 오래 못 삽니다. :)
가늘고 길게~~
You need Python
그러면서 서로 발전해나가는거 아니겠습니까? :wink:
그러면서 서로 발전해나가는거 아니겠습니까? :wink:
^^
저의 연구실 같은경우에는 세미나를 통하여 해결합니다.
그 방법을 말씀 드리겠습니다.
일단 발표하는 사람(주장하는 사람이겠죠)을 제외한 나머지 사람은
그 분야에 대해서 머리속을 초기화 시킵니다. (즉, 그분야에 대해 아는것이 별로 없는것이 되는겁니다.)
그리고 발표하는 사람은 그 주장하는 내용에 대한
아주 기본적이 내용을 말합니다.
(여기서 내용이란 특성이 아닙니다.
X의 장점은 ..... 단점은 ...... <- 이런게 아닙니다.
X란 무엇이다. <- 이것이죠.)
그럼 이제 시작합니다.
발표하는사람의 내용을 듣고 질문을 하며 서로 보완해 나갑니다.
왜 그것이 나왔는지, 기존의 것과는 무엇이 다른지,
어떤것이 좋고, 어떤것이 나쁜지
어느때에 좋고 어느때에 나쁜지...
신기하게도, 아무것도 모르는 상태에서
X란 무엇이다 라는 명제를 얻었을때, 아이와 같은 질문을 많이 하게 되죠
그렇게 함으로써 발표자는 자신의 주장을 한번도 정리하게 되며
참가하는 사람 모두 이해할수 있게 되죠. 왜 그것을 쓰는지...
시간과 노력이 필요하지만,
서로 열린 마음으로 이야기 할수있다면 정말 팀웍만큼은 좋아 질겁니다^^
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
그럴때 일수록 정론으로 해결하는게 가장 좋을듯 하네요.어차피 같은 팀
그럴때 일수록 정론으로 해결하는게 가장 좋을듯 하네요.
어차피 같은 팀원이면 계속 같이 일을 해야 할텐데 억압적으로 하거나 자신의 고집을 계속 부리기 보다는...
차근차근 설명을 하고 토론을 통해서 방법을 찾아야 할듯 합니다...
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
저도 얼마전 디자이너와 한바탕 소동이 있었습니다만..따로 음료수
저도 얼마전 디자이너와 한바탕 소동이 있었습니다만..
따로 음료수 한잔 마시면서 차근차근 얘기해 보니 해결되더군요..
특히 중요한 차이점은 어떤 일에 대해 보는 입장이 많이 다르다는 것이었습니다.
제가 원한건 어떤 스크립트 체계와 툴을 제공해 줄테니 거기에 들어가는 값들은 원하는대로 예쁘게 디자인하면 됩니다 였는데..
디자이너분은 그 체계까지 다 만들고 정하라는 것으로 알아들었더군요..
그래서 왜 내가 그걸해야하냐고 그러고..
직접 그리는 입장이니까 자신이 그린 좌표는 알꺼 아니냐 당연히 해야지 이러다가
서로 감정만 상하게 되고..
디자이너 분들은 아무래도 추상적으로 두리뭉실 개념 잡는 경향들이 계시더군요..
그리고 자신이 생각할 때 가장 아름다운 결과를 내는 쪽으로 하고 싶어하구요..
그리고 프로그램 설계에 참고하게 완성화면을 스케치 해달라고 하면 몇날 며칠을 노력해서 아주 예쁜 미리보기를 만들어 주시더군요..
(그냥 펜으로 스케치만 해달랬더니.. 삐질..)
본인 게임화면은 크고 상대 게임화면은 작게 출력되니까 큰것과 작은것 두쌍이 필요할 것같다고 했을때..
그럼 플래쉬나 벡터이미지로 한번만 그리면 되지 않느냐 했을 때 등줄기로 흐르던 한줄기 땀이란..
물론 그걸 납득시키고 나서 지금은 간혹 "앞으로 플래시 얘긴 하지 말아 주세요 ㅡㅡ;"하고 농담거리만 됩니다만..
서로 생각하는 바가 많이 다르다는 것을 이해하는 것이 제일 어려운 것같습니다.
요즘 제가 주로 하는 방법이란 제가 먼저 생각을 해두고 먼저 일방적으로 얘기하지 않고 여럿에게 의견을 먼저 듣습니다.
듣다보면 아 이게 더 낫겠군 싶으면 생각한바를 약간씩 고치고 나중에 정리해서 결정하고 다시 알려주는 방법으로..
참. 의견을 나눌 때는 무언가를 먹으면서 하면 효과가 좋습니다.. ㅎㅎ
ㅡ_ㅡ;